UP DOWN READY

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
Showing posts with label horse. Show all posts
Showing posts with label horse. Show all posts

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.


Enjoy!

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.

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.

Sunday, May 2, 2010

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.

Tuesday, April 13, 2010

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

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


Wednesday, March 31, 2010

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.

Friday, March 26, 2010

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.

Sunday, March 21, 2010

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.

Sunday, March 14, 2010

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.