Review the Ancients: Trantor: The Last Stormtrooper.

Trantor: The Last Stormtrooper

Developed by Probe Software
Music: David Whittaker
Published by GO!
Written in 1987
Play it online.





A ship pierces the night sky and descends into a narrow canyon. The red walls of rock rise slowly as the ship makes it's perilous journey into the unknown depths below.

The ship's radar dish rotates rapidly, scanning the area for a signal. Eventually, the ship arrives at a landing platform - it extends the landing gear and retracting it's wings. A solitary figure emerges from the ship and beckons for his companions to disembark. He runs from the ship and is blown to the floor as the ship disintegrates. The lone survivor stands, takes a fleeting glance at where his ship and comrades once stood and looks away towards his destination.

He is alone.

The title menu appears, neatly animated - accompanied by an impressive score rendered expertly on the 48k beeper.
Quite how David Whittaker managed to get such sounds out of the beeper is entirely a mystery to me.

The music hits home as the player has just watched an awesome intro sequence... An intro sequence on the Spectrum! This was unheard of and it set the stage for a  
cinematic adventure.

The game starts, revealing a large character, taking up a third of the screen with amazing detail and colour. On command Trantor runs to the left or to the right with incredibly fluid animation - again, unheard of. An alien drone appears and flies at his head, Trantor ducks and the drone flies onward. Another drone appears on a course with his chest, no ducking this time. Trantor pulls the trigger on his weapon unleashing a jet of flame - immolating the alien and it's companion behind it. He realises that he cannot stay still and runs. The place is infested. He must escape.

The place is also littered with environmental traps. Pistons emerge from ceiling. Trantor has to carefully time his run to avoid being hit by the pistons whilst also avoiding the drones. He could fry them, but then his napalm supply is limited. With each hit from a piston or collision by an drone, Trantor's health is reduced. After a perilous few seconds, he reaches a locker. Inside is a burger. He eats it and replenishes his health. Next to it is an elevator leading down to the lower levels of the base. He decides to explore more of the base before going down and discovers a napalm stash. Further exploration reveals a computer terminal. Activating the terminal sends out a transmission. A transmission is received - and the timer is reset to 90 seconds, he is also presented with a code letter. Trantor must find more terminals within the time limit, download the letter and enter the code into the mainframe to have any chance of rescue.

He takes the elevator down. The base looks similar to before, only there are pistons rising from the floor. He knows the drill, kill anything that moves, search the lockers, find the terminal and refuel his flame thrower. Then find the elevator and descend.

The third floor looks different. Instead of the industrial platforms, he is faced with brick floors and ceilings as well as spikes intent on ruining his day. The drone presence has also intensified here who attack him from every direction.

He decodes the terminal, receives another code letter, finds fuel and food and the next elevator. This elevator goes up to an unusual set of corridors.

This level is strange, alien even, ribbed walls in green and yellow suggested that he'd entered somewhere far more hostile. However the floating robot drones which had proved so troublesome were not to be seen. Any calm which the absence of drones afforded him was quickly quashed when an alien standing at least 9 feet tall appeared, it's jaws containing sharp teeth and it's muscular body suggested that melee combat would be inadvisable. A blast from the flame thrower saw it off as another appeared behind him. Trantor ran.


In spite of the rich story which is told by the amazing visuals (for the time), the gameplay is shallow, a simple matter of run, jump, duck and fire. The aliens can only be killed by the flame thrower if at chest height meaning that most of them impact with the trooper as he runs around the level. The alien drones seem to explode on contact with Trantor, meaning that they must exist in a perpetual state of terror as any collisions would spell their doom.

Impacts with pistons and spikes also a fairly unavoidable. Both hitting aliens and moving environmental hazards drain precious health and make for a fairly frustrating journey between health stashes.

It does add tension though, especially as not all lockers contain food. Sometimes you get extra time, other times you'll get a screwdriver which offers seemingly no value to the game. Other times you'll get a shield or more napalm. There seems to be a 1 in 3 chance of getting food.

Enemy encounters are random and frequent, however they pose little threat until you reach the 9 foot tall monsters - who eat your head. The fact that it is impossible to avoid being hit by enemies is the most frustrating thing. It detracts from  the feeling of control. Surely Trantor wouldn't allow himself to be hit in the head by anything. Surely he would at least aim his flame thrower.

The visuals are fantastic though - especially considering that the game runs in 48k of memory. This means that the animation for the trooper, the flamethrower, each alien, the background graphics, the game code, the music and even the intro sequence all fit within 48k.. That's 49152 bytes.

 take a moment to think about that...

Just for comparison, the low resolution scan of the box art at the top of this review weighs in at 186k. Trantor would fit into that jpeg file almost 4 times.

The animation for the main character is fluid and conveys a sense of mass. His flame thrower shoots out fire impressively. Visually, the game was leaps ahead of the competition (even if the graphics were rendered using an xor technique instead of masking - although given the amount of graphics involved they are forgiven ). The alien movement is a little awkward and the 9 foot tall aliens pop into the side of the screen instead of appearing smoothly.

The game is also quite short, but hard and very tense. There are no lives. Once dead, you start again. No checkpoints or hand holding in any way.

On release, the game received a lot of praise in the gaming media - particularly because of the graphics, often overlooking the simplistic gameplay.

The backstory was also a little ambiguous. One spectrum magazine ran a preview for the game with a detailed backstory which included betrayal, an alien war and a 90 second timer for a bomb in Trantor's head which would explode if not constantly reset. Whereas the Amstrad case inlay reported that this was all in trantor's head as he struggled with the accidental death of a child.

In the end none of this mattered.

I fondly remember the game for the tension it caused. I certainly felt it and genuinely freaked out when the large aliens were after me.


I wonder what Trantor would look like if it was remade today - possibly it would play like Abuse, another tense and often terrifying game.

I would love to see this game re-made.

Anyway, here's the music by David Whittaker

If you can find the original tape, on the B-side, there's music from a Rock band called Resister titled "The Fight" 

Making a Game in a Weekend with MonoGame.

Early last week, I was chatting to a close friend of mine - (Dean Ellis) about Game development and we discussed the possibility of participating in a weekend GameJam. Dean and I having written games in the past, but never together (or at least those shared ventures were never completed).

We had no theme, we had no plan. Just come over to my house on Friday evening with your laptop and let's make a game.

Dean arrived around 6pm with his 8yr old Son in tow. Laptop at the ready and it was clear early on that we were going to need supplies for this adventure. We were going to need beer! Lots of Beer... and snacks.

After cleaning the local shop almost out of junk food and beer, we set to the hard task of deciding what to build - and who was going to do what.

Who does what?

It is an important step in any team to decide what role each of you is to play and to stick with it. Otherwise chaos ensues. We decided to step a little out of our comfort zones with this. We'd use a platform I wasn't familiar with and Dean would provide the artwork (normally my role).

The platform we decided on was Monogame. For those who may not know, Monogame is the opensource cross platform implementation of the Microsoft XNA framework (now sadly discontinued by the big M - but lives on with an incedibly strong community thanks in no small part to Monogame, especially with it's cross platform capability (more on that later).

I'm used to using the MOAI framework, but if there were any parallels - It shouldn't be too hard.

The language of choice would be C#. I'm familiar with C# - Many years of ASP.net and Windows Mobile development have given me those skills, however I will admit a little rust, what better way to polish my metal than with an intensive game development session?. 

Dean on the other hand works at Xamarin and is a C# guru - which is handy when said polishing was needed. Thanks Dean :-)

Dean was in charge of Art. He wasn't to take an active role in coding, Instead, he'd be providing a suit of assets needed for the game. His tool chain was Inkscape, Textturepacker and Spine.

To help out and save time however, Dean did provide a library and example class to handle the Spine animation.

So began the evening. We ordered a curry from my local Indian and began the brainstorming process.

We'd need a game we could handle in the weekend - preferably something we could get to "first light"* in the evening.

*First light is the point when you first see something on screen resembling the thing you're trying to make - it's the first piece of visual progress after what can seem like an eternity of coding. It may be as rough as a bears back end, but it's a thing of beauty.

We decided on an endless runner - similar to Canabalt - in which you play a Kangaroo named ROO! (upper case deliberate, and pronounced in a death metal voice). The story being a parody on the old Skippy the bush kangaroo TV show from the 1960's - in which little Timmy has fallen down the well (again) and ROO must race across the outback to inform ranger Bruce - Crikey!

A very simple story, simple game play requiring a single key-press, button or screen touch. Hold down the control to increase the jump height up to a maximum and clear any obstacles.

The curry arrived, we had our idea - it was time to load up with Curry Power and get to work.

Installing Tools

I installed Xamarin Studio and the Monogame framework. Dean created a Git repo on BitBucket so we could collaborate effectively. I used SourceTree by Atlassian as my Git manager - Dean used the command line.  

It was time to create the project. Thankfully Dean had access to a project template for Xamarin to create Monogame projects. That was easy.

Now faced with a blank canvas - no game, no menu system, just an empty XNA game class.

...and we're off!

It was now around 9pm - Installing tools and setting up environments had taken it's toll.

So the first thing we were going to need was a Kangaroo. Dean set about drawing a Kangaroo which he could then break into pieces and animate using Spine.

He built a skeleton for the marsupial and made a decent hop animation.

In the meantime, I created a state stack to allow us to have different game screens. e.g. a Splash Screen and Menu as well as a gameplay screen. This would allow us to separate the game code out into other classes as we needed to and have the main game code control them as if they were the main game code.

This meant creating an object oriented structure of game objects which catered for everything, states which inherited from game objects, an animated sprite class which would handle the spine animation and a level manager to provide the endless running level... which at this time I had no idea how to accomplish.

I had an idea, an endless runner doesn't care about what was past and what's to come, only what is now. This meant that we could have a queue of only the details needed to display the map queuing and de-queuing items as the player moved through it. 

The levels would be random so there would be no level data to store, only a set of rules which would govern the pieces to place in front of the player as they progressed.

By 2am, we had a level being rendered and an animated ROO! 5 Hours of coding and several beers had brought us to first light. We could see where we needed to go from this point on.

The next morning,

I cooked a breakfast of bratwursts, bacon, eggs and beans - we were going to need the energy. We had a lot to do. The game ran in a demonstration capacity, but there was no gameplay and no level.

So after breakfast we continued. Dean created death animations for the kangaroo and I set about implementing a collision detection system against the level. Normally, collision detection is done against objects with position and size within a level. These items are normally loaded and are generally treated as real things according to the game engine. This game had no physical objects created within the game world. Objects would exist for at most a few seconds before being deleted. This meant that we needed to make sure that the objects were as simple as possible. To that end, I created a class which held the texture names for 4 rows and a height to position the entire column on the screen in relation to the rest of the level. This meant that we could draw challenging levels, but there was no level geometry to test. However as the data was predictable, it did mean that we could perform bounds tests on rectangles which were near to the kangaroo. We'd generate the bounding rectangles for each of the levels near-by tiles on the fly, but it would be fast enough.

I progressed on making the kangaroo collide with the level accurately, ensuring that he stayed on the top of the level's terrain. I've feel so spoiled lately using Box2d to handle all of this stuff properly for me.

As Dean made more animations, I put them into the game. ROO can trip on rocks, faceplant, hit sheer cliffs or even just run into a wall - each needed their own animation. Thanks to Spine, Dean was able to build all of them.

At lunchtime, we took a break and went to the local pub - for a post morning debrief and to gather our thoughts on the remaining work.

And with that in mind, we played the Artemis Bridge Simulator for an hour - Awesome game.

After Lunch

This was mostly putting things into place. Animations, Jumping and the all important Level generation.

With Dean busy tweaking animations, drawing backgrounds and recording some initial game audio, I had to figure out how to make a responsive jump action. In endless runners, the player has to judge how high to make the player jump. He has a maximum height beyond which, he'll fall to the ground. The player must feel like they are in control of the character at all times and that any failure in the game is entirely the fault of the player. This is how addictive gameplay is born. If you make the game feel unresponsive, the player will blame the game and will not become as engaged. Making the player feel completely in control adds to the immersion and therefore into the addictiveness of the game. 

To do this, I'd need to know whether it was possible for ROO to jump. If so, then he'd pay attention to the jump command. However, as soon as the command was halted, he'd ignore any further requests to jump until he was eligible to jump once more - basically, when he was on the ground and hadn't hit anything.

Another decision I made was to place all of ROO's jump logic before anything else in the update methods. So you'd always get to jump. It may not seem like much, but if the update loop runs every 60th of a second, that means that there's an entire 60th of a second where you may have pressed the jump button - but if the level is allowed to move before you've had your command registered, you could hit something instead. The player has to come first, so the controls need to be processed first.

ROO is very responsive.

The day wore on and we made more and more progress on the game and consumed quite a lot of tea. The animations improved, Dean worked hard on the tile set and ROO himself to make gaps in the sprite from being shown. He also built clouds and mountains to act as parallax  backgrounds to add depth.

I wrestled with the level generator - I'd made an assumption about the peek method of the queue in that it would give me the first element in the queue, in fact it gave the element about to be dequeued. On retrospect, it was sensible, however I really wanted the most recent addition to the queue. Afterwards the level generation was working great.

By about midnight, we'd got the game running nicely.

The Next Day

So very tired. Dean and Myself were pulling from resources we didn't know we had. Late nights, beer and game development does not make for happy mornings. Still, we got on with the work of polishing the game. We only had a few hours to make a difference, Dean would have to leave in a few hours so we'd have to make the most of it.

I recorded some additional sounds for Roo while Dean made more animations - basically ROO would be able to run at two faster speeds to keep up with the ever increasing level speed. This coupled with shouts from Timmy in the well to boost ROO's resolve added to the atmosphere. I used BFXR to make simple bounding and jumping sounds while recording the voice of Dean's son for the voice of Timmy.

I altered the generation code to make the later levels harder while in the meantime, Dean took a hiatus from the pure graphical side and worked on the high score table. He'd held out for 2 days without coding anything, an amazing feat.

He also worked on the additional build targets so that the game would compile on other platforms.

By the end of the day. Dean had iOS, OSx, OUYA, Android and Windows via OpenGL and DirectX working. With a little luck the Android version would be relatively simple to put onto the market.

Testing on a few different android devices revealed some graphical bugs which were quickly resolved.

I worked on the music for the game. I only had a couple of hours to spend, so I used a tried and trusted tool Mixcraft. Mixcraft has a vast library of samples as well as virtual instruments to call upon. So I made a piece of music which became more intense as time went on. I feel it complements the mood. But then I wrote it.

So in the end,
We have a completed game with a failure state, sound effects, music and animation. It's fun, addictive and accessible.

It took us about 20 hours from nothing to game.
The tools we used were:

Xamarin Studio
Source Tree
Inkscape
Spine
Audacity
Mixcraft
BFXR

London Gamecraft 2014 : Part Deux - The Movie

OK, that's probably a little grandiose, but at 23 mins long, it sure felt like I was editing an epic. I feel that I know how Peter Jackson must feel. 1 day to shoot, many many hours to edit.

Cards on the table: This was my first attempt at making a video production, so it's a little rough around the edges and it's probably a little too long and could use some cutting - But I didn't want to lose any of the interview footage, some of it is golden. It's also taught me a lot. After Effects is an incredible piece of software, I could probably dedicate months of training time and still only barely scratch the surface.

We arrived early, after getting up incredibly early to get the train to London. We arrived before any of the developers to give us time to set up the greenscreen rig.

After that, and after coffee and breakfast, we set about capturing footage for a potential game. We took a load of props with us, from Nerf guns to teddy bears. The teddy bears would be animated with the assistance of the chroma-key suit.

Unfortunately, we didn't make a game with this footage, but it was a good test to see if we'd got everything set up properly - and we were hoping to inspire the developers in some way.

So instead, we made images of clouds using cotton wool. This worked well and they were useful in one of the games.

We also filmed planes for use as sprites. If you can't draw it, film a real one (or a model)

We filmed a bunch of planes, even recorded rotations for a game which I think Dean will make as soon as I get the processed footage to him.

On the day we were mostly expecting to capture footage for the game developers to use. We did that, and provide special effects for those who needed them. We also introduced a few people to the amazing BFXR online sound generator.

As the hours passed and the developers had gotten used to the idea that they could call upon us for assistance - They're typically a self sufficient lot, and demonstrated amazing skills in their craft.

The special effects (mostly explosions) were created as assets for the developers using the amazing TimelineFx.

At the end of the day, those developers who'd completed their games got an interview against the greenscreen where their game would be played in the background.



Thanks to Global Game Craft for organising the event, SkillsMatter for hosting it and providing sodas,beer and pizza and to .mpegasus and _ensnare_ for the music for the video. Go check out their stuff. It's brilliant programming music.

A good time was had by all and Games we born.