wickedworx

August 26, 2010

New Excruciating Guitar Voyage Trailer

Filed under: Uncategorized — wickedworx dev clone 1 @ 10:29 pm

EGV is going amazingly well… we’re getting very close to finishing this thing off, and I’m getting more enthusiastic every time I play through the game. We’re doing some voice-over recording this weekend (so far 4 out of the 10 or so characters have been voiced)… the QA-ing volunteers have been putting on really solid tickets to the database just slightly faster than we can solve them – which is an excellent motivator. The machine is working, so to speak. 🙂

We’ve done a new trailer:

Advertisements

August 17, 2010

EGV Scripting

Filed under: Technical — wickedworx dev clone 1 @ 3:50 pm

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 “Molly” at the helicopter’s current location:

  <spawn_object_data node="helicopterf" x="-2" y="0">
    <object name="molly">
      <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="humanoid_physics" w="1.5" h="3" bottom="1.5"/>
      <component type="animate" filename="molly.anim" layer="3"/>
      <component type="talkable" name="Molly" x="0.5" y="-2" />
      <component type="ai_walk" />
    </object>
  </spawn_object_data>

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

  <cutscene_start />
  <start_music cue="intro_amb" /> <!-- first two commands are run in one go --!>
  <wait time="2" /> <!-- game continues running for 2 seconds, script waits here --!>
  <speak target="narrator" key="narrator_intro_1" />
  <speak target="narrator" key="narrator_intro_2" />
  <speak target="narrator" key="narrator_intro_3" />
  <speak target="narrator" key="narrator_intro_4" />
  <speak target="narrator" key="narrator_intro_5" />
  <speak target="narrator" key="narrator_intro_6" />
  <speak target="narrator" key="narrator_intro_7" />
  <speak target="narrator" key="narrator_intro_8" />
  <speak target="narrator" key="narrator_intro_9" /> <!-- all speak commands run in one go, narrator character queues up his dialogue --!>
  <wait_for_main_slot /> <!-- game continues running while dialogue is spoken, script waits here until it finishes --!>
  <fade target="1" />
  <set_music_effect target="100" />

  <camera_speed speed="5" linear="true"/>
  <camera_zoom zoom="40" set="true"/>
  <add_focal target="pan_1" jump="true" />
  <add_focal target="pan_2" />
  <remove_focal target="pan_1" /> <!-- script sets all these camera options ready to go, in one update. all of these commands are just changing the state of the camera. game does not update --!>

  <wait time="2" /> <!-- game continues updating for 2 seconds, script waits here --!>

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

July 3, 2010

Some new EGV screenshots

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

Here are some new EGV screenshots, showing off areas from the beginning of the game… some of these areas featured in the preview video we did already.

You’ll notice the majority of these sections are set at night – hence the blue/dark kinda feeling (with the only bright light coming from lamps and such…).

We’re at a point now where the majority of our work is scripting and level editing – so it’s all fun! There’s a lot of dialogue and character scripting / animation to do for this game, dialogue trees etc.. – but it’s all worth it – it’s coming along great!

I’m going to write a more technical blog about the workings of the scripting system soon.

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)
<block>
    <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"/>
</block>
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 override="component" unique="type" name="physics_body" index="0">
        <data points="G_crashsite_ground.poly" />
    </override>
    <override override="component" unique="type" name="outline" index="0">
        <data points="G_crashsite_ground.poly" />
    </override>
    <override override="component" unique="type" name="texture" index="0">
        <data points="G_crashsite_ground.poly" texture="rock.png" sx="0.07" sy="0.07" />
    </override>
</object>
(the .scene file is created by componentiator, see original post for screenshot)
c) an inline object definition in script
<wait time="2" />
<spawn_object_data>
    <object>
        <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" />
    </object>
</spawn_object_data>
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:
getRootObject().getComponent(“position”);
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);
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.

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 😉 ) …

May 2, 2010

LOL LOL KITTY

Filed under: Uncategorized — wickedworx dev clone 1 @ 11:40 am

All estate agents must die…

April 16, 2010

acrobatics

Filed under: Uncategorized — wickedworx dev clone 1 @ 12:38 pm

Yesterday I worked on player movement / physics on two games. One is currently going under the title “Stick ‘Em Up 2”, but subject to change if we think of a different name… One of the areas where we got a lot of mixed feedback on Stick ‘Em Up was the controls. We use Box2D.XNA for our physics, so anyone also using Box2D might find this interesting!

So, for SEU2, I have been prototyping improved player movement:

  • Ducking
  • Improved handling of slopes
  • Improved jump handling
  • Wall jumping

One of the strangest complains we got on SEU was that jump was on the left trigger, and not a face button. I really think it’s obvious why jump is on the left trigger…but for those who didn’t understand why: right analogue stick is used for aiming meaning your right thumb is not available to press face buttons.. if jump was on a face button (A X B Y), you’d have to stop aiming while you jumped. In SEU2, I plan to have jump mapped to both left trigger *and* a face button – so people who (for some strange reason) find left trigger awkward, can have it their way. Weirdos.

OK, so the first thing I did to improve the player movement was to ‘reset’ the play velocity every frame, and over-write it with what we felt was correct. This means BOX2D’s world gravity force is not applied to the player (it is still applied to all other world objects), and we have to use our own gravity counter to accelerate the player downwards. The reason for this change is to avoid the ‘mini accidental jump’ the player would do after running up a slope (after running up a slope, your Y velocity is going upwards, the slope ends, and you continue running upwards). Instead of just using an X/Y velocity, we now have the velocity split as “gravity/jump velocity” (Y) and “walk velocity” (not quite X). Walk velocity is then always applied perpendicular to the ground you are currently on (or, if you are in the air – along X). This worked. It was great, and you need no longer fear that mini-accidental jump at the top of slopes (which often meant you couldn’t do a *real* jump because you were already in the air…)

Wall jumping… this was fun, and easy. Firstly, I lowered the amount of control you have of the player in the air – in SEU1 you had as much control in the air as you did on the ground, meaning you didn’t need to take a run up for jumps, and you could completely reverse the direction of a jump once in the air.. This is no longer the case.. while you still have a large amount of control over your jump in the air, it is not on the same level as when you are on the ground (approximately 1/5th the amount of left/right acceleration in the air as on the ground). This means we have much more control over ‘pushing’ the player off walls when they do a wall-jump, even if they are still pressing the stick in to the wall.

Ducking .. in order to do ducking we give the player two physics bodies. Only one is ever enabled, either the ‘standing’ or the ‘ducking’ shape. The properties (position, velocity) of the enabled body are copied in to the disabled one each frame. When the player switches between ducking/standing – we swap which body is enabled. If the player is ducking, we do a raycast check to make sure there is enough space to stand back up, and if not – we make sure the player stays ducking. Actually fairly simple to implement, and so far, appears to work fine!

For Excruciating Guitar Voyage, I’ve been adding extra features which should allow the level design to be more open, despite the game’s 2D limitations.. One of these new additions is LADDERS. I use a ‘sensor’ body for the shape of the ladder, which informs the player whether they can “ladder” or not (on BeginCollision and EndCollision messages are sent).. If the player can “ladder”, and chooses to ladder (by pressing ‘up’ or ‘down’) we simply turn off their gravity, and allow movement in *either* X or Y. This prevents diagonal ladder climbing – you can either go up/down or left/right. If they jump, or leave the ladder area, everything returns to normal. This hasn’t been tested to death, but so far – it seems to have the desired effect. In EGV as there are no other dynamic objects than the player, the world gravity is actually set to (0,0) anyway… one feature I haven’t found in Box2D is the ability to set different gravity values per object (override, for example), so best to not use it altogether in this case.

OK, was gonna write more, but I forgot what while I was eating lunch.

April 10, 2010

continuing on (again)

Filed under: Uncategorized — wickedworx dev clone 1 @ 10:18 am

Stick ‘Em Up has been doing really well in the XBLI charts. Me and Jon are both very pleased. I feel it’s a win for “good gameplay” amongst what can sometimes look like a sea of avatar gimmick. It goes to show, you can just make a good, solid, fun game – and it will be successful on its merits. Party on.

(find out more about Stick ‘Em Up at http://whatevergames.net/ )

Anyway…. it’s time to move on to the next project(s). I’d taken a couple of weeks off after SEU – the first week was very busy, and the second was not. I did some recording with Kieronononon, saw some bands, went to a safari, and even found time to play some games. Either way – right now, it’s looking like I’m going to be very busy for the next couple of months – and I think that’s a good thing..

Here’s a screenshot from Excruciating Guitar Voyage (PC / X360 Indie). You can see here, ‘the EGV sewer band’ – hanging out in the sewers.

Since I last posted about EGV, I’ve pretty much started again…! It may seem wasteful, but now I’ve actually got an idea of how I want the game to play, this restart made a lot of sense. Plus, I’ve brought it up to scratch using all the GameObject/Component management systems we used in SEU (while also bringing over its existing simple scripting system – for cutscenes, game events, etc..). No idea on the timescale for this, as I’m working on another project with Jon – and that will be taking priority.. and I’ll just be working on EGV whenever I get stuck / level design block / etc…

Things should be more efficient on this project, as we actually have a scene editor now! Screenshot below (yes, I realise it still says “form1”.. not all the buttons work yet, either):

I’m also (for a couple of weeks) helping out around the edges on another game project.. it’s starting to come together now – should be really fun! Not sure how much I can write about that, so I’ll keep it minimal for now.

March 22, 2010

STICK ‘EM UP

Filed under: Uncategorized — wickedworx dev clone 1 @ 3:44 pm

STICK ‘EM UP is now available online!

here’s a photo!

« Newer PostsOlder Posts »

Blog at WordPress.com.