# Which features belong to the engine and which ones to a game?

Right now, I find myself implementing and testing new features for my 2D game engine, by directly coding them into the engine. Simultaneously, I have a showcase game with scripting support, which should call the engines functions. I attach e.g. a fixed tile movement to the Entity class in the engine, rather than scripting this specifically for the game. This is definitely breaking the idea of a general engine used for more than one game.

Are there any best practices to keep focusing on the correct implementation in the right parts (that is engine vs. game)?

Well there are a couple ways of thinking about this. One is to list the specific features the engine should have (what you've asked here.) However the other way is to just start making games without worrying too much about the "engine", and then features you find are being reused between multiple games (in particular, features used in every game) you should migrate from the source for a specific game into a shared codebase called "engine."

Because in the end, why you want a given feature in the engine rather than in the game is that it's shared between multiple games. Typically that'll be things like drawing commands, input controllers, and networking code. A 2D game engine will have lots of 2D graphics features, like loading images, a display hierarchy with z-order, handling spritesheets, tweening, etc. A lot of games need physics simulation, although on the other hand many don't. Meanwhile more "under the hood" stuff used in almost every game includes timers, event messaging, and even math functions specific to game development (eg. distanceToTarget()

Long story short:

A) The engine should have features shared by most games.

B) You learn which features are shared by making a bunch of games.

• +1 - just start making games without worrying too much about the "engine" – JCM Apr 4 '13 at 12:13
• Well just start making games without worrying too much about the "engine" is definitely a nice suggestion. – Christian Ivicevic Apr 4 '13 at 12:40
• I agree with the two comments above me, but the "just make games without worrying about the engine" remark has been taken out of context and is pointless without the rest: "and then features you find are being reused between multiple games (in particular, features used in every game) you should migrate from the source for a specific game into a shared codebase called "engine." In short, make as many games as possible so you get to know what should go under an engine and what shouldn't. – user15805 Apr 4 '13 at 13:44
• This is a great idea because it also keeps you from implementing engine features that you don't actually need in your games. – Zachary Yates Apr 4 '13 at 16:30
• +1 for keeping the spirit of the Rule of three. – Joshua Drake Apr 4 '13 at 19:50