The five games offered within the suite spanned a number of genres, though those I built, Flock Together and Sheep Stack, are both physics-based puzzle-ish games. The former, a Tetris variant, challenges the player to drop the leotarded ruminants into colour coordinated piles, whilst the latter is more of problem solving game involving levers, balances, hungry sheep and an underpants catapult.
Initial animation test were done by Robin Davey and Phil Webster which looked fantastic and made everyone involved in the project very excited. Some mock-ups of initial designs by Gavin Strange further added to the anticipation. Then the prototypes were developed for us by Gaming Your Way and we could see that this was going to be really great once it all came together.
At this point I thought I would make a lot more work for myself and decided to broaden the scope of the games I was making from simple, single-level progressive games to multi-level challenges with a greater variety of problems and obstacles for the player to negotiate.
As this were my fist stab at physics-based games (I had dabbled before but nothing on this scale), Championsheeps presented me with a new challenge in learning how to easily design and edit levels that would work in Box2d. Chris Underwood pointed me in the right direction, using a technique which allows easy production and editing of levels using the Flash IDE.
Championsheeps has been live for three days now and has already clocked up 90, 000 views. Despite being one of the more stressful projects I've worked on, I am especially happy with the results and the reception it has received.
The Farmyard |
Leader boards |
Sheepstack |
Flock Together |
Now a geeky bit
As well as the games, I also built, with the assistance of George Crabtree and Richard Davey, the main structure of the suite environment. This handles scores, user data and loading and unloading the games. As expected it presented quite a few of its own challenges, one of which is as follows.
The problem with loading one swf into another is the communication between the two. This can be done reasonably well using bubbling events, but that relies on the dispatcher being on the display list which I don't really like. You could write a shed-load of interfaces, or if you don't mind remembering what all of the method names are and leaving everything untyped you could do it that way (gets very messy though). But I am lazy and I like Flash Develop to fill out all the bits it can without me writing any extra code.
What I wanted was a single place I could dispatch events from and listen to.
So I started playing around with static vars in classes and experimenting with what overwrote what when one swf was loaded into another and they are referencing the same class. I discovered that the host swf always wins, and they do both end up referencing the same value.
This meant I could set up a commonly shared registry (just a class full of static vars) in which I instantiate a listening post (essentially a class that extended EventDispatcher). I used this to communicate from game to manager and back again. It also had the functionality to turn on and off events from all of the games except the one that was playing, so no erroneous events firing and games starting, stopping or quitting when I didn't want them to.
As long as I didn't reference anything in either the games or the manager from the commonly shared classes I wouldn't end up compiling one thing in to another.
There were plenty of other challenges that arose in building this, but I thought this was of note because its quite a nice way of dealing with multiple swfs - all with their own logic and all needing to communicate with one another.
update 18/03/2011
look
On the bbc homepage |
No comments:
Post a Comment