• Advertisement
Sign in to follow this  

Game Control Flow?

This topic is 3002 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm not entirely sure where to go with my game's control flow and abstraction. This is pretty long-winded, but I'm just looking for more information on game control flow and recommendations (component/event/signals/etc systems). It's 2d, online, and uses the haXe/AS3 scripting language. I've got a main loop which: 1) processes input if there's any changes and fires off events 2) updates the game world, which in turn updates game objects 3) updates the physics scene, collision, etc. 2) updates the graphics scene, and renders graphics objects At the moment the game objects just hold variables to the graphics object (model2d) and physics object. I wanted to use the game objects as mixins of the graphics/physics/network objects, but my language doesn't have that feature or multiple-inheritance. I also wanted to only keep track of game objects, therefore game players and game npc's would have to be game objects. The only thing that seems to match this is a component based system. It would also seem like you'd require a get_type method or something to determine if the game object was a player or npc or something else. Seems like a bad idea, so I've just kept 3 separate linked lists. What I'm using at the moment is a sort of event driven architecture. Similar to events/delegates in C#. Some classes have event objects other classes can subscribe/unsubscribe, and some methods having callback arguments. I don't really know if this is a good way to go about it. Components seemed to accomplish the same thing, except interfaces just added unnecessary complexity compared to events. Meanwhile sigslot seems like too much freedom and chaotic. Then again, it's probably the best way to abstract subsystems and still connect them together without adding dependency. Anyway, I figured I'd make graphics/physics/etc objects abstract or components to the game object, but since I can't, I could make them interfaces, pass graphics object etc to the constructor, and proxy through those. Then I can pass the game object to any of the subsystems (graphics, physics, etc) using the base interface. Maybe I should just keep it straight-forward, even if it's worse in the long-run. :D Thanks in advance.

Share this post


Link to post
Share on other sites
Advertisement
What I'm personally doing is creating a module for each subsystem. That is, a rendering module, a physics module, a sound module... where a module is a set of related classes, usually with one 'main' class that provides access to the module. My games often only have one instance of each module, and I'm passing references to them to code that needs to work with them.

All of these modules handle their own kind of objects: the Renderer makes sure that all VisualObject instances are drawn (with Sprite, TextField, those kind of things being derived from VisualObject, and them being stored in some kind of tree structure to make draw order easier to manage). The physics module takes care of all the physics objects, collision handling and all that - possible using callbacks to inform other code of what's happening.


I'm usually creating game objects on a per-game basis. Most of my games don't have need for a complex Entity management system, and using different lists for different kind of objects (player, enemies, bullets -- or player, npc's -- or units, buildings, terrain tiles) works just fine as long as you don't end up with too many different lists.

'Component-based architecture' seems to be the new buzzword, but there's no need to do all kinds of fancy stuff. My game objects use Sprites, CollisionBodies, and so on, as member variables. Which automatically makes them component-based, I guess. Either way, they register those objects to the module that manages them, so all they have to do is modifying them. Change the scale or position, apply a force... the modules take care of the actual work. This means that most game objects need a reference to those modules being passed to their constructor, but that's not really a problem. Once that's all done, they can focus on running their logic and making sure their components behave accordingly.

For communication between game objects, I usually make the code that manages the game objects handle that. If a character needs a target, I'd have it query the object that manages all characters. That object returns a list of characters that conform to the given specifications (in-range, belonging to faction X, etc.). The character then picks a target and maintains a reference to it for as long as it needs to. In case that character dies, a callback system could be useful - or simply an isDead flag that is checked before doing any operations. In a language like C++, a destructor could be set up to send messages to all listeners: hey, this thing is dead, stop following it.


Long story short: I'm using modules as services for the actual game objects, and I'm trying to keep things simple and to-the-point. I hope this gives you some inspiration. :)

Share this post


Link to post
Share on other sites
Thanks for the insight, Captain P. I think it's helpful kind of looking around the table, figuring out if you're on the same page. There's something to be said about consensus.

Let's say I hit the Up arrow and my character moves forward. It moves the model up the y axis. Now what's the best course to get from there to telling the physics and network module about the change? (I call them services, some ppl call them devices, systems, managers, etc) As of now, I have it in the is_key_down scope, constructing a movement event (packet), and sending it to the modules. That's during the update phase. Then I figure what if I have the class that handles the network module register to an on_change event with the player, so all of that packet constructing stays in one place, and the rest of the code isn't aware of the network. Then I'd probably end up sending too many movement packets per frame, so just marking the player as 'dirty' or 'changed' and instead loop over them once per frame during update phase, and then send any corresponding packets (movement, etc)? One of the problems is knowing which player property changed, instead of sending back ALL the variables to the server. When the server sends anything, it can go through this layer and make changes (like update with the player's REAL position, not client-side) without the rest of the classes knowing - although it does fire off events when it makes changes. Doing it this way I found I didn't need to construct any event packets, used for serialization/deserialization and callbacks, instead I could operate right onto the socket stream. Make changes to the world around me client-side, request changes to the world around me to the server-side. The problem is still notifying the network of a change, and efficiently using the network. The easiest thing to do would operate entirely from one interface, ie. SuperMasterClass.ChangePlayerPosition(player_id, x, y) etc. Kind of like C. The component method would be to add a network component to the game object, monitor for x/y changes and whatnot, then notify it's parent during update phase with an event. Similar to callback events and marking the object dirty, but more elegant. So maybe with a callback event to the network module I could construct an event object, add it to it's own loop, and iterate over those during the update phase, and somehow trim them so there's no duplicates (update player position twice). Seems like a wannabe-elegant solution. The component architecture's I've seen look inefficient though (dynamic variables, callbacks, and component lists), maybe too much for a scripting language. Then again using a scripting language I have the benefit of *real* generic/dynamic objects. I just sacrifice some speed and type-safety I guess.

The reason I'm giving it thought is not only because it's the base of the game, but because moving around objects and making changes, with it updating on the server database (assuming the player has permission - like me) would be a huge benefit. Like GM privileges, for absolutely everything, like a live map editor/world builder.

Long post, I know, but this helped and I think I'm coming towards a conclusion.. I'm really only posting so someone can disagree with something I said and maybe I can learn something or get a better idea.

This article's ObjectView's almost match my WorldSession exactly, except I'm stuck on the whole 'keep track of object state' thing. It can be done with components, events, iterating o1.compare(o2), etc. Written in 2002 o.0

http://www.gamasutra.com/view/feature/2948/distributing_object_state_for_.php?page=2

[Edited by - Dae on December 5, 2009 10:44:28 PM]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement