Should I use a game engine that is already made or should I take the time to make my own?
I have made a few really basic 2D games in the past, and I know want to make something bigger. To accomplish this, I believe I have the skills necessary to develop a game engine from scratch, but should I? What are the advantages of developing your own game engine as opposed to using a pre-existing game engine such as game maker or unity?
10 Answers
It really depends on both your short term and long term goals.
Game engines are a spectrum. On one end you have game engines that do everything for you including, but not limited to, rendering, scripting, physics, asset tracking, tools for creating assets, multi-platform support and so on. The downside is that for small games in the short term they can be expensive and have a steep learning curve.
On the other end of the spectrum you have low-level libraries like OpenGL, DirectX, OpenAL, etc that provide everything you need to "build your own". The downside is that they are often platform specific and can take a lot more code to get even the simplest things done.
In the middle you have game frameworks like XNA, MonoGame, LibGDX, etc that provide a mid-level approach that's easy to understand for most programmers but without the constraints of a fully fledged game engine. Typically you'll need to source other libraries for physics, lighting, etc or build your own but you get the flexibility of choosing exactly how it all fits together. The downside is that they still require a fair amount of work to fit it all together.
If you're okay with the initial cost and learning curve in the short term and want to make a few different types of games in the long term a full game engine like Unity is probably the way to go.
If you're short term goal is to make a small game as quickly as possible for low cost I would suggest a game framework like MonoGame or LibGDX. Once you have the first game done, you can build on top of it to make the next game, a little bigger and more complex each time.
If you're okay with spending 1 or 2 years building a game engine before you actually make a game or the long term goal is to make something truly unique and different you might have a reason to build a full game engine from scratch. Just be careful falling into this trap though, it's a time waster.
Disclaimer: My personal preference is using a game framework. MonoGame is my framework of choice because I'm a C# developer targeting Android.
Game engines are a spectrum. On one end you have game engines that do everything for you including, but not limited to, rendering, scripting, physics, asset tracking, tools for creating assets, multi-platform support and so on. The downside is that for small games in the short term they can be expensive and have a steep learning curve.
On the other end of the spectrum you have low-level libraries like OpenGL, DirectX, OpenAL, etc that provide everything you need to "build your own". The downside is that they are often platform specific and can take a lot more code to get even the simplest things done.
In the middle you have game frameworks like XNA, MonoGame, LibGDX, etc that provide a mid-level approach that's easy to understand for most programmers but without the constraints of a fully fledged game engine. Typically you'll need to source other libraries for physics, lighting, etc or build your own but you get the flexibility of choosing exactly how it all fits together. The downside is that they still require a fair amount of work to fit it all together.
If you're okay with the initial cost and learning curve in the short term and want to make a few different types of games in the long term a full game engine like Unity is probably the way to go.
If you're short term goal is to make a small game as quickly as possible for low cost I would suggest a game framework like MonoGame or LibGDX. Once you have the first game done, you can build on top of it to make the next game, a little bigger and more complex each time.
If you're okay with spending 1 or 2 years building a game engine before you actually make a game or the long term goal is to make something truly unique and different you might have a reason to build a full game engine from scratch. Just be careful falling into this trap though, it's a time waster.
Disclaimer: My personal preference is using a game framework. MonoGame is my framework of choice because I'm a C# developer targeting Android.
In short: as a hobby learning project, definitely yes; but as something to build your next game on, probably not, unless you have a good reason and can afford the investment.
Long answer: building your own game engine is a fantastic learning experience, it teaches a lot about how various infrastructure bits work, and why things are done a certain way. This can be very targeted, too: you can build just one element from the ground up (eg. rendering engine), to scratch that particular itch, and use existing libraries or engine bits for the rest.
But, building a full engine for production use, one that actually works well, is optimized, bug-free, extensible, and so on, takes a huge amount of work, much more than just reaching the "it works okay" stage. Even if it's "just" a specialized engine, like a graphics engine, and not a full-stack one, it's still a ton of work, especially for one person.
So if your main goal is to ship a game, you'll probably get to that goal faster if you start with existing engines or frameworks for most of it, and only custom-build the parts that are unique to your game and will make it stand out from the crowd.
That said, do take a shot at building your own game engine. Just don't bet your next game on it. :)
Long answer: building your own game engine is a fantastic learning experience, it teaches a lot about how various infrastructure bits work, and why things are done a certain way. This can be very targeted, too: you can build just one element from the ground up (eg. rendering engine), to scratch that particular itch, and use existing libraries or engine bits for the rest.
But, building a full engine for production use, one that actually works well, is optimized, bug-free, extensible, and so on, takes a huge amount of work, much more than just reaching the "it works okay" stage. Even if it's "just" a specialized engine, like a graphics engine, and not a full-stack one, it's still a ton of work, especially for one person.
So if your main goal is to ship a game, you'll probably get to that goal faster if you start with existing engines or frameworks for most of it, and only custom-build the parts that are unique to your game and will make it stand out from the crowd.
That said, do take a shot at building your own game engine. Just don't bet your next game on it. :)
On making your own game engine you can refine and update everything about it. If it's truly awesome, someday you could license it. You can easily append anything you want to it without waiting for tech support or a hopeful update, and you know exactly how it works.
However, you're going to have to write everything from scratch, you won't have any support, no one can help you answer questions about your engine, and the efficiency isn't backed by a team of paid professionals.
Generally, programming isn't about reinventing the wheel unless you need massive efficiency that isn't there in the pre-invented wheel. Unless money is an issue and time isn't, or unless you're an extremely talented programmer who has a lot of free time and thinks he's more clever than the people working on the game engines, I would recommend going with a pre-existing game engine. Writing network code alone requires a deep level of knowledge and efficiency of programming, and the time you spend writing and debugging an engine could be used making a better game.
However, you're going to have to write everything from scratch, you won't have any support, no one can help you answer questions about your engine, and the efficiency isn't backed by a team of paid professionals.
Generally, programming isn't about reinventing the wheel unless you need massive efficiency that isn't there in the pre-invented wheel. Unless money is an issue and time isn't, or unless you're an extremely talented programmer who has a lot of free time and thinks he's more clever than the people working on the game engines, I would recommend going with a pre-existing game engine. Writing network code alone requires a deep level of knowledge and efficiency of programming, and the time you spend writing and debugging an engine could be used making a better game.
I'm a firm believer in not reinventing the wheel. My answer to this question is almost always going to be "use a game engine."
I would rather spend as much time possible making my game awesome and as little time possible worrying about things like writing .png or .obj importers so that I have an asset pipeline.
The only time I would start considering making my own game engine was if there was some specific feature that my game design hinged upon that wasn't supportable inside an existing engine. Even then I probably wouldn't go to the point of writing a from scratch game engine in order to support that feature, I would just expand an existing game engine with some custom libraries.
I would rather spend as much time possible making my game awesome and as little time possible worrying about things like writing .png or .obj importers so that I have an asset pipeline.
The only time I would start considering making my own game engine was if there was some specific feature that my game design hinged upon that wasn't supportable inside an existing engine. Even then I probably wouldn't go to the point of writing a from scratch game engine in order to support that feature, I would just expand an existing game engine with some custom libraries.
It depends on what your goals are and to a lesser degree what kind of game you want to make.
If what you are interested in doing is developing a game, finishing it, and maybe selling it to people, and the game is going to be a 3D game, then absolutely you should use a third-party engine -- there is no question. Developing a game engine from scratch will do nothing but make it harder to reach your goal, unless there are weird constraints on the game you want to make but there probably aren't, and if there are and the game is 3D you will probably fail anyway unless you really really know what you are doing.
If your goal however doesn't involve being totally hung up on finishing something that is polished and salable, if your goal is to have fun and write interesting code and learn about game development, then by all means write your own engine. It is a very rewarding experience but don't expect to be able to compete with what is already out there, working by yourself in a reasonable amount of time.
Now, 2D is a different story.
The advice above still applies mostly but to a lesser degree in that 2D engines are easier to write so whether you use one or not is less of a no-brainer and more dependent on how many features you need can be easily leveraged from an existing engine. It is unclear to me, in a way, what a 2D game "engine" even is ... that is, yes, use a 2D 3rd party hardware abstraction layer such as SDL or SFML but I personally wouldn't characterize those two as "engines".
2D engines are more things like cocos2d-x which is good to use if developing cross-platform is very important but is also very heavy-weight. So maybe you wouldn't want to use cocos2d-x if you are targeting a single platform and have modest needs; e.g., say you are writing a single screen action game like Tetris, you really don't need to be linking to cocos2d-x's classes for parallax scrolling and so forth.
If what you are interested in doing is developing a game, finishing it, and maybe selling it to people, and the game is going to be a 3D game, then absolutely you should use a third-party engine -- there is no question. Developing a game engine from scratch will do nothing but make it harder to reach your goal, unless there are weird constraints on the game you want to make but there probably aren't, and if there are and the game is 3D you will probably fail anyway unless you really really know what you are doing.
If your goal however doesn't involve being totally hung up on finishing something that is polished and salable, if your goal is to have fun and write interesting code and learn about game development, then by all means write your own engine. It is a very rewarding experience but don't expect to be able to compete with what is already out there, working by yourself in a reasonable amount of time.
Now, 2D is a different story.
The advice above still applies mostly but to a lesser degree in that 2D engines are easier to write so whether you use one or not is less of a no-brainer and more dependent on how many features you need can be easily leveraged from an existing engine. It is unclear to me, in a way, what a 2D game "engine" even is ... that is, yes, use a 2D 3rd party hardware abstraction layer such as SDL or SFML but I personally wouldn't characterize those two as "engines".
2D engines are more things like cocos2d-x which is good to use if developing cross-platform is very important but is also very heavy-weight. So maybe you wouldn't want to use cocos2d-x if you are targeting a single platform and have modest needs; e.g., say you are writing a single screen action game like Tetris, you really don't need to be linking to cocos2d-x's classes for parallax scrolling and so forth.
