next »

[jotapeh]

What I'm hoping for from this post, is to evolve some sort of generically applicable anatomy to the type of application we know and love, called the 'video game'. Oooh, ahhh. Anyway, I want to sort of build on solid concepts, and have everyone contribute pieces until we can diagram something out. Or, if you have your own complete solution and would like to share, I would LOVE to see it! F'real.

This post will probably take weeks or months to look like something real, and maybe never be finished, but it's all about ideas so let's hear and see 'em.

Shall we, sirs and madams? 

Without further ado, I'll commence with a very simple skeleton structure of a game engine. I think we can all agree these are elements which each game MUST have, otherwise it is not much of a game:

- Input Manager
- Game Logic
- Display Engine

Those are the absolute bare bones, in my view. Once you have those three elements, you have something you can call a game. In a sense of what comes from what, we have a hierarchy:

Input from player becomes game actions > Game logic decides what happens based on input and current state > Display engine shows what the game logic is thinking

or


(forgive my terrible googled images)

This is, to me, the most 'holy' and unbreakable of paradigms. At no time, ever, should the input directly affect the display of graphics, or should animations affect game logic. The game should be in charge at all times, and if the game logic is saying, "Hey, I'm in a menu right now," The display engine will change to reflect that.

I'd like to stop here for now and open debate. Yes, this is mind-numbingly basic. The idea here is to build an extremely solid foundation before we go on to build the house that video games will live in.

So please, carry on your thoughts - add to the diagram (pathetic as it is, please give it some detail!) or simply spell out what you might put in which container and where. Or if you feel these containers are completely wrong, give a reason why.

[Mikademus]

Congratulations, you just described a version of a Model-View-Controller design.  

But yeah, any decent game framework should use MVC.

[george]

What do you think of grouping input and display together, something like:

+ interface
  - input
  - display

+ logic

+ data

I only ask because I'm working on this structure now for a new game.

[increpare]

How do you envision these three things interacting george?

[jotapeh]

Congratulations, you just described a version of a Model-View-Controller design. 

But yeah, any decent game framework should use MVC.

Like I said, this is the absolute core foundation, and ultimately I would like people to talk about subcomponents of these three pieces, in specific most obviously the game logic piece.

The catch being not to limit ourselves to a certain type of game, (eg., a platformer, or a card game,) but to talk about a hierarchy that applies to all games. Game engines are written to do this, like Flixel... you can create most any type of game with it... and Flixel works in a state-based paradigm.

So perhaps we could then talk about what exactly comprises a "Game State", or rather, what should comprise one. When I was a novice programmer, immediately I would have said, "Well you need to put a Player object in the game state" -- but that's not always true, particularly when your Game State might be something like a menu screen or a minigame that has nothing to do with the main game concept of the "player". Some games may never even have a representation of the player at all, such as Tetris where the only real "player-specific" information is the score.

So do we use Game States - do they have to "know" which state should come before, and after? Should they be allowed to own substates? Or is this paradigm already too flawed to move forward with?

That's the kind of stuff I'm trying to talk about. I realize this is a tough subject to broach, and perhaps some can set the dialogue up more intelligently than I have here. If so, please do.

Cheers and looking forward to hearing more thoughts. 

Now, back to the topic at hand:

What do you think of grouping input and display together, something like:

+ interface
  - input
  - display

+ logic

+ data

I only ask because I'm working on this structure now for a new game.

I think I see what you are doing here. Many languages (such as AS3) have classes that compose both input and display, such as TextFields. It can be difficult then to split input from display, as the GUI object is both your display object and your data input. The way I solved it in a recent game was this:

1) The game logic creates a TextField and treats it solely as a text piece. In my game, which is state-based (as above), this means the TextField is essentially a piece of data to be read. The game logic registers itself for events when the input changes (which still breaks the structure above, but not as badly :p)

2) The display engine adds the TextField to its list of display objects and positions it correctly.

Because of how AS3 works, that suffices to segregate data entry from display..

[John Nesky]

At no time, ever, ... should animations affect game logic.

What about games like Street Fighter? The hitboxes and timing are closely tied to the animations.

[Cthulhu32]

Congratulations, you just described a version of a Model-View-Controller design.  

But yeah, any decent game framework should use MVC.

Yeah, game frameworks are generally some sort of MVC design because it is simple enough to implement in almost any language/situation.

http://gpwiki.org/index.php/Programming_Techniques

Some of the interesting bits for me are proper resource management, module creation/modification (if you have modules), extensibility through internal/external structures such as XML, using the correct data structures for the correct situations, proper inheritance techniques, and portability.

Professional game engines written by big game companies like Sega also wrap all of their important low-level calls around high-level wrappers, making it a million times easier to port between compilers such as PS3/X360/PC. Tommy is a big proponent for this on his Meat Boy project, and its pretty common practice in the professional world.

But the one thing I really enjoy about this topic: there is not really one right solution. Even if you account algorithm speeds and optimizations, everything is reliant on user-input which can be at any random interval. They could want to shoot 50 missiles instead of firing the single laser beam, which would mean your engine should be able to handle those new physics objects and run their given AI. Or you could run through the entire game without killing a single enemy, which means every AI that is allowed to exist in the current game area has a running AI system. So you have to be efficient enough not to slow down a computer, but you never want to run EVERY AI in the level if its a huge level.

[jotapeh]

At no time, ever, ... should animations affect game logic.

What about games like Street Fighter? The hitboxes and timing are closely tied to the animations.

So glad you brought this up :D This is exactly the sort of thing I think about.

Yes, on the surface, the hitbox appears to be tied to the animation. But why don't we simply reverse that? The game logic (should) know the position of the characters, what state they're in (punching, throwing, hadoken-ing, etc.), and should be tracking what point in the attack the character is in.

Isn't it then trivial for the display engine to simply show the appropriate frame at the moment, with the game logic still being in charge?

Of course, we want the animation to look smooth, and the engine to follow it. Not vice versa. So that approach requires converting the animation delays and frames required to exist as "states" within the game logic.. maybe not the way to go?

I don't really have an answer here, but this is an excellent example of one of many game engine structure problems I bang my head on the wall with every time.

[george]

increpare, I think the recent posts have summarized what I'm doing pretty well.

They lead me to a new question though on the topic of game state. In past games I've done state by mapping input/display/logic states to functions. Different input would replace the current state with a new one. When a game did something it would use the function of the current state (a display function, or an input function, etcetera). I think this is a fairly common/simple approach and it works fine.

However it always struck me as a little unwieldly. Often a new state transition would be triggered in the function for a different state (for example, on the main screen, i.e. the main screen state, hit a key to start gameplay, i.e. transition to the gameplay state) so for this new project I've been reading around looking for a different approach. Are there different approaches than state transitions commonly used?

[jotapeh]

http://gpwiki.org/index.php/Programming_Techniques

Some of the interesting bits for me are proper resource management, module creation/modification (if you have modules), extensibility through internal/external structures such as XML, using the correct data structures for the correct situations, proper inheritance techniques, and portability.

This is great stuff. I really enjoy that link you posted (shame on me for not even knowing it existed.)

[bateleur]

Design patterns are to programming what recipes are to cooking. Read them, learn from them... but don't be constrained by them.

MVC in particular can be quite misleading in a games context. Your view and controller might be nothing more than a few library calls each, with your entire game residing in the logic. Which is fine, but tells you next to nothing about how to make games.

OK, so you've asked for specifics, but few games share the same internal structure unless they're a similar type of game.

[st33d]

Is there a place in this framework for a box labelled "Fun"?

I consider this more important than anything really.

[gimymblert]

It's in game logic i think, not counting overall design (good control, quality feedback "display")

[BorisTheBrave]

Is there a place in this framework for a box labelled "Fun"?

I consider this more important than anything really.

Remind me of a joke:

A great yogi was once asked the secret of long life. His answer:
"Breathe in, breathe out".

Patterns are there to make programming quicker, so they are a means to an end. They also are important as a communication tool (both code comments and verbally), but that's probably not so useful to the average indie developer.

Frankly, I think games should share more code. There's astoundingly few "logic" libraries, which is the bit truly exchangable between platforms and setups.

Also, I don't think the OPs setup is quite MVC. One of the important aspects of a model is it doesn't know about the view, instead each view hooks into the model, via events etc, and reads it. But that's not how most games are written, which is fine as you have a very clear idea of the view compared with other applications.

[David Pittman]

Frankly, I think games should share more code. There's astoundingly few "logic" libraries, which is the bit truly exchangable between platforms and setups.

It's also (by necessity) the most malleable bit of an engine, so I think we'd gain relatively little by sharing. A high-level entity system could be useful, but actual game logic seems too specific. That's the part that I'm most likely to rewrite between my own projects, whereas core libraries and the renderer and such will remain untouched.

[BorisTheBrave]

I'm thinking things like, pathfinding, state machines, multiple dispatch, word stemming, query trees, broadphases, geometry, serialization. Things you would build the business logic out of. And of course, there are libraries for each of these things, but the adoption rate is terrible, and you don't really see a cohesive bunch unless it's tied to an actual engine.

[st33d]

I write crap like this all the time.

Then a month later I realise I could do it so much better when I try to apply that research to a project.

Case in point:

This menu system.

So as I tried to apply it to the project it was made for, I realised the need for MenuOptions that could be toggled between diferent states. I also noticed that my hot key system was broken. And I needed more hot keys. And the tech demo I've just linked sets up the Menu class in a completely different way to the game. In the game I found it was better to extend the Menu class and make a contained object that was going to initialise specifically for this project and deal with its own dispatched events. That kept all the ui code in the ui package. Tidy.

I keep meaning to upload the changes, but I know I'm already planning more changes for the menu system.

[mewse]

The job of a game engine is to provide useful functionality, to make it easier to create games.

In my experience, strictly formalised game engines (such as ones which mandate MVC) are not useful;  they slow down and complicate the process of creating games, rather than expediting and simplifying it.  You'd be better off to throw them away than to actually use them.


I find it far more useful to have an engine which consists of useful functionality, and just have your game code call into the bits it wants to use, rather than have the engine try to enforce a strict game structure that limits what's allowed to talk to what, or try to define and enforce The One True Way To Make A Game.

[Average Software]

The biggest thing with engines, I think, is to make the engine fit the game, don't make the game fit the engine.  Don't be committed to patterns that don't work for your project.  My current project is largely a collection of windows, so I'm doing it with entirely in native windowing APIs (Cocoa, GTK, win32).  I have no "input manager," I don't even have a game loop, unless you consider the native event loop to be that.

I think people tend to make this stuff way more complicated than it needs to be in the name of modularity and reuse.  Those things have their places, but you need to know where to draw the line.

Consider that Richard Garriot required that all of the early Ultima games be written entirely from scratch, with no reused code or engine bits.  Those are considered some of the finest computer games ever made.  I know that correlation is not causation and all that, but it's something to think about.

[jotapeh]

I appreciate the fervor and enthusiasm of some of these replies. I'm not one to hold to a particular viewpoint dogmatically, and if anything my OP was more to spark discussion than to present "THE ONE TRUE GAME ENGINE FRAMEWORK."

It would be nice if such a thing existed, it almost certainly does not - but there might be something we agree works in the vast majority of situations. Then again, probably not

Ultimately I think most people approach the problem of, "How do I make a game?" with a preset engine template of SOME kind in their head. What I'm really interested in is, what do these mental templates most often look like? Are there similarities between successful concepts or between unsuccessful ones?


Now that I think about it, a more successful title for this thread might have been, "Planning the Anatomy of Your Next Game Engine." Can we try that?