5 replies to this topic

[Arnie06]

So I am in a game engine development class...early stages still. Would this be an appropriate list of how a frame is rendered?

1) I/O
2) Game Rules/Logic
3) Collision Detection/Response
4) Update Objects
5) AI
6) Physics/FX
7) Network
8) Render

Also, can any of these steps be re-ordered without it affecting the overall process?

the exact question im stuck on is: "Does the ordering of the stages in the pipeline you drew matter? What parts of the pipeline can the
ordering be changed?"

Thanks for the help guys, im just trying to get my head around this.

-Aaron

[Mattias Gustavsson]

There's not one definitive solution to how to structure your game engine. What steps are included where varies from engine to engine, and which ones can be re-ordered depends entirely on their implementation.

The stages you list could certainly be included in a game engine... but it could be arranged in a different way too. For example, why is AI separate from game logic (in my experience, it's more common to have AI as part of game logic). Why is Physics separate from Collision Detection/Response? And why is lumped together with FX (and btw, why is FX not put together with Render?). Where does audio fit in? Wouldn't you need to recieve (and process) network messages at the start of the frame, near I/O (which should probably be called Input, as you're not doing any output at that stage), and send network messages after all the game logic have been done?

The simplest form of structure for a game engine is:
1) Update
2) Render
where Update is broken down further into all the bits needed to update the state of the game simulation, and Render is broken down to the bits needed to display the result to the user. But even this structure is not adhered to by every engine.

[geon]

There is not really one right way to order the tasks. You might have a lot of dependencies between them:

Rendering is usually dependent on the result of Physics, AI, etc, so You want to do the rendering last. But The AI is dependent on the physics, and the physics is equally dependent on the AI.

The way you order them means that either the AI or the physics needs to work with old data. Which one should have the most recent data is up to you to decide, and depends entirely on your game and implementation.

[Arnie06]

Thanks for the quick answers guys. Those are just what he drew on the board. TBH, he is a terrible teacher lol.

1. Draw the game-engine pipeline and explain in your own words each stage of the pipeline.
2. Does the ordering of the stages in the pipeline you drew matter? What parts of the pipeline can the ordering be changed?

So is question 1 pretty much a trick question? Seeming as the orders differ from engine to engine...He says he wants definitive answers but from what you guys are saying and from what i've been reading online there is a million and one ways to do it right.

Thanks again for the help guys

-Aaron

[alphadog]

Be careful with what reality dictates, what theory states, and what your teacher thinks is right. They don't always line up.

I agree with Matthias that collision detection is really a part of the overall physics of a game, if there is complex physics being implemented. (For example, there isn't any in Space Invaders.)

However, I consider AI and game logic to usually be different, but it's probably more semantics than anything. AI would be non-deterministic things like pathfinding, whereas game logic is more of a "fixed rules" engine, like "your basket can only hold 10 swords". Game logic usually comes into play pretty early, because it checks if the message into the system is a valid one. Input of "Please add an 11th sword" would be denied early, and save processing, animating, etc.

One thing's for sure, for each "tick" of your game world, it generally always starts with input queue and its immediate processing and ends with the pure visual render of the end-state of the game world.

The middle part is mushy, especially in multi-threaded architectures...

[ulthias]

somebody once told me that the whole "engine" metaphor was a bitty iffy, it's better to think about it less like a "Game Engine" and more like a "Game Operating System"; I dunno, just makes more sense in my head I guess.