This is why you abstract your game code from your renderer and focus on portable design in the first place, a mistake I've learned the hard way,. In other words, your game should be able to run in text only before you focus on visuals. Another reason that it's dystopic that we have a game design world that's so visual focused first. : / It's critical, I see this now, that you don't become at all dependent on their art tools, better to use external GIMP, Blender, and your own simple editor tools, of whom you can download their source or their install files and keep them in your project folders at all times as well. If a company goes public at any time, you also don't use that tool.
@lowlevelgamedev9330 So true, because Even though over the years I read people making that point it went in one ear out the next and the tutorials are mostly about entabgling your code into an editor and it's tools
So games like Quake, Unreal etc. should've focused on making their game in text-only mode before making them visual? That makes no sense. It highly depends on what kind of game you're trying to make and why you make it. Some of the early games that still inspire a ton of games today, both at a game mechanic level, as well as a technical one, purely started _because_ of visuals; making rendering faster and more detailed. Others, like Half-Life were purely story-driven for the get-go and visuals were the first things they came up with to have a direction. Without a direction you start focusing on the wrong things for the wrong reasons. Use whatever tools you're comfortable with. Build something whatever and however you like and think about things. Get things done quick, first. Get a concept down, and iterate. Don't bow down to "use open source software, just because I think it's better" rhetorics. You'll never finish anything if you try to abstract and optimize every small detail. Often those are so insignificant that it's not even part of your initial goal, and it stops you from progressing when you get stuck in a rabbit hole.
@@deallocI didn't mean design a game without drawing out concept artwork and testing a custom made renderer and having art assets, I meant that you work with a data first mindset as an engineer, and separate your actual game code, classes, structs, etc... from the renderer. When using Unity you're using their own GameObject class for example, and that class isn't even serializable. You're coaxed into using their animator, and when these individuals or companies are designing game, they're taught to intertwine their coding into the art toole. If your tooling gets entangled into Unity's inspector system, for example, you don't have a portable game, so if the renderer changes, upgrades, or switches, you have a game you can't hook up to any renderer or toolset. I'm only talking about if you write input functions for example, you write 'aButton()' or something then the engine code goes inside of YOUR functions/methods, so that you can change the 'UnityEngine.JoystickWhatever.interface.yaddahyaddah.buttonPressedIn(UnityEngine.KeyCode.A) or whatever you do in that engine later in an easy manner. Instead, for example, you're encouraged to use their callbacks. In Unity they even have a template in where it creates a script for you inherited from Monobehaviour, but it's nicer to start without Monobehaviour scripts, then have a single Monobehaviour as an entry point and a renderer update method. The same goes for any renderer or engine, you can have a single entry point from the renderer and then an update method from your own framework and then have your framework generate everything you need and push all the buttons so to speak. Then later on, your framework is easily portable to any language or any engine/renderer.
@@astrahcat1212Unity (and Unreal aswell) provides APIs and tools that are well integrated with each other, both for ease of use, but also more importantly for optimization purposes for general use-cases. Abstractions can result in hurting performance for little to no benefits, as it can easily make your codebase harder to reason about if you don't understand why you need to abstract something in the first place. So from a technical point of view, you shouldn't prematurely abstract things unless you know the problem space first. Again, choose the tools that makes sense for your use-case, and don't sweat the details of how "portable" your code is to another engine, especially at early stages of development. These are things you can sort out later when you have a better idea of the problems you're trying to solve and your end goal.
Regarding some of these points, especially regarding Godot. Once you start a game, you typically choose a version of the engine for the game, and you do not update it during development. This means if a feature is removed, you'll still have it, because you already decided on a version of the engine that suits your needs. Many Unity games feel the same because developers choose not to dig into their movement physics. Scripting offers a massive amount of customization on its own, and if you really don't like their built in assistance, you can work directly with coordinates, and implement your own physics systems within the engine. Doing this allows you to retain many of the advantages the engine offers without losing your control. Godot is also open source, so if you'd like, you could pick the version that best suits your needs, and alter the engine for any low level changes necessary. This would be a bigger investment, as you need to intimately understand a system that large to effectively change it, so there would be some cost benefit to look at for any particular use case. For the minecraft example, I do not believe there is any engine in use that would restrict you from optimizing what you load in your game with chunking. Engines offer a lot of tools to assist, like dynamically rendering based on what you see out of the box if you want those options, but they're not necessary. That said, if you want a deep understanding of how all these systems work, making a game from scratch is definitely a great way to learn. I'd gently push people in that direction just so they better understand the systems at work, even if I don't think it's the most efficient way to make the vast majority of games.
Making my own games from scratch is such an incredible experience, I'd recommend it to anyone interested just to learn how some of this stuff works. It's a lot of fun. I don't like engines because of the lack of control. When you CAN have control you have to, like you said, intimately understand the engine to start making changes. I also think the recent Unity debacle is a good reminder why the people who own these engines aren't your friends.
@@mbg4681 That's like saying you have complete control over your Linux distro because it is open source, yes in theory but in practice that's BS. Godot is 1M+ lines of code without considering third party stuff. With a project that big, you're tied to their design decisions. You could change bits of code here and there, sure, but mainly you're going to extend it by writing custom plugins. That's not complete control.
@@tzimmermann >> That's like saying you have complete control over your Linux distro because it is open source, yes in theory but in practice that's BS. You're staying that as if it's an absolute. Same could be said about anything higher-level than Assembly.
@@mbg4681 Wait till you learn about speculative and out-of-order execution, and you won't even mention assembly as a level you have "complete control" over. Thus, control as a concept in computer science does not even make sense and we're talking about something that does not exist. Or, I'm more nuanced than that.
Making a game from scratch is way easier than people think, I was watching a video by someone discouraging people from making their own engine, this person had no idea what making your own engine even involves and thought that you need to specify the individual position of each triangle you want to draw. The person had no idea what he was talking about but was so confident that you shouldnt make your own engine
@@lowlevelgamedev9330 I created a Virtual Tabletop using Truevision for the 3d rendering, everything else was just me doing it. Turned out pretty great, including creating a server, chat, and card system. However, the 3d rending tool I used DIED. :( These days it might be easier to do and I'm really thinking of rolling my own for the next game, just because all this Unity nonsense.
@@lowlevelgamedev9330I don't know anything about programming and game development, but I really wanted to learn how to create games from scratch (without an engine). What should I do?
That guy probably doesn't anything about basic calculus and physics (kinematics). I don't believe 3d is any harder honestly; just gotta learn linear algebra where matrices are involved, which I hear is not too hard.
@@redrevyol To be fair, I have experienced it and as a non-artist person I couldn't think of any way of modelling aside from specifying the exact position of each Vertice of each triangle and also didn't think of making a system where you make a list of vertices then simply connect them with triangles, so I actually did end up in that exact situation myself. Regardless of knowledge of calculus and physics, linear algebra doesn't really help with modelling but the engine itself would definitely be benefitted from it.
I never really enjoyed using game engines because it tends to demand the dev to work in a very specific way, and, like you said, if the engine has a bug you can't do anything but hope to it be fixed eventually. After I shipped my first big game I began learning opengl, followed by writing my own game library, and it is going pretty well. I think I prefer keeping it as just a library and not an engine to mantain a high level of flexebility and optimization potential.
this is EXACTLY why I dislike game engines - I hate having routines and formats and "the way to do things" forced onto me. I gladly take on the extra upfront work of writing the engine if it means I can work with the tools that I designed and a framework that is comfortable for me.
in my opinion it really depends on how many and how complex systems you need for your game, and also, how many of those are not offered out of the box by godot or unreal. those are engines that you can customize and modify all day long as you have access to the source code. of course, the big disadvantage is that now you not only need to know how to make your custom system, but you also have to know how to integrate it into the engine of your choice. the tradeoff here is obvious: either you study a game engine's internal workings, or you make your own from ground up. the thing is tho, unless you make some really whacky game that flips everything on it's head (yeah, minecraft was kinda like that, and space engineers too), you will probably be able to use most of a ready made game engine's systems out of the box, and make/modify the rest yourself quicker and easier than making the whole thing from ground up. either way you will gain knowledge and skills, and have a game ready at the end of the day (or decade)
I wish the world would stop calling "Game Engine" to Unity, UE, Godot, etc, because they're actually more than that, and I think that's why there's some confusion about what game engines are. When you mention "making your won engine", many people think that means creating something like Unity. We ought to call them Game Development Kits, or Game Development Environments, or something like that, because that's really what they are.
Or even saying "I wanna make my own game, from scratch not using an already existing engine". Because people are not really making a new full-featured engine, just the underlying basic functions needed for your game idea. When one says "I am doing my own game from scratch", the response is "Are you crazy? You are going to build a whole new engine on your own?". They already assume that if you don't use Unity, Unreal or any other ready made solution, you are planning to code the big monolith that these engines are.
With no game engine experience at all, i'm learning Godot. My level of knowledge is piss poor but i've still managed to create a very basic top-down tile-mapped 2D game world with an animated character and enemies. I really don't know what the fuck i'm doing, but i'm slowly learning it. The main hurdle for me is simply all of the different Functions and Signals you can call in different scripts. Not really knowing how to use them, and yet there are so many of them, is the most intimidating part for me. For people with experience in Unity, i hear that a lot of functions are direct parallels. I'm eager to really get over my hurdle and obtain a bare minimum level of competence in GDScript so that i can be much more efficient. So far though, i'm really excited with what i have picked up so far! It's a fun experience, in spite of the difficulties of learning everything from the very basics with no past experience.
What I like about Godot is that, given that one has enough understanding of the engine itself, it can just be modified to suit the specific requirements of the game. IIRC Sonic Colors was made using a modified version of Godot. But since that kind of thing doesn't seem to be common practice, I have really no idea how well that'd really work in the end.
Something important I learned after making a lot of C++ projects over the years, create external libraries/dlls and never create an app with everything in a single executable (except for really short project) ! It makes your project become messy and if you want to reuse some of the code you made in an other project, you will need to copy manually the stuff you made, instead of just reusing the standalone dlls you made for ! As an example I worked on multiples modding projects on various games, I always add something structured like that at the end: (this was for a multiplayer project) [Client Project] - YourProjectName-Client.exe - WebProcess.dll - ScriptingAPI.dll - DiscordRPC.dll - NetCommon.dll - Shared.dll [Server Project] - YourProjectName-Server.exe - NetCommon.dll - Shared.dll I was used for a long time to only compile everything in a single .exe file, for tiny project it's okay, but when your project become bigger: structure your project, do not rush, take time to debug and clean your code, it will prevent you from restarting your entire project from scratch lol.
Pointless work ahead of time lmao. If you need to copy a part of your project for another one, then extract code into library there and then, in the long run you will save a lot of time... ... because you won't be reusing code and it's all a cope to try and futureproof things you will never do.
@@shinobuoshino5066 Proof you never worked on huge project to say that, first of all in the example I choose, I had a client and a server, and in multiplayer client and server are sharing the same API, meaning copying over the code from client to server multiples times is literally time lost lol. Having a standalone "networking.dll" you use in both client and server, and then use the API in both project IS a time saver. And yes I also use a lot of other standalone DLL I made for in other projects too.
@@sweettea-hv1ls Prone to error, and generally you're not designing source file to work as a standalone, generally you have some external logics coming from other parts of your code, meaning if you want to copy over this specific file, you will need to remove the extra you added from other part of your code or add them aswell. Trust me, creating standalone DLL/LIB for different projects is a HUGE time saver on the long run.
Just Design All The Parts. Includes Objects’s Physics, Materials, Transparency, Music-Maker or Audio-Maker, Graphics like Render/Modelling or Animation, UI, 2D Objects in 3D Toolbox/Images Facing Camera (BillBoard), Camera Moving, Menu Settings, Entity-Component-System, Player/Enemy Component and Language to Do Programming for Game Function or Mechanics
@@rytif If he means design an audio stream handler, then sure that seems normal. If he means make a midi editor to make your audio however... That's like saying you need to build your own Blender for 3D objects and rigging. Not commenting on the rest
Currently I'm working on a game in C# MonoGame (moved from Unity that I started with). Maybe next project I will start from scratch and will try to learn C++.
Brand new to the game dev thing. Been learning the low level aspects of it via Pygame. Have a few arcade games under my belt, and I'm in the process of building my own level editor to use in the creation of my first platformer! I have been avoiding using tools made by others, because I'd rather learn the inner workings and systems myself. Once I have a better grasp on things down the line, it'll be time to learn Rust, and start transferring the tools I've made over to that! +1 sub, love your content.
It’s great to implement things for your own understanding, but don’t fall into the ’using tools made by others is cheating’ trap (not accusing you of saying this), because if you are using Pygame, you are already using tools made by others, and there’s nothing wrong with that. It’s awesome that you’ve finished a couple of arcade games though well done
@@scrung Thanks for the kind words first off. On the topic of 'cheating', I do not have that mindset at all! After taking a look at the SDL2 wrapper in Rust, I have a much greater appreciation for the simplicity and documentation that Pygame does in fact provide. I still do use tools others have made (LibreSprite, LMMS, Audacity) but coming from zero CS schooling, I feel like tools based around structuring and building my game I would like to build myself. If for nothing else than to learn/grasp more of the process. (And honing more of my problem solving skills!) There is the added bonus that my level editor output can be tweaked to work exactly as I need/want it with my game engine. Thanks again for your kind words. Good luck in your own endeavors!
I am in no way trying to be antagonistic, since low level coding, especially engine coding, is not my forte but... You mentioned Godot is free and then mentioned them removing a feature which would make you unable to update the engine for your game but: 1. Godot is actually open source, so you do have control over almost everything that goes on in the engine, if you want to you could make your own fork of Godot and add all the features/opimization you need and pretty much have the same result (your own engine optimized for your project) with a headstart (all the code that is already contributed to Godot) 2. I thought you don't really want to update the engine too often or at all during the development of your project (I know that's the case for unity and unreal at least) so I don't get why you would want to update godot to latest version, unless it adds a feature you need, and if you still need some legacy feature, again, godot is open source so I don't think there is anything stoping you from porting it over and creating a fork of the godot engine with all the features you need. To me it sounds like you were not aware of this and misrepresented godot a bit, but it could also come from place of ignorace or my misunderstanding of your points behind why creating an engine 100% from scratch is worth it... Other then learning (in which case doing it all yourself might be better, but I am also not sure.) I don't see why not use Godot as a headstart for something of your own. BTW if you do take the time out of your day to read and answer my ramblings I just want to say thank you.
ok so yes that is true, I just used that as a simple example, in practice yes you don't want to upgrade your tools mid developement. Also yes you can fork godot but for someone without much experience or even with experience moding the engine doesn't sound like an easy task 😂
so forking godot is hard, that's why you might want to do it all yourself, but doing what I said is also an option. thanks for the answer (yes I saw it just now, I hate YT notification system)
It is a shame that you spent 2 minutes to answer the question from the title and you didn't even do that. Except for saying "I made my own renderer and editing tools from scratch", which sounds like a "yes, it is hard" type of answer.
To be kept in mind one of the biggest companies does not do game engines, does not use game engines for the vast majority of their titles. Ubisoft. They do have a lot of internal shared tools, libraries and frameworks, which each studio combines into a dedicated game codebase each with a game specific overall architecture, which at some point, for marketing purposes, gets called an "engine". Even though it's a single purpose codebase.
I think the mistake here is your definition of game engine. A game engine is an extended framework for handling various aspects of a game : Physics, Visuals, Audio, Controls, Lightings, Asset loading. It is independant from the editor and tools. No business dumb enough to redo everything everytime. Ubisoft has at least 3 game engines. Anvil : Used to build first Assassin's Creed, later Assassin's Creed, then R6:Seige and Immortal Fenyx Rising. Snowdrop : Massive Entertainment used it for The Division series. Ubisoft also used it for Mario + Rabbids. Scalar : Currently developped for developping cloud-native games. UbiArt Framework : Latest Rayman (Legends and Origins) Far Cry was developped on CryEngine and later games on Dunia Engine.
@@Kalahee Yes to me a "game engine" is a piece of software that purports to support all possible gameplay and presentation types and game designs off a common codebase. As such Unity and Unreal are strictly engines which meet this particular definition of "game engine". There are of course more. If we think back first codebases which were called "engines" supported more than one game, but were not general purpose yet - Id Software engines and Build. I would say they were not "game engines" but "first person shooter engines" or even broken out game codebases with very little inherent attempt at reusability. The first mention of "id Tech" refers to "id tech 3" which signifies the codebase of Quake 3 Arena as it was licensed to other companie for reuse - then there were retroactive attempts to fit prior codebases into the numbering. Instead Ubisoft "engines" are living mostly single-purpose codebases, which evolve with the requirements of any given project. They get forked and change substantially between iterations, which often aren't rea;;y numbered. You could ask and receive an answer, which version of Unreal did Ark release on? 4.5. Which version of Snowdrop did Mario and Rabids release on? Welll uh... the Mario and Rabids one. Continuous versioning doesn't make sense here since they're forked, chopped up and reassembled codebases with no central ownership or through history.
yes that is true, they have very big fees + the points that I gave, also to reply to the people in this thread I think you can define a game engine both as something like unity or a framework but most people think of things like unity as engines
Yha I got a game framework in C I’m working on. It’s split into many single file C libraries which each has 1 job to do. This makes the framework modular and easy to maintain.
Very nice 💪 good luck with your project and try to not over generalize your stuff too much. At some point it becomes detrimental to split your code too much but you have to find where that point is
You can definitely learn and make your own engine. What you can't do is a completely advanced tool like Unity or Unreal Engine with the latest and most advanced rendering techniques (or other game engine related systems) to date.
I think that making a game engine is a good way to systematize one's knowledge and experience. When I develop a game or an engine for it, I always find something new about how to solve certain problems in developing a research instrument or an industry tool. Probably, that's because any software is a game of sorts, it just doesn't always have the usual parts like renderer or support for gamepad.
From my perspective, I would recommend going into building systems. Using a game engine just makes life so much easier. Any energy used that doesn't go into making your game ready for market can really stop you from ever being successful.
the point about unity games feeling similar is something I've noticed as well. They all kind of look and feel the same. Whenever I stumble across devlogs of people who are making games from scratch, or just using a library or framework, they tend to have a more unique feel to them. I think a lot of it comes down to the people that use Unity all watch the same tutorials to learn, so they all end up feeling/looking similar.
well they use the same unity systems so that's why. And don't get me wrong you can make something unique in unity but at that point you also spend a lot of time
There are 2 possible reasons why unity games feel the same. One is that unity didn't properly build a physics engine involving acceleration and gravity. The other reason is that the devs don't know how to work with unity's physics engine. I am leaning toward the second reason because I know anyone can implement that themselves.
@@redrevyol I think its more that devs don't tend to modify (if they understand in the first place) Unity's physics engine. So most unity projects use it as an easy way to get started but besides altering acceleration speeds or other default values, its difficult to make the engine 'feel' different from any other game made with that engine without a complete overhaul. At which point you can really consider making an engine yourself honestly, physics is usually the largest chunk of engine design. Its great for game prototypes or for people who don't particularly care about something so specific especially if you don't plan to use physics in your game, but its still something to consider.
@@BlueKanary You're probably right. Though I doubt a complete overhaul is necessary. In physics, the displacement value for constant acceleration would be "y = initY + vt - (gt^2)/2 ". If the acceleration is an equation or that it changes over time, then calculus would be used to get a different displacement equation. I started a new project in SFML to implement it. Turns out the floaty feel is a result of the unit values are mismatched as g = 9.81 m/s^2 wasn't designed for pixels/s^2.
My take on it is this: Even if it's not difficult, in most cases you want to just use an off-the-shelf engine, especially with so many free engines available these days. Otherwise you'll end up reinventing the wheel, with possible worse effect. Only roll your own engine when your game design would require rewriting the whole thing anyway, because no off-the-shelf engine provides the facilities for you to do what you need to do.
I like the idea of developing the game engine myself, mainly because I will understand everything and have the control over it. I did this with one of my games. But then I realized that my challenge was to know how to make money developing my own games, not digging into the low level functionalies. It is easier, simpler and faster to use a game engine and focus in your game mechanics and do the effort to focus in monetization, marketing and everything to make your game profitable. After hitting this goal and being able to pay your bills, maybe it will be better to hire someone or replicate the process rather than going into a low level code. I think it can be a very pleasurable task for someone like us. But this decision will make your challenge of making money developing games even harder. I learned this lesson with a very practical approach.
Also engines dont necessarily need to have an editor application. Some people get the two confused. For procedural games making a static lib or dll is enough alot of the time and custom editors can be made as an aid with the engine. Also making your own engine is super useful when you need to integrate unique systems for your game and you'd like to integrate them easily with the stuff you've already made instead of having to rebuild them all to work with what youve made in some frankenstein fashion. Engines are usually great and doing specific kinds of games and if your game doesnt need to use it then don't, but I can already see how the tools Im making now are going to be useful in perpetuity.
All These Systems Should Be Combined into 1 and Add an XYZ Axis for 3D Object Placing, Rotating Objects and Changing Objects Colors. Now You Have a Game Engine
I mean sure it's not difficult if you know linear algebra and calculus... And physics... Also game engines don't have to necessarily have a graphical interface... Game engines, when you boil them down to their most basic components, are just a library of common code for developing a game.
I remember Bevy having a very annoying bug - starting from some Ventura there is memory leak for native (at least in some macs) and it's a pain to fix it because I have no idea how it works under the hood and not like it's devs can reproduce it for some reason.
@@BusinessWolf1 It literally happens when using any example with 2d or 3d camera... which are all of them. Hell Tracy does not see memory leak happening. I am starting to think MacOS itself is messing something up! Considering old executables also have the problem...
I wrote my own game engine. I added support for GDevelop JSON so I can have an editor. So a simple single platform game engine is easy. A complex multi-platform game engine that is not native libraries and/or HTML5 specific is hard. In fact I think I am probably the only one with that type of solution. In short it depends on the capabilities.
Yes but why would you want to? You would incur serious performance problems and it would be almost entirely redundant. You would be essentially rewriting the game engine but arbitrarily doing it inside another ... so what about the original one would you even be using? What difference would there be to just doing it outside of one? All you are doing at that point is essentially forcing another application to run along side your game engine and any games built on it. Also forcing people to bundle a shit ton of code that they are never going to use.
well yes you could and it wouldn't make sense buuuuuuuuut I don't think other people have done that soooo if you made an youtube video about it it would blow up 😂😂
@@lowlevelgamedev9330 why would it blow up? It's no different to writing a game engine outside of one. If you mean making a game engine inside a game. I am pretty sure people have done that.
Personally, It boils down to your preferences in terms of time constraints etc, I'm using Godot currently since my game is meant to have multiplayer and 3D support which is incredibly challenging for me to do solo with little to no experience in doing so without an engine, I think that if I were coding something much more simple, I would try to make it from scratch with C++ and a couple frameworks if needed such as raylib, But for now, I'd rather use a game engine where all of this is handled for me and I can easily expand on my project too via engine features. Yes, The risk of Godot removing features is real but that's why whenever you update to a major release, It's best to backup the project first and see if there are any viable alternatives to what you use currently. It really does boil down to your own preferences and requirements at the end of the day personally.
Using an existing engine is just very convenient. I have a game I'm working on in Godot, because with that project I simply want to just focus on the game itself. Slap a light and a WorldEnivornment in and ban, scene looks just like I want. Physics and navigation is easy to manipulate with scripts. I *do* have a C++ project using normal OpenGL which I work on when I specifically am in the mood for that, because I have to thoroughly think about everything I do about my own engine. How to implement this well, and to do that. Can very easily go days and do no real game progress and just do project structure instead. Both are rewarding in different ways. But I personally wouldn't ever blame anyone for just using Unreal or Godot.
@@rasmuseriksson6202 Very true, I've been meaning to get into C++ at some point and learn how to make a game with it without any engine help and only a few libraries or so but I just haven't got around to it.
My biggest issue with all of this is the language itself, specially C/C++. I had a lot of issues with this language, such as: external libraries is a pain, relationships between multiple files is unecessarily complicated, errors are unhelpful, the types are easy to break, and many other issues i can't really describe, and I'm not a programming beginner either. You could call this a "skill issue" of mine, but honestly, i don't know. maybe C++ is indeed a language hard to master. or maybe i am learning it wrong. or maybe it requires years of practice to master.
cpp is indeed kinda painfull to work with but forgamedev is for now the best option probably. Zig and jay might take its place. to solve libraries problems I use cmake and also I usually don't use many cpp features like polimorfism destructors and templates, I never throw catch errors to make my life easier
@@lowlevelgamedev9330 ive had look into languages such as rust and zig. my problem with rust is the unnusual syntax and the new concepts that are hard to fully grasp and dominate. and zig would be the perfect language if it wasnt so obscure. honestly, C# is the only language i could see myself confortable coding in. i feel safe coding in C#, i feel like i truly know how to code, whereas in languages such as C++ and Rust, i feel like i have to learn programming from scratch, even if i already learnt the language basics. i don't feel safe coding in C++. and stuff like CMake and Makefiles make it much more harder than it should be. seriously, i have to learn another language just to make my goddamn project? and also, i struggle with big projects in general, no matter what language or game engine, it is a issue i face. and no, i'm not a Unity user, i'm talking about C# in general. but mostly, i use the godot engine, it is my favorite game engine. however, i'm really interested in making my game engine, because its very interesting and challenging, but it seems impossible to me, i always fall into a pitfall or obstacle that makes me give up on my project, and i feel like i don't truly know the language even though ive learnt the basics of the language. idk what is my issue.
For others who think that making own GE is bad idea: World of Warcraft, CS:Go, CS2, Half-life, EA games(half of that), Fallout (all games), RockStar with their GTA made by personal Game Engines. So as we can see - personal game engine equals comfortable amount of instruments which ur games need! Save it in ur mind guys! Huge amoun of big game dev companies don't use Unity, UE4/5 or others corporate game engines. They develop and support own engines for their own games. It helps them to save time, money and access.
Making a simple game engine is easy, especially nowadays. Making a game engine with commonly expected features such as being usable for any genre, asset streaming, level streaming, level editors, asset editors, code scripting, etc to the likes of Unity or Unreal however is not.
100% Question: how more difficult you think it was for you to make the Minecraft clone after you made the Terraia clone? Meaning they are similar, Terraria is a 2D minecraft. Which one was more fun to make and which would you make again? another Question: Will you enter the Lundum Dare now on the 29 and do the 48h solo? what about streaming it on twitch?
hm both were very fun, probably terraria more fun because it was the first, I made terraria to eventually learn to make minecraft but I would say that any game would help you if you want to later something more difficult. it is just programmijg experience. Right now I am working on my latest minecraft clone and I want to make it very nice with shaders and multi player and stuff second question not this year I don't have much time :/
There's a project here on youtube where the guy is making a voxel game, and created his own hyper optimized engine, and he explains what he's done to it in the videos. It's super interesting and explains why minecraft isn't really THAT simple to make. His channel is www.youtube.com/@DouglasDwyer/videos.
Me who wrote a threadpool from scratch in C++: Yes, easy…. (Not). I spent two months learning about threading. And fixing one annoying deadlock bug. It did pay off though.
3:02 that is not how godot works, the development is entirely community driven, most if not all updates come from user suggestion and people creating possible changes on the github page.
Is not that difficult, at least the runtime and editor parts (if you focus on your specific game tools). Multi-platform support however is whats make it difficult cause you have to abstract almost everything (rendering, input, audio, etc) in a clean/scalable way and that's where expertise and experience plays a big role.
It is very difficult if you want it to perform well, most people don't have skills needed to make their C++ code perform better than garbage they'd make in unity. For example there's no point writing your own opengl code if you will write worse one than what's already in engines, you actually need to do better to get any benefit.
U r right and not, like 50/50. 1)U don't need to do it if u wanna use personal GE in ur personal project. 2) if u wanna publish ur GE for others - ur words make sense
the question is vague and it's context/functionality/design dependent, there's no same such amount it takes to make a "game engine" and "game engine" don't have one singular type of definition really
3:03 no, and even if, it would not be a big deal. First and foremost, they would have no reason to, and second, even if they did do that you could still have access to the source code
idk what to say, engines do change things and I have heared from people from EA for example that having their own engine is a big win in terms of custom features, anyway, good luck with modifying unreal's source code
@@lowlevelgamedev9330 thats cool, indont wanna say this but if possibke make it easy and optimize for android paltform, I am not code experr but i can still see its potential for mobile and pc platform 😊👍
Thank you for the encouragement, everyone’s big on getting a job or competing in the industry but some of us just have an obsessive desire to make an art project in the form of a game. It’s like trying to figure out how to paint a face and everyone tells you this is how to paint a Mona Lisa that will make you millions
well the best way is to learn by doing. I have a video called make your first game engine now you might find that helpfull but I think that you should learn to make a 3d game first and that you can try making an engine to learn 💪
Maybe write a game from scratch is not that difficult, but make a proper game engine from scratch is actually difficult. Not because is generally hard, but takes to much time if you doing this alone.
yes it is true but making a game from scratch also takes a lot of time and I think even with a premade engine you still have to spend a ton of time in the end. But yes a gameengine is a big project
@@lowlevelgamedev9330 Yea, because when you making a serious engine, in the end it becomes just a big box with tools even if with editor, and 95% have some kinda of scripting engine, so if you don't have experience with programing this big editors is usefull, but give much help advanced developer's to speed up the dev.
Yo guys, I'm finishing soon a C++ tutorial serie, wanna try to make a bit of money with not so complicated mobile games to begin with as a next step, any idea of where I should focus to start my first "big project" ? Nice video Low Level Game Dev if you read this :) I was starting to feel making a game is ONLY about learning the tools/game engines !
well why not start start your big project with a mobile game than. If you want to use c++ your best bet is to learh how to use railib so go see how that works
Godot is free as in FREEDOM. If you don't feel capable of maintaining a fork that only adds ONE feature to the engine, how can you then take up the task of making your own ?
But what if a wheel isn't what I actually need? What if instead I want a propeller for a boat or a plane? They all do the same thing of making a disc spin but I'm going to get much better and more fulfilling results by learning how to make a propeller myself than try to kitbash a wheel into one
I'm the only one that I don't believe you ? As much as like the idea to have the exact I need for my project I don't even want to imagine how hard can the be to make all the pre existing part's for scratch and make my game on top off that For example in the fps game I'm working now the option to import my blender 3D models very easily It also have use those tools like map editor ect the egine provide And many useful toutorials I don't even want to imagine how hard can the be for solo development like my self that doesn't enjoy codeng that Mach How can the be to make every system for scratch for 3D model import to image import ECT Not mateion have hard the be to networking game for it
@@lowlevelgamedev9330 that is my point For shomene that have big team Or small scale project and enjoy coding I think may make sense to make i game without egine But for person that does Big scope project as Solo developer like my self I don't think it makes sense to make all the tools the and game for scratch It makes more sense to use game engine even if already found those limitesion those egine have
@@watercat1248 The purpose of this video wasn't to say that building a game from scratch is always the better option, or that you should never use game engines. There are pros and cons to both, but it is recommended to give it a go at least once. Knowing how engines work behind the scenes give a deeper understanding and provides skills that are transferable to other engines. But you're right - creating games from scratch isn't necessary for everyone. But if you have the time and patience, it does have its benefits even for large scale projects. Just do what's best for you for each project you make
I am making a game engine in python with C/C++ game dev library but I am using the python version of the C/C++ game dev library like imgui, jolt physics engine, ogre graphics rendering engine, vulkan, bullet physics engine and other C/C++ library and I am using pygame pyglet for 2D and 3D game framework for the game engine. The game engine will be for simple 2D and complex 3D games.. Is python a good programming language to make a game engine with a programming experience in python and no experience in objective C, C++, C# and Java 0:03 ❤🎉😊
oh well after a quick search it seems like it but apperently pika is a sware word in Portugese or something so I'm glad I wasn't the only one to get trolled by this name :)))
interesting video, but the point about unity platformers feeling similar is pretty ridiculous. you can change the gravity scale or turn it off and code the player movement manually while still using their physics for collision and other physics objects.
depends on what you count a *game engine* making a little game with SDL is ezpz, and you could totally consider it an "engine" the only things abstracted for you are some tedious win32 api calls
ok so one of my first videos from my channel is called how to learn cpp for game developement and I also have a newer one called how to start or continue learning cpp. Watch those because I answer your question there. Also I will give you a bonus guide to have a mentor, someone that know more than you so you can learn from him. Good luck you can do it 💪
Its my finals rn so i cant start anything. After my finals ill start OpenGL but the problem is windowns compiler does not support OpenGL with Codeblocks. But linux does so i have to switch to linux (some people might say i can use VS, but it looks too complex and i rather stick to something simple like codeblocks)
nono don't switch to linux. If you want to do gamedev you should use wondows. Also linux is funny with opengl :)). Now if you want to be a programmer you should switch to visual studio it is what it is. I have some videos called easiest way to setup opengl or start making your cpp game now that give you a framework already configured with opengl. Lastly, codeblocks is just a text editor. There is nothing special about it. You can use opengl with codeblocks. The easiest way to start learning opengl in my oppinion is to just take my template (from my video called easiest way to setup oepngl) because configuring libraries is annoying. However that is not a reason to switch your os. (also with cmske libraries are easier to configure)
None of em. People who recommended making an engine are hobbyist programmers trying to get other people to make their own hobby project. Perfectly fine, but you can't make a "bad" game engine. But you can make a bad game. So it puts distance between you and getting to the point where you can be judged.
I can name a handful of well known indie games that made their own engines and reached a full release. Noita and Rain World especially wouldn't have been possible if they were chained down to the limitations of a conventional general purpose engine
stop the cap, engine dev is hard and the time you would put into engine development could be invested in actual gameplay programming. But if you enjoy engine dev and have the time and budget to invest your time into creating tools then I too can recommend it over using a ready made game engine, if your game is simple enough, for example 2d and no 3d mmorgb. I am also creating a game engine with editor and I love it, but I the 3d horror game I am creating is in a full game engine.
Cool you have little respect for everyone except codemonkeys who don't even make any games they tinker with amount of triangles the homebrewed engine can shit out per frame while actual gamedevs just point and click assets in.
But it is really, really, really stupid. If the goal is to make a good game, abandon your programmer ego where you need everything to be perfect and just use a damn engine. You're gonna abandon the project within 2 years anyway statistically speaking, you might as well make a game in less time than that.
No its not hard to make a shitty engine, its impossible however, to make another Unreal Engine unless you have a billion USD and a decade of time. It's the biggest waste of time ever, time better spent actually trying to create something good. Especially considering studios that spend millions on their own engines that are subpar to UE 4. And make their games look worse and feel worse. All that to save 5%? It's so unbelievably stupid, people spending more money and time on creating something a lot worse. Its never easier to build anything from scratch. If you need custom movement/physics/sims whatever just create them in the engine and plug them in. If its all you need then odds are never anything serious and its a waste of time in the first place. Might as well call it a hobby. I honestly think people who make game engines and people who make games should never be the same people, ever. And exceptions are very very very specific. Unless your game looks like it was made in 1980s then I guess it doesn't matter. But if that's what you are doing you would probably never reach UE or even Unity thresholds for them to start charging you so the engine is free for you anyway 😅😅😅 On a side note, I don't know about unity that much but in UE absolutely no limits on creating large worlds. Not to mention if properly configured everything loads perfectly in 80 million km^2 without LODs. (Since 5.1.1) And you can have perfectly fine no loading screen experience in the entire world. I honestly think building your own game engine is the dumbest advice people that have nothing better to do keep giving to people who actually want to create games. And I can go as far as saying it's for people who actually can't make a game that's fun and entertaining, so they waste their time on all that crap. Trying to solve problems that no one else had.
probably you won't reach Unreal or unity graphics for an open world by yourself and unreal especially looks nice but the people who will mentain those tools are people that know how to build an engine
@@lowlevelgamedev9330 Yes, thats the point. Engine devs maintain the engines and make them better by adding new tools for game devs. And game devs use the tools to make fun experiences. What I meant is those 2 should not mix. (in all serious applications and most scenarios in general it's just not practical) Pilots don't learn to build airplanes and Boeing engineers are not pilots. Because that way a lot of time is being wasted to re-inventing a worse version of the wheel. And I do believe giving advice to people who want to build games to build their own engine is dishonest to what they want to achieve and to the quality of what they will get. But that's just me, if people really want to do this by some weird reason. Thats their problems and choices.
@@shinobuoshino5066 Have you ever heard of Flight Simulators? Not to mention flight computers. But regardless my point had more to do with the perspective. We use similar logic in a lot of things that seem unrelated.
@@yushkovyaroslav not sure who is "we" but that doesn't include me. Flight Simulators exist to test knowledge of pilot and nothing more, also incomparable to flying the real thing.
it is not that difficult because you are relying on code made by others too much, also naively underestimate your background experience and your lifetime. thefore some people find difficult using Windows, others find difficult using linux, etc, so don't underestimate your background.
This is why you abstract your game code from your renderer and focus on portable design in the first place, a mistake I've learned the hard way,. In other words, your game should be able to run in text only before you focus on visuals. Another reason that it's dystopic that we have a game design world that's so visual focused first. : /
It's critical, I see this now, that you don't become at all dependent on their art tools, better to use external GIMP, Blender, and your own simple editor tools, of whom you can download their source or their install files and keep them in your project folders at all times as well. If a company goes public at any time, you also don't use that tool.
yes, very nice point, also I think you learn that only by practice
@lowlevelgamedev9330 So true, because Even though over the years I read people making that point it went in one ear out the next and the tutorials are mostly about entabgling your code into an editor and it's tools
So games like Quake, Unreal etc. should've focused on making their game in text-only mode before making them visual? That makes no sense. It highly depends on what kind of game you're trying to make and why you make it. Some of the early games that still inspire a ton of games today, both at a game mechanic level, as well as a technical one, purely started _because_ of visuals; making rendering faster and more detailed. Others, like Half-Life were purely story-driven for the get-go and visuals were the first things they came up with to have a direction. Without a direction you start focusing on the wrong things for the wrong reasons.
Use whatever tools you're comfortable with. Build something whatever and however you like and think about things. Get things done quick, first. Get a concept down, and iterate. Don't bow down to "use open source software, just because I think it's better" rhetorics.
You'll never finish anything if you try to abstract and optimize every small detail. Often those are so insignificant that it's not even part of your initial goal, and it stops you from progressing when you get stuck in a rabbit hole.
@@deallocI didn't mean design a game without drawing out concept artwork and testing a custom made renderer and having art assets, I meant that you work with a data first mindset as an engineer, and separate your actual game code, classes, structs, etc... from the renderer. When using Unity you're using their own GameObject class for example, and that class isn't even serializable. You're coaxed into using their animator, and when these individuals or companies are designing game, they're taught to intertwine their coding into the art toole.
If your tooling gets entangled into Unity's inspector system, for example, you don't have a portable game, so if the renderer changes, upgrades, or switches, you have a game you can't hook up to any renderer or toolset.
I'm only talking about if you write input functions for example, you write 'aButton()' or something then the engine code goes inside of YOUR functions/methods, so that you can change the 'UnityEngine.JoystickWhatever.interface.yaddahyaddah.buttonPressedIn(UnityEngine.KeyCode.A) or whatever you do in that engine later in an easy manner.
Instead, for example, you're encouraged to use their callbacks. In Unity they even have a template in where it creates a script for you inherited from Monobehaviour, but it's nicer to start without Monobehaviour scripts, then have a single Monobehaviour as an entry point and a renderer update method.
The same goes for any renderer or engine, you can have a single entry point from the renderer and then an update method from your own framework and then have your framework generate everything you need and push all the buttons so to speak. Then later on, your framework is easily portable to any language or any engine/renderer.
@@astrahcat1212Unity (and Unreal aswell) provides APIs and tools that are well integrated with each other, both for ease of use, but also more importantly for optimization purposes for general use-cases.
Abstractions can result in hurting performance for little to no benefits, as it can easily make your codebase harder to reason about if you don't understand why you need to abstract something in the first place. So from a technical point of view, you shouldn't prematurely abstract things unless you know the problem space first.
Again, choose the tools that makes sense for your use-case, and don't sweat the details of how "portable" your code is to another engine, especially at early stages of development. These are things you can sort out later when you have a better idea of the problems you're trying to solve and your end goal.
Regarding some of these points, especially regarding Godot.
Once you start a game, you typically choose a version of the engine for the game, and you do not update it during development. This means if a feature is removed, you'll still have it, because you already decided on a version of the engine that suits your needs.
Many Unity games feel the same because developers choose not to dig into their movement physics. Scripting offers a massive amount of customization on its own, and if you really don't like their built in assistance, you can work directly with coordinates, and implement your own physics systems within the engine. Doing this allows you to retain many of the advantages the engine offers without losing your control.
Godot is also open source, so if you'd like, you could pick the version that best suits your needs, and alter the engine for any low level changes necessary. This would be a bigger investment, as you need to intimately understand a system that large to effectively change it, so there would be some cost benefit to look at for any particular use case.
For the minecraft example, I do not believe there is any engine in use that would restrict you from optimizing what you load in your game with chunking. Engines offer a lot of tools to assist, like dynamically rendering based on what you see out of the box if you want those options, but they're not necessary.
That said, if you want a deep understanding of how all these systems work, making a game from scratch is definitely a great way to learn. I'd gently push people in that direction just so they better understand the systems at work, even if I don't think it's the most efficient way to make the vast majority of games.
Making my own games from scratch is such an incredible experience, I'd recommend it to anyone interested just to learn how some of this stuff works. It's a lot of fun.
I don't like engines because of the lack of control. When you CAN have control you have to, like you said, intimately understand the engine to start making changes.
I also think the recent Unity debacle is a good reminder why the people who own these engines aren't your friends.
@@goosewithagibus Godot is open-source. You have complete control over it.
@@mbg4681 That's like saying you have complete control over your Linux distro because it is open source, yes in theory but in practice that's BS. Godot is 1M+ lines of code without considering third party stuff. With a project that big, you're tied to their design decisions. You could change bits of code here and there, sure, but mainly you're going to extend it by writing custom plugins. That's not complete control.
@@tzimmermann >> That's like saying you have complete control over your Linux distro because it is open source, yes in theory but in practice that's BS.
You're staying that as if it's an absolute. Same could be said about anything higher-level than Assembly.
@@mbg4681 Wait till you learn about speculative and out-of-order execution, and you won't even mention assembly as a level you have "complete control" over. Thus, control as a concept in computer science does not even make sense and we're talking about something that does not exist. Or, I'm more nuanced than that.
The thing with godot is that you can allways adopt it's source code to work on your own engine.
Making a game from scratch is way easier than people think, I was watching a video by someone discouraging people from making their own engine, this person had no idea what making your own engine even involves and thought that you need to specify the individual position of each triangle you want to draw. The person had no idea what he was talking about but was so confident that you shouldnt make your own engine
😂😂😂😂 yes well 3D can be hard that is true but for like a 2D game honestly I like coding the entire game from scratch rather than using an engine
@@lowlevelgamedev9330 I created a Virtual Tabletop using Truevision for the 3d rendering, everything else was just me doing it. Turned out pretty great, including creating a server, chat, and card system. However, the 3d rending tool I used DIED. :( These days it might be easier to do and I'm really thinking of rolling my own for the next game, just because all this Unity nonsense.
@@lowlevelgamedev9330I don't know anything about programming and game development, but I really wanted to learn how to create games from scratch (without an engine). What should I do?
That guy probably doesn't anything about basic calculus and physics (kinematics). I don't believe 3d is any harder honestly; just gotta learn linear algebra where matrices are involved, which I hear is not too hard.
@@redrevyol To be fair, I have experienced it and as a non-artist person I couldn't think of any way of modelling aside from specifying the exact position of each Vertice of each triangle and also didn't think of making a system where you make a list of vertices then simply connect them with triangles, so I actually did end up in that exact situation myself. Regardless of knowledge of calculus and physics, linear algebra doesn't really help with modelling but the engine itself would definitely be benefitted from it.
I never really enjoyed using game engines because it tends to demand the dev to work in a very specific way, and, like you said, if the engine has a bug you can't do anything but hope to it be fixed eventually.
After I shipped my first big game I began learning opengl, followed by writing my own game library, and it is going pretty well. I think I prefer keeping it as just a library and not an engine to mantain a high level of flexebility and optimization potential.
yes, this is also what I do 💪 Also I like your profile picture :)
this is EXACTLY why I dislike game engines - I hate having routines and formats and "the way to do things" forced onto me. I gladly take on the extra upfront work of writing the engine if it means I can work with the tools that I designed and a framework that is comfortable for me.
@@juniuwu What do you think of Monogame?
Now do "is it difficult to make a GOOD engine".
I dare ya.
😂 ok let's not go there
Seeing the creation of engine editor with GUI would be also very interesting
yeah well the editor itself is not difficult, the integration is the interesting part
in my opinion it really depends on how many and how complex systems you need for your game, and also, how many of those are not offered out of the box by godot or unreal. those are engines that you can customize and modify all day long as you have access to the source code. of course, the big disadvantage is that now you not only need to know how to make your custom system, but you also have to know how to integrate it into the engine of your choice. the tradeoff here is obvious: either you study a game engine's internal workings, or you make your own from ground up.
the thing is tho, unless you make some really whacky game that flips everything on it's head (yeah, minecraft was kinda like that, and space engineers too), you will probably be able to use most of a ready made game engine's systems out of the box, and make/modify the rest yourself quicker and easier than making the whole thing from ground up.
either way you will gain knowledge and skills, and have a game ready at the end of the day (or decade)
I wish the world would stop calling "Game Engine" to Unity, UE, Godot, etc, because they're actually more than that, and I think that's why there's some confusion about what game engines are. When you mention "making your won engine", many people think that means creating something like Unity. We ought to call them Game Development Kits, or Game Development Environments, or something like that, because that's really what they are.
Or even saying "I wanna make my own game, from scratch not using an already existing engine".
Because people are not really making a new full-featured engine, just the underlying basic functions needed for your game idea.
When one says "I am doing my own game from scratch", the response is "Are you crazy? You are going to build a whole new engine on your own?". They already assume that if you don't use Unity, Unreal or any other ready made solution, you are planning to code the big monolith that these engines are.
I think Integrated Game Development Environment sounds. IGDE
"so you usually have to fight with the Unity physics system"
*proceeds to show The End is Nigh which was built on a custom engine* 😂
good video though
😂😂 you get the point tho 😂😂
I used to write everything from scratch, I even had an advanced editor. I'm currently on Unity with the idea of switching to Godot
With no game engine experience at all, i'm learning Godot. My level of knowledge is piss poor but i've still managed to create a very basic top-down tile-mapped 2D game world with an animated character and enemies. I really don't know what the fuck i'm doing, but i'm slowly learning it. The main hurdle for me is simply all of the different Functions and Signals you can call in different scripts. Not really knowing how to use them, and yet there are so many of them, is the most intimidating part for me. For people with experience in Unity, i hear that a lot of functions are direct parallels. I'm eager to really get over my hurdle and obtain a bare minimum level of competence in GDScript so that i can be much more efficient.
So far though, i'm really excited with what i have picked up so far! It's a fun experience, in spite of the difficulties of learning everything from the very basics with no past experience.
Great video! It's refreshing to see someone else talking about custom game engines on youtube.
glad you like it 💪💪
What I like about Godot is that, given that one has enough understanding of the engine itself, it can just be modified to suit the specific requirements of the game. IIRC Sonic Colors was made using a modified version of Godot. But since that kind of thing doesn't seem to be common practice, I have really no idea how well that'd really work in the end.
You fail to take one thing into account during your presumptions:
I am not a smart man.
nah bro don't go so hard on yourself, try making a game from scratch, maybe you won't like the process but that is something different
Something important I learned after making a lot of C++ projects over the years, create external libraries/dlls and never create an app with everything in a single executable (except for really short project) ! It makes your project become messy and if you want to reuse some of the code you made in an other project, you will need to copy manually the stuff you made, instead of just reusing the standalone dlls you made for !
As an example I worked on multiples modding projects on various games, I always add something structured like that at the end:
(this was for a multiplayer project)
[Client Project]
- YourProjectName-Client.exe
- WebProcess.dll
- ScriptingAPI.dll
- DiscordRPC.dll
- NetCommon.dll
- Shared.dll
[Server Project]
- YourProjectName-Server.exe
- NetCommon.dll
- Shared.dll
I was used for a long time to only compile everything in a single .exe file, for tiny project it's okay, but when your project become bigger: structure your project, do not rush, take time to debug and clean your code, it will prevent you from restarting your entire project from scratch lol.
yes it really depends on the project type and stuff thanks for the advice 💪
Pointless work ahead of time lmao. If you need to copy a part of your project for another one, then extract code into library there and then, in the long run you will save a lot of time...
... because you won't be reusing code and it's all a cope to try and futureproof things you will never do.
What is a problem with just copying a source file containing desired logics?
@@shinobuoshino5066 Proof you never worked on huge project to say that, first of all in the example I choose, I had a client and a server, and in multiplayer client and server are sharing the same API, meaning copying over the code from client to server multiples times is literally time lost lol.
Having a standalone "networking.dll" you use in both client and server, and then use the API in both project IS a time saver.
And yes I also use a lot of other standalone DLL I made for in other projects too.
@@sweettea-hv1ls Prone to error, and generally you're not designing source file to work as a standalone, generally you have some external logics coming from other parts of your code, meaning if you want to copy over this specific file, you will need to remove the extra you added from other part of your code or add them aswell.
Trust me, creating standalone DLL/LIB for different projects is a HUGE time saver on the long run.
Just Design All The Parts. Includes Objects’s Physics, Materials, Transparency, Music-Maker or Audio-Maker, Graphics like Render/Modelling or Animation, UI, 2D Objects in 3D Toolbox/Images Facing Camera (BillBoard), Camera Moving, Menu Settings, Entity-Component-System, Player/Enemy Component and Language to Do Programming for Game Function or Mechanics
@@rytif If he means design an audio stream handler, then sure that seems normal. If he means make a midi editor to make your audio however... That's like saying you need to build your own Blender for 3D objects and rigging. Not commenting on the rest
Currently I'm working on a game in C# MonoGame (moved from Unity that I started with). Maybe next project I will start from scratch and will try to learn C++.
Try Raylib or WGPU
Brand new to the game dev thing. Been learning the low level aspects of it via Pygame. Have a few arcade games under my belt, and I'm in the process of building my own level editor to use in the creation of my first platformer! I have been avoiding using tools made by others, because I'd rather learn the inner workings and systems myself.
Once I have a better grasp on things down the line, it'll be time to learn Rust, and start transferring the tools I've made over to that! +1 sub, love your content.
sounds like a nice path good luck 💪 (Also I don't really recommand rust for gamedev but of you like it feel free to use it)
What's your opinion on Bevy?@@lowlevelgamedev9330
It’s great to implement things for your own understanding, but don’t fall into the ’using tools made by others is cheating’ trap (not accusing you of saying this), because if you are using Pygame, you are already using tools made by others, and there’s nothing wrong with that. It’s awesome that you’ve finished a couple of arcade games though well done
@@scrung Thanks for the kind words first off. On the topic of 'cheating', I do not have that mindset at all! After taking a look at the SDL2 wrapper in Rust, I have a much greater appreciation for the simplicity and documentation that Pygame does in fact provide.
I still do use tools others have made (LibreSprite, LMMS, Audacity) but coming from zero CS schooling, I feel like tools based around structuring and building my game I would like to build myself. If for nothing else than to learn/grasp more of the process. (And honing more of my problem solving skills!)
There is the added bonus that my level editor output can be tweaked to work exactly as I need/want it with my game engine.
Thanks again for your kind words. Good luck in your own endeavors!
I am in no way trying to be antagonistic, since low level coding, especially engine coding, is not my forte but...
You mentioned Godot is free and then mentioned them removing a feature which would make you unable to update the engine for your game but:
1. Godot is actually open source, so you do have control over almost everything that goes on in the engine, if you want to you could make your own fork of Godot and add all the features/opimization you need and pretty much have the same result (your own engine optimized for your project) with a headstart (all the code that is already contributed to Godot)
2. I thought you don't really want to update the engine too often or at all during the development of your project (I know that's the case for unity and unreal at least) so I don't get why you would want to update godot to latest version, unless it adds a feature you need, and if you still need some legacy feature, again, godot is open source so I don't think there is anything stoping you from porting it over and creating a fork of the godot engine with all the features you need.
To me it sounds like you were not aware of this and misrepresented godot a bit, but it could also come from place of ignorace or my misunderstanding of your points behind why creating an engine 100% from scratch is worth it... Other then learning (in which case doing it all yourself might be better, but I am also not sure.) I don't see why not use Godot as a headstart for something of your own. BTW if you do take the time out of your day to read and answer my ramblings I just want to say thank you.
ok so yes that is true, I just used that as a simple example, in practice yes you don't want to upgrade your tools mid developement. Also yes you can fork godot but for someone without much experience or even with experience moding the engine doesn't sound like an easy task 😂
but yes you could totally learn godot inside out and fork it and costumize it that would be something nice
so forking godot is hard, that's why you might want to do it all yourself, but doing what I said is also an option. thanks for the answer (yes I saw it just now, I hate YT notification system)
good video!
thank youu 💪
godot is not only free but also open source. You can be in charge of everything if you want or need to, or you can return a removed feature back
It is a shame that you spent 2 minutes to answer the question from the title and you didn't even do that. Except for saying "I made my own renderer and editing tools from scratch", which sounds like a "yes, it is hard" type of answer.
Get a life bruv.
@@LEMON_2U you said it :p
@@LEMON_2Uwe’re all here watching videos on how to make a game engine Lol
@@LEMON_2U People here don't have a life (not being serious)
Im very interested in your minecraft dungeons clone! Its not an obvious game to remake but I absolutely love the game
thank you, I am not working at it anymore but I will continue to work on my minecraft multi player clone 💪
Woot! Gimme more Motivation!!!
on my way with my next videos 💪
To be kept in mind one of the biggest companies does not do game engines, does not use game engines for the vast majority of their titles. Ubisoft.
They do have a lot of internal shared tools, libraries and frameworks, which each studio combines into a dedicated game codebase each with a game specific overall architecture, which at some point, for marketing purposes, gets called an "engine". Even though it's a single purpose codebase.
I think the mistake here is your definition of game engine. A game engine is an extended framework for handling various aspects of a game : Physics, Visuals, Audio, Controls, Lightings, Asset loading. It is independant from the editor and tools. No business dumb enough to redo everything everytime. Ubisoft has at least 3 game engines.
Anvil : Used to build first Assassin's Creed, later Assassin's Creed, then R6:Seige and Immortal Fenyx Rising.
Snowdrop : Massive Entertainment used it for The Division series. Ubisoft also used it for Mario + Rabbids.
Scalar : Currently developped for developping cloud-native games.
UbiArt Framework : Latest Rayman (Legends and Origins)
Far Cry was developped on CryEngine and later games on Dunia Engine.
@@Kalahee Yes to me a "game engine" is a piece of software that purports to support all possible gameplay and presentation types and game designs off a common codebase. As such Unity and Unreal are strictly engines which meet this particular definition of "game engine". There are of course more.
If we think back first codebases which were called "engines" supported more than one game, but were not general purpose yet - Id Software engines and Build. I would say they were not "game engines" but "first person shooter engines" or even broken out game codebases with very little inherent attempt at reusability. The first mention of "id Tech" refers to "id tech 3" which signifies the codebase of Quake 3 Arena as it was licensed to other companie for reuse - then there were retroactive attempts to fit prior codebases into the numbering.
Instead Ubisoft "engines" are living mostly single-purpose codebases, which evolve with the requirements of any given project. They get forked and change substantially between iterations, which often aren't rea;;y numbered. You could ask and receive an answer, which version of Unreal did Ark release on? 4.5. Which version of Snowdrop did Mario and Rabids release on? Welll uh... the Mario and Rabids one. Continuous versioning doesn't make sense here since they're forked, chopped up and reassembled codebases with no central ownership or through history.
... what you just described is a game engine.
yes that is true, they have very big fees + the points that I gave, also to reply to the people in this thread I think you can define a game engine both as something like unity or a framework but most people think of things like unity as engines
Yha I got a game framework in C I’m working on. It’s split into many single file C libraries which each has 1 job to do. This makes the framework modular and easy to maintain.
Very nice 💪 good luck with your project and try to not over generalize your stuff too much. At some point it becomes detrimental to split your code too much but you have to find where that point is
You can definitely learn and make your own engine. What you can't do is a completely advanced tool like Unity or Unreal Engine with the latest and most advanced rendering techniques (or other game engine related systems) to date.
I think that making a game engine is a good way to systematize one's knowledge and experience. When I develop a game or an engine for it, I always find something new about how to solve certain problems in developing a research instrument or an industry tool. Probably, that's because any software is a game of sorts, it just doesn't always have the usual parts like renderer or support for gamepad.
From my perspective, I would recommend going into building systems.
Using a game engine just makes life so much easier. Any energy used that doesn't go into making your game ready for market can really stop you from ever being successful.
the point about unity games feeling similar is something I've noticed as well. They all kind of look and feel the same. Whenever I stumble across devlogs of people who are making games from scratch, or just using a library or framework, they tend to have a more unique feel to them. I think a lot of it comes down to the people that use Unity all watch the same tutorials to learn, so they all end up feeling/looking similar.
well they use the same unity systems so that's why. And don't get me wrong you can make something unique in unity but at that point you also spend a lot of time
There are 2 possible reasons why unity games feel the same. One is that unity didn't properly build a physics engine involving acceleration and gravity. The other reason is that the devs don't know how to work with unity's physics engine. I am leaning toward the second reason because I know anyone can implement that themselves.
@@redrevyol I think its more that devs don't tend to modify (if they understand in the first place) Unity's physics engine. So most unity projects use it as an easy way to get started but besides altering acceleration speeds or other default values, its difficult to make the engine 'feel' different from any other game made with that engine without a complete overhaul. At which point you can really consider making an engine yourself honestly, physics is usually the largest chunk of engine design. Its great for game prototypes or for people who don't particularly care about something so specific especially if you don't plan to use physics in your game, but its still something to consider.
@@BlueKanary You're probably right. Though I doubt a complete overhaul is necessary.
In physics, the displacement value for constant acceleration would be "y = initY + vt - (gt^2)/2 ". If the acceleration is an equation or that it changes over time, then calculus would be used to get a different displacement equation.
I started a new project in SFML to implement it. Turns out the floaty feel is a result of the unit values are mismatched as g = 9.81 m/s^2 wasn't designed for pixels/s^2.
My take on it is this: Even if it's not difficult, in most cases you want to just use an off-the-shelf engine, especially with so many free engines available these days. Otherwise you'll end up reinventing the wheel, with possible worse effect. Only roll your own engine when your game design would require rewriting the whole thing anyway, because no off-the-shelf engine provides the facilities for you to do what you need to do.
I like the idea of developing the game engine myself, mainly because I will understand everything and have the control over it. I did this with one of my games. But then I realized that my challenge was to know how to make money developing my own games, not digging into the low level functionalies. It is easier, simpler and faster to use a game engine and focus in your game mechanics and do the effort to focus in monetization, marketing and everything to make your game profitable. After hitting this goal and being able to pay your bills, maybe it will be better to hire someone or replicate the process rather than going into a low level code. I think it can be a very pleasurable task for someone like us. But this decision will make your challenge of making money developing games even harder. I learned this lesson with a very practical approach.
Also engines dont necessarily need to have an editor application. Some people get the two confused. For procedural games making a static lib or dll is enough alot of the time and custom editors can be made as an aid with the engine. Also making your own engine is super useful when you need to integrate unique systems for your game and you'd like to integrate them easily with the stuff you've already made instead of having to rebuild them all to work with what youve made in some frankenstein fashion.
Engines are usually great and doing specific kinds of games and if your game doesnt need to use it then don't, but I can already see how the tools Im making now are going to be useful in perpetuity.
I personally recommend using a rendering engine for your first game engine(Irrlicht engine, or something like it).
Haven't tried, sounds like a nice tho idea thanks and I hope it will help someone 💪💪
All These Systems Should Be Combined into 1 and Add an XYZ Axis for 3D Object Placing, Rotating Objects and Changing Objects Colors. Now You Have a Game Engine
yes sounds like a good sumary I like it 💪
Here I go again with false hope that making my own engine might not be hard as hell 😭
It is arguable that Terraria is in fact an extremely limited game engine as well as a game.
Thank you for the subtitles.
you're wellcome 💪💪
I mean sure it's not difficult if you know linear algebra and calculus... And physics... Also game engines don't have to necessarily have a graphical interface... Game engines, when you boil them down to their most basic components, are just a library of common code for developing a game.
I remember Bevy having a very annoying bug - starting from some Ventura there is memory leak for native (at least in some macs) and it's a pain to fix it because I have no idea how it works under the hood and not like it's devs can reproduce it for some reason.
The problem is almost always assuming that it's a bug and not a wrong assumption about something.
@@BusinessWolf1 It literally happens when using any example with 2d or 3d camera... which are all of them. Hell Tracy does not see memory leak happening. I am starting to think MacOS itself is messing something up! Considering old executables also have the problem...
I wrote my own game engine. I added support for GDevelop JSON so I can have an editor. So a simple single platform game engine is easy. A complex multi-platform game engine that is not native libraries and/or HTML5 specific is hard. In fact I think I am probably the only one with that type of solution. In short it depends on the capabilities.
Look into SDL, it's the most multi platform library there is
one stupid question i always ask myself is: can you make a game engine inside a game engine?
It's called framework
Yes but why would you want to? You would incur serious performance problems and it would be almost entirely redundant. You would be essentially rewriting the game engine but arbitrarily doing it inside another ... so what about the original one would you even be using?
What difference would there be to just doing it outside of one? All you are doing at that point is essentially forcing another application to run along side your game engine and any games built on it. Also forcing people to bundle a shit ton of code that they are never going to use.
well yes you could and it wouldn't make sense buuuuuuuuut I don't think other people have done that soooo if you made an youtube video about it it would blow up 😂😂
@@lowlevelgamedev9330 why would it blow up? It's no different to writing a game engine outside of one.
If you mean making a game engine inside a game. I am pretty sure people have done that.
Personally, It boils down to your preferences in terms of time constraints etc, I'm using Godot currently since my game is meant to have multiplayer and 3D support which is incredibly challenging for me to do solo with little to no experience in doing so without an engine, I think that if I were coding something much more simple, I would try to make it from scratch with C++ and a couple frameworks if needed such as raylib, But for now, I'd rather use a game engine where all of this is handled for me and I can easily expand on my project too via engine features.
Yes, The risk of Godot removing features is real but that's why whenever you update to a major release, It's best to backup the project first and see if there are any viable alternatives to what you use currently.
It really does boil down to your own preferences and requirements at the end of the day personally.
Using an existing engine is just very convenient. I have a game I'm working on in Godot, because with that project I simply want to just focus on the game itself. Slap a light and a WorldEnivornment in and ban, scene looks just like I want. Physics and navigation is easy to manipulate with scripts.
I *do* have a C++ project using normal OpenGL which I work on when I specifically am in the mood for that, because I have to thoroughly think about everything I do about my own engine. How to implement this well, and to do that. Can very easily go days and do no real game progress and just do project structure instead.
Both are rewarding in different ways. But I personally wouldn't ever blame anyone for just using Unreal or Godot.
@@rasmuseriksson6202 Very true, I've been meaning to get into C++ at some point and learn how to make a game with it without any engine help and only a few libraries or so but I just haven't got around to it.
Godot is open source. If a bug needs fixing or you need a new feature for your special use case, you can do it yourself. I see it as “my” game engine.
My biggest issue with all of this is the language itself, specially C/C++. I had a lot of issues with this language, such as: external libraries is a pain, relationships between multiple files is unecessarily complicated, errors are unhelpful, the types are easy to break, and many other issues i can't really describe, and I'm not a programming beginner either. You could call this a "skill issue" of mine, but honestly, i don't know. maybe C++ is indeed a language hard to master. or maybe i am learning it wrong. or maybe it requires years of practice to master.
cpp is indeed kinda painfull to work with but forgamedev is for now the best option probably. Zig and jay might take its place. to solve libraries problems I use cmake and also I usually don't use many cpp features like polimorfism destructors and templates, I never throw catch errors to make my life easier
@@lowlevelgamedev9330 ive had look into languages such as rust and zig. my problem with rust is the unnusual syntax and the new concepts that are hard to fully grasp and dominate. and zig would be the perfect language if it wasnt so obscure.
honestly, C# is the only language i could see myself confortable coding in. i feel safe coding in C#, i feel like i truly know how to code, whereas in languages such as C++ and Rust, i feel like i have to learn programming from scratch, even if i already learnt the language basics. i don't feel safe coding in C++. and stuff like CMake and Makefiles make it much more harder than it should be. seriously, i have to learn another language just to make my goddamn project? and also, i struggle with big projects in general, no matter what language or game engine, it is a issue i face.
and no, i'm not a Unity user, i'm talking about C# in general. but mostly, i use the godot engine, it is my favorite game engine. however, i'm really interested in making my game engine, because its very interesting and challenging, but it seems impossible to me, i always fall into a pitfall or obstacle that makes me give up on my project, and i feel like i don't truly know the language even though ive learnt the basics of the language. idk what is my issue.
For others who think that making own GE is bad idea: World of Warcraft, CS:Go, CS2, Half-life, EA games(half of that), Fallout (all games), RockStar with their GTA made by personal Game Engines. So as we can see - personal game engine equals comfortable amount of instruments which ur games need! Save it in ur mind guys! Huge amoun of big game dev companies don't use Unity, UE4/5 or others corporate game engines. They develop and support own engines for their own games. It helps them to save time, money and access.
yes and also you learn a lot of stuff 💪 thanks for the comment
Your thumbnail has my attention.
Making a simple game engine is easy, especially nowadays. Making a game engine with commonly expected features such as being usable for any genre, asset streaming, level streaming, level editors, asset editors, code scripting, etc to the likes of Unity or Unreal however is not.
100%
Question: how more difficult you think it was for you to make the Minecraft clone after you made the Terraia clone? Meaning they are similar, Terraria is a 2D minecraft. Which one was more fun to make and which would you make again?
another Question: Will you enter the Lundum Dare now on the 29 and do the 48h solo? what about streaming it on twitch?
hm both were very fun, probably terraria more fun because it was the first, I made terraria to eventually learn to make minecraft but I would say that any game would help you if you want to later something more difficult. it is just programmijg experience. Right now I am working on my latest minecraft clone and I want to make it very nice with shaders and multi player and stuff
second question not this year I don't have much time :/
There's a project here on youtube where the guy is making a voxel game, and created his own hyper optimized engine, and he explains what he's done to it in the videos. It's super interesting and explains why minecraft isn't really THAT simple to make. His channel is www.youtube.com/@DouglasDwyer/videos.
Me who wrote a threadpool from scratch in C++:
Yes, easy…. (Not).
I spent two months learning about threading. And fixing one annoying deadlock bug. It did pay off though.
You've sold me.
You should born with this skill
Efectiv stiaaaam ca esti roman dupa accent. Mam uitat la about si asa a fost
😂😂 ba credeam cs nu e asa evident 😂😂
3:02 that is not how godot works, the development is entirely community driven, most if not all updates come from user suggestion and people creating possible changes on the github page.
Thats why I can't finish my multiplayer platformer on Godot XD. Cause it's creepy in real
Is not that difficult, at least the runtime and editor parts (if you focus on your specific game tools). Multi-platform support however is whats make it difficult cause you have to abstract almost everything (rendering, input, audio, etc) in a clean/scalable way and that's where expertise and experience plays a big role.
It is very difficult if you want it to perform well, most people don't have skills needed to make their C++ code perform better than garbage they'd make in unity.
For example there's no point writing your own opengl code if you will write worse one than what's already in engines, you actually need to do better to get any benefit.
U r right and not, like 50/50.
1)U don't need to do it if u wanna use personal GE in ur personal project.
2) if u wanna publish ur GE for others - ur words make sense
the question is vague and it's context/functionality/design dependent, there's no same such amount it takes to make a "game engine" and "game engine" don't have one singular type of definition really
3:03 no, and even if, it would not be a big deal. First and foremost, they would have no reason to, and second, even if they did do that you could still have access to the source code
idk what to say, engines do change things and I have heared from people from EA for example that having their own engine is a big win in terms of custom features, anyway, good luck with modifying unreal's source code
Will you open source your game engine? Who whay will community will evolve it in into : )
the source code is available, I have to make it more robust however and finish all the basics before I could let others add controbutions
@@lowlevelgamedev9330 thats cool, indont wanna say this but if possibke make it easy and optimize for android paltform, I am not code experr but i can still see its potential for mobile and pc platform 😊👍
Man, "pika" is "dick" in portuguese lmfao
yeah I have also found that out later 😂😅 it is not intentional
Difficult? YES!
Thank you for the encouragement, everyone’s big on getting a job or competing in the industry but some of us just have an obsessive desire to make an art project in the form of a game. It’s like trying to figure out how to paint a face and everyone tells you this is how to paint a Mona Lisa that will make you millions
For a 3d game you will probably take 4 years to make the engine before starting on your game...
Unfortunately I know nothing about coding, and probably starting with an engine is easier and then learn coding with it
you don't have to start coding with coding an engine tho. I also started coding from 0 and learned my way to being able to make an engine.
I'm not good at 3D rendering nor UI/UX design nor game engine development. Sooo how can I learn these things in order to make my own game engine?
well the best way is to learn by doing. I have a video called make your first game engine now you might find that helpfull but I think that you should learn to make a 3d game first and that you can try making an engine to learn 💪
I appreciate this motivational video but the only way I'm ever touching glfw is with dead hands
no problem, I have just released my first video on how to open a window using windows api 😂😭
Maybe write a game from scratch is not that difficult, but make a proper game engine from scratch is actually difficult. Not because is generally hard, but takes to much time if you doing this alone.
yes it is true but making a game from scratch also takes a lot of time and I think even with a premade engine you still have to spend a ton of time in the end. But yes a gameengine is a big project
@@lowlevelgamedev9330 Yea, because when you making a serious engine, in the end it becomes just a big box with tools even if with editor, and 95% have some kinda of scripting engine, so if you don't have experience with programing this big editors is usefull, but give much help advanced developer's to speed up the dev.
Yo guys, I'm finishing soon a C++ tutorial serie, wanna try to make a bit of money with not so complicated mobile games to begin with as a next step, any idea of where I should focus to start my first "big project" ?
Nice video Low Level Game Dev if you read this :) I was starting to feel making a game is ONLY about learning the tools/game engines !
well why not start start your big project with a mobile game than. If you want to use c++ your best bet is to learh how to use railib so go see how that works
Going to watch for it, thanks a lot for your answer, really appreciate ! :)@@lowlevelgamedev9330
Godot is free as in FREEDOM. If you don't feel capable of maintaining a fork that only adds ONE feature to the engine, how can you then take up the task of making your own ?
Because it's easier to maintain your own than bloat that is godot.
recreating the wheel....
hmm what color is your game?
Is what happened many times because not all wheels are the same...
But what if a wheel isn't what I actually need? What if instead I want a propeller for a boat or a plane? They all do the same thing of making a disc spin but I'm going to get much better and more fulfilling results by learning how to make a propeller myself than try to kitbash a wheel into one
What game is this at 6:43 , is there a video where you cover it more else where on your channel?
yes this one ruclips.net/video/yCVv76_SgV4/видео.htmlsi=UbUukYiBBsi8gCAG
I hope you will like it 💪💪
Your game looks pretty cool! Is there a release date?
thanks. In hopefully a month and a few days 💪
I'm the only one that I don't believe you ?
As much as like the idea to have the exact I need for my project I don't even want to imagine how hard can the be to make all the pre existing part's for scratch and make my game on top off that
For example in the fps game I'm working now the option to import my blender 3D models very easily It also have use those tools like map editor ect the egine provide
And many useful toutorials
I don't even want to imagine how hard can the be for solo development like my self that doesn't enjoy codeng that Mach
How can the be to make every system for scratch for 3D model import to image import ECT
Not mateion have hard the be to networking game for it
well it really depends, look for example unreal was built for making multi-player shooters so in your case using an engine is probably better
@@lowlevelgamedev9330 that is my point
For shomene that have big team
Or small scale project and enjoy coding I think may make sense to make i game without egine
But for person that does Big scope project as Solo developer like my self I don't think it makes sense to make all the tools the and game for scratch
It makes more sense to use game engine even if already found those limitesion those egine have
@@watercat1248 The purpose of this video wasn't to say that building a game from scratch is always the better option, or that you should never use game engines. There are pros and cons to both, but it is recommended to give it a go at least once. Knowing how engines work behind the scenes give a deeper understanding and provides skills that are transferable to other engines. But you're right - creating games from scratch isn't necessary for everyone. But if you have the time and patience, it does have its benefits even for large scale projects. Just do what's best for you for each project you make
@@kplays_6000 that makes sense thanks
I am making a game engine in python with C/C++ game dev library but I am using the python version of the C/C++ game dev library like imgui, jolt physics engine, ogre graphics rendering engine, vulkan, bullet physics engine and other C/C++ library and I am using pygame pyglet for 2D and 3D game framework for the game engine. The game engine will be for simple 2D and complex 3D games.. Is python a good programming language to make a game engine with a programming experience in python and no experience in objective C, C++, C# and Java 0:03 ❤🎉😊
it is
easy answer 😂
@@lowlevelgamedev9330 You know, sometimes simple answers are not that good.
Well the name Pika is seems like already owned by another software
oh well after a quick search it seems like it but apperently pika is a sware word in Portugese or something so I'm glad I wasn't the only one to get trolled by this name :)))
It’s Easy to Create an App for Creating Games
There is something wrong in devs that use Unity, Unreal, or similars, to create their retro pixel-art platform game...
😂 true
If you dont have that accent its hard
fair point 😂😅
I want to see all this in Zig
I'll do one in the future but yes zig is the next language for game dev
Oh also bevt is not 1.0 yet which means it lacks many things.
0:04 🗿
🗿++
bravo frate
💪💪
interesting video, but the point about unity platformers feeling similar is pretty ridiculous. you can change the gravity scale or turn it off and code the player movement manually while still using their physics for collision and other physics objects.
It sounds like this video is on 3x speed
😂😂😂😂 People tell me that a lot
I'm going to try making a game engine made using Java and lwjgll,
depends on what you count a *game engine* making a little game with SDL is ezpz, and you could totally consider it an "engine" the only things abstracted for you are some tedious win32 api calls
This comment isn't about engines, but jow did yall learn coding. I can't seem to learn coding, it feels impossible for me
ok so one of my first videos from my channel is called how to learn cpp for game developement and I also have a newer one called how to start or continue learning cpp. Watch those because I answer your question there. Also I will give you a bonus guide to have a mentor, someone that know more than you so you can learn from him. Good luck you can do it 💪
Its my finals rn so i cant start anything. After my finals ill start OpenGL but the problem is windowns compiler does not support OpenGL with Codeblocks. But linux does so i have to switch to linux (some people might say i can use VS, but it looks too complex and i rather stick to something simple like codeblocks)
nono don't switch to linux. If you want to do gamedev you should use wondows. Also linux is funny with opengl :)). Now if you want to be a programmer you should switch to visual studio it is what it is. I have some videos called easiest way to setup opengl or start making your cpp game now that give you a framework already configured with opengl. Lastly, codeblocks is just a text editor. There is nothing special about it. You can use opengl with codeblocks. The easiest way to start learning opengl in my oppinion is to just take my template (from my video called easiest way to setup oepngl) because configuring libraries is annoying. However that is not a reason to switch your os. (also with cmske libraries are easier to configure)
How many of you who are recommending making your own engine have a successful game studio?
T h i s.
None of em. People who recommended making an engine are hobbyist programmers trying to get other people to make their own hobby project. Perfectly fine, but you can't make a "bad" game engine. But you can make a bad game. So it puts distance between you and getting to the point where you can be judged.
I can name a handful of well known indie games that made their own engines and reached a full release. Noita and Rain World especially wouldn't have been possible if they were chained down to the limitations of a conventional general purpose engine
@@ultimate9056 yeah a handful vs how many that didn't make their own engine, unless its required for a specific idea its very bad advice IMO.
not difficult but redundant.
I made a game engine in Rust.
What do you think about D language? give a try
yes heared about it but never tried it
stop the cap, engine dev is hard and the time you would put into engine development could be invested in actual gameplay programming. But if you enjoy engine dev and have the time and budget to invest your time into creating tools then I too can recommend it over using a ready made game engine, if your game is simple enough, for example 2d and no 3d mmorgb. I am also creating a game engine with editor and I love it, but I the 3d horror game I am creating is in a full game engine.
I have little respect for those who can’t make their own engine and work in game dev
Cool you have little respect for everyone except codemonkeys who don't even make any games they tinker with amount of triangles the homebrewed engine can shit out per frame while actual gamedevs just point and click assets in.
@@shinobuoshino5066 why are you so bent over this lmao
@@juniuwu "you are right" takes less time to type, keep coping about it.
@@shinobuoshino5066 who's coping? im not the one malding on a youtube comments section lmao
@@juniuwu keep coping troon
But it is really, really, really stupid. If the goal is to make a good game, abandon your programmer ego where you need everything to be perfect and just use a damn engine. You're gonna abandon the project within 2 years anyway statistically speaking, you might as well make a game in less time than that.
Not with ChatGPT
No its not hard to make a shitty engine, its impossible however, to make another Unreal Engine unless you have a billion USD and a decade of time.
It's the biggest waste of time ever, time better spent actually trying to create something good. Especially considering studios that spend millions on their own engines that are subpar to UE 4. And make their games look worse and feel worse. All that to save 5%? It's so unbelievably stupid, people spending more money and time on creating something a lot worse.
Its never easier to build anything from scratch. If you need custom movement/physics/sims whatever just create them in the engine and plug them in.
If its all you need then odds are never anything serious and its a waste of time in the first place. Might as well call it a hobby.
I honestly think people who make game engines and people who make games should never be the same people, ever. And exceptions are very very very specific.
Unless your game looks like it was made in 1980s then I guess it doesn't matter.
But if that's what you are doing you would probably never reach UE or even Unity thresholds for them to start charging you so the engine is free for you anyway 😅😅😅
On a side note, I don't know about unity that much but in UE absolutely no limits on creating large worlds. Not to mention if properly configured everything loads perfectly in 80 million km^2 without LODs. (Since 5.1.1) And you can have perfectly fine no loading screen experience in the entire world.
I honestly think building your own game engine is the dumbest advice people that have nothing better to do keep giving to people who actually want to create games.
And I can go as far as saying it's for people who actually can't make a game that's fun and entertaining, so they waste their time on all that crap. Trying to solve problems that no one else had.
probably you won't reach Unreal or unity graphics for an open world by yourself and unreal especially looks nice but the people who will mentain those tools are people that know how to build an engine
@@lowlevelgamedev9330 Yes, thats the point. Engine devs maintain the engines and make them better by adding new tools for game devs. And game devs use the tools to make fun experiences.
What I meant is those 2 should not mix. (in all serious applications and most scenarios in general it's just not practical)
Pilots don't learn to build airplanes and Boeing engineers are not pilots.
Because that way a lot of time is being wasted to re-inventing a worse version of the wheel.
And I do believe giving advice to people who want to build games to build their own engine is dishonest to what they want to achieve and to the quality of what they will get.
But that's just me, if people really want to do this by some weird reason. Thats their problems and choices.
@@yushkovyaroslav lol you really just compared building a game to flying a plane?
@@shinobuoshino5066 Have you ever heard of Flight Simulators? Not to mention flight computers.
But regardless my point had more to do with the perspective.
We use similar logic in a lot of things that seem unrelated.
@@yushkovyaroslav not sure who is "we" but that doesn't include me. Flight Simulators exist to test knowledge of pilot and nothing more, also incomparable to flying the real thing.
.
it is not that difficult because you are relying on code made by others too much, also naively underestimate your background experience and your lifetime. thefore some people find difficult using Windows, others find difficult using linux, etc, so don't underestimate your background.
This video convinced me to not make a game.
Good choice, making games is boring. Playing them is much more fun.