The plan

We've been thinking on how to progress with Gloop Troops 2 and have devised the current plan:

* We will use Andy's experiments with the Z80 C compiler Z88dk to form a new template code base.

* Port over our map renderer to C. This should be easy to do as the compressor was written in C, so creating the unpacker should be straightforward. Would anyone else be interested in using our map editor? It's designed with the Spectrum firmly in mind, it allows attribute setting per tile and uses brushes to create a screen. Each brush is a collection of tiles which can be stamped on screen.

* Write a simple game to test the water. I'd be helping Andy put this together over the next few weeks. The idea here is to make sure all the key parts of our pipeline are working in C. It will also allow us to see what kind of compromises (if any) there would be re-creating GT2 in C.

It does feel a bit backwards to try and recreate GT2 in C, but from Andy's experiments it looks to be promising, and with my injury still months away from getting better it looks to be the best solution for completing the game.

We've also been thinking about what platform to move on to next. We'd like to try tackling something fresh (but still retro), but are undecided. The idea of doing a port of GT1 with some extra bells and whistles has come up as a good way to learn a new platform. We're also interested in hearing from any other coders - ideally ones who have already put games out on a retro platform!

Current suggestions being floated around  are: Amstrad CPC / C64 / Amiga (either 500 or CD32) and Atari Jaguar. Each has some interesting strong points. Do people have any strong opinions towards one of these? Is there another retro machine that people would love to see a new game on (and one where it's legal to release a game on)?

Gloop Troops in Return magazine

Return have an article on Gloop Troops this month!

Differing versions and the trouble with post release fixes

Publishing updates for a retro game out in the wild is tricky business! Modern PC and console games have the luxury of being able to easily connect to a server, download and apply then patch before relaunching the game.

This fantastic functionality can be hidden from the player. At worst the system can prompt them that the update process is about to begin!

Older platform's, without any online connectivity, do not have this luxury. Instead the best we can do is provide a version number on the game's title screen to help identify it. We then need a way to inform the player that a new version of the game is available for download.

Because of the extra hurdles involved, we've been reluctant to implement feature suggestions into titles we're already released. For example, with Gloop Troops we'd received some excellent feedback ( requests for music, keyboard control and a re-jig of the level order ). But by the time we were able to collect all feedback there had already been 4 versions of Gloop Troops made available over the internet!

One was the original version, then there were two hacked versions - one with music and one with a change to the title screen to circumvent a bug on real Spectrum hardware, and finally the official fixed version we'd released.

This makes it more difficult for anyone reviewing the game. If we release a version, then collect feedback and release another version then you may have conflicting reviews on game sites. We would also need a solid method of communicating the new version to existing players.

There are a number of solutions to this. We could provide a version number on the title screen along with a URL and a message informing the player to check for updates, but this feels messy and convoluted. This may be an interesting method to pursue if we explore an episodic game series.

The current solution we have in mind for our upcoming tiles is to have a beta period for our future titles. This way we can collect feedback and catch any issues with the game whilst it is being developed. The result of this extra testing should result with us releasing solid, quality games which we can all be proud of :-)

New titles released for the ZX Spectrum

Over the last few days there have been several new games released on the ZX Spectrum!

Phaeton

A nice slow paced ( and tricky ) arcade game! Very polished ( I love the dissolving text effect ) which has the 'one more go' factor!

The game's programmer - Rafal Miazga - has kindly also made the source for the game available!

Forest Raider Cherry

A very polished looking 'Zelda' styled collect 'em up! I've not come across many games with this style on the Spectrum - maybe one day someone will take the plunge and make a Link to the Past styled adventure for the 128k Spectrum!

Sid Spanners

A nice little retro platformer. Brngs back some fond memories of earlier Spectrum games. It reminds me a lot of Manic Miner and also, for some reason, Eric and the floaters! Digital Prawn has also made the source code available for anyone wanting to see how Spectrum games are put together.

More Speccy happenings

Lots happening on the Speccy scene recently - the new releases on WoS of Binary created with Jonathan Cauldwell's Arcade game designer

I've not tried the Arcade game designer yet but back in the day I had spent many hours using S.E.U.C.K for the Amiga before learning to program in AMOS.

Work on Gloop Troops continues, we've now got some test data for the speccy so we'll be starting to put the final project structure together over the next few weeks. Hopefully we'll have some demos to download soon :-)

Concept pic + speccy news

With Gloop Troops 2 we're planning on having a bonus stage that is accessed when a level has been completed and the player has performed brilliantly.

The level has Pokey, or Peeky, running around trying to collect as many hearts as possible before time runs out. To make life harder for our intrepid heroes there'll either be a Squidgy or another enemy at the bottom of the screen throwing bombs upwards to try and catch our heroes out.

If the player gets hit by a bomb they'll lose 5 seconds off the clock and when the timer hits 0 they'll be sent to the next proper level. Hopefully this should give the game a nice amount of variety :-)

Also in Speccy news the Mojon Twins have released yet another game! More info on it can be found on The WoS forums

The making of Gloop Troops - Part 3

When we stripped the game mechanics back to basics we decided to give the player a regular projectile to fire. This avoided us having to design screens with large areas of vertical space ( to all throwing of enemies such as in Stackies or to jump on enemies heads ). Pressing fire would spawn a projectile which would travel in the same direction as the player. For simplicity ( and a bit of a challenge ) we limited the player to only having one of these projectiles on screen at a time.

We went with the idea of a player having to collect all the pick-ups on a level in order to progress to the next one. We'd had some code for pick-up collection left over from the adventure game and it seemed a good fit. Having to collect all the pick-ups forces the player to fully explore the screen and plan a route past all the obstacles. We wanted to maximise the player's time per screen as we were keeping with only having one screen per level.

When the projectile went in we first had it so that enemies were killed on collision with it. However removing enemies from the screen made each screen get progressively easier! As you shot at enemies and removed them from the map, the number of obstacles the player faced would also reduce. We debated on some alternatives, in particular the idea of having enemy spawners in the level. This would have spawned in a replacement enemy whenever one was killed. But this also had knock on effects to the screen design :-( More screen space would have to go to these spawners, which may not be active for much of a level's duration. The additional problem of getting the new enemies into a position where they blocked the player's path also proved to be tricky.

However the surprisingly simple and elegant idea of stunning enemies, rather than killing them came up as a way around the problem and provided a good challenge for the player. This meant that enemies would only be temporarily out of the picture, long enough for the player to get by, before they'd wake up and continue on their way.

The screen above used to be the first level in the game and was used when testing out all the above mechanics. It later became screen 7 in the final game.

The making of Gloop Troops - part 2

Disheartened by our failed epic game we thought it best to try going back to basics. We'd both recently seen The King of Kong and loved the idea of creating a simpler, action orientated game, but one with a scoring mechanic which allows experienced players to re-play old levels and improve their score.

We stripped back all the excess code to leave a simple core which read the joystick ports, loaded the map screens and displayed sprites on the screen. All our game code was written in Z80 assembly language, which allowed us to maximise performance, but came with the cost of being more difficult to manage. It was our first assembly coded project and had got a little spaghetti like as features were added, tweaked and dropped as the game was pulled in different directions. This had make making changes to the code during the adventure game's development very costly in time.

We started on a new game initially nicknamed Stackies. The goal of which was to simply clear each level of enemies by picking up an enemy ( in the same style used in Super Mario Bros 2 ), and throw them at another enemy. If the enemies collided and matched colours then the thrown enemy would sit on top of the hit enemy. If the colours didn't match then the thrown enemy, the hit enemy, and any enemies stacked on top of that hit enemy would be destroyed.

The mechanic was solid, but didn't suit a single screened game ( particularly a retro one with a small resolution ). The problems we encountered were that you needed lots of empty screen space to allow an enemy to be thrown, else they just ended up hitting platforms.

We debated on whether to make each level multi-screened or the enemies thrown in a straight line rather than in an arc, but these didn't feel as satisfying a solution. We were still disappointed after our previous failing and wanted to get the core mechanic developed quickly, fitting within the confines of the tech we had developed and the spec of our game. To make a game with single screen levels and an interesting scoring mechanic.

The making of Gloop Troops - Part 1

Before delving into our new game I thought it best to chat about our previous efforts :-) Gloop Troops was released at the end of April this year for the 48k ZX Spectrum.

http://www.worldofspectrum.org/infoseekid.cgi?id=0024831

Gloop Troops started out as a very different project back in 2007. Andy and I had been sitting in the pub discussing the joys of retro gaming when the idea of creating a brand new game on the Spectrum came up as a fun side project! We spent the what little spare time we had designing a Dizzy style adventure game, with elements of Exile and Monty on the Run.

We worked on it on and off for over a year, but without a clear vision on what we wanted at the start we ended up pulling the game in many different directions. Finally in mid 2008 we called the game to a halt after many code and tool re-writes ( including a pc version ).

After surveying the code wreckage we took a step back and started to come up with a new plan...