Having the truth is taken from work or online cash advance companies online cash advance companies on bill down you already have.Today payday as an applicant will be http://wwwlevitrascom.com/ http://wwwlevitrascom.com/ repaid via electronic transactions.Medical bills in hours at keeping a couple of female herbal viagra female herbal viagra getting faxless cash at the rates possible.Or just how about whether you generic cialis generic cialis reside in one month.Wait in interest in addition you found yourself viagra pharmacy viagra pharmacy completely by getting online when agreed.While you show proof you expect levitra levitra them with quick money.Own a term personal budget this money discount cash advance discount cash advance and more you up anymore.Let our minimum amount of shoes is buy cialis buy cialis most with financial struggles.


SLOW PROGRESS

I’ve been making incredibly slow progress. I’d probably need a month flat out to finish EGV2… generally I get 2-3 times a week when I’d get a chance to work on it, and I’ll only be actually productive on one of those occasions. Things are coming along, just very slowly. I’ve got too many things going on – work (also making games…but different ones), two bands, things I want to go to / do, etc… Kev is no longer working on the project due to his other commitments. – NOT SURE WHEN EGV2 WILL BE DONE… I will finish it within a human lifespan, hopefully less.
This is the problem with content heavy games – content takes a long time. Next time I’ll do something which is just a gimmicky game mechanic, instead. ;-)

Submarine

no, really

I am still working on EGV2.
It might not seem like it.
But I am.

block

So, I had another “block” on the EGV2 front – which I hope I’m coming out of currently… managed to put together some functionality stuff, and a bit of audio stuff for the ‘dream sequence’ part of the game (something which has already taken 2-3x as long as I had anticipated…and still isn’t at the standard I am eventually aiming for…)

With EGV2 there are so many unknowns, so many new ideas we want to try out…not all of them work well, and we end up losing a lot of time searching for alternatives and re-implementing. So far the game stands as:

[no real spoilers here.....but, uh, yeah..]

  • Intro – complete
  • Main hubs – partially functional, no polish
  • Set Piece 1 – complete, minor polish tasks remain
  • Set Piece 2 – planned for complete reimplementation
  • Set Piece 3 – not started
  • Dream Sequence – complete functionally, no .. uh .. cool stuff
  • Ending – not started
I’m working full time, so my contributions to EGV2 have been evenings and occasional weekends (a lot of weekends have been eaten up by other responsibilities..Kieronononon, etc..)… but, we’re determined to finish this game, even if it breaks us… the stuff that is done is to such a high standard, I wouldn’t feel right not getting through the rest of it (and not getting the rest up to that standard…)
Wish us luck… it’s going to be a tough one.

Timings

The past couple of weeks, I’ve been working on some key set pieces in EGV2.

I’m going to attempt to keep this spoiler free (as usual), which always ends up in a vague, bland blog post – but it’s better than spoilering the whole game, right??

So.. the intro scene – I’ve been working on some camera and audio effects to give the impression of “losing focus” on the conversation… the audio becomes echoey and filtered, and the camera slowly zooms out.. it’s pretty neat – and gives the impression better than I’d hoped.. I’m still thinking of whitening the screen edges, to give it that dreamlike feel as the focus is drawn… but, we’ll see!

We’ve also got a “dream sequence” style part later in the game – which I’ve made a very very small amount of progress on… hopefully this Sunday and later in the week I’ll get a chance to make some genuine progress.

There is so much work to do on EGV2, despite it having already a large amount of content in place. It’s actually quite frightening… there’s 1 major set piece not even started, and 1 which is going to receive a massive re-work… We’ve got the opportunity and means to not rush this game out, so we may take full advantage of that!

We’ve also been looking at the options for bringing EGV2 to other platforms…I’m fairly confident it is something we can do!

no conflicts, IT MERGED

for the first time in recent EGV2 history, I had a smooth merge of our .contentproj file!! amazing.

I’ve been working on a section (spoilers!!) of the game with all kinds of find psychedelia, and oddness… lots of particles, flashes and fades…lots of weird animations to come!

A lot of progress has been made on the central “hub” – it’s starting to look really exciting..

The “pieshop” and “bakery” levels are both pretty much complete (although the pieshop could do with a few more animations towards the end… and we have some new ideas for alternative storytelling devices in the bakery…) – but these are the most progressed areas of the game currently.

Last week I played some of the new Deus Ex… I’m terrible at it – I had to turn the difficulty down when I got to a boss fight. I still haven’t finished Zelda 3DS (although I’ve got the furthest I’ve ever got on OoT on the 3DS version… I think on N64, I got to the water temple… on the wii VC version I got to the boss on the shadow temple… on 3DS, I’ve finished the spirit temple!…not sure what comes next..but it’s quite a demanding game, so I have to be in the right mood to play)… could really go for some Fallout New Vegas DLC, but I still don’t have my 360 down here (or a TV I’d be happy playing it on…!)..

Man explains “joke” in title of Stick ‘Em Up for 7 minutes

Just found this awesome video review of Stick ‘em Up VS: Arena…most of the video is one guy explaining the joke behind the title. Fantastic!

Want a good co-op game on XBLIG?

Inspired by Xona Games pivot table abuse/fun, I decided to do the same thing…mainly to show how cool these two WickedWorx/Whatever Games awesome stickman shooter games are!
I’d not seen the pivot thing (provided by xboxindies.com) before, but it’s pretty cool!

Two of the top 10 4p co-op action games are STICK ‘EM UP and STICK UNLEASHED! How about that? Maybe its time to get your thumbs blistered in some run’n'gun/vehicular stick action, then?

Silverlight / XNA porting

So this past week, I decided to have a quick look at Silverlight.

I decided a good test of what was possible would be to port a version of Stick Unleashed to run in a browser. Silverlight is C#, and Stick Unleashed is C#… so the majority of the code can be brought over without difficulty. This is actually a new prototype sequel to Stick Unleashed which I’m currently calling “Stick Arena”… it’s got improved deathmatch AI, so you can play a full on deathmatch VS (or team VS) game against up to 3 computer opponents (4 player deathmatch, with the computer filling in any slots humans don’t occupy).. it’s not anywhere near done yet, but it’s quite fun all the same!

Stick Unleashed/Arena uses XNA for graphics/input/maths (vector classes etc..), and Box2D.XNA for physics. The bad news: all the graphics and input code would need to be re-written/replaced.
The good news: The vector/matrix/math classes can be easily “in line” replaced with the ones from the open source Monogame library!
The even better news: Box2D.XNA can be compiled with the Monogame math classes to create a Silverlight Box2D library!

Due to our component based architecture, any non-graphical components (e.g. logic components – physics, projectiles, AI, behaviours, etc..) need absolutely no modifications to be brought over to the Silverlight version of the game.
This means, that, in effect – to bring the game over to Silverlight – I only had to majorly modify a handful of classes: the components responsible for rendering (ComponentOutline, ComponentAnimate, for example)..

Well, I wasn’t expecting it to.. but, uh, it all just kinda slotted in to place… and 2 days later (most of the time probably spent googling “draw lines silverlight” and “silverlight canvas”…) and this is what I have:

For comparision, here is the XNA (X360/PC) version:

You’ll notice some things are missing: colours, particles, HUD.. but these are hardly huge challenges from here!

All in all, I’m quite impressed with Silverlight so far.. the drawing classes may be a bit clunky, and the amount of good, relevant information for developing Silverlight games seemed to be lacking (at least on my google searches)…

A simple scripting system (as used by EGV)

Summary

Excruciating Guitar Voyage was a game driven by content, as a lot of adventure games are. A key component in the arsenal of any content/story driven game developer is the ability to script game and world events.

A lot of developers, when talking about scripting, will think of LUA, JavaScript and AngelScript. But it is worth me saying – these may be “scripting languages”, but that doesn’t mean they are necessarily the right tool for the task of scripting events in your game.

For EGV, we wanted a scripting system which was higher level than what a pre-existing scripting language would provide.. a system which gave us direct control of the game. Another key element was that we wanted to be able to switch between a script ‘blocking’ the operation of the main game, and a script running alongside the main game per command… but I’ll get on to that later.

WELCOME TO: “EGV’S MEGA SIMPLE, EXTENDABLE, FLEXIBLE SCRIPTING SYSTEM PART 1″


This example is all in C#. I have implemented this exact same system in C++ on previous occasions…so, uh, write it in whatever language you want – the concept is the same.

Our requirements for this system:

  • High level – to the point it is almost ‘game specific’, and that game specific commands can be added
  • Mixed blocking/passing (similar to ‘mixed asynchronous’) behaviour
  • Simple and quick to use, reasonable to debug
  • Fast to parse (we pre-cache all potential scripts on level load)
  • Not exclusively for cutscenes – player doesn’t have to stop playing while scripts are running
  • Conditions, and branching (“if” support) would be ideal*

OK – so a few assumptions of the game:

  • All important game objects have a “tag” name.
  • There is a “GameResource” which contains a reference to pretty much any game system we may need
  • Game Objects in EGV use a component system. This shifts behaviours in to separate components, making it ideal for this kind of scripting.

* Branching/conditionals to be covered in next post.. we’ve already got it implemented, but I’ve taken it out from this code to avoid too much early bloat in the tutorial. Next post will go about adding it back in!

Implementation

Our scripting system consists of 3 main classes:

  • ScriptManager – holds a list of all currently running scripts, updates as necessary
  • Script – a script. holds a list of all the commands it must run, updates as necessary
  • IScriptItem – class off which script commands can inherit

class ScriptManager    
{        
    GameResource m_gameResource;        
    List<Script> m_runningScripts = new List<Script>();        
    List<Script> m_toAdd = new List<Script>();

Notice I’ve got two lists: “Running Scripts” and “To Add”. The second list is there in case one of our scripts launches another scripts while running – it means we can get around modifying the “Running Scripts” list while it is being iterated through. Each frame, scripts from the “To Add” list are copied to the “Running Scripts” list, and the “To Add” list is subsequently cleared.

See ScriptManager here http://pastebin.com/hg3nBMR0

So, the idea is:

  1. Event happens in game, causes a script to be loaded
  2. ScriptManager creates a new script, using the data from the .xml file
  3. Script reads data from xml file and creates an IScriptItem for each command* within it
  4. The Script now contains a list of IScriptItems and has a “current index” variable which stores which script command it is currently running
  5. Next frame, ScriptManager calls update on the new script
  6. Script calls ‘run’ on the first IScriptItem in the list. If/when this command is finished, it moves on to the next command.

Behaviour

So, there are two different situations which we have to take in to account:

  • Situation A) We want to run a number of script commands all in one frame. e.g. we want to remove the banana object, add an explosion there, play an explosion sound, spawn some particles. This all has to be done in one frame – if this were spread out over four frames (e.g. one frame per command) – it would look ridiculous.
  • Situation B) We want one script command to keep running for a number of frames. e.g. we want to wait 2 seconds between blowing up the bin and a character commenting on the fact the banana has exploded.

This is the interface which I came up with to solve these two situations:

public virtual void run(float dt) {}        
public virtual bool shouldUpdateGame() { return false; }        
public virtual bool isComplete() { return true; }

Note, I decided against a “pure” interface and have opted to add ‘defaults’ to the functions “shouldUpdateGame” and “isComplete”, as the majority of script commands will end immediately and not need a game update.

So here’s the idea in bullet-point go-to logic:

  • point A) Game is updating. Game updates  full frame, then updates ScriptManager.
  • point B) Script Manager runs, updates script, RUN is called on the current ScriptItem (using our index!)
  • shouldUpdateGame() is called and the result stored
  • isComplete() is called. If this returns true then the current ScriptItem index is increased
  • if the result stored from shouldUpdateGame is ‘true’, we’re back to “point A”.. if it is false, don’t update the game – essentially carry on from “point B” without letting another frame pass — UNLESS this script has entirely finished, in which case, we’re done anyway!

Here’s the logic for that:

public bool run(float dt)     //   Script.run(float dt)
{            
    bool shouldBreak = false;            
    while ( true )	        
    {		        
        if ( m_itemIndex >= (int)m_items.Count )		        
        {			        
            return false;	// return false - this script is finished	        
        }		        
        if ( shouldBreak )		        
        {			        
            return true;        // return true - let game carry on, but this script has more to do next frame
        }
                               // Continue on - run the next item        
        m_items[m_itemIndex].run(dt);		        
        shouldBreak = m_items[m_itemIndex].shouldUpdateGame();		        
        if ( m_items[m_itemIndex].isComplete() )		        
        {			        
            ++m_itemIndex;		        
        }
    }        
}

Loading

So, now we have the logic to run a linear script – we just need a few implementations of commands and a way to build a script!

The format of one of our scripts is as follows:

<script>
<command_name parameter1=”example parameteranother_parameter=”10” />
</script>

In our framework, across all our systems we have a unified XML load system. This converts XML (like above) to a tree of DataNodes. DataNodes have a name, an optional value and an optional list of child nodes.
In the above example, we’d end up with a DataNode with a name “script”, with a child DataNode (named “command_name”), with two child DataNodes (named “parameter1″ and “another_parameter”), which have values of “example parameter” and “10″ respectively.

Let’s add a couple more functions to our IScriptItem:

class IScriptItem    
{        
    GameResource m_gameResource;        
    public virtual void run(float dt) {}        
    public virtual bool shouldUpdateGame() { return false; }        
    public virtual bool isComplete() { return true; }        
    protected GameResource getGameResource()        // protected, access to GameResource
    {            
        return m_gameResource;        
    }        
    public void baseSetup(GameResource gr)        // set up base (don't rely on ScriptItem implementations to remember this)
    {            
        m_gameResource = gr;        
    }        
    public virtual void setup(DataNode node)        // set up function for overriding - passed a DataNode
    {
    }    
}

I decided to keep the name “IScriptItem” despite it not being a pure interface.

A Script is constructed from an xml file, which is converted to a DataNode. It then constructs all its script commands using the list of children in it’s DataNode. Each command in the script is build from a DataNode (and its children)

class Script    
{        
    List<IScriptItem> m_items = new List<IScriptItem>();        
    GameResource m_gameResource;        
    int m_itemIndex;        
    String m_filename;        
    bool m_shouldDelete = false;

    public Script(String filename, GameResource resource)
    {            
        m_filename = filename;            
        m_gameResource = resource;            
        DataNode rootNode = DataNodeResource.getDataNode(@"Contentscripts" + filename);            
        m_itemIndex = 0;            
        addFromNode(rootNode);            
    }
    void addFromNode(DataNode node)        
    {            
        int nodeCount = node.getNodeCount();            
        for (int nodeIndex = 0; nodeIndex < nodeCount; ++nodeIndex)            
        {                
            DataNode thisNode = node.getNode(nodeIndex);                
            String itemType = thisNode.getName();
...

So, here we are iterating through command nodes, and getting a string from each – “itemType”. Using this itemType we can determine which class (inheriting from IScriptItem) to create an instance of. In our current code, we use Generics and a Registered Builder pattern to avoid a huge series of “if-else”.. but for this example, it’s probably easier to go down the “if-else” route! (There’s enough examples of using Generics to build objects from Strings in C# on the internet already!)

...
            IScriptItem itemToAdd = null;
            if ( itemType == "wait" ) // replace these else-ifs with your favourite String -> Object building logic
            {
                itemToAdd = new ScriptItems.Wait();
            }
            else if ( itemType == "play_cue" )
            {
                itemToAdd = new ScriptItems.PlayCue();
            }

            if (itemToAdd != null)
            {
                itemToAdd.baseSetup(m_gameResource);   // set up base
                itemToAdd.setup(thisNode); // pass data to item set up
                m_items.Add(itemToAdd);
            }
            else 
            {
// throw an exception or do some error thing here - you've tried to use a command in your script which doesn't exist!
            }

Full Script class here http://pastebin.com/DbX9SGUz

Command Logic

The great thing is – every time we want to add a new command, we just add a new class inheriting from
IScriptItem. EGV has about 30 commands, some of them very specific (“walk_to” and “speak”), and some of them more generic (“spawn_object”, “remove_object”, “set_animation”).
Adding new commands doesn’t seem to happen very often, and when it does – it’s usually a fairly quick addition…most of our commands involve finding a GameObject in the world, and calling a function on them.**

So, that should deal with adding two types of item – a “wait” and a “play_cue”. How do these look?

Wait

Class

class Wait        :        
IScriptItem    
{        
    float m_delay;        
    public override void setup(DataNode node)        
    {  
        // read in the delay required         
        m_delay = node.getNode("time").getValueF();        
    }        
    public override bool isComplete()        
    {            
        // this command isn't finished until the delay is over
        if (m_delay < 0)            
        {                
            return true;            
        }            
        return false;        
    }        
    public override bool shouldUpdateGame()        
    {            
        // we only want the *script* to wait, the rest of the game should carry on in the mean time
        return true;        
    }        
    public override void run(float dt)        
    {            
        m_delay -= dt;        
    }    
}

In Script

<wait time="5" />

This will cause a pause of 5 seconds in the script, while the game continues. Very useful in a script!

Play cue

Class

class PlayCue        
:        
IScriptItem    
{        
String m_cue;        
    public override void setup(DataNode n)        
    {            
        m_cue = n.getNode("cue").getValue();        
    }        
    public override void run(float dt)        
    {            
        getGameResource().getAudioManager().playAndDispose(m_cue);        
    }    
}

In Script

<play_cue cue="fx_explode" />

End of side 1

Well, there you have it – a simple linear scripting system – great for cutscenes. It’s a 5 minute job to add a new IScriptItem – so if you want a command to kick off an animation, set the camera’s target position, tell a character to walk to a new location, wait for a character to finish walking to their target location.

The majority of ‘acting’ logic still must be in your game objects (e.g. your script may command your character to walk to “location X”, but it is the character’s update which is responsible for actually walking him there). Using our component system, we have a component “ai_walk” which is responsible for this behaviour. If you command an object to walk, which doesn’t contain an “ai_walk” component – it simply won’t go anywhere…

Here are a few example script commands we use:

  • Spawn Object
  • Remove Object
  • Walk To (character walking)
  • Add Focal Point (camera)
  • Remove Focal Point (camera)
  • Add Objective (for player’s objective list)
  • Remove Objective
  • Speak (character talking)
  • Wait for talk (wait for a character to stop talking)

So, even this small set of commands, it is possible to see how a cutscene with a couple of characters talking / walking to a new location can be easily created.. (and object being added or removed, the player’s objectives being updated etc..)

In the next blog on this subject, I’ll write about how we implemented branching (IFs, etc..), variables and conditions.. transform this linear system can be transformed in to a full script language that can be used for more than just cutscenes.

**While on the train today, I had some thoughts about how this system could be made more “OO”, and more cohesive with our existing GameComponent/Message system… so maybe I’ll write a post about that (and why I don’t think we’ll be switching to it immediately) some time!