TIGSource Forums

EXCRUCIATING GUITAR VOYAGE
A platform-puzzle-adventure
WE FINISHED DEVELOPING THE GAME, AWESOME!!!!


Excruciating Guitar Voyage is a platform-puzzle-adventure game by wickedworx games. We're working on this as a very small team, but we hope it's got a hint of a big feel about it.

Set yourself on fire, electrocute yourself, collect items, talk to a bunch of weirdos, and much more to get yourself through Excruciating Guitar Voyage.


(http://www.wickedworx.net/egvimages/sshot1.png)
(http://www.wickedworx.net/egvimages/sshot2.png)
(http://www.wickedworx.net/egvimages/sshot3.png)
(http://www.wickedworx.net/egvimages/sshot4.png)
(http://www.wickedworx.net/egvimages/sshot5.png)
(http://www.wickedworx.net/egvimages/sshot6.png)

This is a technical community, you aren't gonna scare anybody here! :gentleman:

That said, you use real portraits on your sprites? Is this player-defined, too?

hehe, you're right.. i'll probably post the more exciting technical stuff here in future - but seemed kinda silly to do a copy-paste job straight away :)


they're set for the game.. they're all different characters, so they'll make sense with the character's personality & portrait matching. - i think there's a risk that some of the characters would lose their charm if they had different faces.
(then again, there won't be anything stopping someone replacing one of the texture files!)

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
(http://img339.imageshack.us/img339/7440/awfuldiag.png)

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)
b) a .scene file referencing multiple object files, e.g. here's one _block.object being overriden
(the .scene file is created by componentiator, see original post for screenshot)
c) an inline object definition in script

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:

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:
etc..

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.

I like component-based designs. Why the two threads though, what's the benefit? It seems to be just a huge hassle to keep everything synchronized.

it's loads faster because (on X360 or a dual core system) all the update/physics is parallel with the render side!
no point stalling up the physics while we're rendering etc..

and there's very little synchronisation, in fact all we have is an end-of-frame wait.. when we were doing this on Stick 'Em Up (X360 indie) which uses mainly the same underlying tech, we went from around 30-40fps to 55-60fps by splitting in to two threads...and it was around 1 hour's work!

render side is (pretty much) read only, so there's no real worries there. - as long as you make sure your render side stays read only, and that you don't pull the rug out from under anything while its rendering (it's ok to move things about by 1 frame's worth while rendering, generally...this doesn't tend to notice).

Ahh, I was about to ask about this myself but this makes sense. Does rendering really take that much time? I didn't realize that it could cause such a significant framerate jump by giving it it's own thread

well, in Stick 'Em Up the render wasn't really too slow.. took around the same length as the physics update did.. the 'regular update' was fastest out of all 3 (this didn't really do huge amounts - player input, bits of game scoring logic, spawning new objects, etc..)..
but splitting the physics/regular update apart to run in parallel is a lot messier than splitting the render off to its own thread.

in EGV, the render is actually quite a large chunk (there's more going on than the screenshots may imply) - as there are several 'layer' passes (in order to do the static lightmapping, with a dynamic lightmap on top - light map affects sky areas differently to non-sky areas... and the little drop shadows etc.. without dropping shadows on the sky) + a fairly simple post process running on all of it... so it's a little slower than SEU was in terms of render time, which really means there's a huge advantage to having it split on two threads.

but actually, the slowest part of the render is where we draw the 2D lines.. building up the buffers to render these is quite CPU heavy (and they can be dynamic, so rebuilt per-frame), so there's a fair bit of work before sending anything over to the GPU. it's not huge, but it's still CPU work rather than GPU stuff...

i was quite surprised it made such a difference too - but i guess it makes sense... if you don't parallelize any of your code, you're basically choosing to only use a fraction of the processing power available..

The video looks pretty cool, I remember coming across you blog before. I suppose you aren't using Chipmunk anymore if you have a 360 version.

You should look into adding shadow casting to your lights for your next version. We did in Twilight Golf and it's a pretty awesome looking effect: http://www.youtube.com/watch?v=EhSq8jqxTx4 It's not too hard to implement, though it uses a lot of fillrate.

cheers man! :)
yeah, we've switched to using Box2D.XNA for our projects, as it works in C# and on X360...
next time we're doing C++, we'll probably use chipmunk again (all our C++ stuff already uses it...) - but i'm not sure when that'll be. i'd got some really neat 1-way-platforms working with chipmunk, too.. was good fun!
we haven't done that in this newer iteration..everything is just solid, or non-solid. we did some ladders & stuff using sensors, but nothing too much further than that.


whoah! that's really neat.. very effective lighting effect.
i saw another project using that (presumably) lighting effect recently (i think one of the assemblee entries from january)..
have you got any good links with explanations of how to implement it / the basic concept? a stencil buffer kinda thing? you stencil out the 'shadowed' areas then render the light effect on top everywhere but where its stencilled? or it something different?

the majority of our lighting is done offline (the pre-baked / ambient lighting) .. this is actually done by doing a whole load of raycasts in box2d while in componentiator, to create a big lightmap texture... but then we can also 'add' lighting shapes dynamically too (we have some cheesy spotlights & glow effects) just by drawing in to the 'light buffer' - not very clear to see these in the video, however...

This is a well written article: http://www.gamedev.net/reference/programming/features/2dsoftshadow/ Not exactly what we did in Twilight Golf, but pretty similar. I used the stencil buffer for masking when I first figured out how to implement it, but you can easily use the destination alpha if you don't have stenciling.

The article also talks about soft shadows, but I was never able to get it to work very well and it prevents you from doing a lot of optimizations. Even if you do the fin clipping like they talk about, it never looked right to me. I sort of like the hard edged look anyway.

(http://img837.imageshack.us/img837/5954/egvbox.png)

was bored last night so did some box art..... probably not the actual one we'll go with ;)

some screenshots & stuff here:
(http://wickedworx.files.wordpress.com/2010/04/excru_new.png)
(http://wickedworx.files.wordpress.com/2010/07/egv_2010_july_1.png)

screenshot of our custom scene editor (named 'componentiator')
(http://wickedworx.files.wordpress.com/2010/04/lol_form1.png)
...you can see where it still says "Form1" ;) ahaha

I've posted a new blog update, to do with our scripting system!

Quite a lot of the work we’re doing currently is writing scripts for Excruciating Guitar Voyage.

EGV uses its own custom scripting system. I was trying to explain to someone how this worked the other day, so here’s a blog about it.

EGV script comes from simple XML. You have a command and a set of parameters.

Commands can be synchronous or asynchronous with the game (e.g. “wait” is asynchronous, as the game will continue.. but many other commands – e.g. spawn object, delete object, set value) will be run synchronously with no game update between them (this means if you want to do a bunch of commands in one frame.. e.g. spawn 4-5 objects in one go, you don’t have to worry).

More than one script can be running at any one time – but, the same applies – depending on the commands they are running, they will either block other scripts or run asynchronously alongside them.

This is set per command type – so you don’t have to worry about this while writing scripts (just when adding new command types).

We’ve also got very simple branching/if statements/and “goto” style things… as well as asynchronous wait command for animations to finish, player to make decisions, characters to walk / talk / – or even for just a fixed time etc..

So far we haven’t had much difficulty writing scripts for the game… and we’ve documented our many commands on our private dev wiki.

Currently we’ve got around 40 different commands… A large number of these are to do with camera movement/zoom/focus, and also object spawning/behaviour…
One of the coolest features we have is the ability to spawn a custom component-based object  in script… So I can just say “spawn this object, with these components (using this data)”… e.g. in one of our cutscenes, I want to create a custom “Molly” at the helicopter’s current location (offset by x:-2 and y:0) :

Here is an example showing how the mixed asynchronous/synchronous scripting works:


anyway – hope someone finds this interesting. we’ve got loads of work to do, so i’m gonna get back to it!

we've just done a new trailer...
we're getting really close to finishing this thing off! it's exciting watching all the pieces fall in to place!

we've spent the last week or so polishing the game, and it scripts.. other than that we've been recording dialogue. there's a lot of dialogue to record, but we've had some very helpful volunteers and things are coming along well!

we're now only 2 character voices away from a finished game!
some new screenshots:
(http://www.wickedworx.net/egvimages/smallss1.png)
(http://www.wickedworx.net/egvimages/smallss2.png)
(http://www.wickedworx.net/egvimages/smallss3.png)

some "behind the scenes" shots:
(http://img718.imageshack.us/img718/764/dscn3356.jpg)
Dan Flashbang recording
(http://img820.imageshack.us/img820/9740/dscn3357d.jpg)
Bruce (the robot)

and we're FINISHED.
now just sorting out distribution!

XBLI is sorted, as we just have to get through peer review.. we're just looking at PC distribution solutions, also.

HOORAY!!! EGV is now out on X360 Indie... we're still wanting to release this on PC too, so hopefully we'll sort that soon, also!!

HOORAY AGAIN, we've released the game for PC ourselves on our website!
it's only $3, this is about £2.
It's well worth it (I think), and it's awesome.

We got made "xbli game of the week" by dealspwn (http://www.dealspwn.com/tag/excruciating-guitar-adventure/) .. this is good!