“write games, not engines”
If you have any experience with developing games, then you’ve probably heard of the phrase “write games, not engines“. This may seem like wise advice, and it is – that way, you can focus your attention on what matters: the game, and waste no time in making it happen.
But imagine this: You have successfully completed a game. Game-specific code makes up most of your codebase, probably hardcoded – or perhaps you used some XML to make editing that little bit easier. It may have saved you a significant amount of time too. But now you’re starting to think of that next game idea. Sure, you can take advantage of some of the things you’ve learned, reuse the odd class, but either way it’s time for File -> New Project.
Not very sustainable, is it? Especially if you’re an indie dev looking to break into the industry, and even more so in the mobile market where everything is either a hit or a miss. You need a way to churn out games quickly and effectively, but if you stuck by the phrase I mentioned earlier, you’re now actually wasting time worrying about code that is not specific to your game.
“write engines around games”
Now turn your attention to this: “write engines around games”. First of all, this addresses a fundamental flaw in the approach many developers take when writing an engine. Don’t think: I’m going to write an engine. Think: I’m going to write a game, with an engine to assist me.
If you start developing an engine with no focus, then you end up wasting a huge chunk of time and will eventually get lost in unnecessary complexity, working on features that you will probably never use, and eventually give up. I know of countless projects that have failed because of this, open source or not.
Start with the goal of completing a game. Plan out how it will work. Write up every feature you think you will need to complete that game. Now it’s time for some smart thinking: you need to come up with an architecture that will accomplish all of these features, but at the same time be generic enough to be reused in future projects. Think libraries, decoupling, cross-platform, layering. Keep all of your game-specific, platform-specific code separate from your ‘engine’. Work on the game in your game project, and add features to the engine as needed.
Of course, this has to be planned in advance. Think of it like building a house. An architect draws up the plans. The builders construct the house, bit by bit, adhering to the plan. It is done in stages – first the foundations, then the walls, then the roof. Each of these components have their own function, with the next one up depending on the one below it, keeping in mind the foundations can exist without the roof. I will go deeper into this point in a future post, but to reiterate: plan well, implement in stages.
This way you can focus on developing a game, while simultaneously constructing something that can be reused in the future. In fact, the more games you develop this way the better, broadening the capabilities of your engine, covering a wider range of genres, with every feature being put to good use. Because every addition made will improve the game in some way, there is far more satisfaction, and motivation is improved.
If you were considering writing an engine, this method reduces wasted time and improves productivity. For those of you who prefer to write games directly, admittedly this will extend development time of your initial project, but every new project will become exponentially quicker, easier and even more ambitious.
Next time I will talk specifically about architectures, the do’s and don’ts, and the importance of developing an editor.
