Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Right now I find myself implementing and testing new features of my 2D game engine by directly coding them into engine. Simultaneously I have a showcase game (with scripting support) which should call the engines functions. However it happens, that 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)?

share|improve this question
add comment

1 Answer

up vote 25 down vote accepted

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.

share|improve this answer
7  
+1 - just start making games without worrying too much about the "engine" –  JCM Apr 4 '13 at 12:13
1  
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
3  
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. –  Alex M. Apr 4 '13 at 13:44
2  
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
2  
+1 for keeping the spirit of the Rule of three. –  Joshua Drake Apr 4 '13 at 19:50
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.