• entries
    437
  • comments
    1000
  • views
    335193

Game Coding Complete

Sign in to follow this  
evolutional

94 views

I've been mulling over some of the code and ideas talked about in Game Coding Complete 2. One idea I'm really liking right now is the separation of game 'logic' and of game 'view'. At present I'm massing in all my AI and player updates and rendering in the main game/level classes. The 'view' approach separates it all out:- It moves the core logic into one class which is responsible for keeping the world up to date and ticking over, and the 'view' code into another. A view can represent anything you want, it's a 'view' into the game world. It could be your player, an AI player, a floating camera, a special monitor class, whatever...

I like this idea a lot as it ensures that you keep everything out of the way and that everything *must* act within the same game logic. There is no way of 'bending' the rules from a view as the view makes requests to the game which can be completely ignored if needed. It's very much akin to the client/server approach that I've tried to implement before, but in a much simpler, more intuitive way.

One thing that I *don't* like is the way the event system works. Whilst I like the idea of creating event 'types' that don't require the use of a global enum (ick), I dislike the way the events are dispatched to a single function and handled in the manner of 'if/then/elseif/then/elseif/then', etc. Even the simple example provided in the book has a hugely cluttered event handler function; come on, we can do better than that. What I think would work better is altering the event handler class, so that rather than implement an interface, the classes are derived from a baseclass. Event handlers are then registered with the class which in turn are registered globally to that handler. In the main 'handle event' function, we would now implement our own dispatcher, which dispatches the event handling to member functions.

So instead of:-

class MyActor : public IEventHandler
{
public:

void HandleEvent( Event &a_evt )
{
if (a_evt.type = "x") { do something }
if (a_evt.type = "y") { do something esle }
}
};


We would have...


class MyActor : public EventHandler
{
public:

void OnX( Event &a_evt )
{
// Do something
}

void OnY( Event &a_evt )
{
// Do something else
}
};


Registering the events would change very slightly, but the basic idea is the same - we're mainly hiding the dirty switch statement from the user and replacing it with a nicer dispatcher which we never have to touch. The clever thing is that as EventHandler implements the IEventHandler interface, none of the other code has to know or care about how we're handling the event. The main game event dispatcher just carries on as normal without any code changes.

I like how this book has implemented different events as classes. I typically just had the one event class and had a specific mechanism for passing parameters. Here, each event has its own customise data packet which relates exactly to the event type. There is no worry about receiving crap event data or having to validate each parameter type when you're consuming the event, you just know that what's in the packet is what you're expecting it to be.

Suffice to say, I'm enjoying the book so far.
Sign in to follow this  


1 Comment


Recommended Comments

The view/model thing sounds interesting, might try that sometime.

The (boring) stuff I do as part of my day job is very similar... we have an underlying document model (the logic) and then the actual display on screen (etc..) is just a view into part/all of the model.

Jack

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now