The making of Gloop Troops - Post mortem

What went right:

* We managed to finish a home brew project! :-) We all start lots of mini projects in our spare time, and very few of these ever reach completion. We were both very proud to have seen one through to the end.

* Re-playability - Once the scoring mechanic was in we found that it made each level playable in multiple ways. The player could rush to the end collecting all the starts, or plan how to keep as many enemies glooped as possible in order to maximise their score.

* Great art work - a big thank you to Andy who stuck with the project in all it's guises and delivered some fantastic artwork for the game. He was able to work with the limitations of tghe spectrum, colour clash and all and deliver something which is brilliantly styled and makes each level easy to read at a glance.

* Tools - having written our own tools for editing levels, compressing level data and converting images files to a Spectrum friendly format allowed us to maximise what we could do with the platform.

What went wrong:

* The difficulty curve was too gradual, most retro gaming players could easily get to around level 15 without breaking a sweat before hitting the tricky levels. Our initial play testers were all friends and family who perhaps in hind sight may not have been the best candidates for testing. The reason for this is Gloop Troops is a very hard core retro game at heart and should have been tested by a more hard core games playing audience.

* Sound & music - this was something we only added late in the day. We had not been playing other Spectrum games and missed that the audio bar was much higher than we remembered :-) Next time we may target the 128k Spectrum and make use of the AY sound chip.

* Scoring mechanic was missed by a lot of players. We were going to display sprites over glooped enemies to show the amount of score you'd earned by glooping them. However this information was lost to the players we found as as this feature didn't make it in and a lot of players missed the score in the top right flashing. Next time we'd like to focus more time and memory on highlighting the player's achievements.

* Writing the game in assembly was time consuming. This had been done to maximise performance out of the limited hardware, but instead we could have used a C compiler such as Z88DK and rolled our own sprite and collision routines in assembly.

* Continuous experiments - whilst beneficial to the overall quality of the game, each new feature we added took around a weekend to implement, test, tweak and then decide if it was worth keeping or not. For future projects we've chatted about the possibility of creating a PC version to test game-play ideas before finally porting them to the target platform.

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.