Basic Game Engine Structure

re: Basic Game Engine Structure

Machaira — Thu, 14 Dec 2006 15:42:45 GMT

You beat me to it. I was thinking about doing something on this (it comes up a lot in game dev forums), but yours is probably better written than what I could have done. :) For what it's worth, I'm linking to this from my blog.

re: Basic Game Engine Structure

Machaira — Thu, 14 Dec 2006 16:43:04 GMT

I did come up with an idea for one improvement - if a window's BlockDraw is set, the ones below it could be drawn greyed out. This would require a little change to the draw, probably overloading it with a flag to specify whether to draw regularly or greyed out.

re: Basic Game Engine Structure

Ultrahead — Fri, 15 Dec 2006 16:48:25 GMT

Very good article.

Maybe one of the search processes for the Draw call can be erased, at least partially, by taking advantage of the update method.

I mean when the update method goes through the stack in a top-down manner it also verifies whether the screen must be drawed or not.

To ways to follow from here: either you let that search to "scan" all screens objects in the stack regardless whether a BlockUpdate was found or you stop when the BlockUpdate was found and continue the search in the draw method in case the BlockDraw was not yet found.

Another approach would be using "events".

Again, very good series of articles.

re: Basic Game Engine Structure

CatalinZima — Fri, 22 Dec 2006 20:23:59 GMT

The whole thing looks very good, but when I began implementing it, a thought crossed my head.

Does this design ensure the calling of LoadGraphicsContent for the components in the GameScreen, when the device is reset ?

re: Basic Game Engine Structure

Ultrahead — Wed, 17 Jan 2007 01:03:09 GMT

@Catalin: maybe you could test it throwing a device exception at some point in the execution that requires resetting?

re: Basic Game Engine Structure

nickspacek — Tue, 20 Feb 2007 02:51:47 GMT

I'm implementing this pattern as well, and I had some thoughts, possibly related to CatalinaZima's above.

If you aren't managing a pool of screens, then how do you ensure that the Initialize and LoadGraphicsContent methods get called? I did a test, and if you Components.Add a DrawableGameComponent at the end of Game.Draw (after base.Draw) then the Game class is still smart enough to Initialize the component before it tries to Draw it. Unfortunately, as far as I can tell there is no way to check if the Component has called its Initialize and LoadGraphicsContent. But how is the Game class doing it then?

re: Basic Game Engine Structure

nickspacek — Tue, 20 Feb 2007 02:56:53 GMT

Just had a thought. What could be done is to have either the GameScreens themselves or the manager add them to the Game.Components list and just manage their Enabled and Visible properties based on the blocksUpdate and blocksDraw properties.

Game Maker Studio .Net

Mykres Space — Sun, 04 Mar 2007 02:06:48 GMT

I came across this a little while ago and have been watching the progress, Game Maker Studio is a 2D

re: Basic Game Engine Structure

JoelBennett — Wed, 11 Apr 2007 03:43:41 GMT

nickspacek: I am wondering about the same thing. I guess there is only one way to find out - try it!

re: Basic Game Engine Structure

zygote — Sun, 22 Apr 2007 22:57:28 GMT

for (int i = screensToDraw.Count - 1; i <= 0; i--){ screensToDraw[i].Draw( gameTime );}

this needs to be:

for (int i = screensToDraw.Count - 1; i >= 0; i--){ screensToDraw[i].Draw( gameTime );}

note the change of <= to >=

thanks,

Ziggy

Game Maker Studio .Net

Virtual Realm — Sat, 10 May 2008 08:58:34 GMT

I came across this a little while ago and have been watching the progress, Game Maker Studio is a 2D editor and Engine for Tile based RPG Systems. In the month of January the system was released in CTP for us all to try and see how it goes. Included on