I'm making a group of two or three simple javascript games for fun. After someone finishes one game, they'll be presented with a harder or easier version of another game depending on whether the original game was won or lost. I have a high-level question about the design of things:

So far I've created a class for one game type that manages the interaction with the UI and the state of the game itself. But for tracking how many of the subgames have been won, or for understanding whether the next game presented should be more or less difficult, are there arguments to be made for making a 'game engine' class? How does the engine communicate to the games? For instance, when a game is won, how is that information relayed to the engine? Is there a better or more common design?

(If you want to see what I have so far, the games are slowly taking shape here: https://github.com/yosemitebandit/candela and can be viewed at http://yosemitebandit.com/candela)

  • 2
    You should ask this on the gamedev.stackexchange.com instead, they might have better input on this. – Spoike Nov 16 '11 at 18:24

Think about N games, not only two. Now, take out everything that is repeated across every implementation, that is your 'game engine'. An engine should offer you common implementation solutions, like giving you the coords clicked, rendering shapes, etc. and not storing states.

For more information about how games are structured, I would recommend reading: Quake 2 Source Code Review it's complex, but you'll get an idea how a real game works, and the Irrlicht Engine tutorials should give you an idea how game engines are commonly used.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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