Bob’s Fury Update: Bug Squished!

For quite some time I’ve had a very nasty bug in my game, where basically it would lock up whenever a sound was played through any sound device on my microbyte 386sx machine. What made this bug tricky to fix is that it worked perfectly fine on other hardware I had available and on the emulation I was using for testing (which was Dosbox).

I had already discounted any results from Dosbox, as it is widely known that the emulation is not hardware accurate. So I tested on the hardware I had available. Unfortunately I don’t have a lot of old 286 and 386 machines laying around, so I tested on the Microbyte 386sx and my Pentium MMX system. The big clue I got from that is that the sound code worked fine on the Pentium but not on the 386.

This is where I was stalled for quite a while, I tested much of the code and couldn’t figure out the fault. What I needed was another 286 or 386 machine to be sure it wasn’t just a quirk of the Microbyte, but this wasn’t something I could do easily. Recently I found an alternative solution that helped me solve the problem.

I have been watching some of Jim Leonard’s videos, as he makes some really good content about PC’s and is generally extremely knowledgeable. He had some of the same sorts of issues with developing DOS software using Dosbox for emulation, which is why he tends to use real hardware where possible. However he did recommend a PC emulator I hadn’t heard of called 86box.

So I downloaded 86box and fired it up. I was able to set up a virtual machine fairly quickly and found I could change some key configuration options I would later need. Most importantly I could replicate the crash in the emulator and experiment to find the cause.

Knowing that some aspect of the hardware configuration was causing the crash, I changed the configuration of 86box until the game didn’t crash, the key element turned out to be enabling the NPU. With it enabled the sound code worked a treat even on an emulated 386 system.

The reason for the crash, whilst difficult to work out, is actually quite simple. I have an interrupt hooked on $1C for playing sounds of any type, during the interrupt it would figure out the length of the next sound in timer ticks. This would use some simple floating point arithmetic.

Because I had configured the pascal compiler to use 80287 instructions and included emulation for when a NPU isn’t present the code would crash during the $1C interrupt. This would happen because of how the NPU emulation works. If a 286+ CPU encounters a floating point instruction and there is no NPU present it fires an interrupt, which redirects to the software emulation.

The problem plays out like this: In the main code there were some floating point calculations, these would use the emulation which could then be interrupted by more code also needing the NPU. This would mess up the internal state of the emulation causing a crash. This can’t happen with a real NPU because it can’t be interrupted mid instruction.

The solution was fairly simple, I turned off 80287 instructions and emulation and made minor adjustments to code so as to not require it. This got it working on real machines without a math-coprocessor and in 86box so I was quite pleased. I’m not entirely sure why I had used the 80287 code generation in the first place, but I can see why it persisted in my code for so long. Many of the machines I had tested on over the years were 486+ class computers, these all have the co-processor built in, so the problem wouldn’t appear. Dosbox didn’t expose the bug because there is no configuration option for turning off NPU support.

There is more work yet to do, such as implementing a lookup table to save on some of the calculations, and fixing other bugs. I’m now automatically packaging a download based on my most recent subversion revision which you can find here. I’m thinking about eventually hosting the binaries and code on somewhere like github.

Neut Tower for DOS

Today’s game was made by SpindleyQ starting in 2018 releasing a shareware episode in early 2020. It is an EGA puzzle game that would have fit right into the shareware gaming scene in the late 80’s and early 90’s. The author took on an unique challenge, doing all the development on a 286 machine without using any tools created after 1992.

They used Borldand Turbo C which was a very popular language at the time, and used that to make almost all the tools they used for producing the game. In a way this makes it feel much more like a game from the era, everything you see could have been genuinely made at the time.

The graphics are in EGA, and uses the Borland Graphical Interface (BGI) as an engine for drawing to the screen. Whilst not super fast, the BGI is good enough to make this game run smoothly and animate well. The graphics style is well put together, colourful and animated smoothly.

There is some basic sound support for the Adlib card and the PC speaker, I used the Adlib support and I thought the sound is perfectly reasonable. There isn’t any music and there are some simple sound effects for most events in the game.

The controls are fairly simple, basic movement controls, a key to activate switches, a key to activate your companion, and a key to switch which character you are controlling.

The games starts with Jaye sitting at her desk when an earthquake hits. The building becomes quite damaged and she gets trapped in her office. She then activates Neut, an AI program that she has been working on. Jaye is able to move through the real world and interact with switches and turn on terminals whilst Neut can only travel through the network cabling in the walls and use powered on terminals as teleporters to access and hack security devices. Your goal is simply to escape the damaged building.

Along the way there are snippets of story mixed in with the puzzles, and both are generally done exceptionally well. There are companions to find and help, and terminals to interact. Although there is some mild coarse language, it’s not over the top, and isn’t really all that bad. Keep an eye out for clues, one puzzle I did had clues in the boss screen, not somewhere you’d usually look!

Neut Tower is a compelling and interesting puzzle game. The available shareware episode is a bit short at only 6 levels, but they are very well designed and fun to play. On the authors website it says this is still in development, so there may be more content yet to come and the possibility of some registered episodes. You can download it and support the author on their website.

Solder Runner for DOS

Today’s game, Solder Runner, was made by Sumware Software back in 1996. This is notable as it’s after the release of Windows 95 and was in a time of decline for games development for DOS. It’s kind of like Paganitzu, Chaganitzu, God of Thunder or Bloxinies, except the puzzles span multiple screens. It comes with a level editor and three episodes, although the third episode appears to be incomplete.

I originally tried playing this in Dosbox, but it seemed to cause issues with the game such as only being able to play the third episode despite selecting the first one to play. So I fired up an old PC, to run the installer you need to be running windows9x (or better), but once installed the files can be copied to a pure MS-DOS machine. In this case I copied the game to the old IBM thinkpad laptop and captured images and video using my epiphan capture device.

The game appears to use high resolution VGA graphics (640x400x16), which for the most part aren’t bad. I noticed that a few digital photos of circuit boards were used in places, which is interesting, but the images appear to be a bit noisy where they are used. Other artwork such as the tiles and sprites are reasonably well drawn, although it isn’t clear what the functionality of some items are just by looking at them. However you’ll learn what they are fairly quickly.

There is supposed to be some digitised sound, but I couldn’t get it to work for me. The standard PC sound isn’t too intrusive or annoying, so it’s acceptable in this case. The controls take a little getting used to as you need to press a direction key twice to move a space  when changing direction. It’s annoying at first but you get used to it.

The game is divided up into three episodes, each episode is one large level consisting of many screens. Puzzles vary in size from simple ones that fit in one screen to much larger puzzles that require back tracking or retrieving keys or solder beads. The very first large puzzle on the first episode has you circle around the same screens multiple times before you can collect everything you need and move on.

The static hazards are much like those in similar games. Some shoot at you and others block your path or offer a small puzzle element. Keys may be required for progression at times and you’ll almost certainly have to back track at times. This can make things a little tedious as screens do not reset, so you can end up traveling several screens with basically nothing to interact with when you return to fetch something you need.

The enemies are quite different to what you’d find in similar games, they represent different types of computer virus in the system. They move quite erratically, in a semi-random fashion that makes them difficult to shoot and predict. I think this has made it harder to implement good puzzles involving them, if they had a more predictable logical behaviour that differed depending on the enemy type then you could base some puzzles around them. Much like those you’d find in similar games. As it stands they are more of a nuisance that you have to avoid or shoot.

Apart from issues with dosbox there are some game mechanics that may cause you problems. Diodes in the level only allow you to travel through them in one direction, you’re automatically pushed in that direction if you move onto one and they are often laid out in chains. Your controls are not disabled whilst this is happening, and you can attempt to move or shoot whilst the diodes push you to your destination. This can result in you glitching into a part of the level you’re not prepared for, so best to keep your hands of the keys whilst moving through a diode chain.

Solder Runner was reasonably fun to play, but it has some flaws. It does do multi-screen puzzles reasonably well, just other games such as God of Thunder in particular do it better. It feels incomplete and unpolished in many ways, which is confirmed by the third episode, which has barely any content and is clearly incomplete. Bellow is a video with some commentary and game play.

Daymare for DOS

I found today’s game whilst playing random shareware I found on my F19 CD. Daymare is a dungeon crawler made by Jim Todd, originally it was made for the Atari ST, but was later ported to DOS in 1992. It was released as shareware with a sequel eventually being made.

The graphics are in VGA and are reasonable for the most part. It’s not as pretty as a more professionally made game such as Eye of the Beholder, but the dungeon is rendered quite well and the other artwork works well enough. There wasn’t any sound to speak of.

At first when I started playing the game I didn’t have much idea about how to play. It’s controlled entirely by the mouse so it wasn’t too difficult to figure stuff out, even though much of what you need to know isn’t in the instructions. There is a cluster of controls arranged in a grid of 8 buttons, and a section for storing and equipping items. Basic movement and attacking were easy to figure out.

Using items was a bit trickier, but I did figure out how to do it. For food items you pick them up with your mouse and click the item on the mouth. Most food items disappear, but the vials of water leave an empty vial after consumption. You can fill these empty vials at a well such as the one found in the starting area. Other items, such as the scrolls and the bag of holding need to be in the right hand slot of your inventory, clicking the diamond (with out starting a spell) uses the item.

Spells are cast by clicking the symbols around the diamond in the correct sequence for the spell, then clicking the diamond. The spells are revealed by hints left throughout the level, such as a readable item that tells you the softens spell. Signs and other text around the levels will provide other hints.

The game starts you out in a little courtyard with a few items around on the ground. You’ll find some water vials, some treasure, healing scrolls and a weapon. The treasure seemed pointless at first, but I found out that you gain experience (and levels) by putting it in the well. The water vials are quite useful as they restore some health in addition to thirst. Since they can be reused they are one of the easiest ways of restoring health. You’ll still need to find food to fill your hunger.

The first enemies I encountered were some worms and attack dogs that were tougher than they looked. It really helps to use the softens spell, as it increases your resistance to physical damage. You’re quite vulnerable at level 1, so I died a few times before I leveled up, but after that I only died if I had bad luck or went somewhere I wasn’t ready for yet.

I’ve played for a few hours so far and feel like I’ve only really scratched the surface. So far I’ve explored most of the first level and managed to find the bag of holding in a hidden section. There is a locked door I haven’t found any keys for yet and a section that kills me quickly, so I’m guessing there are some parts I’ll have to come back to when I’ve leveled up and found some keys.

I quite enjoyed playing Daymare once I got over the initial hurdles. There are a few quality of life issues, such as only having one save slot, not having an auto map and being forced to quit the game every time you die. However I still think it’s worth a download and play. I found the sequel on the authors website, however this version wasn’t available there, if you want to give it a try you can find it on dosgames.com.

This slideshow requires JavaScript.

Bob’s Fury Update: Bug Hunting

I’ve been doing some coding on Bob’s fury lately, basically making adjustments and making code faster in the hope that I could make it work well on a 286 class machine. I have been using dosbox to develop and test, but this doesn’t fully test the compatibility or stability of software as dosbox has its own quirks and does not behave exactly as real hardware does. This is where my old Microbyte 386sx computer steps in, here’s a photo from when I first bought it.

It has been very useful for performance testings as it has a turbo feature that is software controlled. You can not only toggle the CPU speed with a key stroke, but you can set the slower speed in the BIOS configuration. This has allowed me to test with the machine running at its stock 20Mhz as well as a slower speed, I’ve used 10Mhz for my testing as a rough equivalent of many 286 machines. The testing I was able to do has shown that my game should be playable on a 286 depending on the video mode. CGA and VGA both have acceptable speed for game play, whilst EGA is marginal.

The testing did however uncover a rather annoying and difficult to squish bug. If I have the sound turned on (PC speaker is all this machine supports) the system will freeze when a game event that plays the explosion sound happens. Hunting bugs such as this are difficult as there is little feedback about the potential causes. It sounds like the code supporting the PC speaker should be at fault, so that’s where I began the search for the bug.

For the PC speaker I found a support library many years ago that allowed you to use the music macro language used by the play statement in GWbasic and QBasic. It hooks interrupt 1Ch (the system timer interrupt) to update the state of the PC speaker. Whilst I haven’t had any previous issues I wondered if there was a fault that could cause the crash. At first I wondered if using floating point instructions could have been the cause. The library has a small section using floating point to determine the number of ticks a note should last. On a system such as the 386sx without a FPU such instructions cause an interrupt so that emulation in software can take over. This interrupt within an interrupt was what I thought may be the cause.

So I constructed a test program hooking the same interrupt and performing a series of floating point calculations as a test, this didn’t yield the result I’d hoped as the test program worked fine. So I then wondered if the 386 was getting another type of problem that would cause an unwanted interrupt. So I copied sections of code from the library into the test program to run in a normal procedure that would show run-time error messages and debug information I could use. No run-time errors appeared and the results of the required calculations appeared to be correct.

I have a few ideas left to test, but I’m left with quite a puzzle regarding the cause. This does illustrate the need for testing on actual hardware, it’s usually better to test on many machines. Unfortunately I don’t have a large supply of 286 and 386 class machines, although I have a few I may be able to repair. I need to test on another machine because there could be something specific in the design of the Microbyte machine that isn’t compatible and is causing the issue.

Bloxinies and Bloxinies II for DOS

One afternoon I had a bit of spare time, whilst looking around the doshaven website for something to play I ran into two simple puzzle games. Bloxinies and it’s sequel Bloxinies II. These were both made by Sebastiaan Jansen (also known as Thandor) in 2013 and 2016 respectively.

The first game is much like Paganitzu in many ways. Your character, Bloxinies has gone through a gate into a puzzle realm. It has to collect all the diamonds in each level before it can move onto the next, eventually to be able to return home. The levels contain hazards similar to those found in Paganitzu.

Technically the game uses CGA graphics and some basic PC speaker sound. The graphics are fairly well drawn for CGA, although there is basically no animation. Whilst it’s basic, the simplicity works with a puzzle game like this.

I found the levels a bit simpler than those in Paganitzu, but still quite challenging. The only thing that was annoying is running out of lives and being sent back to the start of the game. To make progress it’s important to conserve your lives as best you can, so when you return to a point of difficulty you have the best chance of success.

This slideshow requires JavaScript.

The second game is a much improved version of the first. Some new features have been added such as a few new enemies, gates and levers, the ability to use bombs, and extra lives. Notably there is multiplayer with a special set of levels. Each person has their own controls on the same keyboard.

There have been some technical improvements as well, mostly in the graphics which now supports VGA. Appropriately there is a significant improvement in the art, there’s more variety in the blocks that make up the walls in addition to the new features, making it more pleasing to look at. The sound system appears to have remained the same, retaining PC speaker sound.

The levels are more complex due to the new features, but at the same time have a shallower learning curve in the sequence. I feel like this is because the designer had more features to explore before increasing the difficulty. This gave me a bit more time playing before I hit any major road blocks, which were more punishing because of the lives system being carried over from the last game. Levels from the first game are included if you wish to play them with the improved graphics.

This slideshow requires JavaScript.

The only real complaint I have for both games is the lives system, which I feel doesn’t really belong in a puzzle game. Otherwise I quite enjoyed playing both of them. I didn’t get a chance to dive deeper into the multiplayer aspect of the second game, what with lacking a second player, but it does certainly look interesting. If you’re looking for a download you can find it here on the authors website. He’s included the source code for each game and a means for editing levels if you so desire. I was pleased to see it’s implemented in pascal, mostly because I use it myself for my own DOS projects.

Some DOS Games for the IBM PC

The early IBM PC was not really all that good at playing games, it was after all primarily designed for businesses. Despite this many developers did make games for them, although they were typically very limited by the capabilities of the PC. I didn’t get to play any of these older games when they were new, mostly because I was quite young, but also because we got our first PC in 1990. Being a 386sx @ 20Mhz it wouldn’t play most of them.

Because many of these older games are simpler and shorter I’m rolling up a few of them into a single post. The games for today are Bowling, Hardhat Mack and Moonbugs.

This slideshow requires JavaScript.

Bowling is a simple text-mode ten-pin bowling game. There’s not really a whole lot to say about it. After you enter a number for the game speed, the number of players and their names it jumps straight into the game. The players take turns to bowl, which basically is just striking a key when the ball lines up with where you’re aiming. The pins fall down in a deterministic way that eliminates much of the variety you would usually have. This is partly because the ball is the same size as the pins and there isn’t much vertical resolution in the alley. This one is simple enough it may have been implemented in BASIC, although there isn’t any way to know for sure.

This slideshow requires JavaScript.

Hardhat Mack was originally an Apple II game made by Michael Abbot and Matthew Alexander in 1983, it was ported for the IBM PC the next year by Dana How and Kevin Gilmore. It’s a single screen platform game starring the titular character Hardhat Mack, who is working on a construction site. Like in Donkey Kong, Mack has a different task in each level to complete. There are three different stages to complete before the game starts again on a slightly harder difficulty level.

Technically it looks much like most other games of the era, with 4 colour CGA graphics and PC speaker sound. The artwork looks fine, but the technical implementation seems a bit slow and suffers from colour distortion due to the way the sprites are drawn and moved, most likely using the XOR operation. It also affected my ability to get a good screen shot whilst playing in dosbox.

The controls takes a little getting used to, you press a directional key and mack continues to move in that direction until you press down (for stop) or change direction. Mack and the enemies move fairly slowly, so it’s not a particularly action packed experience, but there is some challenge avoiding the enemies and completing the level. That being said other games like Freddy’s Rescue Roundup have more and deeper game play.

This slideshow requires JavaScript.

Moonbugs was made by Windmill Software back in 1983 who are much better known for making Digger in the same year. Moonbugs is an arcade style game much like many of the early arcade shoot ’em ups, what makes it unusual is the graphics mode that it uses. It is one of the few CGA games to achieve 16 colour graphics in what is essentially a hacked CGA text mode.

The graphics whilst chunky are very nicely implemented. Animation in general is very smooth even with a large number of objects on screen and the movement looks quite good. Sound is of course PC speaker, which is again implemented very well, I’m not sure how they achieved it, but it sounds very much like an old school arcade game.

The game play is a combination of ideas from arcade games with twist of its own. The main enemies move around the screen and shoot in a way that reminds me of the insects in galaxian. They will swoop down and steal some of the uranium fuel at the bottom of the screen, you can shoot the enemy to recover the fuel. More of them spawn as the game goes on at a rate dependent on the level and up to a limit as well. A bonus bad guy will occasionally fly along the top of the screen like in space invaders which you can shoot for a bonus and later levels seem to include homing missiles that you need to destroy or avoid.

The main aspect of the game play that is original is the machine collecting the uranium fuel that you’re protecting. The machine gradually collects the fuel over time, once all of it is collected and the machine connects to the dish the level is over. You get a bonus for each piece of fuel collected at the end, so having the fuel stolen reduces the time available to shoot enemies and your score.

Moonbugs is colourful and noisy in a way that would fit right in an arcade setting. It’s fairly challenging without being painfully hard. I quite enjoyed my time with it. The best way to play it today is via dosbox with cycles and settings to match a CGA XT machine. You can find it at the digger remastered site (scroll down a fair bit) along with other Windmill Software games.

Skunny: Wild West for DOS

Having already looked at three of the Skunny games you’d think I would have learned my lesson and avoided today’s game Wild West, featuring our not so favourite Skunny Hardnut. This entry in the Skunny series of games came out in 1994 and was made and published by Copysoft. With the previous games not being terribly good and expectations low for Wild West you’d be forgiven for thinking I am some kind of weird retro gaming masochist.

The story for Wild West isn’t as nutty as some of the others, Skunny is simply diverted to the Wild West on his way home from Rome to help his parents retrieve their missing sheep.  I am actually kind of disappointed as the nutty stories from previous games were quite amusing. No sticky nut pudding to be found anywhere, and who doesn’t like a sticky nut?

The VGA graphics are very much like previous games, they’re decent in their own way but not great either. It’s very much like Save our Pizza’s in style. I suspect it uses the same engine and has had new artwork made to fit the Wild West theme. I did notice one funny inconsistency, Skunny’s hat disappears when he bends down to pick up a crate, perhaps it falls off his head.

Audio is again like previous games, reusing many of the sound effects where they could. In general the digitised effects and PC speaker bloops are ok. There is only one track of music that loops constantly, so that gets a bit maddening after a while, although it’s better than the last game you’ll want to turn it off.

The keyboard controls are basically the same as they were in Save our Pizzas, although there are less issues getting around the levels and dealing with enemies. I still found that the game would completely miss pressing jump when using the keyboard.

Because the keyboard controls aren’t great I thought I’d try out using a game pad with the built-in joystick support. Back in the day this would have been uncommon, as most people had either an analog joystick (which isn’t appropriate for a platformer) or only a keyboard and mouse for input. It turns out using a gamepad solves the issue where it misses input for the jump button. I’d imagine that this may also help Save our Pizzas play better as well. Although the movement mechanics are still a bit janky, so it still doesn’t control well.

The game play is better than Save our Pizza’s for a few notable reasons. Firstly Skunny has a water pistol as his main attack, which means you’re much less likely to touch the enemies in the process of taking them out. When you are hit you don’t bounce backwards unless you touch an enemy. This significantly reduces how often you’ll be knocked into a hazard that kills you instantly, although it still happens. There are quite a number of health and ammunition pickups in the space that I played, so you generally can recharge.

Although the game play is improved I still found it to be frustrating to play. The enemy projectiles are generally impossible to dodge, just because they are fired so frequently.  Resulting in losing some health at every encounter with no way to avoid the damage.

The levels are set in a magical part of the wild west where everything is suspended on platforms in the sky, even the lakes and trains. Perhaps they mastered levitation and didn’t tell anyone. So basically most jumps are over a pitfall of some kind and any mistake at all is pretty much insta-death. So it’s better in the sense that you’ll get further into the game before you lose your mind.

I got far enough into the first level to discover that there are check points if you can make it far enough, mostly because using a gamepad made things a little easier. However after numerous attempts I couldn’t get any further just like the other games. I took some screen shots from the demo as I didn’t want to keep playing, and it shows some areas I couldn’t reach.

Like the other Skunny games there isn’t a terrible lot to recommend it, although I concede you may enjoy it if you have some nostalgia for Skunny. I downloaded the shareware version from the usual place, until recently you could still buy the registered version from the Copysoft website, but that seems to no longer be available.

This slideshow requires JavaScript.

Silly Knight for DOS

Today I’m looking at a small home brew game named Silly Knight made by Petr “AfBu” Kratina in 2017. It was made for a DOS game creation competition hosted at high-voltage.cz. It uses a special CGA text mode for drawing at 160×100 resolution with 16 colours by using code developed by Jason M. Knight originally for Paku Paku. The story and game are fairly simple: you’re a silly knight trying to make your way to the throne to become king, killing anything that gets in your way.

Whilst the graphics are blocky due to the low resolution they are quite well drawn and animated. The animations in particular are quite impressive as they move quite fluidly despite the large pixels. Sound support is PC speaker with some bleeps and bloops for player actions like jumping and picking up power ups. I’d say it would probably work on 286 class machines quite well, and perhaps be playable on 8Mhz 808x systems, but wouldn’t perform well on a 4.77Mhz machine.

The game controls are fairly simple, left and right for basic movement, space for attack and up to jump. The knight is fairly easy to control and goes where you expect him to. I’ve heard some people are critical of using up for jump, but I didn’t have any problem with it on this particular game.

Now what do those boots do?

The level design is good in much the same way the graphics are. It is limited by the technicalities of the game engine, but designed very well given those limitations. Basically there are a number of screens which you travel between by using doors. Each screen has some obstacles to overcome, such as bad guys or pitfalls. Generally the bad guys can be overcome with patience and your sword, but in sections that are more difficult you’ll probably die multiple times. Death just sends you back to the last check point with no other penalty, the check points are fairly common so you usually don’t have to travel far to try again.

One issue I did have was working out what the boots power-up gave me. It enables double jumping, which is necessary to escape where you pick them up. I looked up someones play-through on youtube to find out how to escape that area. I did feel pretty silly for not working it out on my own, but some kind of documentation or notification of what it was in game would have helped.

Other than me being a bit silly with the power-up, the only real criticism I have is the game is a bit short, I easily completed it in around half an hour. Granted it would need more features such as more bad guys if it were to be larger, and being short isn’t really necessarily a bad thing. It’s just I liked it enough I wanted to play more. This is totally worth a download, whilst I couldn’t find an official website for it, you can find it at the doshaven home brew website.

This slideshow requires JavaScript.

Paganitzu: Romancing the Rose for DOS

Whilst Apogee were better known for publishing action games they also had some puzzle games in their catalog. Todays game, Paganitzu is one of those puzzles games, having some features in common with Sokoban. I’m just playing the shareware episode, but you can still buy Paganitzu on steam or through the 3drealms website. It was originally released late 1991 and made by Keith Schuler.

The story of the game is fairly simple, it’s a continuation from the first game. Alabama Smith (totally not a rip-off of Indiana Jones) had gotten famous from his exploits in Chagunitzu. Now his fame is fading and he is busily researching a new pyramid to raid, that is Paganitzu. The game starts having just entered the pyramid.

The game is like Sokoban in that it is played on a grid of tiles with items you can push around to solve problems. Unlike Sokoban there are hazards in each level that will kill you if you’re not careful. Spiders move quickly, usually hugging either the left or right wall and snakes spit fire at you if they catch sight of you. Your task is to collect all the keys so you can move through the pyramid to accomplish the greater goal of the story. In some parts of the levels you will find hints, parts of the story, or little jokes that add a bit extra to the experience.

CGA and EGA graphics are supported, with EGA looking reasonably nice but CGA not looking so hot for some of the more detailed graphics. Animations are pretty good in general with the exception of the player or enemies moving. Each entity sort of jerks a whole tile at a time, some with no animation at all. I suspect this is because it’s a tile based game. PC speaker is the only sound device supported, with only a few bleeps and bloops for various events, it’s not annoying but is totally optional.

The controls use the normal cursor arrow keys on the keyboard, so the control layout is generally fine. However I’ve found that the game doesn’t buffer key presses and doesn’t always accept input when you’d hope. This left me sometimes mashing the keyboard trying to move as fast as I could, but actually moving significantly slower instead. This made some puzzles harder to finish than they needed to be.

The levels and progression are generally well done, although there are a few levels that are out of place because they are easier or harder than they should be for that point in the game. The shareware episode I played today is 20 levels long, although I wasn’t able to complete that set in the time frame I had to play. The two registered episodes each have slightly different mechanics and hazards, so are refreshingly different from the shareware portion.

Despite the control issues I managed to almost complete the shareware episode in roughly 2 hours, getting stuck on level 19. Only because I couldn’t move fast enough to escape the spider and block it in. I did for the most part enjoy playing Paganitzu, and I recommend it to people who enjoy puzzle games.

This slideshow requires JavaScript.