From Retrosoftware

Revision as of 22:13, 27 August 2011

Hard Hat Harry 2 by Tom Walker

Licence

Non-Profit Commercial

Introduction

Hard Hat Harry 2 is a massively expanded sequel to the original platformer, for the BBC Model B and possibly the Electron. Development started in June 2011, and it is due for release at the end of September.

It was demoed at the In Da 80s show in Manchester in July 2011.

Discuss Hard Hat Harry 2

Features

• MODE 2 graphics
• 64 screens
• A selection of returning and new enemies
• Puzzley bits

Screenshots

Hard Hat Harry 2 title screen Posted: Jul 27, 2011	Starting out Posted: Jul 27, 2011
Exploring the caverns Posted: Jul 27, 2011	Locked door - but where's the key? Posted: Jul 27, 2011

Development Diary

30 July 2011

Had a bit of a play with the map data format today. Started out with 25 screens taking 2187 bytes.

HHH1 used a simple form of RLE on map data. In a single byte, bits 0-3 gave the tile number (a total of 16 tiles, though only 10 were used) and bits 4-7 gave the count. Due to an oversight this count was 1-15, though 1-16 should have been easily possible.

HHH2 is based on this system. However it is less efficient as there are now 32 tile types, all of which are used! This means 5 bits are used for tile type, and only 3 bits for count, giving 1-8.

In order to improve efficiency tile type $1C (one of the keys) has been given a double meaning. $1C with a count greater than 1 is interpreted as tile 0 (air) with a count of 9-15. This addition knocked nearly 200 bytes off the total, going down to 1995.

Today's main work has been to counter another problem. The 'earth' uses a collection of 10 tiles and tends to compress badly, as the runs are interrupted by changing from one earth tile to another.

The solution was to reduce all the 'earth' tiles to a single tile, $0F. This is processed by the compressor and leads to much better compression. Then the map draw routine processes all earth tiles, based on the surrounding tiles, and draws the correct image.

This change took a few attempts to get right (I reused the routine used for map collisions, and had quite a few issues with temporary variables being reused), but the end result is the map data down to 1444 bytes (a 551 byte, or 28% saving) and an overall saving of 454 bytes. Not too shabby! Quite a bit more work to go though, especially as there are another 39 screens still to be added!

3 August 2011

Broke the halfway mark, 39/64 screens now exist. Some redesigning will probably be done before the game's over though. I've got a better idea of how the cavern fits together now.

Also did some work on enemy handling. In both HHH games enemies are defined using a compact 3 byte structure :

Byte 0 - X and D1, or $FF for end of list
Byte 1 - bits 7-3 = Y
            bits 2-0 = type
Byte 2 - bit 7 - direction
            bits 6-0 - D2

D1 and D2 are 'type specific' but are usually start and finish X coordinates. Type is simply what sort of enemy, eg 1 = bird, 2 = monkey etc. On entering a screen this is expanded to a structure in low memory (page 7 at the moment) which has room for 16 enemies per screen.

After this a per-type function is called each frame for movement, then a generic function handles collision detection.

In HHH1 there was an exception to this - Big Kong. BK used some global variables to handle the tracking of barrels. This worked simply because there was only one BK per screen.

A new exception has had to be added for HHH2 - the Hyper Viper. HV consists of several sprites, moving along the bottom of several screens. In order to keep track of this, his location is entirely held in global variables, and a completely separate function has to be called so he moves correctly even when off screen. Each of his 'segments' have to be separately tracked (which makes him not really a viper, but he looks good) - I originally tried to have the segments calculated based on the location of his head, but this caused problems when he was only partly on screen.

With the constraints of the existing sprite engine, this took a few attempts to get right - but he now works quite well methinks (he's certainly a better way of blocking of an area than just another door + key). The only tradeoff is minor slowdown - when all 6 segments are on screen, processing takes longer than the normal 2 frames and you get minor slowdown and flicker. Worth it though I think.

Another change is to allow for vertically moving enemies - reusing the bird sprites in this case. This just means having another enemy type, where the X and Y coordinates are transposed. Just changing the drawing routines means that the existing (horizontal) movement routines can be reused.

17th August 2011

Took a little time off to work on other projects, but back to HHH2. Today's addition is switches. These are used to turn on/off conveyors, to move objects (maybe) or to make areas more/less accessible.

Each switch is an enemy type combined with tile $B. The tile is merely to stop Harry walking through the switch. In order to track switch states, D2 in the sprite structure has been used as a zero page address (though only $00-$7F due to the top bit having a different purpose) containing a switch state. These are used to enable/disable palette animation in the vsync IRQ handler. There is an exception (as ever!), for the master power switch. Messages pop up on screen when enabling master power, or when trying to enable a conveyor when power is off, so that the player doesn't have to rush back to the instructions to see why pressing switches isn't doing anything.

Note, however, that while having the power on enables conveyors, it might enable some other, less helpful, things as well...

19th August 2011

Implemented boulders today. These follow conveyor belts (Harry isn't strong enough to push them) and form something of a puzzle element.

Also juggled memory about a bit. Tiles are now in low memory (below $D00) which leaves about 1.6kb free. This should be just about enough memory for the remaining 25 screens - in theory anyway...

26th August 2011

Another 9 screens, 16 to go. Nearly there... And nearly out of memory. Again. Why did I insist on writing this in MODE 2?

27th August 2011

Another 7 screens done, and most of the game done now. Remaining screens are for after the final door and for the boss! Only 200-odd bytes left so some serious memory-saving needed!