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.

Going solo

Hey there cats and kittens. This is your recently-appointed resident sound guy talking (okay, sound girl, technically, but that sounds naff and wishy-washy).

Finally getting around to blogging about my individual role for this semester's projects, so that all of you (my current developers-in-arms) what's going on, and what you can ask me for if you need it.

The way I am currently thinking about it, the role of sound in these projects can be broken down into three areas:

1. Design

The decision-making process. This is really key to the what, if any, impact sound has on the way the player plays the game, and the player's impression of the game.

Off the top of my head, this is the sort of stuff I can work with people on, if you guys want my input:

• deciding where and if music or sound effects should be used
• picking and choosing the right kinds of sounds and the right places to use them
• what will they signify to the player?
• do they serve as feedback or stimulus?
• will the player be able to read them correctly?

2. Sound programming

I would really like to build some kind of simple system that everyone can use to easily organise and trigger sounds and music for their games (probably in Unity, since the majority of projects will be happening in that).

I haven't had a chance to think too deeply about this yet, and I would welcome feedback on the kind of system people would like in order to help them streamline the audio pipeline. How would you guys like to be able to handle sound in your scripting?

3. Composition/Recording

This one is slightly trickier. I am a little rusty in this area, and I am not sure how quickly I will be able to produce music and/or effects. At this stage, I'm going to say tentatively that I will do the music for two projects this semester. These are actually already pretty much set - I'd like to compose for Horse, because there is the potential for a lot of fun and silly chiptuning there, and Tyson has already lined me up to work on their Bullet game, so unless the projects get especially shuffled around these two are pretty much locked in.

That said, if people want me to record Foley or create SFX (or even come over to my place and do their own while I record), I am happy for this to be arranged.

Do let me know if you want this facility available to you as an option, because I need an excuse to go get a new mic + monitoring headphones, and I will need time to sort that out.

So, in a nutshell, get in touch if you want soundie stuff, kids.

Brutality

Okay, time for some honesty. The latest version of the fishman gameplay prototype is up here and I'm frankly tired of dancing around the main point that keeps coming up as I work on it, which is this:

It's shit.

It fails to communicate with the player, the interactions are unclear, it's clunky, and above all, it's boring and feels pointless. I know there are things missing, like a decent GUI and specific end states, but if the main mechanic feels like crap, then there's no point in dressing it up.

So. Failed experiment. Moving on to horse tomorrow, which I hope I can manage to not screw up.

The progress of fishman

Gradually getting somewhere with this. There is a newer, more playable and commented-code type version of the unity project on Dropbox. It suffers, at the moment, from grey box lolz visuals, but the key things are there.

To be honest, I'm not sure how well it's expressing the gameplay though. I know the theory of the mechanic is okay, but in practise it may well turn out to be a little lacking. Hmm.

Trying to nut out some better visual feedback for the player and tweak the feel of the gameplay now.

We are only going to spend at most another day on this before we move on to prototyping Horse in Flixel.

Illuminated thoughts

Just some quick notes with reference to the amalgamation of my Chiaroscuro and Zac's Lantern game.

After the pitch we had a quick discussion about the two ideas, the key point being of course that they approach the same idea (the rather obvious duality of light and darkness), but from opposite ends - while his character emanates light, mine draws in darkness.

There didn't seem to be a way to comfortably reconcile these two concepts in the already quite well-defined character of Zac's lantern guy, so this is where the idea developed of having two characters with distinct abilities who have to help each other through the environment. As evident in Zac, Amjad and Cameron's blogs, they are rapidly progressing and solidifying the concept - I particularly like the idea they have developed of the dark character taking a slightly less human/solid form and being able to climb and jump to areas Lantern Guy can't, and it opens up more scope for puzzle elements than were available to either of the characters individually.

I do think it would be nice to keep the lantern as a linking motif between the characters - possibly as something they have to pass back and forth and use in different ways in order to solve puzzles (in the hands of Lantern guy, it emanates light, whereas in the hands of the dark character it draws in the darkness). On a different tack, if the two characters are made completely distinct, it might be worth keeping our minds open to the possibility of the game working as a two-player co-op experience, but I don't think it really needs to be considered for the purposes of the prototype.

As it stands, I am perfectly happy to step back from the design and development of the Lantern game at this stage unless my input is specifically requested. I think these guys are doing a stellar job and taking the gameplay in an interesting direction.

Technorage

Suffering from computer troubles of various kinds. Bizarre corrupt file problems have been plagueing my rubbishy Unity prototype project and I've had multiple crashes with no useful error information. Not to mention my usual Windows problems. So I've gone a little dim (not dark, I promise!)

Net result: I am behind in my work. This is something of a concern, particularly when I look around and see the amount and quality of work that other people have already achieved. It is time, therefore, to start pouring out that bottle of midnight oil into the lamp. So it begins, and so, I suspect, will continue - the next week will set the rhythm for the semester, and probably the year. Not what I would call an auspicious start, but we take what we can get.

Anyway, so. Here is my current complete trainwreck of a prototype on Dropbox, to be updated as frequently as I am able. There are grey things. They move. They move slightly differently if you press keys. It's a... well, it's a thing.

I suppose.

http://dl.dropbox.com/u/2512414/3114GFS/fishman2.zip

And so it begins

Along with Henrik, I will be prototyping my concept 'The Fisherman and the Moon', codename Fishman, and Henrik's unnamed concept, codename Horse.

First off, after a quick chat with Henrik, we decided to go ahead and work in Fishman in Unity, because we can use this FMOD plugin, which will be necessary for sound manipulation and analysis (more on this when I've looked into it in more detail). Horse, however, will be developed as a flash game, with the Flixel library in Adobe's Flex Builder.

The aim now is to get a functioning game working in Unity, with a variety of grey boxes to represent in-game objects and, at this stage, key presses in place of loud/soft sounds.

Tasks I'm working on for Fishman (Horse to come later):

- set up scene, locked to 2D plane
- on key-press
- the moon moves/changes direction/changes speed
- the fisherman's boat moves/changes speed
- win state when fisherman reaches shore
- loss state when moon gets too close (boat 'capsizes')

More as it comes to hand.

The Pitch - Retrospective

I've put a bit of thought into the outcomes of this session and my reactions to it, and haven't been able to come to a satisfactory conclusion.

I think the net outcome was successful, but the process was incredibly wearing, and perhaps this is because it was not entirely what I expected. I felt that we had all worked too individually, and I think the game ideas we were pitching were, on the whole, too complete. The result was what I like to think of as the ownership problem - there was a sense that each pitch idea belonged specifically to the person who had pitched it.

The following session of picking and choosing the games we were going to prototype was therefore very difficult, because the language we were using lent itself to the description of the games by the name of the originator. It was difficult to separate which game we wanted to make from the idea of whose game we wanted to make. That said, I think the whole class managed this quite well in the end, and I think we have a good range of interesting and diverse prototypes to work on at this stage.

Vis-a-vis my individual experience of the pitch, I will say that I wasn't happy with it. In my impeccable 20/20 hindsight, it may have better not to include Threadsuns in my pitch. In my head, it was a very malleable idea that I just wanted to put out there for kicks, and I was hoping for maybe a little more interaction and back-and-forth during the pitch session (see above re: possession problem). Again, I think everyone was too shy to put their own spin on something that was being presented as 'my' idea and 'my' game.

Alternatively, they thought it was a stupid idea (never ever rule this out. Everyone has stupid ideas. The important part is always seeking feedback so you can tell the difference).

I also don't think I really managed to accurately convey of my ideas with the possible exception of the fisherman and the moon, because it was dead simple (an interesting note: Henrik correctly cottoned on that I had been thinking of Hemingway's The Old Man and the Sea. Nobody, however, managed to pick up the loose parallels to Terry Pratchett's Nation.)

So, hm. I suppose all of this adds up to the fact that I would have preferred a more open pitching session - something with a little more trading of ideas, and less fully-formed concepts coming from each individual. This point, of course, is moot, because that process will inevitably take place over the semester as development progresses.

My thoughts on the whole thing, anyway. I think we're doing pretty well though.

Game Concept 5 - The Fisherman and the Moon

Just after dusk in a peaceful oceanside village. Out on the water where the sheltered bay meets the wider sea, the fisherman hauls in his last catch of the day. There is a heavy storm lurking on the horizon, and he wants to be back home and dry before it hits.

Knee-deep in slippery silver bodies, he reaches for his oars - and to his dismay, finds them missing! Frantically, he casts about in the boat for them, but they are nowhere to be seen. They must, he thinks, have slipped out of the oarlocks and overboard while he was busy pulling in the nets. He reaches over the sides of the boat, in a vain attempt to paddle back to shore with his hands, but with the weight of the fish, he can't even budge it.

The storm is encroaching at a frightening pace now; the fisherman can see high, white-capped waves rolling towards him. With no practical solution in sight, he looks up at the moon and utters a soft, crooning, sing-song prayer for safety. To his surprise, his prayer is heard - the moon seems to drift coyly a little closer, and he feels the unmistakeable surge of the tide beneath his boat. He laughs and sings the soft, lilting prayer again - and the tide pulls stronger.

Delighted, he calls to the moon, flattering and praising her. She gets closer and closer and now the tide becomes wild and uncontrolled, and he is sent sprawling back onto the pile of fish in his boat, on the verge of capsizing. He flushes with anger and changes his tune in an instant, yelling vulgarities and cursing her carelessness. She backs away into the sky and after a moment, the water is dead still.

The fisherman, however, is still far out from the shore, and the oncoming storm is closer and more threatening than ever. Overcome with penitence, he lowers his voice again and murmurs his apologies to the moon, drawing her back. Again, she comes too close, and again he sends her away - but his boat is now a little closer to shore. The fisherman smiles - he knows what to do now.

After an alternating sequence of soft, gentle cajoling, and violent screaming anger, the fisherman, exhausted, manages at last to bring his boat ashore, hauling it up with its precious silvery load onto the shore just as the first drops of rain strike on the sand. He gives his thanks to the moon and unloads the fish into a wooden bucket - and much to his surprise, nestled lengthways in the bottom of his boat, are the two mysterious disappearing oars.

With one last screaming curse, he makes his way up the hill in the pouring rain.

Game Concept 4 - You're in a box

You're in a box. A glass box. It's not much bigger than a person. You can move a little in the box - back and forth, bumping against the glass. The glass is so thick and heavy, the box doesn't budge. Outside the box, there's a breathtakingly beautiful world. You can see it, but you can't reach it, you can't hear it. You have to get there. You have to get out of the box.

You hurl yourself against the glass. You punch and kick and beat your head against it, to no avail. The box doesn't even move. You don't even leave a mark on the glass. Maybe you slump against the wall now - fall down, sob a little. You want to get out but you can't. You can't reach this beautiful world that seems just a hand's breadth away.

You get mad. Mad like a captive animal. You know no-one can hear you in here, but you have to get it out, and you scream. Loud and long and visceral and the more you yell, the more you want to yell. You are so caught up in the noise and the rage that you don't notice the box vibrating with the volume - at least, until it shatters.

The glass goes everywhere, bursting outwards away from you. You cower a moment in the wreckage as the pieces rain down around you.

When you look up, you aren't standing where you expected to be. You aren't standing in that sublime world that surrounded the box. But you can still see it. It's ahead of you, and above. In a blind fervour, you leap towards it, and tumble into space. You fall, surely to your doom. But the horrible sensation of the free-fall is broken surprisingly quickly as you crash land... into the wreckage of the box. You don't know how you got to be above it, but you're thankful for the absence of a grisly death.

Out in the empty space between you and the beautiful world, there are more boxes and other glass contrivances of all shapes and colours and sizes - drifting gently from side to side in an invisible aether, and all of them too far for you to reach easily. Infuriated again, you swear out loud; to your surprise, some of the boxes pop and shatter into a powdery mist. New ones coalesce from the pieces, and you are in luck: some of these are close enough to leap onto.

You step lightly from one glass creation to another, and happily begin humming a little tune. At the sound of your voice, the bridge beneath you collapses into nothing and re-condenses as a large Klein bottle, further up. With a gasp that causes an effigy of a kitten to shatter and shift downwards into a jellyfish, you manage to catch onto the rim of a passing bowl and haul yourself to relative safety.

You've figured it out, now - it's the sound that does it (took you long enough). Different pitches affect different coloured objects, and the volume dictates where they move in the space. Happily, and with more than a little trial-and-error and occasional dramatic falls, you make your way upwards and forwards, singing, whistling, yelling and cajoling the objects into position.

The beautiful, exquisite world is in reach. You can hear the sounds, taste the air. You step forwards off your last glass elevator and... bump into a wall. Startled, you stumble backwards - and bump into a wall.

You're in a box.


Mirror's Edge DLC, for visual reference.

Game Concept 3 - Hyperacusis

Disclaimer: I firmly believe this concept is too ambitious for this project year, and will in all likelihood not be pitching it because I won't have time in my pitch, but I wanted to put it up here anyway.

Working Title: Hyperacusis

Genre: First-person puzzle/adventure (somewhere between Myst and Half-Life?)

Platform: Unity Web/PC

First-person, 3D

Core concept/s:

• imagine any first-person shooting game that involves killing hostile or dangerous aliens
  
• what if you couldn't see them, couldn't touch them, didn't know how to hurt them - because all they are is a sound?
  

Environment:

• either a desert or an arctic environment - an open space the player can explore with some signs of civilisation

• the player's "home base" is a research station of some variety (more than a little generic, there) where they return to replenish their health etc

• the whole area is completely abandoned and devoid of life

• the only signs of people are abandoned belongings and homes, and the occasional corpse for good measure
  

Objective:

• the player is alone in the environment, which they have to explore at first

• they will come across non-corporeal 'sound creatures' who are embodied by noises which are severely harming to the player character

• the player must explore, find items, and progressively discover how to destroy the sound creatures

• overall goal is to wipe them out completely from the gameplay area
  

Gameplay:

• there are a variety of different sound creatures in the area, which have different effects on the player character and different weaknesess the player can exploit

• the creatures are limited to different 'zones' - most of them do not move around, so the player can remember their locations

• when the player enters the zone around a creature, they will first hear a warning sound that indicates an enemy is nearby (eg/ a high-pitched, grating whine). The nature of this sound may give a clue as to the sound generated by the creature

• when the character is exposed to a creature, s/he loses health and the player may not be able to fully control the character's movement

• the creatures can only be defeated with sound

• the character's main 'weapon' is a handheld sound recorder and playback device

• at the research station, the character has a very simple interface to be able to record and mix sounds from elements in the environment

• the correct combinations of sound played back at the creature will destroy it

• when a creature is destroyed, the zone it inhabited becomes completely 'dead': there is no atmos, and any player-character created sounds are almost inaudible - as if the creature sucked the sound out of the area as it died
  

Other mechanics:

• initially, the only item the player has is a pair of earmuffs. These cut out the sound of the creature and reduce the health loss experienced by the player character

• however, they inhibit the player's ability to respond to the creature - the sounds the creatures make are cyclic and pulsing in nature, and the player must record starting on a pulse, or the recording will be useless

• the earmuffs can only be used to allow the player to explore some areas in relative safety - however, they are completely ineffectual against some of the more powerful creatures, who can pierce through them
  

Obstacles/game elements:

• some creatures can be temporarily stopped by the character making noise (stomping, clapping, vocalising), but this will not destroy them
  

• some creatures can be destroyed simply by being played back at themselves (a more extreme version of holding up a mirror to an animal to make it aggressive)

• others are not so simple

• for some, the sound must be manipulated in some fashion

• for others, the sound cannot be properly recorded, and must be synthesized using elements from the environment, character vocalisations etc

• the way the player character responds to the sound can be a clue about how to defeat it

Examples:

• if the character becomes hyperactive and frantic (camera shake, over- sensitivy to controls), the sound needs to be slowed down to defeat the creature

• if the character becomes slow and dull (blurring vision, reduced sensitivy to controls), the sound needs to be sped up to defeat the creature

• if the character becomes disoriented (inverted controls), the sound needs to be played backwards to defeat the creature
  

Sound:

• Obviously the entire premise of the game is based around the use of sound and the player learning how to respond to sound instead of visuals

• there would be no background music - the soundscape would be comprised of atmos and ambient noise

• no animal or human sounds except the player and things left behind by the researchers to add to the story and mood
  

Other visual elements:

• obviously this would require some more complex first-person character animations

• however, the environment and animations could be simplified to be more stylised

• since the use of sound in the game is not entirely realistic or physically accurate, the player may be more inclined to accept less realistic graphics - though this may detract from the strangeness of the situation with which the player is faced
  

Potential problems/other issues of interest:

• There are so many problems with this idea like you would not believe

• As mentioned, the project is far too ambitious for the time allowed

• I think the core concept is solid but I am not happy with the specifics of gameplay - they seem both lacking and overly contrived

• the concept of the earmuffs to allow the player to move around in a less inhibited way is good, but doesn't cohere well with the other ideas about recording/playback
  

• earmuffs could be replaced with simply the character putting their hands over their ears - during which, of course, they can't perform any other actions except movement through the environment

• also toyed with the idea of a sinewave generator, with the player trying to match the core frequency of the creature - possibility of finding multiple 'weapons' as in a traditional FPS
  

I really like the idea, but it needs a LOT of work, both conceptually and for execution.