June 24, 2010

WickedWorx and Components

Filed under: Technical — wickedworx dev clone 1 @ 11:19 am
(this is a post I wrote on tigsource forums… I know a lot of this has been covered here before)
I thought I’d write a little about how the ‘dynamic aggregation’ game object model works in terms of EGV…
this horrible diagram probably doesn’t show very well what’s happening, so I’ll explain further below
so, the game runs on two ‘main’ threads..
  • render / state – the main game’s render loop, and also state machine (out of game update)
  • update – update, physics (in game update)
there is also a network thread for the minor bits of networking the game does…
ignoring the state machine, it’s best just to see this as render/update.
when an object is spawned, it can either be spawned from
a) a .object file (looks like this)
    <component type="color" r="200" g="200" b="200" />
    <component type="position" x="0" y="0" z="0" rx="0" ry="0" rz="0" />
    <component type="physics_body" points="bridge.poly" density="0.1" static="true" renderable="false"/>
    <component type="outline" points="bridge.poly" />
    <component type="texture" points="bridge.poly" texture="machine.png" sx="5" sy="5" ox="0" oy="0" layer="3"/>
b) a .scene file referencing multiple object files, e.g. here’s one _block.object being overriden
<object name="Object_block.object">
    <override override="component" unique="type" name="color" index="0">
        <data r="0" g="100" b="0" />
    <override override="component" unique="type" name="physics_body" index="0">
        <data points="G_crashsite_ground.poly" />
    <override override="component" unique="type" name="outline" index="0">
        <data points="G_crashsite_ground.poly" />
    <override override="component" unique="type" name="texture" index="0">
        <data points="G_crashsite_ground.poly" texture="rock.png" sx="0.07" sy="0.07" />
(the .scene file is created by componentiator, see original post for screenshot)
c) an inline object definition in script
<wait time="2" />
        <component type="color" r="255" g="255" b="255" />
        <component type="alpha" alpha="1" />
        <component type="position" x="0.5" y="0.4" z="0" rx="0" ry="0" rz="0" />
        <component type="sprite" texture="credits_jon.png" sx="0.4" sy="0.1" layer="6" use_color="true"/>
        <component type="fade_in_out" />
The data is merged as required (e.g. using the overrides supplied in the .scene) and then sent to the GameObjectManager.
From here, each component definition is separated and sent to the ComponentBuilder. Each component is built (the correct component type is built depending on the type=””, using a templated factory thingy.. i know templated isn’t the right word in C#, but it’s the nearest equivalent C# does to C++ templating and i forget what C# calls it…) and sent its data.. e.g., here is how a “alpha” component builds:
public override void componentInitialise(string name, DataNode node, GameResource gameResource, GameObjectManager objectManager, GameObject gameObject)
m_alpha = node.getNode(“alpha”).getValueF();
Once all the components are built and added to the object, a ‘linkup’ stage is performed to allow Components to register with render, physics and update (or any other systems) as appropriate. This is usually not done in the componentInitialise as the whole object has not been created by this point.
e.g. a “sprite” component will register with render, but the “fade_in_out” component will register with just update.
when an object is destroyed, it calls an ‘unregister’ function on all of its components, allowing them to unregister with systems they have registered with.
Components can query the root object for other components, like this:
so, for example – the “sprite” component will get the “position” component, and use this to determine where to render itself.
if you have more than one “position” component in an object, it can be accessed as such:
getRootObject().getComponent(“position”, 0);
getRootObject().getComponent(“position”, 1);
there’s quite a bit of thread safety involved, especially with management of registered lists (it may be registering or deregistering with ‘render’ from the ‘update’ thread, for example).. to avoid any stalling, an intermediate ‘waiting list’ is used, and then flushed in to the main list on the next local update.. this means there is no holding on to mutexes during actual render/update, only during the flushing of the lists immediately before render/update.
destroying an object is never instant, it happens at the end of the current update frame.
well, there you have it – that’s how the whole of our game works. every time we need a new behaviour or new rendering method – it’s just a case of writing a new simple component… it’s quite neat!
watch the trailer and you can see where one of the objects detailed above is spawned in script.. 😉
next time i think i’ll write a bit about the scripting system, which works in a ‘mixed mode’ synchronous/asynchronous per-instruction timeline against the game updates.. it’s a custom scripting system (all in xml), but it allows us to make it very powerful.

June 8, 2010

Excruciating Guitar Voyage – first footage

Filed under: Uncategorized — wickedworx dev clone 1 @ 9:35 am

we spent some time editing together a short clip of the first few minutes of EGV.

things are starting to look awesome.

it’s using Box2D.XNA for physics (albeit fairly loosely – mainly using just for collision detection, rather than responses…), and uses our own game component system, and our new mixed-mode (asynchronous/synchronous per-instruction) excruciatingly simple scripting system. we’ve put a lot of effort in to making sure it’s quick for us to be able to create content & get it running in game, so we can script nice scenes and easily put a load of awesomeness in to the game… i’ve got a whole load of work to do before i head off to a festival for a few days, so i can’t really spend too much time writing here now!

better, more exciting blog post when i’m back!! for now, just enjoy video.

June 1, 2010

Time off

Filed under: Uncategorized — wickedworx dev clone 1 @ 11:15 pm

Had a week off to record with awesome brutaltechnopunk band Kieronononon … was really fun, and we got a lot done. Good stuff.

Also, made a whole load of plans / design decisions for Excruciating Guitar Voyage… the project is looking really ambitious (but hopefully achievable)  – and I think it’s gonna turn out great. We’re looking at a mid-August release for PC.

It’s a bit too early to show any more screenshots than I’ve already posted (and quite a lot of what’s been posted will change / has changed already).. but I can write a little bit about some of the game concepts we’re using.

Componentiator is still being used as the scene editor.. it’s still a bit rough, as tools go, but it’s far better than hand editing .scene (our own xml scene format, used by SEU/EGV) files.. Some simple play logic can be done with ‘triggers’ and ‘receivers’ in Componentiator.. but more complicated behaviours can either be done by scripting (simple xml based scripting, which uses commands which can choose to be synchronous or asynchronous with gameplay as they wish), or by writing a behaviour component (for more constant or repeated behaviours)… or a combination of the two!

EGV also uses a 2D lighting system which combines pre-baked lightmaps (generated using the physics system / raycasts when editing the level), and real-time ‘splashes’ of light to illuminate the scene… it looks pretty awesome, and really adds some mood to the game. – something we’re definitely going to be using!

We’re at the point now in EGV where the bulk of work is scripting/content creation/design… and the occasional helper component. It’s great to be in that kind of situation when working on a game like this, as it means we can just focus on bringing our ideas to life… I’ll try and post a short video in around 2 weeks of our progress, because I think it’ll be cool for people to see.

So, it was good to have some time off… my brain is still a bit fuzzy from finishing SEU, but I think I’m just about back on track to kick some ass on the next couple of projects.

“SEU2” (if that’s what it ends up being called) is looking really good! The graphics are a real jump from the first, and the wall jumping / new enemies / etc.. really makes for a different feel to the gameplay. We’re hoping to have several different gameplay modes in the game (survival, race, vs, team vs, anything else we can think of… suggestions from either of my readers are welcome 😉 ) …

Create a free website or blog at WordPress.com.