Why you should not create a game engine
Before we put our hands on the keyboard and write our own game engine, we need to search and test all engines available. This can be time consuming and kinda boring work, but think about how much time you will save if you find the right engine that makes almost everything you need. Instead of spending time creating a tool, you will be creating a game. It sounds obvious but several companies that I worked (and some independent projects too) thinks in creating the engine, all the tools and the game at the same time, increasing the engine features and the tools as the game requests. This seems to work but don’t. Really don’t work.
If you intend to create a game engine, here is some problems you will face:
- Create a game engine is a very hard work, that take a lot of time thinking about and creating architectures and patterns, writing a lot of code, testing, fixing and testing again and again. If your engine can create games for more than one targets, you will have to test in every target every time you make a change in your code, see if your engine is still working in all of them and if the game is still working too. Several targets is not only different platforms like PC and Mac or different devices like Android and iOS, is also different hardware configurations in the same (or not) platform, different screen resolutions, video cards, processors, speed, Operational System, etc, all of this should be a concern of the game engine and must be tested a lot to make the games smoother to ensure that is will not frustrate the developer neither the final user.
- Because it’s a lot of work, it takes a lot of time, and because of that it’s very expensive to create an engine from the scratch. You could say “that X game engine is very expensive”, but think like this: how much time you think you will spend to make a good game engine like X? Now, how many programmers, testers, designers you need in your team to make it? OK, now multiply the time you will spend by the salary of each member of your team and you will get a number that I assure is greater than the price of the engine.
- Trying to create a engine by yourself it’s insane. You could create one engine alone, no doubt, but you will be the only user. There is so many things you need to make, so many tests, that when you release the first final release of your engine, the 1.0, your engine will be two generations late.
- Documentation. Unless you are writing an engine just for yourself you will need to document it, otherwise no one else will use your engine. And even you are creating an engine to yourself, you need to document things (believe me: you will forget what that damn method do and how to pass right parameter to it to get the right functionality). And developers know how painful is create documentation. Everything you create, not just engines, should be documented (not like a book but just a few words explaining what is not clear at the first look), but an engine requires a lot of documentation because there is intrinsic features, behaviors and dependencies that should be well explained.
- Since you are creating the technology, you don’t have where to search for specific help. If you are stuck with a problem in your engine, you need to figure out the solution alone or with your team. There is no community that you could make a question and another experienced user could help you to solve the problem since there is no engine yet! You and your team are the support, the community and the help.
And if you intend to create the engine and the game at the same time:
- Just one use case. You could create a great engine with great tools, but they will be based in just one game, you can’t prevent all things a different game will require, so you will end with a specific tool to make another game like the first. If your plan is make just one game, then it’s a waste of time create an engine.
- Usually there is two teams when you are developing the game and the engine at the same time, one for each product. Two teams is more expensive than one, and tool developers are usually more expensive.
- When an error occurs, sometimes you don’t know where it is. Is in the game or is in the engine? When is in the engine, is hard to foresee and takes a lot of time before you even suspect that could be it. I was in this situation a lot of times, and in almost all of them the problem was in the engine and sometimes great refactors was necessary.
- Refactors can break not just the tool, but the game too. This is a great problem when you have a big team working in the game and/or your game is already released and is a incremental game, like a MMO or have DLCs. Changing the engine code can make the entire game department stop until the code is fixed. Usually, the engine team is separated from the game team, and one does not know much about the work of the other. So, when the engine crashes the game, the engine guys don’t have the time nor the knowledge to test the game, this makes the incompatible codes problem very frequent. And if your product is already released, you risk the image of your company releasing a buggy game.
Despite the title of the post, I’m not saying that you must not make your own game engine if you want to. I’ve created a lot of them and learned great things. I’m just saying that you need to keep in mind you are creating a tool, a middleware, not a game. Make sure you have the time, the team and the necessary resources to achieve this goal. If you want to create games, not tools, it’s always better find an engine that is already done and work with it. It’s easier, faster, cheaper and you have at least the community to help you (and sometimes the paid support). But definitely never create the engine and the game at the same time. The Unity3D team was doing that. They throw away the game and now are focused to make and maintain the engine.
I can be wrong about my thoughts, but my experience until now shows everything I said in this post. If you have a case of success creating the engine and the game at the same time, please share.