Hi there! You've probably reached this page from the Freeplay website in search of the elusive 'Up Down Ready' which took Best Design in this year's awards.

UPDATE: Hello! If you've arrived here from StumbleUpon, why not go play the game now on Kongregate! With high scores and EVERYTHING.

The versions of the game that were on this page were hosted on Dropbox. Since the recent spike in traffic, Dropbox has cut off access to my public folder. I will hopefully be migrating this stuff across to an actual server, but the version on Kongregate is the official release.

I'm Delia, the Sword Lady half of Sword Lady and the Viking. You can find my teammate over here. We are third year students in the Games Design course at Griffith University, and Up Down Ready (previously known as Horse) is our first semester project from this year, made using Adam Atomic's free Flixel library.

We entered it in the Freeplay Awards for a lark, and were incredibly surprised and excited to make it to the finals and take away an award. We hope you enjoy playing the game as much as we enjoyed making it!

- Delia

Saturday, September 25, 2010

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.

Thursday, September 9, 2010

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

Saturday, August 21, 2010

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

Thursday, June 17, 2010

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.


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.

Saturday, May 29, 2010

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.


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.