Playing Humanoid (Atari 8-bit)

Despite the house currently being in chaos and the room I use as an office having been dismantled there’s still been a little time for some gaming recently. So I’ve been playing Humanoid on the Atari 8-bit, a scrolling shoot ’em up released in the early 1990s. The gameplay doesn’t really offer much in the way of frills, just seeing the player guiding their craft through increasingly narrow spaces in the landscape whilst avoiding contact with enemies which drift across the screen, occasionally changing speed to make things more difficult.

There are also destructible walls to blast a path through and laser gates which need to be temporarily disabled by shooting the nearby control units, so the player has quite a bit to keep an eye on which can rob them of a precious life. At the end of each level is a boss stage where a static mothership sits on the right side of the screen and peppers the player with bullets; this repeats but doesn’t seem to change in difficulty as the game progresses, but dying doesn’t have an effect on the lives counter and it’s worth slogging through for the cool explosion and extra ship awarded at the end.

The backgrounds and player sprite might look familiar to C64 gamers because they were lifted wholesale from Hugh Binns’ budget blaster Subterranea – even the code for decompressing the backgrounds seems to have made it across – whilst Mirax Force on the Atari 8-bit seems to have donated its enemy sprites to the cause. This “borrowing” of assets for a commercial title has happened a few times on the Atari 8-bit and I’ve previously spotted graphics lifted from Lethal Zone, Task 3, Uridium, Tangent, Hawkeye and Stormlord (the latter two used by the same Atari game, Hawkmoon) amongst others. Here’s what Subterranea looks like for reference:

And, although there are other games like Astromeda which work in a similar way as regards in-game sprites, Humanoid presumably looks to Mirax Force for inspiration on that front too. In this case the player craft is using two players and all four missiles to build a twelve pixel wide object, leaving just the two remaining players for all of the nasties so only one of them can exist on a horizontal row with the player and everything just moves right to left without any changes to the vertical position to avoid conflicts. A few people these days seem to feel that the limitations make this technique somewhat “cheap” but it’s a good starting point for a newly-minted coder at least and can still make for a fun to play game.

The game is does have some issues though; there’s what appears to be either a bug – or potentially a fault in the cracked version online – which will occasionally cause the player’s gun to “jam” for short a while and the collision detection is stricter than Subterranea too so getting through some of the already tricky-to-negotiate gaps is more difficult. Enemy spawning also seems to be random as do the speed changes made whilst they travel across the screen and the sudden changes in speed; that’s not a bad thing in itself but makes avoiding obliteration even harder, especially since the exploded ships continue moving and explosions are also fatal.

Humanoid is an average shooter but one I’ve always had fun with personally, although I possibly wouldn’t recommend it to anyone not looking for a challenge since it doesn’t take many prisoners on the difficulty front and some of the deaths can be pretty cheap, even more so than the game it lifts elements from. With a little tweaking it could’ve been less frustrating to play and some bespoke graphics probably wouldn’t have gone amiss as well, but what’s there is still worthy of at least some attention.

Workprint – December 2017

Keeping with my “schedule”, it’s the first Friday of the month and time for a quick update… and yes, I’m as surprised as everybody else that this turned up on time!

Rubidius is slowly taking shape, it completed its first proper loop – going titles page to game and back with or without passing through the completion screen with the presentation stuff mostly being placeholder code – yesterday and I’ve got the score counter in and a test version of the music Andy is working on playing in the background. There’s nothing new to show right now because it doesn’t look much different to the previous screenshot, but some proper level graphics have been started and, once I get a certain writing deadline out of the way, I hope to find a few days to draw and install some actual backgrounds.

There has also been some pondering over the idea of writing a C64 game for C64CD in part as a demonstration of how easy it actually is; since scrolling shoot ’em ups are my default state it’ll almost certainly be one of those, but trying to keep things as simple as possible to the point it’ll essentially be a more primitive but tile-based version of Warflame. I have a few interesting ideas about “features” and the thought of publishing it in some form is amusing (to parody a certain person’s suggestion of Kickstarting a book based on his blog) but most of those options still need feasibility tests and bespoke code. This might also end up as the final resting place for the tiles that’ll soon be pulled from Rubidius as well.

Workprint – November 2017

I’ve decided to try a few little changes around here; for a start I want to stick to a schedule (goodness, I used the S word and it almost looked like I meant it too!) so from now onwards all workprint posts will appear on the first Friday of a month like this one is doing. That probably doesn’t sound like a major shift to most people but, as certain editors will no doubt attest, I’m a teensy bit rubbish with deadlines and even worse without! At some point over the “festive season” there’s going to be a few other changes too, but those are still in what I’m rather euphamistically referring to as “the planning stages”.

As far as programming goes, the scrolling shoot ’em up Rubidius in progress for the Hex Files rewrite is coming along slowly but surely with the most recent feature added is the subroutine that preps the engine for the start of a level; previously it was hardwired to just one map and block of attack wave data but now it deals with multiple levels correctly… although that wasn’t the case for several hours! When the new routines went in last Sunday they worked fine with the first level but would start doing bizarre things that should have been impossible during the second, including glitching entire tile rows. Remember kids, always keep a track of your “set in stone” subroutines because sometimes…

In this case the background scroller spreads the load out over eight frames and a couple of missed RTS commands (which I suspect were left out when the colour scrolling was added to previously empty “slots”) meant that, along with the update that was meant to happen on a specific frame, one of the other routines would be called out of sequence as well. I have no idea why the problem only manifested on the second level map though…