Moderate success!

Well, Henrik and I just posted the mobile version of Up Down Ready on Kongregate. Which is, admittedly, almost identical to the desktop version bar a couple of bug fixes and the addition of some touch-based controls.

I've spent an unpleasantly harrowing couple of weeks working on this, compounded by the inability to access any flash-compatible Android phones on which to test it. I have learnt a lot, the most important thing being this: YOU GUYS, IT'S SWEET THAT ANDROID IS OPEN SOURCE AND ALL, I GET IT, THAT'S ADORABLE, BUT JESUS FUCK DEVELOPING FOR IT IS HORRIBLE*. Ensuring a consistent experience for all users is a massive headache when half of them have something like half the display resolution of the other half.**

Also half of them don't have flash yet - because it's not a case of 'everyone gets the latest OS all at once'***, but rather 'oh well here is the latest OS but Samsung hasn't put it out for THEIR phones in Australia yet, who knows why.'

And in ANY case, if you are running an actual, honest-to-goodness open-source distro of FroYo such as Cyanogen, while it may 'greatly extend the capabilities of your phone' this does not actually include the capability to run Flash, because Google apparently hasn't actually released the FroYo source code yet. Go figure.

On the other hand, the new Multitouch API in Flash Player 10.1 was surprisingly easy and pleasant to use (then again, it's Adobe, so my expectations were kind of low). Touch support detection is as simple as Multitouch.supportsTouchEvents (of course, there's another potential minefield here - you can also check Multitouch.supportsGestureEvents, and given that some phones support single touches but not gestures or multitouch, you would have to create multiple input methods and different UIs and - augh, see? It just snowballs.)

This was actually all I used Multitouch for - since I was using single touches, which also automatically fire MouseEvents in Flash, I just used mouse input. I also spent some time noodling around with scaling modes and alignment, so that it doesn't look completely pants when it goes to fullscreen mode.

ANYWAY. What I am saying is that we entered Up Down Ready in Kongregate's mobile games contest (we had to upload it as a new game to be under consideration for the competition, which I thought was a bit silly, but there it is) and now we are officially downing tools on it for this year. We will hopefully come back to it in the future, at such time as we feel we can make a significant leap in quality and depth of gameplay (possibly an iPhone port or similar).

For now, we move on to Snowball. We will be crunching heavily over the next few weeks to attempt to get something, you know, functioning.

- just stab the other guy in the face straight away, it saves time

*Compared to, say, developing for iPhone. I'M JUST SAYING. I concede that developing for desktop environments has always, and will pretty much always be a compatibility hassle, but that's a different ball game and outside the scope of this blog post.

**See also: I know half of you half as well as I should like, and I like less than half of you half as well as you deserve.

***Gosh wouldn't it be super convenient if all the users got the updates to the OS at the same time OH HEY THAT'S WHAT APPLE ALREADY DOES WITH THE IPHONE.

Don't mind the cobwebs

Eep. It's been quiet here for a while, hasn't it? I am rather shame-faced about it. Still, I have been busy!

It's been a couple of weeks since we 'officially' released Up Down Ready on Kongregate. We got a really good initial reception, and since then we've had:

- 46,000 plays and counting
- an average user rating of 3.5/5 stars
- US$25.40 in ad revenue
- a whole bunch of player feedback to take into consideration
- a number of reviews and shout-outs (even one in Spanish!), all generally positive and some absolutely glowing

See the full list of reviews &c. on our under-construction homepage HERE

We also recently received an email from Greg who is in charge of badges and achievements on Kongregate, suggesting that we do some optimisation and a touch-based control scheme for Up Down Ready to make it suitable for play on Android devices and enter it Kongregate's upcoming Mobile Games Contest.

So this is what I am working on at the moment. I admit to struggling to find time for it with my job taking up a pretty hefty cut of my time. I have spent the past week screwing around with Flash and Flex just trying to get an environment where I could work with the relatively multitouch API in Flash 10.1

Technobabble time: I have been working primarily in Flex Builder 3 for Up Down Ready, which so far has been absolutely fine. However, it doesn't automatically target the latest flash player. I spent a lot of time faffing around in config XML files trying to point the IDE in the right direction and have not thus far had any luck.

I've just installed Flash Builder 4 to see how that goes, as it targets Flash Player 10 by default and should be a little easier to direct to the right versions. I'm hoping to have the touch interface code up and running by Monday to test it on an actual Android phone, at which point I can happily move on to the scaling and display voodoo required to make it not look like rubbish on the phone.

Kids, kidlets, cats and kittens: the lesson here is if someone tells you it's just a matter of adding some extra input and should be easy, the correct response is to suggest how about you add some extra input to THEIR MUM. Shit will invariably take longer than it looks like it should, especially with poorly-documented Adobe products.

I also have some messing around in Musagi to do, to clean up some of our music files and make them able to be looped seamlessly. See here for an explanation of how the Viking is making our .mp3s do this.

Plus there are, as always, bug fixes, user feedback to respond to, and a few little features here and there that will hopefully go in and give us a shot at that delicious US$5000 prize.

In the meantime, go play Up Down Ready! Give us good score if you like it. Maybe drop some Kreds in the tip jar if you REALLY like it.

- remember, the pointy end goes in the other man

A horse by any other name...

Hello the internet!

I have not been great about updating this. THINGS have been HECTIC.

Yes, Henrik and I went to Freeplay, and as you can gather from the sticky post at the top of the page, we WON a thing. The good fairy Freeplay Awards saw fit to turn our little Horse into a Real Game with the magical (rather hefty) wand of Best Design in a Game trophy.

And now that we've gotten through that rather strained metaphor - what is on the cards for me this semester?

Priority number 1: Get the newly christened Up Down Ready onto its feet (hooves?). I am, as we speak, spitting and polishing and integrating with the Kongregate API. We have also bought a domain and hosting, so UDR will be up there as well, with a separate mySQL highscore database.

The 'official' release will happen in the next week, so expect shameless and constant plugging of the game around then.

Then the Viking and I will be moving on to another little game currently known as Snowball. More on that when we get up to it, since we'll need to scope down and just build something as fast and tight as we can. I'm hoping to continue work on the Unity sound handler thing, too, since this semester we have an actual for reals sound designer.

First, though, we gotta get Up Down Ready ready.

In the meantime, be hoopy and stuff.

- your friendly neighbourhood sword lady

Horses for courses

The last gasp of Horse. Here it is, in all it's end-of-semester glory:

I'm not exactly sure about how the high score stuff will work online. It was sort of a last-minute why-not addition, so I have no idea how it will work with multiple users accessing it from different computers. It works on a local computer though.

Enjoy!

Some quick documentation for the sound system

This might be kind of dry, because I haven't had a chance to go through and add screenshots etc. But here is the documentation for the Sound System as it stands now.

The Sound System is a general purpose sound handler written in C# for game development projects in the Unity environment. It is designed to allow developers and/or sound designers to centralise control and handling of all sound effects and music.

Soundscapes are defined in XML and loaded from within Unity. The system itself is comprised of a single gameObject with a set of public static functions that can be called from any other script in the same scene. This mitigates the need for Unity AudioSources to be attached to specific gameObjects, allowing them to be instantiated dynamically at runtime using simple function calls.

Setting Up the System

1. Import the SoundSystem unity package into your project

By default, the system and all attached scripts will be placed in the Standard Assets folder.

If your project uses C#, you may choose to move the SoundSystem to a different location according to the specific requirements of the project.

If your project primarily uses JavaScript or Boo, it is recommended that you leave the Sound System in the Standard Assets folder due to potential compile order issues with non-C# scripts accessing the Sound System.

2. If you have not already done so, import the audio files for use in your project.

These will need to be placed in a Resources folder. An empty Resources folder is provided in the unity package. However, according to the Unity documentation, Resources folders can exist anywhere in the project hierarchy as long as they are correctly named.

3. Setup the XML resource file

The XML template is called SoundSystemXML. You can edit this file directly, or create a copy so that you have a template to refer to.

The XML file should be included in the same Resources folder as your Audio files. This ensures that it will be included when you build the scene. If it is not, you may encounter problems with the audio not playing when exporting your project as a standalone or web player build.

There are three kinds of objects that can be defined in the XML file (I can't display the XML correctly on the blog because the tags look like html and the text doesn't show up).

• SoundEffects, which represent a single sound that is played once or looped (eg. Character noises, environment sounds, looping ambient tracks. Can also be used for music). This is basically a single sound clip.

• SoundSets, which represent a set of related sounds that can be played randomly once or at set intervals (eg various similar gunshots or explosions, bird calls, lines of character dialogue that can be selected randomly for NPCs). This can have as many clip elements as you like. The numclips property must match the number of clips elements you have included.

• SoundPairs, which represent sounds that have an 'initialisation' followed by an indefinite loop (eg. A car starting and then the engine idling for a random period of time). This has two clip elements – the first one listed will be the initialisation sound, and the second the looping sound.

For each object, name is the name you call the object by using sound system functions, and clip refers to the import name of the clip in the Unity Inspector. Keeping these things distinct can be useful if you are using effects from various sources and need to keep track of attribution. All of the name properties you assign must be unique, or the system will not be able to load the sounds correctly.

There can be as many SoundEffects, SoundPairs and SoundSets as you like within the XML file, and they can be placed in any order within the SoundScape.

Using the SoundSystem methods

In order to use the SoundSystem methods, you will first need to place the SoundSystem prefab somewhere in your scene.

In the inspector, you will need to change the public variable XMLFilePath on the prefab to reflect the location in the project of your XML file. The default example is Assets/Standard Assets/Resources/SoundSystemXML.

SoundSystem methods are called from any script in the same scene as follows:

SoundSystem.methodName(“soundName”, objToPlayAt);

where soundName is a string and objToPlayAt is a gameObject (in most cases this will be the gameObject attached to the script you are calling the sound system from.

Some methods are overloaded to allow the user to specify volume as well. In later iterations, these will be further extended to provide finer control over how the sounds play.

The functions available in the current build of the SoundSystem are

playOnce(String Name, GameObject Caller)

This plays a one shot sound using Unity's playClipAtPoint() functionality and can be called on any clip loaded into the sound system, even ones contained within a SoundSet or SoundPair.

play(String Name, GameObject Caller)

play(String Name, GameObject Caller, float volume)

These play the sound object with the specified name once and parent it to the Caller object. Can be called for any kind of the three sound objects.

startLooping(String Name, GameObject Caller)

startLooping(String Name, GameObject Caller, float volume)

These start the sound object with the specified name looping and parent it to the Caller object. Can be called for any kind of sound object.

stopLooping(String Name, GameObject Caller)

This will stop the named clip from playing, and turn off looping. Can be used to cut a playing sound short if required. Can be called for any kind of sound object.

playAtInterval(String Name, GameObject Caller, float interval)

playAtInterval(String Name, GameObject Caller, float minInterval, float maxInterval)

playAtInterval(String Name, GameObject Caller, float minInterval, float maxInterval, float volume)

This will start the named SoundSet playing a random clip at the specified interval, or at a random interval between the specified max and min intervals. Can currently only be called for a SoundSet object, a SoundEffect or SoundPair will simply do nothing and log a SoundSystem warning.

I will upload and post a link to the current version of the Unity Package, so if anyone wants to play with it they can. I will also be updating this documentation as I further develop the system - it's still very much in the early stages.

Also also

Before I go to bed, the current build of Horse. The code has progressed a long way since the last build (hey, don't knock it, it got me a job), but the inclusion of assets has gone backwards. Lots of placeholders here - squares in the background will be randomly spawning stars, stuff like that. Asset handling is still a little messy, hence the large filesize. I'm a-working on it, as per my previous posts. Apologies to Henrik and Kai for not having all their rad art in at the moment.

There's a new mode though!

You guys! It's going to be SO RAD SOON.

Codespam

Okay so this is mostly a note for myself so that I remember when I go to work on it later.

But I SHOULD be able to fix some performance issues with the sound system by using UnityEngine's Object.GetInstanceId(), which returns a guaranteed unique id for every object. I can concat the unique gameObject id with the name of the soundEffect that has been paired with it and use that as the key when I want to lookup that specific soundEffect instance again.

Which in turn means I can eliminate the Transform.FindChild() call I am making in startLooping and stopLooping.

Which, gentle readers, should make it run faster since I am not searching a gameObject hierarchy every time a sound system method is called.

That said, you should still only be calling startLooping or stopLooping once on a state change, not every frame the object is in a state that needs a sound effect.

/spam

News from the northern front, at last! Also: using SWC files with Flixel in Flex Builder 3

Ohai there.

Apologies to anyone reading for the lapse in posting over the last couple of weeks. THINGS have been HAPPENING.

The main thing being that within the space of the last week, I put together a resume and folio, went to an interview and got offered a job as a Flash programmer and game designer at 3 Blokes Studio. I'm to start next Thursday, so everything is a bit of a scramble at the moment.

ANYWAY.

I have been looking into better ways of importing assets in Flixel. It is kind frustrating and there aren't many good ways to do it, because Flixel really is designed to use embedded graphics. Which in the case of Horse will mean a zillion frigging lines of embedding all the sprites. This is not code which I want to have to write. And anything that involves reading files from a folder makes it a pain in the butt to put on the interwubs.

I just spent several hours looking into using an SWC exported from the Flash IDE as mentioned here. The linked post discusses how to do in a regular AS3 Project in Flex Builder, where you can happily access Flash's MovieClip or BitmapData classes with no problems.

Unfortunately it's not quite as simple for the Flixel library. In order to be useful, a graphic must be loaded into a FlxSprite instance so that all of Flixel's clever collision magic can happen. As far as I understand it (and I might be wrong), to do this, you need pass in a class that inherits from Bitmap - which is exactly what gets created when you embed an image directly in an AS3 file, thus:

[Embed(source = "data/bg2.png")] protected var ImgBG2:Class;

The Flash IDE, however, exports JPEGs and PNGs as extensions of the BitmapData Class, which Flixel's FlxSprite can't use as input.

I spent some time grovelling over these threads trying to figure out what to do - it seemed like the only way to use these BitmapData classes was to directly modify the .pixels property of the sprite, which sort of defeats the purpose of handing Flixel a spritesheet and telling it to go do its stuff.

But then I found THIS, which solves everything magically with a few lines. So thanks to Flixel forum user L_O_J for that fix.

Ok, so there is still some faffing around that needs to be done with loading the sprites. But I am content with the amount of embedding and related horrors that this will save me.

SO. Here is how to do it.

1. Open up Flash and import all your graphics into a new .fla file. (I'm going to assume you're clever enough to not need screenshots for this bit).

The next part unfortunately could be a bit of a grind, depending on how many assets there are.

2. Export the graphics for ActionScript. EDIT: Export in frame 1 MUST be ticked, or Flash won't export the files to an .SWC when you publish.

2a. Make sure the ActionScript class names DO NOT include a filename extension, such as .jpg or .png, because that makes ActionScript explode when you try to access the class. There doesn't seem to be a way to get flash to import files without including the extension, so yeah, this bit is not so great if you're doing it in bulk.

I would recommend taking the file extension off the end of the library item name and then selecting all the items and exporting them all in one go, rather than exporting one by one.

There's always this extension for Flash which you could use, but it's only useful if you don't need specific naming conventions.

3. Go to Publish Settings and make sure it is set to export an SWC file when it publishes

4. Publish the file

5. In Flex Builder, go to the properties for whatever project you want to use the assets in. Under ActionScript Build Path, click on Library Path and Add SWC, and point it to the SWC you just created.

6. This bit is crucial for use with Flixel! Add the following code to the FlxG.as file of the Flixel library, as shown here:

This at the top of the file:

// needed for processing bitmapdata

import flash.utils.getQualifiedSuperclassName;

And this in the addBitmap() function:

if(!checkBitmapCache(key))

{

//--------CHANGED CODE FOR PROCESSING BITMAPDATA FILES CONTAINED IN AN SWC

/*replaces/adds to the following line:

_cache[key] = (new Graphic).bitmapData;

code found at http://flixel.org/forums/index.php?topic=628.msg4563#msg4563

thanks to flixel forum user L_O_J*/

var classType:String = getQualifiedSuperclassName(Graphic);

if (classType.indexOf("BitmapData") == -1)

{

_cache[key] = (new Graphic).bitmapData;

}

else

{

_cache[key] = new Graphic(0, 0);

}

//---------------------------------------

if(Reverse) needReverse = true;

}

And there! You should now quite happily be able to access the files by class name as if they were embedded in the .as files, without the hassle of copying filepaths and assigning new class names.

For certain values of progress

I am currently (still) working on refactoring the code for Horse. Because it is a mess.

This is largely due to the fact that we are on such a tight schedule - I never got the time to throw away my original prototype and rebuild the game on a more solid base. In addition to this, we didn't have a full design treatment before we had to start producing working builds, so I couldn't account for what was going to go into the game.

The net result is that there are hacks on top of hacks and weird bits of redundant code, which I am in the process of fixing up.

I'm a bit behind on the sound system. Hoping to get some more stuff into that over the weekend and have a preliminary music handler built this coming week so I can focus on producing the actual music and sound effects for the games.

Implements

On Wednesday, I had the opportunity to actually integrate the early sound system build into a few projects to see if it would explode horribly. So far it hasn't, although a number of inevitable bugs have been revealed by the in-project testing, which were fixed on the fly.

The current version of the sound system is now active in Blockets, Bullet, and the non-GFS project Migration. It went straight into both Blockets and Bullet with no real problems, and the coder on the Migration Project (Michael the Machine) is currently working to allow the system to talk to the gameplay engine he's written (most of which sits outside Unity and interfaces with the scene through a single class).

There was some good feedback from my fellow developers about what other kinds of functions they would like to see in the system, as well, which I diligently wrote down on my list.

I also had a chat to the Islands team about sound for their game, and this was what really got me thinking - their game has five unique areas with distinct soundscapes, which means I need a bigger and more complex class structure to contain this stuff and allow things to be called when required.

Without further ado, this is a list of ideas that I will be considering for the next build of the sound system, in no particular order.

- functions to fade sounds in and out and set volume

- functions to set up sounds that need to be attached to gameObjects (and possibly functions to kill them if they are no longer needed)

- "Sound Scape" objects, which contain all the sounds for a specific area of the game, with master play, stop and fade functions

- "Sound Sets", which contain arrays of related sounds (eg. various similar explosion sounds), so you could do things like this:

• play the sounds from the array in a set or random order at a set or random interval
• play a random one-shot sound from the set

-"Paired Sound" objects, which contain an 'initialisation' sound (eg. a jetpack firing up) and a looping sound that seamlessly follows it

That's my thinking so far, and what I will be working on with regard to the sound system over the next week or so. Other suggestions for useful things to do with sound are most welcome!

Who put this milestone here? I could have tripped!

Behold the milestone build for Horse. May take a while to load, it has music in it. Probably should start thinking about a preloader for it:

Arts are by Henrik and Kai. Music is either written and arranged, or just borrowed and arranged, by me. Also I scripted it. Controls are still only and ever up and down.

It has shiny! Also, more bugs. While I was busy trying to make it more milestoney, I uncovered and created a variety of weird behaviours that I need to fix in the next iteration. But it has pictures! And a new mode! And bad jokes!

Contains retarded Musagi renditions of part of the Amazing Horse theme from this video (NSFW), and also 'U Can't Touch This'.

Apologies to both Weebl and MC Hammer for butchering their music! I'm pretty sure since this is non-commercial and educational use that it falls under 'fair use', but if not I can just take it down.

Bang! (Clay pigeons are fuckers)

The first build of the Sound Effects Handler for Unity is go!

It is a single invisible GameObject that sits quietly in your scene until you invoke one of its public static methods from another script, whereupon it makes some kind of noise. It is dead simple, but it took a while for my thinking to progress to the stage where I could make it so.

The basic premise of the handler is that it centralises all of the sound effects contained in the scene.

As far as I know, Unity is designed to handle sound by attaching to objects AudioPlayer components, the functions of which are then called from that object's script. While this approach has its uses, it is one that I can only imagine would be immensely frustrating for a sound designer who had no contact with the game other than to provide sound effects.

Funnily enough, this is the role that I am taking on with all of the class' projects bar Horse. I decided that I wanted an interface that allows me to put all the sound effects into a scene and then say to my fellow developers this:

"Here are your sounds. This is what they are called. Here are some simple lines of code to make them play or stop, which you can call from any other script in the scene. Have fun, please try to leave my code alone, and call me over if you have problems."

And this is exactly what I plan to do.

At a glance, the SoundSystem prefab I have built looks like this:

The script property called "Sound Clips Input" is a public array where you put all your sound clips.

You may notice that some of them have pretty weird convoluted names that will be impossible to remember when you want to call one. The solution is in that Text File property of the script.

The Text File links up the names you want to attach to the sound with their initial file names. At the moment, it has to be set up by hand, but for the scope of these projects, it won't take long enough to be an issue.

In my example project, the contents of the text file look a little something like this:

blues=13-Gritty Harp 1

rocket=18380__inferno__hvrl

bang=65731__Robinhood76__00759_explode_2_distant

On the left, the new name for the sound. On the right, separated by an '=' symbol, the original file name. This gets read and set up inside the SoundSystem script when the scene starts. Simple, no? (As testing progresses this week, I will put some thought into if there are more efficient ways to manage this.)

The Sound Object Input property contains a template "Sound Object", which is a GameObject containing a blank AudioSource. This is what I use to create and play what I call 'state-based sounds' - those that loop continuously when an object is in a certain state e.g. character footsteps. This template shouldn't really be editable - I suspect there is a way to link up script properties to assets in code rather than the inspector, which I will look into in a later iteration.

At the moment, the Sound System script contains three public static functions with which developers need be concerned. They can be called from any script in the game. It does not require an explicit reference to the SoundSystem object within each script. Just use this syntax:

SoundSystem.functionName(parameterA, parameterB);

These functions are as follows:

playOnce(string Name, GameObject Caller)

This function plays the sound with name Name once at the position of the GameObject Caller, and then immediately destroys the AudioSource and cleans it up. (For those interested, it uses Unity's built-in playClipAtPoint function).

The Name should be the name of the sound as specified in the text file, and the GameObject is the object at which you want the sound to occur. Usually this will be the object the script is attached to, which would be written as this.gameObject.

startLooping(string Name, GameObject Caller)

This starts the sound with name Name looping continuously at the position of the GameObject Caller.

It does this by instantiating the Sound Object Template prefab at the position of the Caller object and changing the blank AudioSource clip to the clip called Name. This new object is then parented to the Caller object, so that if the caller object changes position, the sound effect will pan and fade accordingly.

If there is already a Sound Object attached to the Caller GameObject, the script will simply call Play() on the AudioSource component of this object, rather than creating a new object.

stopLooping(string Name, GameObject Caller)

This finds the looping sound with name Name at the GameObject Caller and stops it playing.

If this function is called from an object that has no such sound playing, the Sound System will print an error to the console.

So, that's the basics of the Sound System.

I have also collated a bunch of placeholder sound effects to be used in most of the games, so I will be implementing and testing the system with the rest of the class this week. I have a list of things I would like to iterate on as I progress through the rest of semester, and I am sure my fellow developers will have useful things to add to it.

Quiet in here, isn't it?

I got sick last week. I had a charming cough that sounded like I was about to bring up a lung. The cough is gone but I have missed at least one class and am still recovering.

Net result: I got almost nothing ticked off my list.

But I do now have a project plan and task list that stretches to the end of semester.

Hooray.

This week (Week the Seventh): mad rush to catch up and put myself back in a balanced position.

Right now: Going to sleep, because I need it.

Lists - Week the Sixth

List-dump! This is for my own sanity management and goal-setting; no pictures here, move along.

It is Week Six of semester and we are therefore nigh on halfway through this first lot of crazy (and nigh on a quarter of the way through the entire insane year). What follows is a large and impossible list of things I would like to have done, or at least well on the way by the end of this week.

Not all of these are related to the Games Project stream, but I will put Games Project first so you don't have to wade through everything else (if you are even bothering to read this dross).

Games Project:

Horse

- for now, cut back graphics to focus on mechanic

- main music theme

- create shared google doc for everyone to post ideas

- lock in 10 unique mode concepts

- implement transitions between modes

- finish code cleanup & lock in code structure (diagrams)

Individual

- sound system preliminary build

- placeholder SFX for all games

- lock in main themes/atmosphere for Islands and Bullet

Industry Workshop:

- finish fixing and welding the mesh of godawful house thing

- new UV unwrap

- re-texture

CGI Environments:

- to-scale floor plans

- to-scale orthographic views

- full library of reference images for architecture, props and machinery

Migration (this is an extra-curricular project):

- better understanding of code architecture

- one gameplay implemented

- one level type implemented in XML file

Also also, Horse is now on Pivotal Tracker.

Horse takes on Supanova

While over the Easter week I didn't make as much progress on the code base for Horse as I would have liked, I did, over the weekend, attend the hallowed halls of Brisbane's original nerdfest, Supanova.

Ostensibly this was for the purpose of promoting QCA and recruiting future students, but since we had game prototypes on display it turned into a prototype play-testing experiment. What I discovered was that the prototype for Horse elicited almost exactly the reactions that Henrik described in his initial pitch.

People would stop by and start playing with exclamations of 'oh, this is easy'. As soon as the mode changed, this quickly became 'what the fuck? Why am I not- I'm jumping?' And yet I rarely saw anyone walk away at this point. It seemed like the difficulty curve was just enough to challenge and entertain people, but not enough to frustrate them so that they stopped playing - they wanted to beat the game, but it didn't seem impossible.

There was one kid who came back at least three times in the morning and knelt down in front of the screen to play for 5-10 minutes with an expression of quiet concentration. I never actually said anything to him because I didn't want to break the spell, but it's probably fair to say that he was amused by it.

I also hacked in a few things over the weekend, just to see what people would do. They need to be cleaned up, but I will probably keep them all in some form:

- lives. At this point you start with three lives, and I rigged it so that that you get a new set every time the mode changes - for this context, I wanted people to be able to see all the modes before they ran out of lives

- a few seconds of invincibility when you respawn or start a new mode

- score bonuses when you skim very close to a block without hitting it (these were actually buggy, the bonus comes up but I forgot to have it add to the score. No-one seemed to notice)

- visual feedback on score subtraction when you die

- a brief instruction screen

- a game over screen which displayed your final score

Horse: The Supanova Build

Make some noise about it

I have been working on a variety of things this week (Horse updates will hopefully occur in the next day or so), but most importantly I have been working on my solo deal: namely, making music.

So, for those of you with no attention spans who require images, this is what I have been working on:



Part of the music for Bullet, so far. This was based on my brief of 'epic strings' a la Hans Zimmer's work in The Dark Knight. It's scored for string orchestra plus timpani, bass and snare drum, and to be honest, it came out kinda Philip Glass (Philip Glass, Philip Glass, Philip Glass /music joke).

You can listen to a first musical 'sketch' of themes and ideas for Bullet here.

Bear in mind that the samples are the default output from Sibelius (the notation program, not the composer), and is kind of dodgy sounding. This will not be the final sound - it's just to give an idea of the harmonic structure and the kinds of motifs I want to layer in the music.

I'm fond of that triplet figure, even though it would be kind of horrible to play. Fortunately this won't be getting recorded, so I can fudge the samples as much as I like in Pro Tools. But in any case, Tyson and I have agreed that this first attempt is too dark for the game in question - Tyson pointed out that he felt like he should be killing kittens if this was in the background while he played. The next step, from where I'm standing, is to get rid of some of the heavier scoring in the bottom end and adjust the chord structure underscoring that top motif in the violins so that it's a little bit less edgy but still has a lot of depth.

Waiting to hear from the rest of the team before I make a move on this, though.

Next on the list was Islands:


Musical 'sketch' for Islands is here.

There's not as much stuff here, because it was really really easy for me to nail down the main motif. Going for that floaty Jo Hisaishi piano sound, a la Spirited Away. It accidentally ended up moving into 5/4 after those three introductory bars when I started noodling around with the chords on the piano, and it works really well because the extra beat gives it that slight lilt that emphasises the sense of air and flight.

I'll be eventually writing modulations, chord changes and variations on the theme (chords need work. I am not a pianist and I don't do interesting ones naturally), as well as instrumental parts to bring in and out, but this main motif will always be at the heart of it. This one I do want to record the parts for. On top of the piano, I want to write at least a sax part and a flute part, and maybe a guitar part. I am now wondering if I have any favours to call in from, say, horn players or oboists...

Anyway, I am still waiting to hear back from the team on this one.

My sound system is also making some progress, but I want to go back to focussing on implementing some more things in Horse, and writing music for it. I'd like to have a reasonable version of it ready for Supanova this weekend, so tomorrow is a Horse day.

Fuck screenshots...

...this is a flash game!

Controls: Up and/or Down. That's it. That's all you get. Every time the mode changes, the effect of those two buttons changes. It's up to you to figure the rest out.

Iteration the Furst: this is the version that was presented as a prototype on Wednesday 24 March



Feedback was mostly on the pacing - changing to a different screen between modes really disrupted the gameplay, and it felt a little slow. It's also perhaps a little too hard.

Iteration the Next: this is the slightly updated version that was presented for more different feedbacks on the following Monday. Not much changed, really, except for pacing. The whole thing is kind of more hectic (and possibly confusing?)



Still probably too hard, harder than the previous version, because it's faster. Some useful stuff came out of the feedback session, most importantly that we need to nail down our target audience before we iterate more. There are also plans in the wings for more player feedback and clearer flagging of new game modes. Some complaints were made over the acceleration and drag on the character movement, too. I am currently in the process of stripping down the code base and turning it into a more modular system.

ALSO the text is off-centre and it bothers me. I will fix that at some point.

Target Practise

Current vaguely scheduled list of targets/goals I'd like to hit this semester. Subject to frequent updates and adjustments. Delivery times are 'as at end of week x'.

Week 6
Primary: Sound design breakdowns complete
Placeholder SFX implemented in projects
Secondary:
Story treatment roughs completed

Week 7
Primary:
Initial rough music concepts
Secondary:
Design documentation completed, if required by teams

Week 8
Primary:
Sound system initial version complete

Week 9
Primary:
Music concepts complete and locked in

Week 10
Primary:
Majority of SFX recorded/produced and in place

Week 11
Primary:
Sound system final version complete

Week 12
Primary:
Music composition and production complete

Going solo, update

Here is a clearer list of what, in an ideal world, I would like to achieve by the end of this semester (some of these, of course, may get extended to whole-year goals).

Mostly copied and pasted from my individual contract for this semester, but it helps me to put it up here.

Primary Goals

Sound Design

I will write sound design breakdowns for at least 3 – 4 projects (initially I am thinking for Horse, Bullet, Lantern and Islands), if not all of them. This includes lists of sound effects required, brief documents discussing the choices made in the sound design and the intended impact of sound and music on the player.

Sound Programming

I will build and maintain a sound system for use in Unity projects to streamline the inclusion of sound in the game. This is dependent on the nature of each game, whether the sound needs to be simulated in 3D space or not, and the needs of the separate teams.

I am still unclear as to the exact nature of this system. I am hoping that over the next week with some more feedback I will be able to define the problem better and start building a solution.

Music Composition/Effects Production

I will be composing most, if not all, of the music for Horse. This will include different tunes with various arrangements and styles for different stages of the game. While initially the music should have an 8-bit feel to match the retro look of the game, it should change frequently and drastically, in accordance with the subversive nature of the game design.

I have also been asked to compose the music for Bullet. The current music direction suggested is something on the lines of 'epic strings'.

I am keen to compose music for Islands, as this would allow me to explore a slightly different realm of composition – rather than music that is based specifically on the visuals or the theme of the game, Islands requires music that evokes a specific emotional reaction in the player.

Over the course of the projects, I will build up a library of sound effects based on the sound design for each game. Some of these may be generated using synths or tools such as SFXR, others will be Foley and general effects recorded at my home studio or sourced from various free sound effects libraries.

Secondary Goals

Story treatments

Subject to the desires of the core teams, I will be assisting with the development of narrative contexts for the Lantern and Islands projects. If this goes ahead, I will be writing story treatments for both games that form part of the overall design and inform the use of the gameplay mechanics involved.

Design Documentation

This is less of an individual focus and more of an element of the overall group design work. I am including it here because I have a specific interest in synthesising design ideas into a clear written format that effectively communicates the core concept of a project. I would like to use my writing abilities to help teams bring their ideas together into a cohesive whole that can be used for reference during development.

I will put my scheduling goals in a separate post, so that I don't get tl;dr problems when I need to refer back to them.

The Prototype - Retrospective

Just some quick reflections on Wednesday's prototype presentation session.

I think, overall, it went pretty well. Everyone had something to show that answered some of the questions raised by the pitches, and the feedback and criticism given was generally constructive and meaningful.

The presentation of Fishman didn't go too poorly. I was of course disappointed that I wasn't able to demonstrate it clearly, but the reception of my explanation was not received as harshly as I might have expected. I think a large part of the problems that occurred with the prototype of Fishman was that Henrik and I were trying to tackle the prototyping of two games with just the two of us, while other teams were focussing on a single game or spreading the workload to more team members (the work for Lantern and Islands, collectively, was split between four people).

The key problem, however, was the inability of ordinary keyboard interaction to accurately demonstrate the gameplay mechanic. Fishman is something of an input gimmick game (this is not strictly a bad thing), and it really doesn't work without the mic input. I had put together a very simple demonstration in processing of how the volume information from the input could be used to raise and lower the height of a bar, but unfortunately the microphones on the lab computers weren't working.

The net result is that Henrik and I have decided to put Fishman on the backburner at this point. We are not giving up completely on the idea, and I for one still think it has the potential to be an interesting game, but I don't want to sink time solely into trying to get the code the input analysis to work properly when I could be developing something that I know we have already proven.

The presentation of Horse, on the other hand, was fairly successful. I think the prototype helped us towards answering the question about timing - there was some pertinent feedback given on this, particularly that the game should continue running when the player gets an alert that the gameplay is about to change. It was also recommended that we make the different stages more distinct, which I know was something Henrik had been planning on anyway. Over the weekend, I will be working on passing the game information between the gameplay states so that the player's experience of the game doesn't get put on hold when the state changes, while Henrik will be developing more art and designs.

We'll also both be tinkering around with writing some silly dinky 8bit music to put into the prototype, with musagi (I will probably also faff around with midi data in Pro Tools).

With regard to other people's prototypes, there was some really nice work demonstrated - some in particular that I would like to be involved in the initial design and writing stages of, as long as the core team members are willing to have me on board. I'll probably be sending out a few emails with more detail to this effect.

That's all I can think of that needs to be addressed for now. I am of course working out my individual contract to deliver to Matt by the end of the day.