Thursday, 30 December 2010

New titles released for the ZX Spectrum

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


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!

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!

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.

Saturday, 25 December 2010

Vote for Gloop Troops and Crimbo!

There is a poll for best game of 2010 on the World of Spectrum forum! If you enjoyed Crimbo or Gloop Troops them please vote for them!

Friday, 24 December 2010

The making of Crimbo - Part 2: What went wrong

Whilst Crimbo - A Gloop Troops Tale has been a roaring success for us, and is something we are all immensely proud of, it still has a few tiny things we would of liked to have fixed.

Developing a game in such a small timeframe is tough, naturally there was always going to be unresolved issues with the game. It's thanks to the dedication of the whole team that we were able to push ahead and deliver a game we are all proud of.

Below are some of the issues with the final game we would have liked resolved. These will hopefully be resolved in our next title:

ULA "snow" on first release

Whilst we had tested the game on numerous emulators, we still fell foul of the ULA "snow" issue. This issue is caused by having an interrupt routine in the memory address range 0x4000 to 0x7FFF ( so the second 16k memory block on a ZX Spectrum ). We had integrated the Arkos tracker into our project to allow for AY chip music when running on a 128k model spectrum. To service the music we installed an interrupt routine at address 0x6161 which would be called once per frame on a V-Sync. Whilst this worked brilliantly on the emulators we tried, it turned out that this causes the ULA "snow" effect to occur onscreen. Once the issue had been identified on the WoS forum we were able to supply a quick fix.

As we now knew the final size of all our assets we were able to move all of our data to the start of memory, plus a little padding, so that we could install the interrupt handler at 0x8181. In future we will be able to avoid this issue, but there is no substitute for testing on real hardware :-)

Sound Effects

We initially wanted to have our sound effects also be played through the AY-3-8192 chip. Unfortunately we ran out of time to fully utilise the chip and instead used the Spectrum beeper for our sound effects. We used a modified routine from Gloop Troops to generate a few beeps ( player death and collecting a present ). The upside to this is that there are sound effects played when playing the game on a 48k Spectrum!

Just before the game shipped AJH was able to re-create the title theme using the Spectrum beeper. There was a brief chat about whether to release a 48k version without the AY music, but with beeper renditions of the music instead. This would have been a cool feature to have supported, but may not have added much to the game for the extra work involved. Perhaps in the future we may want to look into separate 48k and 128k versions of the game if there is demand.

Keyboard control / configuration options

Something we wanted was configurable keyboard controls. This was left until the last minute and then dropped as we were short on time. Our reasoning was most people would play the game on an emulator, so would be able to configure their keyboard however they liked to represent the joystick. Another issue is the jump on pressing the joystick up versus pressing fire. Our previous game Gloop Troops, like a lot of games of that era, used up on the joystick to jump. However a lot of forum feedback requested fire to jump ( perhaps this is better when playing on a portable emulator? ). Next time we will provide this option if the game allows.

Sprite flicker

One of the issues with our sprite system is in how the sprite being drawn will splatter over the background image. This is not a problem usually within the game as we have a single colour background. However when two sprites overlap there is noticeable flicker. This is something we'd like to reduce further in future games where possible. This might be done by using a different sprite draw call if a collision between two sprites occurs. Alternatively we may see if preventing sprite overlap is possible. We could, for example, have the sprites bounce off each other instead!

Overall we are very pleased with Crimbo and are eagerly starting work on our next game! :-)

Monday, 20 December 2010

The making of Crimbo - Part 1: What went right

Now that Crimbo has been out for a little while, it's a good time to look back over Crimbo's development.

The idea for doing a Christmas themed popped up in October. We had taken a small break from developing Gloop Troops 2, when Andy came up with the idea of doing a Spectrum game for Christmas! We loved the idea of a Christmas game but we had to act fast! With only two months to put the game together, we had to take a very critical look at what was needed.

We decided not to deviate too far from the Gloop Troops formula and would keep the game a single screen platformer. We we also wanted to use this opportunity to take the feedback from Gloop Troops and apply it to Crimbo where possible. We had previously toyed with the idea of releasing a Gloop Troops 1.5, but this had it's own problems ( to be discussed in a future post! ).

We narrowed down the scope of the game quickly. We kept with the idea of collecting pickups to clear a level, as it is a popular theme in Spectrum games, and is easy to communicate to the player. But with Crimbo we would remove the ability to defeat enemies. This would easily make the game alot tougher! We also knew we wouldn't be able to create many polished levels within the time limit, so instead we opted to only a handful of very tough levels. We took inspiration mostly from Manic Miner for Crimbo:

Like Manic Miner the game should be short and sweet. Also like Manic Miner we wanted to give each room a name to help give it some character. Before settling on having the player control Santa, we had toyed with the idea of the player controlling an Elf gone rogue! The working title for the game was "Elfish little b@stard" until quite late in development.

Andy had previously created all the levels for Gloop Troops, so was in the best position to create most of the levels for the game. We were originally going to have all of us chip in a few levels but this didn't end up occurring ( more on this in a later post ). Andy put a lot of time and effort on both the level design and look of Crimbo! With the results being both excellent and extremely well received!

Tech wise we didn't want to over commit on new features. With only two months to develop ther game, there woiuld be a high risk of trying to cram in a feature which would end up broken. major additions to the game's code was the snow effect used on the frontend, the new intro sequence and integrating the Arkos music player into the code base.

AJH has been working with us on Gloop Troops 2's design but this was his first opportunity to compose some music for the Spectrum! He did an amazing job with the short amount of time available, and really hit the ground running!

Next time we'll cover what didn't go to plan with Crimbo!

Wednesday, 15 December 2010

The Music of CRIMBO!

Hi everyone, AJH here.

It’s great to be releasing a brand new Little Shop of Pixel game, especially one spreading holiday cheer! We had such a great time making the game and I like to think it shows!

The guys have wanted music in a LSOP game for a while and CRIMBO was a great chance to test it out and when they asked me to put some music together for the game I jumped at the chance.

We knew we wanted something upbeat for the main game, something up-tempo, light and festive. With the many of mainstream Christmas favourites still under copyright we looked at seasonal traditional folk songs. The Sussex Carol just seemed to pop out and after a few different interpretations we settled on the version you hear in the release.

For the title screen I wanted something more atmospheric, something more ethereal even magical – and once the snow (not bug snow!) went in it just reinforced the vibe. At the same time it snowed here in the UK, so I sat watching snow in the game and outside the window - the game and reality in sync provided the perfect inspiration!

The music for the game was created using the fantastic Arkos Tracker. It’s been an extremely long time since I used a soundtracker program and it was my first time on the AY chip but Arkos is so intuitive, smart and clear that I had tunes running from the start. If you haven’t checked it out I highly recommend it. Great work guys, keep it up!

Finally, creating the music for CRIMBO gave me the perfect excuse to rediscover all my chip tune heroes, old and new. More on this in another post, but I highly recommend the excellent Modizer iPhone app. Chip and mod tunes on the move! We must be living in the future!


Crimbo's reception

We've spent the last few days excitedly reading all the feedback on Crimbo!

After many nights of quietly working away on Crimbo, it has been incredibly rewarding to read about other people enjoying the game.

Here are some of our favourite quotes over the last few days from the World of Spectrum forum!
"LOVE the way the game looks, the font, the graphics, just reminds me of a classic Bubble Bobble style game. Really liking this. Thanks very much."

"Just one more go...."

"This is fantastic! The loading screen is the best I have seen for a very long time - SO colourful. I love the game."

"Catchy, addicitng tune that Bubble Bobble wouldn't be ashamed of."

"I think it is fantastic that people are still producing such quality software for the Spectrum."

"Brilliant brilliant game, brings a smile to my face to have a Spectrum 128K game before Chrimbo, I feel like I just got a new Issue of Crash with this on the cover Graphics are beautiful, music on the title screen is so relaxing, almost hypnotic and yet strangey sad/remembering (in a good way like Gunrunner 48K tune)... "

"Got to level 3 on second go after reading to hold jump down, really love hard games, I´d have got the bus to Newcastle and payed 10 pounds for this back in the early 90´s... Thanks "

"Thanks for contributing something like this to the Speccy community - its a quality product!"

We will post up a postmortem on the game soon - and use the feedback to help make our next game even better!

Sunday, 12 December 2010

New game! Crimbo

We are pleased to announce our new game! Crimbo - A Gloop Troops Tale.

Help Santa save Christmas! Santa's helpers have gone and hidden the world's presents all over his home! Go Santa Go!

Saturday, 11 December 2010

New title imminent

Our secret game is close to being released! Our new game will be going live on Monday evening. We're testing the game over the weekend to make sure it's as bug free as we can make it before releasing it out into the wild.

Wednesday, 8 December 2010

Secret project

We've been taking a break from Gloop Troops 2 and instead been working on a secret little project this month. The game's now pretty much done and just having a few final tweaks before being released!

Sunday, 21 November 2010

New Speccy games released!

Genesis: Dawn of a new day

A top quality horizontal shooter from Retroworks. I'm still amazed at what people are able to get out of the ZX Spectrum!
The smooth scrolling and starfield effects are top work and it'd be great to know how they managed to push the machine so well. Smooth scrolling isn't on the agenda for Gloop Troops 2 but maybe it's something we'll have to investigate for another title.

Ghost Castle 2

The second title is Ghost Castle 2 - the sequel to Ghost Castle . This title feels more refined that the original puzzler, with some great sprite work and smooth animation - we're eager to see what follows!

Monday, 18 October 2010

Winter is fast approaching...

and what better way to spend the cold evenings than to make some retro games! We're still working away on Gloop Troops 2 and hope to have something special to announce before Christmas :-) Speaking of events we've got Halloween also just around the corner! Halloween is a great event to base a game around. I remember firing up Cauldron years ago, not knowing what to do, just flying around for ages shooting bats!

What's your favourite Halloween themed game?

Monday, 26 July 2010

Gloop Troops 2 additions: The bomb

We've been toying with changes to the Gloop Troops formula and in our PC testbed we've recently been experimenting with a bomb pickup.

We wanted a pickup which would reward the player for collecting it and to tie into the main scoring mechanic of trying to keep as many enemies glooped as possible. We did not want a pickup to take away from the score mechanic of chaining enemies or to destroy enemies.

Our plan for the bomb is to have it appear much like the fruit in the first game. It will materialise every few seconds and once it's collected by the player it will cause all enemies on screen to be shaken by an explosion!

As with glooping enemies it will check how many enemies have been glooped when the bomb is detonated and reward the player with a higher points bonus per enemy glooped than you would have earned by just glooping them.

However once all the enemies have finished being shaken by the explosion they will all return active to the game and be invincible for a second! This'll make the player think twice before collecting the bomb, and plan their path through a level more carefully :-)

Monday, 12 July 2010

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 :-)

Saturday, 10 July 2010

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

Monday, 5 July 2010

Work in progress - Gloop Troops 2

Here's a in-development screen shot of Gloop Troops 2! This is taken from our PC version test bed which we'd created so we can rapidly test out new gameplay ideas. In the screen shot above we have one of our new enemy designs being tested out, patrolling platforms above Pokey. The HUD also has had a lick of paint to help keep everything on screen fresh. Pokey too has been given a suit of armour to help defend him on his quest! All work in progress at the moment so don't take anything as being set in stone :-)

Monday, 28 June 2010

Working away....

We're still working through design ideas at the moment. Some of our key ideas revolve around how to fully use the 128k now available to us. Ideas for cut scenes and sub games are bouncing around as ways to help expand on Gloop Troops 2.

Also check out natami !
Could we be about to receive some new Amiga hardware?
Between this and the X1000 things are certainly getting interesting :-)

Like many programmer the Amiga was the first machine I learnt to program on. It would be fantastic to revisit the Amiga at some point and develop a new game. Amiga Gloop Troops perhaps?

Saturday, 26 June 2010

Compressing map data for the ZX Spectrum

Working on platforms with tight memory budgets like the ZX Spectrum requires some head scratching work on how to cram in as much data as possible into such a tiny amount of space.

One of the biggest potential uses of memory is storing map data. Whilst working on our ZX Spectrum project we had iterated through 3 different map formats! Below I work through these map formats, showing their pros and cons before describing the final format which we'll be using on Gloop Troops 2.

Format 1: No compression on tiles.

First of all we tried exporting data directly to see what kind of memory hit we would take. Our maps are 32 x 22 tiles in size, with each tile representing 8x8 pixels of screen space. This leaves a space 2 tiles blocks for the HUD at the top of the screen. Initially we stored all the tile data uncompressed but compressed all the tiles attributes using a simple form of run length encoding.

The way we stored attributes very simple. After all the tile data was written to the map file we'd write out all the attributes.. There is 1 attribute setting per tile block used in the map. We would start by writing out an attribute's value into the map file and then check to see if there were subsequent tiles which had a matching attribute value. If so we'd scan along the rest of the map counting the number of times this attribute occured without changing and write this number as a second byte after our written attribute value. If there were no matches ( so only 1 instance of this attribute before it changed ) then we'd set the FLASH bit of the attribute to ON. This is because we knew we'd never have any background tiles with the FLASH bit set as it tended to look ugly.

Example attribute data ( uncompressed ), 5 attribute tiles with the value 8 followed by one of 16, followed by 2 3's, and finally another 0x8:

0x8, 0x8, 0x8, 0x8, 0x8, 0x10, 0x3, 0x3, 0x8

Example of compressed attributes:
0x88, 0x5, 0x10, 0x83, 0x2, 0x8

So we've written out attribute our attribute 0x8 with the top bit ( the FLASH bit ) which changes the number to 0x88 ( 10001000 ). We've then written out the number 5, which is the number of times this attribute occurs, followed by attribute 16 ( 0x10 ) without the top bit set ( so the number stays as 0x10 ). We've then written attribute 0x3 with the top bit set ( becoming 0x83 - 10000011 ), followed by the number 2 ( as there were 2 instances of the number 0x3 in our uncompressed data ). Finally we have the number 0x8 as the last attribute, and there was only one instance of this in a row so no FLASH bit and counter byte set.

We also stored the width and height of each map at the top of the map file. This is because we'd envisioned having a variety of map sizes and could save some space.

The pseudo code for the map file was:
Width - 1 byte.
Height - 1 byte.
For tile_y = 0 to 21 do
For tile_x = 0 to 31 do
Tile_Id - 1 byte.
next tile_x
next tile_y
{ Attribute data }

The advantage with this method is each screen can look distinct as there are no rules regarding which tiles can be adjacent to another tile. But the big problem with this format is that whilst the attribute data compresses nicely the tile data still uses up 704 bytes, which is quite a bit of space on a machine with only 48k!

Format 2: Mixed - Tile brushes and custom tiles data.

This was the method used for Gloop Troops 1 and offered up a sizeable saving but still wasn't enough. We realised that a lot of the tile data tended to repeat throughout a map, so rather than storing each tile individually we could store a single "brush" which would store many tiles worth of data.

Example tile brush: This is a 3x2 Tile brush which stores 6 tiles worth of data.
[ 4 ][ 4 ][ 4 ]
[ 7 ][ 8 ][ 9 ]

We stored the tile brushes separately from the map data so that they could be used by several levels. Tile brushes were written out without attribute data and in the format:
Width - 1 byte.
Height - 1 byte.
For tile_y = 0 to brush_height do
For tile_x = 0 to brush_width do
Tile_Id - 1 byte.
next tile_x
next tile_y

Our map format changed to:

Width - 1 byte.
Height - 1 byte.
Num_Tile_Brushes_Used - 1 byte.
For tile_brush_id = 0 to Num_Tile_Brushes_Used
Tile_Brush_Id = 1 byte.
Tile_Brush_X_Pos - 1 byte.
Tile_Brush_Y_Pos - 1 byte.
Next tile_brush_id

For tile_y = 0 to 21 do
For tile_x = 0 to 31 do
if ( tile_is_not_part_of_tile_brush )
Tile_Id - 1 byte.
next tile_x
next tile_y
{ Attribute data }

This meant we'd write out all the tile brushes first, then for any parts of the map which weren't covered by a tile brush we'd write out the tile data. We also did a simpler compression to tile 0 as what we did with attributes. If we wrote a 0 as the tile ID then we'd write a second byte indicating how many tile 0's to write out. This is because tile 0 represented blank space on the map, and there would typically be many of these in a row.

The advantage of this method meant that we could cover most of the map with a few tile brushes and then touch up areas with a few individual tiles. The compression on this was a lot better but still not fantastic.

Format 3: Tile brushes only and flood fill attribute.

This is the method we'll be using on GT2 - we'll be ditching the concept of individual tiles and purely using tile brushes. By default our screen will be flood filled to a particular attribute ( and tile 0 ) and tile brushes will also now store attribute data. The attribute data will still be stored in a simple run length encoded method inside the tile brush data.

Width - 1 byte.
Height - 1 byte.
Default_Attribute - 1 byte.
Num_Tile_Brushes_Used - 1 byte.
For tile_brush_id = 0 to Num_Tile_Brushes_Used
Tile_Brush_Id = 1 byte.
Tile_Brush_X_Pos - 1 byte.
Tile_Brush_Y_Pos - 1 byte.
Next tile_brush_id

We found that this now gives a far superior compression for each screen for some sacrifice of flexibility ( which we found we'd hardly used ).

This should mean less space wasted on storing map data and more space dedicated to graphics, game-play and sound!

Thursday, 24 June 2010

Making music

Currently playing around with the new Arkos Tracker

Only had a brief play with it but so far it seems like a lovely piece of software! Hopefully we'll be able to use it to put together some tunes and sfx for Gloop Troops 2 :-) Now all we need are some musicians...

Tuesday, 22 June 2010

New Speccy Releases from Other Developers!

Trooper:Point 5!

Looks to be a pretty solid game that reminds me a lot of JetPac, I quite like the shadowy effect underneath the platforms.

Full info can be found at World of Spectrum

Monday, 21 June 2010

Gloop Troops 2 - The wish list.

Now Gloop Troops is out the door we can take the time to see where we can improve the original game! Below's a list of features we'd love to include in the sequel:

* 128k Spectrum - by targeting this machine we'll be massively increasing the amount of RAM we'll have to play with! There looks to be a bit of a learning curve on using memory pages effectively which hopefully won't throw us off too much.

* Music - we had problems getting music into the original game, targeting the 128 and getting some AY music in should solve this brilliantly.

* Bosses! We wanted to have an end boss originally but in the end dropped it. It'll be great to go back to this idea and maybe have a few bosses every few levels?

* Power ups - Always a blast to collect in any game and missing from the original. We'll have to think up something fun for these :-)

* Cut scenes - We had 2 levels in Gloop Troops where we displayed some text above the action. We'd love to work on this more and have some more personality to the characters!

* High score table - Missing from the original, we only displayed a single high score. Having a high score table will hopefully add to the competitive nature of the game.

* More enemy types - there were a few enemies dropped from the original due to time and memory restraints. That shouldn't be a problem any more :-)

First up for coding will be the music system...

Sunday, 20 June 2010

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.

Friday, 18 June 2010

The making of Gloop Troops - part 4

Other elements started to make their way into the game in order to provide a sufficient challenge for the player. A timer was added to the game, first set to 20 seconds, but that caused new players to the game to struggle completing even the starting screens. With only 20 seconds on the clock, most players ran out of time whilst still watching the enemy patterns and planning their route through the level. The idea of having a brief pause before the level starts, displaying "Get Ready!" over the screen was discussed. This would have allowed us to keep a tight time limit to complete a screen ( as the player could see the level ahead and plan their actions ), but was dropped due to complications. In a sequel this idea would hopefully be revisited and implemented correctly.

In the final version of the game we gave the players 30 seconds to complete each stage as a compromise between allowing them enough time to figure out what to do and to execute their plan.

Using the timer we decided to spawn a bonus points giving fruit pick-up ( inspired by Pac man ) every 10 seconds, giving a maximum of 2 pick ups per level. This tied in nicely with other games spawning a reward the player could grab, at the risk of leaving any safe zones of the screen they might have found. It would have been more ideal to have this tied to the player performing an action, such as having glooped all the enemies on screen.

An element that went late into the game was spiked platforms. Previously the player could freely jump up and down platforms, easily avoiding enemies. Spikes were added to create more threatening platform sections and channel the player through certain parts of the map. They also make the player feel more uncomfortable when jumping over gaps ( as failure now costs a life ) and add a sense of danger to the screens.

Invincible enemies were added around the same time as spikes to create moving obstacles for the player to avoid. These, unlike the spikes, would require the player to time their actions to avoid colliding with them. Originally these enemies were going to be a particular colour, but it was difficult to communicate their invulnerability to the player as we were using a range of colours for the enemies already. A neat solution was to cycle the colour used on invincible enemies. That way they stood out easily when the player glances at the screen, and separated them from other enemies.

Wednesday, 16 June 2010

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.

Tuesday, 15 June 2010

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.

Monday, 14 June 2010

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.

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...

Sunday, 13 June 2010

New blog

Here's the start of a new blog charting the development of our next title Gloop Troops 2! We're hoping to share lots of info on what goes into making a new game, post up in development screen shots, code snippets, and other assorted bits of retro gaming joy!