Game Engine Design Principles even apply to the most basic of games (or applications)...

A friend of mine is getting into game programming.  He is actually heading back to college and taking the necessary classes to break into the field.  Since the first few semesters will be kind of bogus in terms of actual game development stuff I'm working with him on some various projects so that when he gets to the harder courses he is ready for them.

He kept mentioning that he had worked on a basic tic-tac-toe game in Visual Studio.  I think everyone tries this out at some point.  Almost like a challenge I'd say, “How fast can I code Tic-Tac-Toe!”.  But I think everyone else that sits down to this task has a different goal than I do.  When I sit down to a new game I think about the game engine design principles and how I can apply them to tic-tac-toe.  Who cares how fast I plug it out, or even how pretty it is, IMO, but instead would you use the same principles in a larger commercial style game.

So I went over his Tic-Tac-Toe game (don't kill me for posting about this here John, others can learn by your example ;-) and he had taken the how fast approach.  Then in the same email he had a large list of feature enhancements he wanted to work on.  Basically things he couldn't do during the initial phase of development and so he wanted to figure each of them out in turn.  The problem was, because of the initial engine design, everything he does is going to be a bolt-on, rather than an extension of the engine.  He never separated his presentation layer from his input layer, or his input layer from his game engine layer, etc...  Basic principles, that when in the game development field, you try almost always to follow (and when you don't you wind up as a post-mortem in Game Developer Magazine).  So here is the contents of the mail I sent back since I think it might get people's thought processes going about how to organize code (even non game type code) to make it more extensible.

I'll run through some stuff for you.  Basically what I need to point out is that Tic-Tac-Toe as a game really only has a single engine.  I'll run through some basic concepts to define what a game engine is and how it works:
 
Fact: A game engine consists of a game state, methods to change that game state, and methods to report that game state.
Fact: A game engine should be independent of user input methods, display, and any other connection that doesn't have to do with a game state or the methods needed to change the state.
Fact: A game engine has a lifecycle that consists of setup, iteration, and conclusion.
 
So think of a tic-tac-toe engine (make it a class) that is independent of the UI (have the UI interact with the engine by using it to make moves and then displaying the results of those moves rather than allowing the UI to actually take part in storing the game state) and the user input (don't have the buttons pressed set game state directly, instead have them call methods on the engine that change game state in a protected manner).
 
So a tic-tac-toe game might have the following game engine layout:
Setup
    Clear Game State
    Select Piece that Moves First (X or O)
Iteration
    If GameOver Throw Exception
    Make Move by turning a click in the UI into a game engine method MakeMove(cellX, cellY, PiecesEnumeration.O)
        If cellX or cellY is taken or PiecesEnumeration doesn't mesh with the current move piece Throw Exception
        Else SetStateOfBoard
    CheckForWinConditions
        If WinConditions SetEndGameState Goto Conclusion
        Else CheckForDrawConditions
            SetEndGameState Goto Conclusion
Conclusion
    ServeResults
 
So out of the things you wanted to add to your game.  Most of them were UI items, not game engine items, but you don't actually have a game engine yet.  Lets finalize a game engine, something cool that works well that can be played from a command line, a winforms UI, or a web page with relative ease.  Thats the key to an awesome game design.
 
So what you should send me is:
a) A single class that I can compile into a library
b) I can link that library into a new application I'm writing and add the ability to play tic-tac-toe
Published Friday, January 23, 2004 8:39 PM by Justin Rogers
Filed under: ,

Comments

Saturday, January 24, 2004 3:22 PM by Chris McGuirk

# re: Game Engine Design Principles even apply to the most basic of games (or applications)...

If you want an example that is just a tad bit bigger than that, you should check out Axiom http://axiomengine.sf.net, which is quickly approaching a full blown .Net graphics/game engine.
Thursday, August 11, 2011 5:24 AM by chi flat irons

# re: Game Engine Design Principles even apply to the most basic of games (or applications)...

Zeal without knowledge is a runaway horse.

Leave a Comment

(required) 
(required) 
(optional)
(required)