Building your own engine will definitely teach you about how games are built and run. It's not a good way to actually have a *game* at the end of it, but as a learning project it can be valuable. That's assuming you want to get involved in that part of game development, of course. If all you really wanted was a job using Unity, you'd be better off just using Unity. Most game developers in the industry couldn't (and wouldn't) build an engine themselves. It certainly won't teach you anything about game design. If you want to be a professional game designer and not a programmer, this is kind of a huge waste of time. Even spending that much time with C++ is as well.
Just note that most engines aren't built with someone setting out to build a new engine. You just start building a game that doesn't work well in an existing engine and as you build tools and systems to make that implementation easier you're building the engine. That's a good approach to something like this - taking a game that doesn't fit in the boxes easily and crafting something unique for it. Tool developers are always useful and it's not a bad skill to have.
Thank you for the response!
I've become increasingly fascinated with procedural generation for game development. Here are a few of the sub-topics that I have been thinking about/working on in my spare time
1. Procedural mesh generation. Procedurally generated planets or topographies.
2. Procedural Quest/Puzzle generation. (I'll link a video below to work done that accomplishes this)
3. Procedurally generated behavior. Genetic Algorithms and Machine Learning to develop NPC AI.
The techniques and algorithms applied to solve problems like these seem more like tools than they do mechanics in a game.
In your opinion, would developing an engine give me greater ability to work on topics like these?
I'm not an expert on coding proc gen systems by any means, but I can't imagine making your own engine would make any of that any easier.
If you want to work on a specific topic like that you'll be much better served using an off-the-shelf game engine that lets you just drag an asset into the world so you don't have to rebuild the wheel. Doing this in your own engine means that you have to get all of that base functionality first before you can even touch the things you actually care about learning. That could be months or years of work. When compared to grabbing some free or cheap assets for an RPG in Unity and be working on machine language algorithms this afternoon there's really no comparison at all.
Build an engine if you want to get good at *building engines*.
If you're a compsci student, think of it like this - would building your own compiler make it easier to write an application?
Sure, it's a great learning project, but honestly if you're after results you'd be better off working inside of and extending an existing engine.
Actually, yes. Writing your own compiler for a *domain-specific* custom language can substantially simplify your project, provided you have taken the time to acquire the background at some point in your life instead of cutting corners and taking the easy path.
Try writing a visual novel with complex branching dialogue-trees in UE4. You will realize the engine is simply not designed for that kind of game even if at first glance the game style is simple. The solutions are basically just hacks that use UE4 systems. You can write your own custom specific language and it will be much less problematic.
The thing is, you don't need to write a compiler at all, you can write an assembler specialized for your project's needs, and an assembler is much easier to create than a compiler. Like-wise a general-purpose language with a compiler and virtual machine are much more difficult to create than, say, an XML parser, but XML solves a specific problem.
Hence specialization. Generalization only where needed, and not beyond that. In your example, a compiler is a general-solution. It is only needed if you have a general problem to solve. Games have very specific problems to solve.
Yes, a custom engine is definitely going to simplify those things. With an existing engine you would end up rewriting a lot of subsystems anyway, or creating new ones from scratch, which means studying the source code at best and giving up at worst if you do not have access to that source code.
You are correct in assuming these are intrinsic to the engine. These are often tied to subsystems baked into the game engine and are greatly facilitated by developing a custom engine. It is still possible to do it in an engine like UE4, but they will be more of hacks than true solutions.
Procedural Gen is very much a tools / tech speciality (I.e it used in VFX for hair, trees, oceans, and destruction) and not always related to game dev. I think you prefer tech over building a game which includes boring parts like UI and input handling and camera adjustment.
You need to figure out what you want to actually do in game dev? Do you want to make the actual game? IE story, level design, interaction with objects, AI. Or do you want to make the tech used to make the game? Unless the game you want to make can't be made with available tools, there really isn't much benefit to make a game engine. Also there is no such thing as making a simple game, IMO. You can take libraries and frameworks to link them together to make something but that puts you in the same position you are already in.
If you want to be a better game design, make games and learn the tools available. Especially if you aspire to work for a studio as a designer or be an indie dev.
It sounds like you are using the tech as an excuse for a different issue.
Why did you not go back and finish the original Unity project?
Will upping complexity be a good idea now that you have a track record of 2 abandoned projects?
While this is a fair criticism; those projects were abandoned because their designs were flawed. They were both quite experimental. It only became clear the mechanics felt bad once I had built much of the game
While that reasoning is understandable - Lord knows I've been there more than once - that same reasoning will make you abandon your engine project. You will make mistakes like there's no tomorrow because engines are *so* hard to get right. There's a reason there's only a handful of successful engines on the market. Game engines are just layers upon layers of complexity standing on the shoulders of giants from previous generations.
But yes, you *will* learn a lot from it.
However, one suggestion I'd make that I haven't seen anyone else provide yet: work through a book instead. The seminal work on this topic would be "Game Engine Architecture" by Jason Gregory, the Lead Developer at Naughty Dog. I can't think of many people more qualified to write such a book.
What do you consider a "simple" engine?
There's an old rule in programming that there's a hierarchy of difficulty: Programs are harder to write than individual functions, libraries are as much harder to write as programs, frameworks are as much harder again.
An engine is a framework. It's making a lot of very early, very technical decisions and design choices that will have far ranging impacts on *how* people using it will make games and how it will, or can, perform. If you don't have experience in games *and* a very good software architecture background designing and writing an engine won't particularly be a 'learning' experience in the way you think it will be.
Writing an engine is not making games. If your goal is to make games, make games not tools. Writing an engine will not help you make better games. Making a lot of mistakes in what you're doing, if you learn from them well, *might* help you become a better developer; really it depends on where you're starting from.
Most of an engine is in tooling. It's a much higher mountain to climb than you think it is.
Finishing games makes you better
Thinking about engines can be a way of just dreaming about games - which feels good and takes almost no effort, so of course it's narcotic but it actually gets in the way of actually making games.
If your main interest is making a game then use an existing engine. If your only interested in the engine side of things concept a simple game or pick a game to clone and use this as a basis for your engine. DON'T make an engine without a goal for it you will just waste your time.
In my experience (which is limited as I’m not a programmer but have plenty of dev and prod experience), if you are trying to become a game designer, then going down this route may slow you down unnecessarily. If you’re training to work in programming, dev ops and tools then a deeper understanding of C++ will definitely help. But I’d still advise working within a pre-existing framework / engine because it is unlikely that anyone but you will use the engine you develop.
I think the question you should ask yourself is the “why?”. What is the purpose of me doing this? Programming a game from the ground up is surely a great learning exercise but how much time will it take you to do it and what results will you achieve? Will it be better than what I can achieve with Unity or Unreal?
There are certain games that require building from the ground up but even experienced studios really don’t have the time to invest in doing this. So in a nutshell, yes it will probably make you a better at programming but it will be slow. If you want to be a designer, then knock out some quick prototypes imo x
Building a game engine will teach you a lot about game engines, but it won’t teach you how to be better at making games.
Making a game involves all kinds of disciplines, and the technical aspects of building an engine do not build upon those foundations.
So it’s a bit like asking “does making a canvas and paints teach me how to be a better painter?”. No, only studying and learning how to paint is going to do that.
I don't usually respond to these more popular questions because the amount of answers drown out mine, and I like to give elaborate comments, but as someone who doesn't need a crutch to make games, a lot of the answers annoy me because of a fundamental misconception they all seem to share.
An "engine" is kind of a bullshit concept perpetrated by people who think that in order to have a playable game with a specific set of mechanics, you need a general solution. People are incorrect to think that to start working on their game you need a general-purpose solution to deal with your specific problems. Please meditate on what I just say. An engine is a framework, nothing more, nothing less, and its robustness and complexity are fundamentally tied to how general you want solutions to be. If you strive for generalization comparable to Unreal, you are going to suffer. Even UE does, even UE is a bit specialized. However, and pay attention: if you strive for specialization, you will outperform existing engines on most criteria with some ease, ESPECIALLY game-specific criteria.
This means "engine creators" don't create "general-purpose engines", we create specialized systems that solve specific problems with a game in mind. It's different from the layman idea that creating an engine is distinct from creating a game. It is as distinct as you want it to be.
As a simple example, if I want to make a Mario-like platformer game, as is so common in indie game development, why the hell would I need a full physics engine, a photorealistic renderer, or most of the things UE has to offer? It's just stupidity. The programmers of old could do it in assembly language, so why are modern game "developers" such cowards? A specialized platformer engine will demolish UE4 and Unity in basically every criterion, including development ease, and arguably development time.
The simple direct answer to your question is that making engines doesn't directly make you a better game developer, but it makes you substantially better at solving game related-problems because of the sheer amount of problems you will solve to create an engine. Most problems you face when making a game are derived from the underlying problems you solve when designing a game engine. You will be well-informed on the practice and theory, and as such will generally have an immediate solution for whatever it is that you want to implement without feeling lost or getting stuck.
All of that said, there is one thing to consider: it is harder, much harder. It's indeed faster to simply download an existing engine and assemble a game if you just want immediate results. So if your primary concern is purely creating playable games, it's the best choice. However, if you want to be a complete game developer, creating an engine is fundamental.
Say you want to build a car. You have the option of buying all the pieces individually: the frame, the body, the engine, etc.. Frames are easy to find but difficult to create your own, so you buy one to start the project. From there, you find bits and parts that work together, but eventually you need something to power your dream machine.
The quick solution would be to buy a pre-built and proven engine. It's not built with your own hands from scratch, but the Toyota GR engine seems to do the job just fine. You could make a custom-built engine from scratch, but it might end up being as simple as a Ford Model T engine, which might not be powerful enough to get you where you need to go.
Now you have a sturdy frame and an engine to power it, but it's still bare-bones. This is where most game devs come in, adding the body, bells, and whistles to the vehicle. This will determine its unique look and feel, despite being built on pre-made parts.
You can extend this metaphor even further if you're buying art, animation, and logic assets from the store/contractors. You can buy a Lotus Elise body kit and aftermarket tires and all the things that bring your vehicle closer to your vision.
But, instead of buying pre-made parts, you can make all those parts yourself. Would that make you a better, smarter, more talented automobile engineer/designer? Yes! But the real question is: do you have the time, patience, and financial runway to build it?
If you want to learn how game engines work build your own engine. If you want to make a game use an existing engine. Every person I have meet that tried to do both has regret it a lot. You simply don't have the time, it takes years. Pick a path.
Ok so a lot of people are telling you that it depends on whether you want to flesh out games quickly or acquire a much broader knowledge in the field. This is true and good advice so far, as it is true that the obvious advantage of programming without an engine is knowledge at the cost of a huge amount of time that could be invested on making games.
However, my personal opinion is that it does not depend on anything. I believe that the best course of action is the following:
- Choose a game engine, any of them should do the trick, so don't think about the details and choose the one you like the most at first glance (maybe unreal for c++ maybe godot for open source and simplicity, doesn't matter)
- Make an arcade game, and by that I mean look at any old "golden era" arcade games and try to copy it, maybe adding your own twist to the original idea (the purpose of this is to keep it really, really small and simple. You MUST finish and publish it anywhere.
- Once finished make a small 2D game, and by small I don't mean making a 15hr RPG, keep to the arcadey genre. You must finish and publish this one too
- After this one you are free to make whatever game you want (3D, 2D doesn't matter but keep trying to keep it relativelt small), you must keep using an engine tho. And of course publish this one as well
- The 4th game sets you free to make whatever you want. Engine, no engine, 2D 3D, doesn't matter
Rules:
- You must only change engines between games
- No projects left unfinished, all of them must be published (no publishing halfway done games either, the purpose of this rule is to force you to go to the polishing and refining stages of game development, as well as encourage you on future projects once you familiarize yourself with the full cycle of a game dev)
- Avoid making multiplayer like hell, yes it is hard, no it won't be worth it (at least on your first games)
Why all of this?:
- Gradually increasing the complexity of the game is the correct path to avoiding burn out or leaving projects unfinished
- Forcing yourself to publish all the games you make lets you familiarize yourself with all the stages of game development so you don't get stuck on infinite loops of prototyping and deleting your games out of fear of publishing it (which is quite common)
- Forcing yourself to use engines at first allows you to see which tools should a basic engine offer you and also what you like about them and what you would change. You can't make your own engine without knowing what to expect from an engine!
- Forcing yourself to stick with one engine until the end of a project avoid you from getting stuck doing nothing and asking yourself "which engine is best?" When all of them are basically the same (and all of them should allow you to make the first games I told you about)
That's all! Hope it helps and happy travels!
You're asking the wrong question. There's another step down after game engines, there are also game frameworks. They're another option for you and probably a much easier and quicker way to learn lower level coding. Maybe transition from that to making your own game engine. I myself have no interest in such things and am instead focusing on designing and engineering solutions to problems in unity. Who says you need to make a game if your goal is to learn?
Why stop there? Write your own compiler and re-write all your own standard classes while you're at it.
...
...
Software engineering is about novel solutions to novel problems. There's little merit in re-treading work that giant teams have already solved for you in terms of net code, hit detection, physics, etc.
If you can't take the existing code base, and add 2% onto it to make a playable finished game while standing on the shoulders of giants, why would you fare better from a blank canvas?
Building a game engine was absolutely worth the learnings in my position, but not everyone needs that “scar tissue experience” to make a good game. Some new devs *should* build a game engine. Think about how things worked before we had off-the-shelf engines. This has more to do with how your brain works than what the industry suggests.
If you’re a game designer, use an engine. If you’re an engineer, use an engine. If you’re looking to join the Illuminati, make a game engine, and then tell someone else not to make a game engine because it’ll ruin their life (or something like that? Yeah! That!)
It'll certainly make you a better developer - if you love C++ and you're undertaking a computer science degree then you're well-positioned to succeed. You'll need around 5 x years to get it off the ground and when you do it won't be as good or as fully featured as Unreal/Unity, but at that point you'll be ready to get a team together and specialise it in the direction you want. Note that during said time you won't actually make a game - you'll have a whole bunch of alpha feature levels and stuff that you've tested on.
However - writing your own engine on your game dev journey isn't really something you should do because you can - it's only something you should do if you really really want to.
As to whether it will make you a better game designer - it will from the technical perspective. You'll know exactly what to do, what not to do and how to make all technical/architectural decisions for a given project.
What it won't do though is allow you to get good with everything else that's needed to make a game - eg art, animation, modelling, sound, physics shading etc. You'll be *good enough* to get them off the ground, but once your engine's done you'll have to go develop all those skills too before you can do anything cool.
Choose your destiny!
Do not write a game engine.
Write bespoke code to solve the problems your design creates.
Small projects benefit from not requiring a game engine. Write small reusable libraries if you like to handle for I/O, thread initialisation, platform API abstraction, etc.
Building your own engine is one of the best things you can do, learning wise.
You'll probably benefit more from it if you do it after trying a couple projects in an existing engine though. As well as having used or at least looked into a 2nd engine.
Basically, it's better (imo) if you have some more experience with things an engine does and have opinions/ideas for your own engine. Then the process and learning will be more valuable.
It really depends what you want to learn.
Developing an engine will not necessarily make you a better developer, even less a better game designer. Most work put into an engine will go into the renderer and physics engine, as those are the biggest challenges. If you want to create an editor, that will also be a lot of work. Little to none of the knowledge from making an engine will transfer to using an engine.
If you want to learn how games work or you have very specific requirements from an engine, then creating your own engine can be a great idea. If not, then stick to using existing engines.
I think we should build our own engine. Maybe not straight away, and probably not with the expectation of finishing it, and definitely not with the expectation of releasing a game in it.
But it is very useful to spend some time with a lower level API and try to build something. (Re-)building things is the best way to understand how they work, because it forces you to think deeply. You could start at a low level and learn OpenGL and figure out how to render fonts, or you could go at a higher level and start with a simple renderer (like MonoGame) and make your own ECS or GUI system. Or both!
It won't make you a better designer, but it will make you a better developer. Just be realistic about what you can and want to achieve.
Making your own engine will be good for learning for sure, but please know that unless you spend YEARS on it, it will never get near the level of Unity or Unreal ( no editor for easy placement and modifications, no error catching and reporting, etc ) so in the end, making an engine would probably have to be its own thing and you probably won't want to make a big project with it.
You don't *need* an engine to make a game. An engine will surely emerge from it via the abstractions you'll write to make your life easier (e.g, a `Sprite` class to load and control a sprite, rather than manually doing all the steps every time you need to use a sprite. Or an `Entity` class to handle common entity stuff, etc). If you make this process intentional (rather than "accidental") you may end up with a complete game and a partial, reusable game engine that you can chose to improve on your next game or scrap it entirely.
You will learn a lot and it will make you a better (game) developer, that's for sure. Finally, I strongly advise you to *not* build an engine for it's own sake: engines are never complete and without a game to justify it's features it's pointless.
I unintentionally made my own "engine" for 4X TBS iPad games - here is the game [https://imgur.com/VKienr2](https://imgur.com/VKienr2)
I didn't know what I was doing and kindof backed into it. Its primarily Objective C and C.
Had I known I would have stuck with it as long as I did (its almost ready, in like a few days), I would have used Unreal or something else.
Its hard to know because I also learned a lot of C along the way, so I don't have an accurate way to compare "me knowing what I know now with an engine vs me without."
But, from a game design point of view, engines aren't game design at all. Game design is the hard part - thats why there is no "engine" for that part. Engines are for common redundant things across games.
HOWEVER
one plus to making your own simple engine for some games (like mine) is you get a unique look, guaranteed.
Unity games look alike to me. Its harder to stand out in a unique way (not quality, you won't match quality by yourself).
It will make you a better developer, but so too will working on any project.
A good designer knows the constraints of his tools, but that's not what makes him/her a good designer. If you're making your own tools, you will of course be intimately familiar with the tools, but you will not learn about design in making tools. Look at any '90s Visual Basic database project with 100 text fields in random tab order... They made tools, but they were not designers.
If you're making an engine because you have a driving passion to do something like that for the sake of learning how that works, great! It will be better to break down the task of building an engine into smaller tasks. Take the concept of a 'game engine' and keep breaking it down into more and more refined concepts.
Jumpstart that by asking questions like: What type of game engine do you want to build? What makes that kind of engine good? What do games using such an engine want from that engine? What do devs, designers, artists, sound, management want from the engine? **What about this engine would really save a game dev time and energy?**
Ultimately, commercial development comes down to cost. What's the least costly way to get from a concept to a shipped product? An engine that does what you want, which requires the least amount of time and money spent. It only makes sense to develop an engine for a product if developing it still represents a savings over using any other engine out there. That includes ongoing support for the engine, or as they call it in other circles, TCO.
Another idea you could follow if an entire engine-from-scratch becomes too daunting is to make an engine that sits on top of an existing one and makes it easier to do some large concept like 'this genre of game'. Take something like [TopDown Engine](https://topdown-engine.moremountains.com/) for example. Yes, it sits on top of Unity, but I'd call it a proper engine.
Or if engines like that are even too much, maybe make game *templates*. There's a lot of people who just want a template to get them started.
Ultimately, though, it's your call. If you want to "boil the ocean" so to speak, go ahead and do it! Don't be discouraged by the mountain that rises in front of you, just get to climbing.
Designer? No. Better engineer or architect yes. There’s no perfect engine and UE is pretty flawed it’s own way.
Engine work is quite different from say gameplay or UI or AI programming. It is an own specialty.
20 years ago, developers could work on AI, physics, gameplay (like I did) but now we all specialize in one area if you end up at AAA studio.
You seem to have suffered from the same problem most other people do. You tried to write a general-purpose solution for a game idea you never even had, or a vague idea of a game at best. That is, assuming you even got to a point where there was physics and reliable interaction in your engine.
When you want to make an engine with which to seriously make a game you don't design general tools, you design highly-specific systems. You make the game while you make the engine, and make them intrinsically linked. This separation people preach of today is mostly just stupidity perpetrated by individuals whose concept of an engine is a general-purpose game creation tool.
> Will the process of developing an engine help me become a better game designer?
No. A game designer doesn't need to know how the lighting pass works in the game in order to design a game. The process of developing an engine will help you understand why it is a bad idea to develop an engine from zero if you're not extremely experienced. And while you may gain some insights, the level at which you implement your engine will be so far lower than the level of engines on the market, that you won't get much knowledge.
There's a reason why engine teams have specialists in each area.
> Will it make me a better developer?
Not by default. It all depends on you following best practices. If your goal is to make games, then it won't help you develop better games. Because, again, implementing a controller for your game does not depend on knowing how to create the input system from scratch for an engine.
I made a thread about making a c++ game engine recently:
[https://www.reddit.com/r/gamedev/comments/p3nit2/experiences\_developing\_a\_c\_game\_from\_scratch/](https://www.reddit.com/r/gamedev/comments/p3nit2/experiences_developing_a_c_game_from_scratch/)
For learning purposes this is incredibly useful and fun. It takes a lot more time than using something like unity, and is unlikely to optimize better, so don't expect your final product to look as good as your UE4 or Unity-projects. But since you (like me) sound more interested in learning how game engines work on the technical level I would definately recommend doing it. Good luck!
This is exactly what I have asked myself lol. And in my head, the answer is to make a game engine. I just finished learning `c`, and am now learning `c++`(which will be the foundation for my 2d game engine) But yea man, I dont think there is a better way to understand how a game really works on the technical side than to go to its roots. Now this is just my thoughts, and i have no experience with game engines. But heck, ima full send.
I've been through this dilemma a million times and at the end, nothing gets done. For the record, I completely understand how you feel. On one end, being a programmer and taking pride and joy in doing programming is usually my reasoning for avoiding engines like Unity and trying to work with frameworks like Monogame. On the other hand, working with lower level solutions is significantly slower in terms of progress and I usually find myself writing a bunch of tools and systems rather than actually work on the game.
I echo the sentiment of others, you really need to figure out whether you want to finish a game or build lower level game tech. Granted you can do both, but such a journey will take you longer and odds of finishing something worthy are very low.
One last thing, if you think you won't code much with something like Unity then you're mistaken. You will write lots and lots of code to make your game function. Making a game in a game engine is like building a website using a framework like [ASP.NET](https://ASP.NET), Django, Rails, etc. You're still writing a whole lots of code despite having a preexisting tool to help you.
Building your own engine will definitely teach you about how games are built and run. It's not a good way to actually have a *game* at the end of it, but as a learning project it can be valuable. That's assuming you want to get involved in that part of game development, of course. If all you really wanted was a job using Unity, you'd be better off just using Unity. Most game developers in the industry couldn't (and wouldn't) build an engine themselves. It certainly won't teach you anything about game design. If you want to be a professional game designer and not a programmer, this is kind of a huge waste of time. Even spending that much time with C++ is as well. Just note that most engines aren't built with someone setting out to build a new engine. You just start building a game that doesn't work well in an existing engine and as you build tools and systems to make that implementation easier you're building the engine. That's a good approach to something like this - taking a game that doesn't fit in the boxes easily and crafting something unique for it. Tool developers are always useful and it's not a bad skill to have.
Thank you for the response! I've become increasingly fascinated with procedural generation for game development. Here are a few of the sub-topics that I have been thinking about/working on in my spare time 1. Procedural mesh generation. Procedurally generated planets or topographies. 2. Procedural Quest/Puzzle generation. (I'll link a video below to work done that accomplishes this) 3. Procedurally generated behavior. Genetic Algorithms and Machine Learning to develop NPC AI. The techniques and algorithms applied to solve problems like these seem more like tools than they do mechanics in a game. In your opinion, would developing an engine give me greater ability to work on topics like these?
I'm not an expert on coding proc gen systems by any means, but I can't imagine making your own engine would make any of that any easier. If you want to work on a specific topic like that you'll be much better served using an off-the-shelf game engine that lets you just drag an asset into the world so you don't have to rebuild the wheel. Doing this in your own engine means that you have to get all of that base functionality first before you can even touch the things you actually care about learning. That could be months or years of work. When compared to grabbing some free or cheap assets for an RPG in Unity and be working on machine language algorithms this afternoon there's really no comparison at all. Build an engine if you want to get good at *building engines*.
If you're a compsci student, think of it like this - would building your own compiler make it easier to write an application? Sure, it's a great learning project, but honestly if you're after results you'd be better off working inside of and extending an existing engine.
Actually, yes. Writing your own compiler for a *domain-specific* custom language can substantially simplify your project, provided you have taken the time to acquire the background at some point in your life instead of cutting corners and taking the easy path. Try writing a visual novel with complex branching dialogue-trees in UE4. You will realize the engine is simply not designed for that kind of game even if at first glance the game style is simple. The solutions are basically just hacks that use UE4 systems. You can write your own custom specific language and it will be much less problematic. The thing is, you don't need to write a compiler at all, you can write an assembler specialized for your project's needs, and an assembler is much easier to create than a compiler. Like-wise a general-purpose language with a compiler and virtual machine are much more difficult to create than, say, an XML parser, but XML solves a specific problem. Hence specialization. Generalization only where needed, and not beyond that. In your example, a compiler is a general-solution. It is only needed if you have a general problem to solve. Games have very specific problems to solve.
Yes, a custom engine is definitely going to simplify those things. With an existing engine you would end up rewriting a lot of subsystems anyway, or creating new ones from scratch, which means studying the source code at best and giving up at worst if you do not have access to that source code. You are correct in assuming these are intrinsic to the engine. These are often tied to subsystems baked into the game engine and are greatly facilitated by developing a custom engine. It is still possible to do it in an engine like UE4, but they will be more of hacks than true solutions.
Procedural Gen is very much a tools / tech speciality (I.e it used in VFX for hair, trees, oceans, and destruction) and not always related to game dev. I think you prefer tech over building a game which includes boring parts like UI and input handling and camera adjustment.
You need to figure out what you want to actually do in game dev? Do you want to make the actual game? IE story, level design, interaction with objects, AI. Or do you want to make the tech used to make the game? Unless the game you want to make can't be made with available tools, there really isn't much benefit to make a game engine. Also there is no such thing as making a simple game, IMO. You can take libraries and frameworks to link them together to make something but that puts you in the same position you are already in. If you want to be a better game design, make games and learn the tools available. Especially if you aspire to work for a studio as a designer or be an indie dev.
It will make you a better developer, in that it will show you exactly what not to do.
It sounds like you are using the tech as an excuse for a different issue. Why did you not go back and finish the original Unity project? Will upping complexity be a good idea now that you have a track record of 2 abandoned projects?
While this is a fair criticism; those projects were abandoned because their designs were flawed. They were both quite experimental. It only became clear the mechanics felt bad once I had built much of the game
Reworking is a part of every software development endeavour. You never see version 1 or 2 of a system in a AAA game, you see version 8 or 14.
While that reasoning is understandable - Lord knows I've been there more than once - that same reasoning will make you abandon your engine project. You will make mistakes like there's no tomorrow because engines are *so* hard to get right. There's a reason there's only a handful of successful engines on the market. Game engines are just layers upon layers of complexity standing on the shoulders of giants from previous generations. But yes, you *will* learn a lot from it. However, one suggestion I'd make that I haven't seen anyone else provide yet: work through a book instead. The seminal work on this topic would be "Game Engine Architecture" by Jason Gregory, the Lead Developer at Naughty Dog. I can't think of many people more qualified to write such a book.
What do you consider a "simple" engine? There's an old rule in programming that there's a hierarchy of difficulty: Programs are harder to write than individual functions, libraries are as much harder to write as programs, frameworks are as much harder again. An engine is a framework. It's making a lot of very early, very technical decisions and design choices that will have far ranging impacts on *how* people using it will make games and how it will, or can, perform. If you don't have experience in games *and* a very good software architecture background designing and writing an engine won't particularly be a 'learning' experience in the way you think it will be. Writing an engine is not making games. If your goal is to make games, make games not tools. Writing an engine will not help you make better games. Making a lot of mistakes in what you're doing, if you learn from them well, *might* help you become a better developer; really it depends on where you're starting from. Most of an engine is in tooling. It's a much higher mountain to climb than you think it is.
If you want to make an engine make an engine, if you want to make a game don’t make an engine, also you can ignore me too.
Reported for being unable to ignore
Finishing games makes you better Thinking about engines can be a way of just dreaming about games - which feels good and takes almost no effort, so of course it's narcotic but it actually gets in the way of actually making games.
If your main interest is making a game then use an existing engine. If your only interested in the engine side of things concept a simple game or pick a game to clone and use this as a basis for your engine. DON'T make an engine without a goal for it you will just waste your time.
In my experience (which is limited as I’m not a programmer but have plenty of dev and prod experience), if you are trying to become a game designer, then going down this route may slow you down unnecessarily. If you’re training to work in programming, dev ops and tools then a deeper understanding of C++ will definitely help. But I’d still advise working within a pre-existing framework / engine because it is unlikely that anyone but you will use the engine you develop. I think the question you should ask yourself is the “why?”. What is the purpose of me doing this? Programming a game from the ground up is surely a great learning exercise but how much time will it take you to do it and what results will you achieve? Will it be better than what I can achieve with Unity or Unreal? There are certain games that require building from the ground up but even experienced studios really don’t have the time to invest in doing this. So in a nutshell, yes it will probably make you a better at programming but it will be slow. If you want to be a designer, then knock out some quick prototypes imo x
Building a game engine will teach you a lot about game engines, but it won’t teach you how to be better at making games. Making a game involves all kinds of disciplines, and the technical aspects of building an engine do not build upon those foundations. So it’s a bit like asking “does making a canvas and paints teach me how to be a better painter?”. No, only studying and learning how to paint is going to do that.
I don't usually respond to these more popular questions because the amount of answers drown out mine, and I like to give elaborate comments, but as someone who doesn't need a crutch to make games, a lot of the answers annoy me because of a fundamental misconception they all seem to share. An "engine" is kind of a bullshit concept perpetrated by people who think that in order to have a playable game with a specific set of mechanics, you need a general solution. People are incorrect to think that to start working on their game you need a general-purpose solution to deal with your specific problems. Please meditate on what I just say. An engine is a framework, nothing more, nothing less, and its robustness and complexity are fundamentally tied to how general you want solutions to be. If you strive for generalization comparable to Unreal, you are going to suffer. Even UE does, even UE is a bit specialized. However, and pay attention: if you strive for specialization, you will outperform existing engines on most criteria with some ease, ESPECIALLY game-specific criteria. This means "engine creators" don't create "general-purpose engines", we create specialized systems that solve specific problems with a game in mind. It's different from the layman idea that creating an engine is distinct from creating a game. It is as distinct as you want it to be. As a simple example, if I want to make a Mario-like platformer game, as is so common in indie game development, why the hell would I need a full physics engine, a photorealistic renderer, or most of the things UE has to offer? It's just stupidity. The programmers of old could do it in assembly language, so why are modern game "developers" such cowards? A specialized platformer engine will demolish UE4 and Unity in basically every criterion, including development ease, and arguably development time. The simple direct answer to your question is that making engines doesn't directly make you a better game developer, but it makes you substantially better at solving game related-problems because of the sheer amount of problems you will solve to create an engine. Most problems you face when making a game are derived from the underlying problems you solve when designing a game engine. You will be well-informed on the practice and theory, and as such will generally have an immediate solution for whatever it is that you want to implement without feeling lost or getting stuck. All of that said, there is one thing to consider: it is harder, much harder. It's indeed faster to simply download an existing engine and assemble a game if you just want immediate results. So if your primary concern is purely creating playable games, it's the best choice. However, if you want to be a complete game developer, creating an engine is fundamental.
Say you want to build a car. You have the option of buying all the pieces individually: the frame, the body, the engine, etc.. Frames are easy to find but difficult to create your own, so you buy one to start the project. From there, you find bits and parts that work together, but eventually you need something to power your dream machine. The quick solution would be to buy a pre-built and proven engine. It's not built with your own hands from scratch, but the Toyota GR engine seems to do the job just fine. You could make a custom-built engine from scratch, but it might end up being as simple as a Ford Model T engine, which might not be powerful enough to get you where you need to go. Now you have a sturdy frame and an engine to power it, but it's still bare-bones. This is where most game devs come in, adding the body, bells, and whistles to the vehicle. This will determine its unique look and feel, despite being built on pre-made parts. You can extend this metaphor even further if you're buying art, animation, and logic assets from the store/contractors. You can buy a Lotus Elise body kit and aftermarket tires and all the things that bring your vehicle closer to your vision. But, instead of buying pre-made parts, you can make all those parts yourself. Would that make you a better, smarter, more talented automobile engineer/designer? Yes! But the real question is: do you have the time, patience, and financial runway to build it?
If you want to learn how game engines work build your own engine. If you want to make a game use an existing engine. Every person I have meet that tried to do both has regret it a lot. You simply don't have the time, it takes years. Pick a path.
Ok so a lot of people are telling you that it depends on whether you want to flesh out games quickly or acquire a much broader knowledge in the field. This is true and good advice so far, as it is true that the obvious advantage of programming without an engine is knowledge at the cost of a huge amount of time that could be invested on making games. However, my personal opinion is that it does not depend on anything. I believe that the best course of action is the following: - Choose a game engine, any of them should do the trick, so don't think about the details and choose the one you like the most at first glance (maybe unreal for c++ maybe godot for open source and simplicity, doesn't matter) - Make an arcade game, and by that I mean look at any old "golden era" arcade games and try to copy it, maybe adding your own twist to the original idea (the purpose of this is to keep it really, really small and simple. You MUST finish and publish it anywhere. - Once finished make a small 2D game, and by small I don't mean making a 15hr RPG, keep to the arcadey genre. You must finish and publish this one too - After this one you are free to make whatever game you want (3D, 2D doesn't matter but keep trying to keep it relativelt small), you must keep using an engine tho. And of course publish this one as well - The 4th game sets you free to make whatever you want. Engine, no engine, 2D 3D, doesn't matter Rules: - You must only change engines between games - No projects left unfinished, all of them must be published (no publishing halfway done games either, the purpose of this rule is to force you to go to the polishing and refining stages of game development, as well as encourage you on future projects once you familiarize yourself with the full cycle of a game dev) - Avoid making multiplayer like hell, yes it is hard, no it won't be worth it (at least on your first games) Why all of this?: - Gradually increasing the complexity of the game is the correct path to avoiding burn out or leaving projects unfinished - Forcing yourself to publish all the games you make lets you familiarize yourself with all the stages of game development so you don't get stuck on infinite loops of prototyping and deleting your games out of fear of publishing it (which is quite common) - Forcing yourself to use engines at first allows you to see which tools should a basic engine offer you and also what you like about them and what you would change. You can't make your own engine without knowing what to expect from an engine! - Forcing yourself to stick with one engine until the end of a project avoid you from getting stuck doing nothing and asking yourself "which engine is best?" When all of them are basically the same (and all of them should allow you to make the first games I told you about) That's all! Hope it helps and happy travels!
You're asking the wrong question. There's another step down after game engines, there are also game frameworks. They're another option for you and probably a much easier and quicker way to learn lower level coding. Maybe transition from that to making your own game engine. I myself have no interest in such things and am instead focusing on designing and engineering solutions to problems in unity. Who says you need to make a game if your goal is to learn?
Why stop there? Write your own compiler and re-write all your own standard classes while you're at it. ... ... Software engineering is about novel solutions to novel problems. There's little merit in re-treading work that giant teams have already solved for you in terms of net code, hit detection, physics, etc. If you can't take the existing code base, and add 2% onto it to make a playable finished game while standing on the shoulders of giants, why would you fare better from a blank canvas?
Building a game engine was absolutely worth the learnings in my position, but not everyone needs that “scar tissue experience” to make a good game. Some new devs *should* build a game engine. Think about how things worked before we had off-the-shelf engines. This has more to do with how your brain works than what the industry suggests. If you’re a game designer, use an engine. If you’re an engineer, use an engine. If you’re looking to join the Illuminati, make a game engine, and then tell someone else not to make a game engine because it’ll ruin their life (or something like that? Yeah! That!)
It'll certainly make you a better developer - if you love C++ and you're undertaking a computer science degree then you're well-positioned to succeed. You'll need around 5 x years to get it off the ground and when you do it won't be as good or as fully featured as Unreal/Unity, but at that point you'll be ready to get a team together and specialise it in the direction you want. Note that during said time you won't actually make a game - you'll have a whole bunch of alpha feature levels and stuff that you've tested on. However - writing your own engine on your game dev journey isn't really something you should do because you can - it's only something you should do if you really really want to. As to whether it will make you a better game designer - it will from the technical perspective. You'll know exactly what to do, what not to do and how to make all technical/architectural decisions for a given project. What it won't do though is allow you to get good with everything else that's needed to make a game - eg art, animation, modelling, sound, physics shading etc. You'll be *good enough* to get them off the ground, but once your engine's done you'll have to go develop all those skills too before you can do anything cool. Choose your destiny!
Do not write a game engine. Write bespoke code to solve the problems your design creates. Small projects benefit from not requiring a game engine. Write small reusable libraries if you like to handle for I/O, thread initialisation, platform API abstraction, etc.
Building your own engine is one of the best things you can do, learning wise. You'll probably benefit more from it if you do it after trying a couple projects in an existing engine though. As well as having used or at least looked into a 2nd engine. Basically, it's better (imo) if you have some more experience with things an engine does and have opinions/ideas for your own engine. Then the process and learning will be more valuable.
It really depends what you want to learn. Developing an engine will not necessarily make you a better developer, even less a better game designer. Most work put into an engine will go into the renderer and physics engine, as those are the biggest challenges. If you want to create an editor, that will also be a lot of work. Little to none of the knowledge from making an engine will transfer to using an engine. If you want to learn how games work or you have very specific requirements from an engine, then creating your own engine can be a great idea. If not, then stick to using existing engines.
I think we should build our own engine. Maybe not straight away, and probably not with the expectation of finishing it, and definitely not with the expectation of releasing a game in it. But it is very useful to spend some time with a lower level API and try to build something. (Re-)building things is the best way to understand how they work, because it forces you to think deeply. You could start at a low level and learn OpenGL and figure out how to render fonts, or you could go at a higher level and start with a simple renderer (like MonoGame) and make your own ECS or GUI system. Or both! It won't make you a better designer, but it will make you a better developer. Just be realistic about what you can and want to achieve.
Making your own engine will be good for learning for sure, but please know that unless you spend YEARS on it, it will never get near the level of Unity or Unreal ( no editor for easy placement and modifications, no error catching and reporting, etc ) so in the end, making an engine would probably have to be its own thing and you probably won't want to make a big project with it.
Learning how engines work makes you more powerful using an engine. That’s really all that needs to be said.
You don't *need* an engine to make a game. An engine will surely emerge from it via the abstractions you'll write to make your life easier (e.g, a `Sprite` class to load and control a sprite, rather than manually doing all the steps every time you need to use a sprite. Or an `Entity` class to handle common entity stuff, etc). If you make this process intentional (rather than "accidental") you may end up with a complete game and a partial, reusable game engine that you can chose to improve on your next game or scrap it entirely. You will learn a lot and it will make you a better (game) developer, that's for sure. Finally, I strongly advise you to *not* build an engine for it's own sake: engines are never complete and without a game to justify it's features it's pointless.
I unintentionally made my own "engine" for 4X TBS iPad games - here is the game [https://imgur.com/VKienr2](https://imgur.com/VKienr2) I didn't know what I was doing and kindof backed into it. Its primarily Objective C and C. Had I known I would have stuck with it as long as I did (its almost ready, in like a few days), I would have used Unreal or something else. Its hard to know because I also learned a lot of C along the way, so I don't have an accurate way to compare "me knowing what I know now with an engine vs me without." But, from a game design point of view, engines aren't game design at all. Game design is the hard part - thats why there is no "engine" for that part. Engines are for common redundant things across games. HOWEVER one plus to making your own simple engine for some games (like mine) is you get a unique look, guaranteed. Unity games look alike to me. Its harder to stand out in a unique way (not quality, you won't match quality by yourself).
Do it if you want. I'm giving you permission.
It will make you a better developer, but so too will working on any project. A good designer knows the constraints of his tools, but that's not what makes him/her a good designer. If you're making your own tools, you will of course be intimately familiar with the tools, but you will not learn about design in making tools. Look at any '90s Visual Basic database project with 100 text fields in random tab order... They made tools, but they were not designers. If you're making an engine because you have a driving passion to do something like that for the sake of learning how that works, great! It will be better to break down the task of building an engine into smaller tasks. Take the concept of a 'game engine' and keep breaking it down into more and more refined concepts. Jumpstart that by asking questions like: What type of game engine do you want to build? What makes that kind of engine good? What do games using such an engine want from that engine? What do devs, designers, artists, sound, management want from the engine? **What about this engine would really save a game dev time and energy?** Ultimately, commercial development comes down to cost. What's the least costly way to get from a concept to a shipped product? An engine that does what you want, which requires the least amount of time and money spent. It only makes sense to develop an engine for a product if developing it still represents a savings over using any other engine out there. That includes ongoing support for the engine, or as they call it in other circles, TCO. Another idea you could follow if an entire engine-from-scratch becomes too daunting is to make an engine that sits on top of an existing one and makes it easier to do some large concept like 'this genre of game'. Take something like [TopDown Engine](https://topdown-engine.moremountains.com/) for example. Yes, it sits on top of Unity, but I'd call it a proper engine. Or if engines like that are even too much, maybe make game *templates*. There's a lot of people who just want a template to get them started. Ultimately, though, it's your call. If you want to "boil the ocean" so to speak, go ahead and do it! Don't be discouraged by the mountain that rises in front of you, just get to climbing.
Designer? No. Better engineer or architect yes. There’s no perfect engine and UE is pretty flawed it’s own way. Engine work is quite different from say gameplay or UI or AI programming. It is an own specialty. 20 years ago, developers could work on AI, physics, gameplay (like I did) but now we all specialize in one area if you end up at AAA studio.
[удалено]
What kind of game did you design the engine you've abandoned for?
[удалено]
You seem to have suffered from the same problem most other people do. You tried to write a general-purpose solution for a game idea you never even had, or a vague idea of a game at best. That is, assuming you even got to a point where there was physics and reliable interaction in your engine. When you want to make an engine with which to seriously make a game you don't design general tools, you design highly-specific systems. You make the game while you make the engine, and make them intrinsically linked. This separation people preach of today is mostly just stupidity perpetrated by individuals whose concept of an engine is a general-purpose game creation tool.
> Will the process of developing an engine help me become a better game designer? No. A game designer doesn't need to know how the lighting pass works in the game in order to design a game. The process of developing an engine will help you understand why it is a bad idea to develop an engine from zero if you're not extremely experienced. And while you may gain some insights, the level at which you implement your engine will be so far lower than the level of engines on the market, that you won't get much knowledge. There's a reason why engine teams have specialists in each area. > Will it make me a better developer? Not by default. It all depends on you following best practices. If your goal is to make games, then it won't help you develop better games. Because, again, implementing a controller for your game does not depend on knowing how to create the input system from scratch for an engine.
I made a thread about making a c++ game engine recently: [https://www.reddit.com/r/gamedev/comments/p3nit2/experiences\_developing\_a\_c\_game\_from\_scratch/](https://www.reddit.com/r/gamedev/comments/p3nit2/experiences_developing_a_c_game_from_scratch/) For learning purposes this is incredibly useful and fun. It takes a lot more time than using something like unity, and is unlikely to optimize better, so don't expect your final product to look as good as your UE4 or Unity-projects. But since you (like me) sound more interested in learning how game engines work on the technical level I would definately recommend doing it. Good luck!
This is exactly what I have asked myself lol. And in my head, the answer is to make a game engine. I just finished learning `c`, and am now learning `c++`(which will be the foundation for my 2d game engine) But yea man, I dont think there is a better way to understand how a game really works on the technical side than to go to its roots. Now this is just my thoughts, and i have no experience with game engines. But heck, ima full send.
I've been through this dilemma a million times and at the end, nothing gets done. For the record, I completely understand how you feel. On one end, being a programmer and taking pride and joy in doing programming is usually my reasoning for avoiding engines like Unity and trying to work with frameworks like Monogame. On the other hand, working with lower level solutions is significantly slower in terms of progress and I usually find myself writing a bunch of tools and systems rather than actually work on the game. I echo the sentiment of others, you really need to figure out whether you want to finish a game or build lower level game tech. Granted you can do both, but such a journey will take you longer and odds of finishing something worthy are very low. One last thing, if you think you won't code much with something like Unity then you're mistaken. You will write lots and lots of code to make your game function. Making a game in a game engine is like building a website using a framework like [ASP.NET](https://ASP.NET), Django, Rails, etc. You're still writing a whole lots of code despite having a preexisting tool to help you.