Review the Ancients: Dynatron Mission - Mastertronic 1987

Written in 1987
Coded by Paul Hargreaves
Music: None
Published by Mastertronic
http://www.worldofspectrum.org/infoseekid.cgi?id=0001559

Play it online http://jbacteria.retrolandia.net/48s?dynatron.tap
Thanks to http://jbacteria.retrolandia.net/ for hosting it and many other games.

Twenty Eight years ago, Two 13 year old boys were sat in their living room after school.
A new game had been acquired. One of them places a tape into the deck of the Spectrum +2 and 3 minutes or so later, it loads.

The loading screen showing an armoured space marine in what appeared to be MotoX armour, the cassette box looking like a scene from a sci-fi movie.

Having both seen Alien and 2001, the atmosphere could be cut with a knife.

The game loaded and play began. The case lay strewn across the floor in the usual manner - we didn't need instructions - we were kids - we knew how to game!

The space marine glided effortlessly into the Novar base on a personal hang glider and landed at the starting screen, all was quiet apart from a heart beat - rendered through the beeper with a Chwee Choo sound.

We quickly got to grips with the controls. Jumping was tricky but the added power boost made jumping large distances possible and tricky terrain easy.

Chwee Choo

The first room seemed easy enough, no enemies - moving to the right presented some sort of ledge, moving quickly.. Woah, stop. Gas traps. It's just gas, it'll be OK in the space suit. Using the power run, We attempt to run through the gas but alas the space marine dies with a shrill and a contorted image. Looks like the gas eats through the suit. down to 2 lives.

Chwee Choo

Carefully timing the run until after the gas has dissipated, yields the next room. Aliens and a laser firing into the rock in a pit. A quick round of weapon fire should take care of the aliens and we'll leap over the pit..  OK, where's the weapon? Can't see the weapon right now.

Chwee Choo

The aliens seem to be moving in a predictable pattern, we'll be fine as long as we stay out of their way. Oh no! An alien coming from the previous screen, that screen was clear, it must have followed me. One life left.

Chwee Choo

Avoiding the aliens, we jump up to where the the laser pit is and power run and jump over the pit. Trap avoided!

Chwee Choo

The next room has a moving platform. We leap onto the platform and ride it over to the other side.

Chwee Choo

We're then presented with two hydraulic rams moving up and down aside a hole in the ground, our obvious destination, a quick leap down towards them - Boing, a trampoline propels us towards the rams. Not wanting to touch them - we hold back and wait until they are high enough to pass between them and drop down the hole.

Chwee Choo

The next room is strange, no hazards at all. Just some arrows on the ceiling pointing up and a moving floor, moving towards the right. We attempt to jump off the ledge towards the exit. What is this? We're floating up - but we can move mid-air. We move towards the end of the arrows and fall. Obviously these have a finite influence over localized gravity. We move left, towards the only exit. The moving platform prevents us from simply walking, instead we power-run.

Chwee Choo

The room to the left appears to be a large chunk of tech, but it blocks our progress, even power jumping cannot clear it. Above the tech is a hole in the ceiling, it must be the chasm the moving platform carried us over. To the left of the tech is an exit to another room.

Chwee Choo

Back to the right then, up the lifter and jump up to the previous screen, avoiding the hydraulic rams. Boing. The trampoline catapults us towards the sheer cliff - but not high enough. There has to be a way up. Maybe a run-up, between the rams, landing on the trampoline and power jumping will be enough to get us up to the top.

Chwee Choo

Boing, we're at the top of the cliff we came down earlier. This was the wrong way. Just get back onto the moving platform. A mis-timed jump meant that the marine slid down a surface and landed in the screen with lots of tech. We'd have to go back to the gravity lifter, avoid the rams and use the trampoline jump again. This is tricky stuff.

Chwee Choo

Eventually we make it and slide down the surface on the other side. Placing us at the other side of the tech obstacle. We walk to the left and see bladed balls falling slowly into what appears to be lava or acid, in any case it's hot and bubbling. Above us is a pit with lasers.. hmm, I wonder if jumping down the pit at the start would bring us here.

Chwee Choo

A running jump over the lava seems to be the only way. We'd have to wait for it to be clear otherwise it'll be death from bladed balls.

Chwee Choo

Death it was. A misstep, landed us in the lava.

Shrrreeeeeeelll 
No Men Left - Game over.

The instructions on the case inlay were studied. Unusual for us, but this game was hard! Where is the weapon? On the case there's a weapon. The cover-art shows a weapon very clearly.
There, right there in the instructions, it says you're armed.. Where's the gun?!

It appears that our marine forgot his weapon. There is no combat in this game.

I mentioned "We" a lot because it was my Brother and I taking it in turns to see who could get the furthest, and although the preceding paragraphs may have been long and detail heavy, it doesn't even come close to the amount of time and effort it actually took to make it this far. The failed attempts, the deaths. Death by aliens, death by hydraulic rams, death by gas, by lasers, by bladed balls. But it was interesting.

We both still have muscle memory dedicated to defeating the first few rooms of this game. Then it turned out that the majority of the rooms described so far could have been skipped by hopping down a hole guarded by a timed laser.

This game was intense.

The constant heart beat kept the tension and the shrill of death was actually something quite unpleasant and was feared.

Each room was filled with frustrating and often deadly obstacles to be overcome, but with practice and patience - it was possible. All the while the marine's heartbeat would pound in our ears - Chwee Choo.

Over exerting or scaring the marine would increase his heart rate and would mean he couldn't perform power runs or jumps; meaning that you had to wait for him to calm down before you could proceed. Run or power jump too much, dangle from moving platforms for too long or fall too far and your heart will be pounding with the marine's. Chwee Choo-Chwee Choo-Chwee Choo.

After many hours of play, we finally made it to the Bomb room in the Novar base. A siren blares and a timer on the screen begins to count down - we now have to make it back to the exit room we passed some screens ago and a short time it seems to get there.. now where was it? A mad scramble back up through screens we fell from, alternate paths with new challenges - never before experienced and must now be overcome while under time pressure. All the while the marine getting more and more out of breath.

This game was terrifying. It lured you in with it's simplicity and then beat you over the head.

It's graphics were colourful, yet alien. The locations often seemed functional in some odd way. The traps were clearly identifiable (a sign of good level design). A great deal of care had been taken in this game's construction - and it was all made by a single person.

In the first few screens, the player learned pretty much everything they needed to play the game. They also got a taste for the danger which lay deeper into the complex.

The lack of a weapon was novel. It meant that players had to think their way out of situations rather than rely on combat prowess. This was a thinking boy's game - A game which rewarded patience and clear thinking. There was an element of luck, but mostly death came because the player messed up.

Careful leaps, timed jumps and a clear head were needed to progress to the ultimate goal.

I'll be honest, My Brother and I never made it back to the exit screen on any of the levels (or at least he never told me that he did, I imagine he would have as it's kind-of a big deal). We got close, only a couple of screens away. But the bomb would always detonate and it was Game Over.


A lot of people cite games like Manic Miner, KnightLore and AticAttack as their classics for the ZX Spectrum.

However for me, near to the top of my list is Dynatron Mission. A game so tense, so difficult and so atmospheric I will never forget it. It is unfortunate that it remains an obscure title that only a handful have played. I encourage you all to play the game - there is a link at the top of this review.

I do wonder whether a game like Dynatron Mission would be possible on modern platforms. The difficulty curve might put most people off. I do wonder why it enraptured my Brother and I. We had other games, but nothing had the atmosphere, especially when played along-side Holst's The Planets Suite - played on a record player.


I've been unable to find recent activity for Paul Hargreaves on-line. I would like to thank him for this game. It has certainly been an inspiration. 

Review the Ancients: Death Stalker - Codemasters 1989

Death Stalker

Written in 1988
Coded by Tony Warriner
Music by David Whittaker
Produced by Tag Computer Games
Published by CodeMasters in 1989
http://www.worldofspectrum.org/infoseekid.cgi?id=0009330

Imagine: You're a 15 year old with a Spectrum. It's summer in 1989. It's raining outside and there's nothing on the 4 channels the UK had to offer. You've just purchased a new game for the computer, it's a budget title priced at £1.99, but you don't care. Some of the best games were budget games anyway.
The box art promised an adventure similar to childhood movies like Beast master or Conan the Barbarian - which I was probably too young to watch, but watched them anyway.

The tape was placed into the tape player and 3 minutes later the game had loaded to an amazingly atmospheric David Whittaker tune. So far, so good. I'm gonna slay me some orc men!

The player was placed in a forest without any guidance, clues or any story as to how he became to be there in the first place. The forest drawn in a monochrome red with green leaves, mostly bare branches selling the feeling of death and dread - this was not a safe place to be.

The player is attacked early on by skeletons and orcs which are fairly quickly dispatched with your sword or power. You are faced with a choice. Should you move to the left, you are faced with a tower with a bird-like creature waiting in a window. If you move in more, he swoops down and attacks you forcing you to either retreat or to fall into a pit of spikes. There is no way out of this pit, should you survive the fall you cannot climb out again, your only option is suicide by jumping onto the spikes.

Move to the right and you see a hole in the ground and more monsters. They are quickly killed. Holes in the ground are never good so deftly leaping over the hole and moving to the right seems the most sensible course of action. To the right is another building with another bird creature blocking your path.

Down the hole it is then.

You fall down the hole and land in a dungeon room with ghosts floating around. They cannot be attacked. If they touch you, they'll hurt you, damage being shown by the state of four skulls on the bottom right of the screen - alas it seems these do not represent lives; however as you fall you notice something remarkable about how this game is displayed.

Unlike other flip screen games of the era, Death Stalker doesn't show you anything you can't see from your current vantage point. So in order to see what's around the corner, you have to venture forth. This works really well where there are doors, pits and ladders. You can see the ladders, but you can't see what's on the platform above you. You'll have to climb them and see for yourself.

The idea behind this was brilliant and added greatly to the atmosphere. It is also to my knowledge, the only spectrum game that did this.

The presentation of the game visually was pretty good overall, it's graphical style lending itself nicely to the fantasy adventure style. The combat animations left a lot to be desired and the overall feel for the controls was sluggish. This could mostly be forgiven. Jumping would prove to be quite a pain. Jumps would often need to be timed very accurately to progress - or perish in a pit of spikes.

The game ran at a poor framerate for the most part, it would periodically slow down while a piece of scenery came into view or disappeared. I can understand this, it was doing a lot with the limited power of the spectrum. The speed problem was forgiven and there were certainly worse examples of performance.

Killing creatures caused items to drop. Keys, food, potions and other goodies which would help in your quest. There was a primitive verb based inventory system. It was slow to use, but functional.

There were also NPCs to talk to - prisoners to rescue. A nice touch making the dungeons feel alive and giving the player purpose. Even the ghosts would talk.

Death Stalker's biggest problem though was that it had more than a fair amount of instant death traps and areas with no way to return, whose only end was a gruesome death.

Spike pits aplenty and pits of acid. The game became a tedious memory game instead of the hacking slashing adventure it wanted so hard to be, which was a shame really.

If you were lucky enough to make the correct choice, you'd better remember what you did and don't be curious about the other door or wonder what's just off the ledge, it'll be certain doom if you do.. or maybe not, there was no way to be sure.

The dungeon appeared to take joy in killing or trapping the player without mercy. Only by knowing the correct path did you stand a chance. Then again, the game was called Death Stalker - what did I expect?

Once your health had depleted, it was game over. You'd have to start all over again from the beginning.

Back in the speccy days, this wasn't such a shock - but can you imagine what would happen if a game pulled that trick today? Current difficult games like Dark Souls had nothing on this.

Death Stalker is a game which I wish was a bit better. It could have been a classic. Instead we have some good ideas and a nice soundtrack and a dungeon that wants to kill you, horribly.

I really wish CodeMasters hadn't put the legal blocks on their games being reproduced or stored on-line. It means that games like this will disappear into obscurity. I believe that there's still something to learn from DeathStalker; After-all, I still remember it fondly.

Remembered for being a little awkward and a cruelly difficult - but remembered all the same even after all these years.


Tony Warriner now works as the co-founder of Revolution Software and he's made some games you have probably heard of: Lure of the Temptress, Beneath a Steel Sky and Broken Sword.
Still Adventuring.

Retro Music - Why is it cool? Because Batman!

I remember fondly growing up with a Sinclair Spectrum +2, it's limitations were largely unnoticed by me.
Instead, it was a source of constant wonder and of all the things in Speccy gaming that I was the most impressed with was the music. Mostly the 128k music, but occasionally 48k music too.

In fact, any game which didn't have decent music was seen as inferior to even sub-standard games with good music.

One such game was a CodeMasters game called Death Stalker.
I'll probably do a review of Death Stalker at some point as although it wasn't brilliant, I believe that there were some truly visionary things in that game.
It's a pity that the actual gameplay was so unfulfilling in the end.
However the thing which I did truly love with Death Stalker was the music.



The music was written by David Whittaker, a musical hero of mine.

I love the way he overcame the 3 channel limitations of the AY chip to produce something very atmospheric and impressive. It kept me playing this game when all other senses told me to stop.

It is a shame actually that CodeMasters refused to make their back catalog available to emulators. The internet is littered with details of a great many spectrum games. However a lot of the older CodeMasters games are missing from this archive simply because people cannot find them to play on-line; instead relying on pirated versions or original tapes. These tapes are

Another David Whittaker masterpiece which stuck with me was the music for Trantor the Last Stormtrooper

This music sounds a little rough and Lo-Fi - however when you consider that this is played on a beeper without the aid of a sound chip. This is the Z80 processor going "hell for leather", "all-out" to render drums, bass, melody and pads. This is a technical masterpiece and I would love to remake this.

I recently remade the titles music for Robocop. The music was originally written by Jonathan Dunn - another hero of mine - and this music stuck with me for many years.
It was even used in an Ariston TV advert.



Remaking Retro music is actually quite difficult with modern tools as it's very tempting to over-do the composition.

It's important to remember that the original composers were working within a very rigid set of constraints. To do the tune justice, you should use a limited set of instruments and effects.

The C64 version of Robocop sounds similar but has some additional portamento effects, which work quite nicely. I personally prefer the ZX Spectrum version, but each to their own.

A great site to visit if you're interested in remixes of older C64 tunes is http://remix.kwed.org/

So why is it cool?

Well, my opinion is that when faced with restrictions, we can often find amazing things within ourselves. We are at our most creative when the resources are scarce.

That's the deepest pit of human creative desire right there, and that my friends - is amazing!


In closing, I'll leave you with Storm Bringer.

Take it away David (yup Mr Whittaker again)


You're welcome... ;-)

Physics Engines for things other than puzzles and explosions.

What's a Physics engine good for anyway?

I made my own Physics engine for Crashblock
 - cue rapturous applause - 
Thank you, it was hard work and there were times when I thought I couldn't resolve all of the issues, but I got there in the end. 
- applause intensifies -
It's main tasks were to prevent the player from passing through walls 
-hang on, that's a collision detection and resolution system - applause dies down slightly- 
and to simulate gravity 
- so it's basically, move everything down and use the collision detection and resolution system to stop things from falling off the level? - rapturous applause stops and crickets are heard -

Yup, that's basically all it did and it took a long time to get right; and isn't it basically what most games need?
So why do we keep re-writing the same code and why is it always hard?

I think it's because we re-write each game basically from scratch for a very specific idea.

If only there was some sort of library which could take the effort away and focus on the game...

Enter the Physics Engine

At it's heart a physics engine keeps track of entities, their energies and attributes and makes sure that changes in energy are correctly applied and objects don't move through other objects.
Come to think of it, that's quite a task.

Serious people spent serious time writing serious software to do all of this.

Something that can handle velocity, friction, acceleration, elasticity, gravity, mass and the resolution of collisions, calculating and transferring energies to other objects seems to be something that should only be used in serious games just to do it justice - anything else would be a waste right?

It is true, you can get a really good racing game written using a physics engine - but they're useful for other things too; and if you bear with me, I'll explain why I don't think it's overkill and actually very beneficial to even the simplest of games.

Most game requirements are the same

You see, the tricky parts to any game are simulating a world. Every 2D platform game does this.

Consider Mario:
Mario describes a world where a man runs along a blocky world jumping over obstacles and collecting gems. Mario must simply reach the end of each level to complete the game.

The world has physical attributes, gravity, collision detection and solid objects and destructible scenery when hit from underneath.

Consider Sonic the Hedgehog:
Sonic describes a world where a hedgehog runs at ridiculous speeds through a world filled with hazards to be jumped over, loop the loops and enemies to be killed. Sonic must reach the end of a set of levels and defeat a boss in various guises to complete the game.

The world has physical attributes, gravity, collision detection and solid objects. It also has things to increase velocity and destructible scenery when hit at a certain speed.

Consider Treasure Island Dizzy:
Dizzy describes a world with a cute egg who jumps over obstacles and tumbles when he lands. He avoids hazards and interacts with the environment. Dizzy must solve puzzles and collect items to unlock areas of the world to reach an island via a boat.

The world has physical attributes , gravity, collision detection and solid objects. It also has hidden objects to find and underwater sections.

With just these three different games, there are quite a lot of overlapping areas.

• Physical Attributes 
• Mass
• Friction
• Velocity
• Gravity
• Global
• Local
• Collision Detection
• Projectiles
• Hazards
• Hidden objects
• Zones
• Solid Objects
• Static
• Destructible
• Movable

For just these three games, the same problems were solved in different ways to simulate a world and to provide the game mechanics.

Back when these games were made, there really wasn't much of a choice; You made a game engine for a game or series of games and you optimized it to within an inch of it's life. 

Having a common system (if one existed) would have introduced inefficiencies. The simulations needed to be as bare bones as possible to be as fast as possible as every CPU cycle counted. That means bespoke code each time.

Those days are mostly gone. Processors are powerful and memory is plentiful. 

Games are often written in cross platform languages where you have little control over the actual implementation at the machine level. The chances are that a Physics System will be written in a more efficient way to any code you or I could write ('Serious People' remember)

So why do so many people still write their own physics simulations?

Well, It could be because it seems like overkill to use something so powerful for a simeple game. 

Or there's the challenge of rolling your own. There are a lot of interesting mathematical problems to get your head around. But for me, it's a distraction to the game. It's a problem someone else who is possibly much smarter than me and a whole lot more interested in solving said problems than I am.

I choose to use an engine.

This decision is fairly recent however. But now I've seen the light, I'm sold on the benefits. I'll never roll my own again.

What are the benefits of using a generic physics engine over rolling your own to your specific needs?

Collisions

Writing a collision detection system is to be fair - Tedious - and at it's most primitive, involves testing each object in your game with other objects in your game to check if they collide. 

The mechanism you use for this will have a massive impact on the performance of your game.

From the outside it seems simple enough so it's a common thing to write early on. 

The most common is a simple bounding box test.

You can do broad testing using rectangles to check if any corner of one object intersect with any other, hopefully this means that you've zoned your level otherwise you'll be checking a lot of objects. 

As you can see, the bounding box test is clearly not good enough to detect accurate collisions with the planes.

Then what happens when you collide? Do you need to do more granular collision checking? Pixel level? Polygonal? With each step comes more work. 

Pixel level checking is more accurate but old-school and was always CPU intensive. 

With more and more work being done on the graphics card, you don't have access to pixels these days. So you're more than likely looking at a collision mesh.

Then what happens when you've detected the collision? Do you let each object know about it and allow them to decide the outcome? Do to compute the energies exchanged as part of the collision and apply the resulting energies to the objects? 

What about really fast moving objects? Will you implement some form of ray-casting? Do you care about transferring rotational forces or velocities to your objects as a result of collision?

Are all objects Solid? Do you need sensors? Will you have Passive or Active checking?

Can all objects move or do you have static objects which cannot move no matter what?

Just this first part has uncovered a mountain of work. 

These decisions will need to be made before the game development can begin. or you can let a Physics engine do it for you.

X = X + 1 // Movement

Most early games have a section which reads something like this:

If Left is pressed Then Player.X = Player.X - 1

If Right is pressed Then Player.X = Player.X + 1

This code normally evolves to:

If Left is pressed Then Player.SpeedX = -1

ElseIf Right is pressed Then Player.SpeedX = 1

Else Player.SpeedX = 0

For each object in game

object.X = object.X + object.SpeedX

The origins of a physics system. You are tracking velocity in the X axis.

With a physics engine, you can apply an impulse to an object and have it calculate the energies appropriately.

Collisions Pt2 Sensors

The Physics Engine I wrote for Crashblock was also used in a game which was tragically shelved called Guns-Reloaded. 

The AI for enemies was assisted by attaching sensors around an enemy tank which could inform the tank's brain of things like incoming projectiles and dangerous terrain. This meant that the enemy flying tanks could in theory fly close to rocks but not close enough to become damaged by collisions. It also meant they could raise shields to save themselves. 

The data from these sensors was fed into an AI routine and appropriate behaviour was determined. All in all, it worked pretty well.  

Unfortunately, the game failed to mature but the lessons learned from that were carried on to a recent game which I did complete, called SchemeWars. 

In that game aliens were aware of their own positions and the position of the ground as well as dangerous objects flying towards them so they could defend themselves. They also used other collision objects to keep each-other a nice distance from other aliens.

This behaviour was much easier to code that with Guns-Reloaded as I was using a Physics Engine.

Box2D is fast and awesome, you should use it.

http://box2d.org/

I first heard about Box2D when I first saw a game called Crayon Physics. A simple game where you draw objects in order to get a ball from one place to another. 

It was very clever and used the majority of Box2D's features.

http://www.crayonphysics.com/

I seemed to be a perfect fit for that game, but it never occurred to me to use it in a platform game.

I started building the Reversion Bureau (working title) and again, I rolled my own physics and collision detection within the MOAI framework early on; not giving a second thought to the Box2D implementation already built in. My collision code sucked. It was buggy and it was inflexible.

www.getmoai.com

So one day after reading a book from the writers of MOAI, I gutted my game and implemented everything using Box2D. Suddenly, I had perfect collision detection, silky smooth movement and slopes (gasp!). The previous collision code used the tile set and slopes would have required specialised code.

 

This is a screenshot from a very early build of the game with a debug layer showing the collision rectangles. Anything collidable has a green hue and 2 lines (green and red ) showing it's orientation. 

As you can see if you look closely, there is a rectangle around the red guy on the right. That's his collision rectangle. 

There's also a little block underneath him, intersecting the floor. This little block is a sensor attached to the sprite to detect the floor so that the sprite can see whether it is falling or standing; very useful.

There's a block to the left over a door, this is an interaction sensor.

So in this one screenshot you can see Rectangular collisions blocks, polygonal collision blocks, sprite collision blocks and sensors; and it's FAST!.

This does involve a bit more work building your maps in such a way as to provide an object layer to create the collision blocks and polygons. 

Tiled does this very nicely.

http://www.mapeditor.org/

The end result being a smooth and reliable collision resolution system, far better than anything the average developer could write as well as accurate simulations of bounce, torque, friction, gravity.. pretty much anything you need to build a game world - realistic or cartoon.

In Closing

Physics Engines are amazing and useful, they're not just for realistic simulation games and you should absolutely consider using one if you're serious about making any game.. spend your energy wisely and don't reinvent the wheel... literally.

Wow that was a long blog post.

Crashblock Postmortem

Introduction

Every year, for the several years, the Pascal Game Development forum held a game development competition and each year Real Life played nasty tricks on me - meaning that I had no time to dedicate to join in the fun. 

One year was different. I made time available and after playing some of the resulting games from the previous years' entrants, I was determined to put as much effort into the game as possible to at the very least, achieve the same standard as the example which had been set before me.

The competition's theme when I built Crashblock was Multiplexity; in other words, the melding of seemingly incompatible genres to make a single coherent game which should feel as thought those genre's should have always been together and challenge the idea that they were incompatible in the first place. A tough one. What would make things tougher was the quality of some of the ideas being thrown around, I really would have my work cut out for me if I was to make an impression.

The Idea

Coming up with an idea, a good idea should have been the hardest part.. I've read quite a few books on gameplay, balance and planning and I might have spent a while considering my target audience, then formulating an idea and planning it in great detail, perhaps some sketches, a prototype and maybe a focus group, if I'd followed some of the advice I'd been given. Instead, I plucked one out of thin air and wrote it down in as much detail as I could, still not sure how I would meld the two genres together. Well, when I say plucked out of the air, I really mean... I'd been playing Another World, Flashback and Blackthorne a short time before the competition started and I really liked how those games moved. They used rotoscoped animation to create really lifelike animation. The amount of detail in the animation added a lot to the games, there's just something about how people move which is very hard to capture using traditional animation techniques. Especially at my level.

I wanted to do something similar. I knew how much work was involved making rotoscoped animation, so I considered using live action instead. It would turn out that I would need a combination of both live action and rotoscoping. For the puzzle aspect, I thought Tetris would be an easy game to implement. The rules for Tetris are incredibly simple and I'd written a game programming tutorial based on the popular game in the past so I knew what I was doing. In fact, the code from the VB tutorial would provide valuable time savings later on.

Refining the Idea

The starting whistle blew for the competition and along with the other teams, I set to work. The PGD competition had a rigid deadline structure with goals to be accomplished in a timely manner. Missed goals meant missed points, so it was important to score highly in as many of the goals as possible.

The first goal was writing the design document. This was the first time after announcing to the world that I was writing a game based on Tetris and Flashback that I really started to think about how this game would fit together. The question kept buzzing through my head about How someone could play a flashback styled 2D game within the bounds of a Tetris game?.. this was the toughest nut to crack initially and it had to be cracked correctly otherwise the game would not play properly, at the worst case it would feel like two incompatible genres bolted together with some string and sticky backed plastic.

In the end, after a lot of thought, I settled on the idea that the player would control the an avatar who would in turn call a crane holding the current block, which was attached by a weak chain which would eventually snap and the block would fall. This last feature meant that the difficulty could be increased fairly easily by reducing the amount of time the player would have to get the next block into position. The player would scramble and climb over the fallen Tetris blocks and would need reactions and planning to survive. It soon became apparent that the player's avatar would need a substantial amount of moves to be able to get from one side of the Tetris arena to the other but to keep it accessible to everyone, the controls had to be kept simple, using as few keys as possible.

Adding to the Idea

Just running around and positioning blocks was going to be boring and wouldn't add much to the platform game experience. Platform games are about collecting things and avoiding hazards, not just jumping onto blocks for the sake of it. So there had to be things which needed to be picked up or avoided. At this point, the idea still wasn't mature. For instance, I still had no idea how the player would complete a level.. would they complete X number of lines? Or did the player have to reach a certain height to escape from the arena via a door or some other device? I decided that the first idea was too much like the original Tetris and didn't include enough platform elements and the second idea was too much like a platform game and had little to do with the Tetris game, especially since the idea behind Tetris is to keep the number of rows at the bottom as small as possible. In the end, I came up with the idea of collecting stars. These stars would be released from blocks as the rows were completed. This seemed to work well and added just the right amount of balance between planning the next position and scrambling to get the stars.

The other aspect which needed to be thought about was that of the player's avatar and her frailty. The most important part of the platform game for me was that the player should ot become overly frustrated or powerless, they should never feel that an action on their part should get them stuck or killed. The player would always be able to choose whether to venture into an area which may trap them and they would have tools to help them to escape in most circumstances, that was the plan anyway. As it turned out, keeping the player from getting themselves stuck was harder than initially planned. Imagining the possible scenarios where the player could trap themselves and working out animations to help them to get out of it while keeping the controls simple was quite a tough process. So in the end, I covered the basics and added a couple of special moves which the player could find for themselves. They would also be able climb up the walls and to collect bombs, which were previously a hazard, and use them to carve holes in the fallen blocks to get them out of trouble. Failing that, they could forfeit a life and be placed at the top of the arena once more.

The Hazards

When coming up with a list of hazards, it was obvious that I had a limited playing field in which to place them. The simple controls system reduced the options for avoiding some hazards, so ideas like Spikes coming out of blocks and walls and Monsters were dropped. I did have an idea where monsters would be trapped within cages in blocks which would be released once the row was completed. But after extensive play testing it became obvious that some monsters would be either too powerful or useless, meaning that the player would become trapped with nowhere to go and no way of dealing with the monster waiting on the block below them or the monster would become an annoyance and wouldn't add anything positive to the game. So I removed the idea. Monsters may make a comeback in later editions of Crashblock, but as a delaying object, grabbing hold of the avatar's legs as they run over the monster cage, but on the removal of the line, the monster would be destroyed. This is not yet in the game and careful testing will be done to ensure that the gameplay balance is maintained.

The bomb hazard needed to be dangerous and exciting at the same time. While they are easy to avoid, I wanted to give the player an incentive for attempting to collect a bomb which had already primed. So I opted to give a score bonus if the bomb was collected with just seconds to spare as opposed to the small score increase if a mundane bomb is collected.

The bombs would also have the ability to set off chain reactions. Where a bomb explodes and removes a bomb block from play, that bomb is released and will prime and eventually explode. This situation can carve massive holes in a carefully constructed block pile.

The Bonuses

The player needed things to collect. Stars complete a level but the real scoring is done with the fruit and coins, especially when the items were thrown out of a bonus block with a x2 or x3 bonus on them. Originally, I had planned on making the x2 and x3 bonuses much more critical to the game-play, where if the player managed to line up 4 of the same bonus in a row, they would receive a massive bonus. But I decided against this as the player really only sees the ghosted image of the current block and would rarely use the camera move function to see the alignment of the blocks. So the x2 and x3 bonus blocks simply multiply the score of the items they throw out.

Originally, I planned to not include a high score table. But after watching other people play the game, I noticed that they weren't collecting the scoring items. When I asked why, they replied, There's no point if the score is not saved. A valid point. So in the post competition version, I included a high score table. You can learn a lot about the game you're writing just by watching people play it.

I also noticed that people were not completing multiple lines, this was a major part of the Tetris experience. Clearing 4 lines at once would net the player a large bonus. So I decided to implement this feature in the form of Diamonds. When the player clears 2,3 or 4 lines at the same time, a diamond will fall. This diamond will have a different score attached to it for the number of rows cleared. The diamond will also require collecting for the score to be applied. This would add an additional level of planning and decision making on the part of the player.. should they go for the diamond or the last star to complete the level?.

As the levels get more difficult, the player was going to need to be able to rest for a while or get some extra time to climb up a large block pile to get to the other side of the arena. So I introduced Time-Outs. These devices stop time for the chain, ensuring that it will not snap while the Time-out is in effect. The Time-Outs would be retained between levels (unlike the collection of bombs which are cleared at the start of each level) this was to give the player the choice of wasting a timeout early on or save it until they really need it. Time-outs would be available for collection after a number of points had been collected, as would extra lives.

When is it Game Over?

In Tetris, it is when the blocks pile to the top of the screen. In a platform game, it is when you run out of lives. I wanted to preserve the feeling of intense panic as the blocks reached the top of the arena and I didn't want the player to have the option to reset the blocks by allowing them to reach the top, only to lose a life. That's not what Tetris was all about. So I settled on a dual system. If the blocks reach the top of the arena, It's game over. It the player runs out of lives, It's game over. The player can forfeit a life to get out of traps, but not to put right bad planning, the player would have to use their intelligence to do that. I believe this added just the right amount of panic to the game. It starts out very relaxed, there's no real danger. But later on, when the chain only lasts a few seconds and bombs are fizzing away, and the blocks are nearing the top, there is a lot of panic.

The Music

In previous games I've either written the music myself, or charged my brother with the task. For this game, Time was of the essence and I did not have time to write the music myself. I also did not have time to direct my brother and go through the lengthy music development process. Luckily, I found an artist whilst surfing AcidPlanet, William Christiansen from Symphonic Chronicles. I felt that his music would suit the game perfectly, so I approached him to get permission to use his work in the game. Amazingly, William was delighted to help and gave permission for me to use his work, providing me with a rich soundtrack to build upon. If he had said No, I fear the game would have a completely different atmosphere to it and would not have been as successful as it was.

Creating the Graphics

Crashblock's graphics were created using a combination of 2D drawings and Live action animation. The menus, the levels and all incidental graphics were created using the Xara Xtreme tool, a product I've used and raved about for many years. The job was made much easier with it's ability to use Photoshop plug-ins which meant that I could make some really nice effects. The live action was recorded in our local park using a digital video camera, tripod and tape measure. Getting my Wife to perform various actions for the camera and videoing the results. These actions involved climbing onto rubbish bins, jumping off, running, leaping, falling and even crawling along the ground. Recording the video attracted a lot of attention including that of a group of teenagers who seemed disappointed after asking us about the game that it wouldn't be on the X-Box. I reassured them that it would be downloadable for the PC, but they just rode off on their bikes. It was when transferring the graphics from video to stills that I encountered my first problem. The images contained a very real park in the background. So I would have to spend quite some time cutting around the images in Xara to make the individual frames. This job turned out to be the very definition of a pain. Still, without blue-screen technology immediately available, there wasn't much else I could do. Several days passed, animations were made.

What went wrong

There were numerous things which could have gone better. For one, moving house whilst writing the game didn't help. For another, being made redundant from my day job didn't help either, neither did the stress of finding alternative employment. Luckily, most of the work on Crashblock had been completed by then.

By far the hardest part and without a doubt, the most time consuming part of the development process, and the one part which made me contemplate throwing in the towel, dowsing my PC with gasoline and setting it on fire in a ditch in the garden was the state machine. Crashblock uses a state machine which chooses the most appropriate next state based on the current state, the player's input and the blocks around the avatar. What appeared from the beginning to be a relatively simple task dragged on for days and days, seemingly without an end in sight. Just when I thought I had everything working properly, the Avatar would disappear off the side of the screen, or get stuck. What made it worse was that the state machine used data to determine the next animation and was not a hard coded process. This made debugging much more difficult and meant that I became very close friends with conditional break points. After several days of hard graft, I had something which resembled the final state machine. Once the bugs were isolated and neutralised, other bugs could be tackled. It was a part of my life I would not forget in a hurry.

Originally for the live action component, my plan was to use a blue-screen system. My wife was at university at the time and there was a chance that I would have the opportunity to use the facilities to record the video. This would mean that I would have to erase the background using Gimp or Photoshop, but it would be far quicker than cutting out the backgrounds by hand. In the end, this opportunity never materialised and I ended up having to cut out the frames by hand.

If I ever do anything like this in the future, I will build a bluescreen rig myself as cutting out the frames by hand kills the flexibility let alone the tendons. I did want to re-shoot the running animation, but when faced with the prospect of cutting out the backgrounds, I decided against it and kept the old animations.

What went Right

Pretty much everything else went according to plan. I was using an engine I had written a few years before so I knew the framework well, I managed to get a working Tetris game for the 2nd competition deadline, complete with the graphics I would go on to use for the 1st 4 levels of the final game. The Xara Plugins helped a lot, taking away the tedium of creating detailed graphics from scratch and allowing me to get on with other tasks and keeping a consistent look and feel to the graphics, which can be more important than having some fantastic graphics and some poor graphics.. if all of the graphics are of the same quality, they stick out less and don't detract as much from everything else. On the other hand, if all of the graphics are fantastic or rubbish, they will add or detract from the game on their own. But that was obvious.

I had a lot less feature creep in Crashblock than on other projects. This was probably to do with the deadlines and the fact that we each had to create a living design document, it was a good tool to rein in the creative side. It is very tempting to add feature after feature without fully thinking things through. With Crashblock, I knew that it would fail if I made it too complicated. I also knew that I didn't have a lot of time to spend on the game, only a few hours each night at the most. Sometimes days would pass without having any time to spare on the game. This was very frustrating. I spent a long time Play Testing crashblock. I took the advice contained within one of my books to get as many people playing as possible. My idea of fun is not the same as someone else's and it's important to make the game fun for as many people as possible. In this task, I think I succeeded.

Conclusion

Crashblock was a very interesting project for me. It was a simple game but as with all things, it's simplicity was deceptive. By adding a new element to a well known genre, it changed it completely and a new set of rules had to be understood in order to determine if the game was functioning correctly. The live action part was great fun to create and broke up the development process nicely, switching between pure coding and video directing. Sometimes it is nice to get away from the code and think about something else for a while. This helps to solve complicated problems. Aspects which should have taken longer were completed quite quickly and part which should have been simple took a very long time.

In the end, I created a game I enjoy playing, my Wife enjoys playing and my family and friends enjoy. I'm hoping that other people will enjoy it too.

In Closing: Zen-like wisdom

If a problem is hard and you're banging your head against the wall, take a step back, have a cup of tea and do something different. You'll perhaps see that the way forward is simply a matter of walking around the wall.

Building MOAI for Android and OUYA - all in one.

Building MOAI for Android.

Some things you’ll need before you start.

Patience and Attention to Detail - There are a lot of steps, thankfully once you’ve completed the earlier steps, you won’t need to repeat them. The steps have to be carried out accurately and while you can repeat them, they delete and recreate directories in some cases, so be sure you’re following the correct steps..

An existing runnable MOAI project. There are example projects to use, but as you’re at the point of building for Android, it is probably safe to assume that you have a project ready to at least test on Android.

It’s quite simple once you’ve got the hang of it.

Installing the Environment

Install CYGWIN (Install everything, MOAI uses a bunch of modules, be safe and get them all)

Install adt (Eclipse IDE with built in Android SDK and plugins)

(install to c:\adt-bundle-windows-x86_64)

Install android NDK (copy into subdirectory of adt-bundle-windows-x86_64)

Install Apache ANT (install to c:\apache-ant )

Add ant directory to your path

Add ndk directory to your path

You can use the [Start]->[Control Panel]->[System]->[Admin System Settings]->[Advanced]->[Environment Variables] and edit the value of the path variable.

(Make a copy of the previous path first before you edit as it’s hard to repair if you break it)

or you can use the command line

It’s important to get these 2 directories added to your path otherwise all sorts of things will go wrong as the build process won’t be able to find things it depends on.

Start cygwin

The Cygwin terminal places you in your user’s home directory on your the virtual linux.

To get access to your filesystem you need to:

cd /cygdrive/c

This places you at the root of your hard drive (C:\ in DOS speak)

Optional: If you already have a MOAI source codebase you want to work from,
you can use that instead.

Get the most stable MOAI from the git repo into c:\moai-dev

git clone git://github.com/moai/moai-dev.git

Once the source code for MOAI has been retrieved to moai-dev

cd /cygdrive/c/moai-dev/ant   

(remember in cygwin / takes you to the root of cygwin - not the root of C: )

Run the script to compile MOAI and generate the project structure.

(this will trash any previous projects - be warned)

Pay attention to any errors, this part will fail if anything is wrong with your environment settings.

./make-host.sh -p com.yourdomain.moai  

(make sure yourdomain does not contain [-] characters, it breaks java when compiled as it can’t be used in a namespace..

Changing Settings files.

modify settings-local.sh file.

Set the android_sdk_root to point to your android SDK.

modify the src_dirs to point to your game code.

(note that the path is to be visible to cygwin e.g. “cygdrive/c/gamedev/awesomegame/” )

Modify settings-global.sh file

change the requires=( … ) line to read just

requires=( “miscellaneous” )

Save the changes to the files.

Run the script to build the project file.

./run-host.sh

If this works properly, you’ll have the files you need to start a project.

Bear in mind that cygwin may not have created the directories with the correct permissions. So to save yourself a lot of heartache, set the permissions on the untitled-host folder to give yourself permissions to add to it modify etc. You can also rename it to something more suitable.

Once you’ve completed this section without any issues, you shouldn’t have to repeat this unless you’re re-compiling the MOAI source.

Compiling the Android Project

Start ADT and click the file menu, choose Import.

Then navigate to the directory c:\moai-dev\ant\untitled-host/Host/build/project

If you moved your host to somewhere else, then use that directory.

At this point, your game files should be in the Host/build/project/assets folder.

Once you have the project imported into ADT, you should be able to run it as an Android application.

Note: I’ve noticed a permissions issue when I try to build  the APK, if you get messages saying that you can’t add to the apk, then you need to set the permissions on the folders again as the permissions didn’t inherit when the new build folders were created.

Building Moai for OUYA

To build for the OUYA console, you follow the exact procedure for a standard Android build but with source code (for now until MOAI includes OUYA code in it’s standard host) .

Bear in mind that this is an unofficial Fork of the MOAI engine and may not have newer fixes or features.

The git repo is at: https://github.com/krusmir/LionK1tty-based-moai-dev

krusmir/LionK1tty-based-moai-dev

Once you’ve grabbed the repo either with git or by downloading the ZIP and saving it to c:\moai-dev

(or anything you need, personally mine is called c:\moai-dev-ouya so I can have both Android and OUYA builds )

You can build the project using the steps above. The only change being that instead setting

requires=( “miscellaneous” )

instead you need

requires=( “miscellaneous” “ouya” )

OUYA Specific development

Deploying to an OUYA

Take a micro-USB cable and connect the OUYA to your PC.

Windows will not be able to install the driver initially - so you’ll have to follow instructions on the OUYA web site on how to connect it.

You’ll need to make sure your Android SDK has the Google USB driver installed.

In the directory ( atdbundle/sdk/extras/google/usb_driver/android_winusb.inf), make sure you add

;OUYA Console  

%SingleAdbInterface% = USB_Install, USB\VID_2836&PID_0010  

%CompositeAdbInterface% = USB_Install, USB\VID_2836&PID_0010&MI_01

to the [Google.NTx86] and [Google.NTamd64] sections and save it.

This video explains the steps http://www.youtube.com/watch?v=454JFvFTxww

Handling Controllers.

Here’s a handy table of controls and how they’re mapped along with a brief description.

The icons are from the OUYA Dev kit. https://devs.ouya.tv/developers/docs/interface-guidelines

There are listeners which have to be defined to see the OUYA events.

MOAIOuyaAndroid.setListener ( MOAIOuyaAndroid.OUYA_MOTION_EVENT, onGenericMotionEvent )

MOAIOuyaAndroid.setListener ( MOAIOuyaAndroid.OUYA_MOTION_EVENT_TOUCHPAD, onGenericMotionEventTouchpad )

MOAIOuyaAndroid.setListener ( MOAIOuyaAndroid.OUYA_BUTTON_DOWN, onOuyaButtonDown )

MOAIOuyaAndroid.setListener ( MOAIOuyaAndroid.OUYA_BUTTON_UP, onOuyaButtonUp )

The event handlers are defined as:

function onGenericMotionEventTouchpad(touchpadX, touchpadY, player)

…

end

function onGenericMotionEvent(leftAxisX, leftAxisY, rightAxisX, rightAxisY, l2Axis, r2Axis , player)

…

end

function onOuyaButtonDown (keyCode, player)

…

end

function onOuyaButtonUp (keyCode, player)

…

end

You’ll note that the player number is passed as the last parameter. This is 1 to 4.

Also, there is no way to directly query the state of the sticks or buttons, instead you get the events when something happens.

Also note that the Java code handling the sticks takes the deadzone into account. So you need only check for values in the -1 to +1 range in either axis.

Button	OUYA Name	Typical Use	Maps to MOAI
	O	The OK/Select button	Button code 96
	U	The Secondary OK button	Button code 99
	Y	The Tertiary OK button	Button code 14
	A	A - The Cancel / Back button	Button code 97
	D-Pad	Used for accurate directional control.
			Button code 21
			Button code 22
			Button code 19
			Button code 20
	L1	Left Shoulder Top	Button code 102
	L2	Left Shoulder Bottom	General motion l2axis
	L3	Left Analog Pressed.	button code 107
	LS	Left Analog Stick	General motion leftAxisX leftAcisY
	R1	Right Shoulder Top	Button code 103
	R2	Right Shoulder Bottom	General motion r2axis
	R3	Right Analog Pressed	Button code 107
	RS	Right Analog Stick	general motion rightAxisX rightAxisY
	Touchpad	The Touch Pad. Acts as a touch screen.	motion event touchpad touchpadX touchpadY
	System	The System button - Used for pause menus, be aware that pressing this button for more than a couple of seconds quits the game	Button code 82

Here’s a handy list of constants:

AXIS_L2 = 17

AXIS_LS_X = 0

AXIS_LS_Y = 1

AXIS_R2 = 18

AXIS_RS_X = 11

AXIS_RS_Y = 14

BUTTON_A = 97

BUTTON_DPAD_DOWN = 20

BUTTON_DPAD_LEFT = 21

BUTTON_DPAD_RIGHT = 22

BUTTON_DPAD_UP = 19

BUTTON_L1 = 102

BUTTON_L2 = 104

BUTTON_L3 = 106

BUTTON_MENU = 82

BUTTON_O = 96

BUTTON_R1 = 103

BUTTON_R2 = 105

BUTTON_R3 = 107

BUTTON_U = 99

BUTTON_Y = 100

In App Purchases

The business model for OUYA has always been Free to Play. This doesn’t mean Free games however, it is perfectly fine to offer a Free to play Demo of a game which requires payment in order to continue or even a Free-To-Play game which offers in app purchases for in-game-items.

Purchases and card details are handled through OUYA’s market place. All the game has to do is talk to it.

Checking purchases

When the game runs, after a purchase has been made - it’s important to check to see if the game has been purchased or not. Part of the ODK deals with this.

Sources and Thanks

Thanks to gamesfromscratch for getting me through the build process so I could create this document. http://www.gamefromscratch.com/post/2012/08/28/Setting-up-a-Moai-Android-host-build-environment.aspx

Thanks to Krusmir for putting the OUYA MOAI branch together