It’s the last part of the Muri dev blog! Oh my!
The plot and setting were inspired mostly by Doom and Sin & Punishment, though it’s not as over-the-top as the latter. Since each person the player meets only gets a few minutes of screentime, it’s hard to establish them as characters, and as a side-effect they all get portrayed in a pretty negative light… on the other hand, the story is about strife anyway, so it might just fit.
I wanted it to be possible to take the story as both serious and/or cheesy, depending on what you want to get out of it. One tester managed to be immersed at least, but I think it’s a mindset you need to have when going into any media with a dramatic setting. Heck, I liked the bizarre and creepy story in Doom, eventhough most people I’ve talked to didn’t even know it had one, and Doom is hardly a game I take seriously.
I didn’t want reading the story to be mandatory, so you can skip the cutscenes and still enjoy the game. Of course, the reason you’re fighting the weirder bosses won’t be clear, but if you’re not interested in the story it shouldn’t matter anyway.
While I made Iji previously, which has a lot of modifiers depending on what the player does, Muri only has one alternate way out of a specific bossfight which doesn’t change the episodes that come after it. It wouldn’t really fit this kind of game to be more complex than that, I think.
One of the biggest challenges in level design was the fact that the player can only see a short distance vertically, so platforms, spikes and enemies had to be placed carefully. Though the player can safely bounce on enemies’ heads, making it more fair when falling into unknown places from above, I just avoided putting enemies in unknown areas below the player in the first place.
The small screen size also made it hard to let the player know what a boss on the other side of a big room is doing. One enemy that is part of a boss encounter was designed to rush the player from a distance, but since this was hard to anticipate when the enemy was off-screen, I lowered its speed by a lot. The boss was hard enough as it was, anyway.
Teaching the player
Although the game only needs a few buttons to play, I have to tell the player the controls somehow when they’re playing with a keyboard. I didn’t want to show the controls on-screen like more modern games, instead prompting them to “PRESS F1 FOR HELP” which explains the controls, and if you flip the pages, the most basic parts of the rest of the game.
The testers never looked up the help screen aside from curiosity, as they immediately found at least one set of the buttons that perform the game’s only two actions (jumping and shooting): Control and Alt, Z and X, Numpad Ins and Numpad Del, and a few more. Y is also mapped to Z due to these being swapped on German keyboards. I decided against the user remapping the Z/X keys, since it wasn’t necessary given that Control and Alt are in the same place regardless of your keyboard layout, and rarely “block” the arrow keys when used in conjunction like other keys do.
In the first level, the player is dropped into a small room with a barrier guarding the exit. A nearby generator (obvious reference to Hero Core) needs to be shot while ducking, lowering the barrier. The player must then keep the jump button held to jump higher and reach the ledge above, and with this they have discovered the basics of the game by themselves. Jumping on enemies is usually discovered in stage two, where enemies are clinging to a wall at the bottom of a thin vertical shaft. The player inevitably bounces on the enemies on the way down.
The game could’ve clearly communicated everything about how to play it through text and icons, but this being a DOS-like game, I didn’t want to overdo it. I prefer when games don’t underestimate the player or waste their time, too (though I’ve made some long-winded tutorials in the past).
Well, that’s it for the Muri dev blog. I hope you’ll like the game! 🙂
It’s Muri time!
Many DOS games let you choose between PC speaker sound or MIDI and digital samples, which required a sound card. When dad got a Sound Blaster 16 we had to manually input the IRQ and DMA in setup programs for each game, though later games like Tyrian could autodetect the sound card.
Anyway, the PC speaker can only generate one fairly simple wave at a time, with no way to adjust the volume. For Muri I used a synth emulating the PC speaker, set up by Mattias, to generate these sounds. The game uses a priority system to make sure that only one sound is played at a time. A higher priority sound will overwrite a lower one, which works surprisingly well in practice!
Mattias also wrote two PC speaker songs for the game, but only one was used. The other was going to play in a cutscene, but was considered too distracting.
There’s at least one new enemy or boss in each of Muri’s 20 stages, ranging from small robots that don’t even notice you to jumping, ducking and dodging humanoids with rapid-fire rifles. Most robots come in four different colors with slightly different abilities, and each episode has a unique enemy that usually guards or carries something important.
Though most enemies are limited to simply running into you or firing slow-moving bullets in one of 8 directions, I hope I’ve managed to add enough variety to them. I noticed during testing that since you can jump on enemies from above to damage them, some testers tried to do this all the time, even if it meant crashing into them and dying more often than usual. :p
Pickups and weapons
Aside from the regular point bonuses, there are several energy pickups and one extra life more or less hidden in each stage. Both the energy and extra lives are replaced by point bonuses on higher difficulties.
Since all the enemies and bosses are defeated by simply shooting at them, the game could become too hard or too easy depending on your current weapons. To alleviate this, there’s a rare kind of pickup that gives you infinite ammo for a weapon, usually before a boss where I wouldn’t want the player to get stuck with just the regular gun. I also tried to make the weapons different enough from one another that they all had their uses, though as you’d expect they are more powerful the rarer they are.
The weapons got the DOS-y names RAPID, MKV, LASER, MEGA and CHAOS, with distinct sounds for each one. MKV stands for Mark Five, but this isn’t explained by the game. Letting the player guess at the meanings of weird acronyms is part of what I liked about old games. But now I’ve ruined it for you. Oh well.
Next up is story, vertical problems and teaching the player!
It’s time for another Muri post!
The game emulates the 320*200 EGA graphics mode that uses the 16 CGA colors for its palette. I’ve actually only played a few games that ran in this, like Duke Nukem, which used the optional brown color instead of gold.
There’s a lot you can do with these 16 colors, but I didn’t want to use dithering or more advanced pixelart, since it would look more like an Amiga game in style. I was rather inspired by the simplistic look of games like Electro Man, plus I’m not that good of an artist.
You might remember the bright-red and yellow character portraits in Duke Nukem – it’s hard to get a proper skin tone, especially a darker one, with these colors without heavy dithering. The only time you see Adwoa without the helmet is when red sunlight is reflected in her face, providing some context for the high contrast. Thanks to Scott Robertson for help with this!
The only other time people’s faces are seen is in a greyscale portrait, which probably looks better than if I’d tried to do it in the 16-color palette. Speaking of these limitations, the colors used for the Muri suit were chosen to stand out from the background and enemies, and each suit has a different colored visor.
Late in development, I realized that the game – which normally runs in 16 frames per second – may be too archaic (and a bit nauseating) for most people. The low framerate also makes it harder to turn around quickly or react to enemy bullets. After a bit of testing with doubling the framerate and rewriting the code for the player character, I decided to implement a 32 FPS “smooth mode”.
The smooth mode required programming special cases or timing changes for all the logic in the game, which was pretty tedious. I think it was the right decision in the end though, making the game more visually appealing to players who don’t want their retro games that retro. Essentially, it just makes everything move twice as smoothly.
The game asks you to select the “authentic” or “smooth” mode on first startup, but can be easily changed in the options afterwards. It was the only option I considered important enough to ask the player about, since many players never go into the options menu.
The next post will be about sound, enemies and pickups!