Reanimating the dead ’21

Raiders of the Ancient Spaghetti

It’s been a while. As originally promised, we will be talking more about the coding side of the things on this post. We discussed with Pekka about if there should be something detailed information about the code, but he felt that codewise “There has not been anything interesting happening”. OK, maybe talking about nuts and bolts and finesse of the assembly is not needed on the blog, but eventually we thought that talking about the coding challenges of this project in general level would be a good thing so this would be accessible to more people. Like the last time, most of the content here is partly based this on our email / discord / phone discussions.

Originally the game was programmed by using C64. At some point amount of code grew so large that code editing and (cross) compiling was done on Amiga 500. At this time game code contained roughly 5000 lines of code that was either not commented or “commented” (somehow, in Miha’s memories, it was tens of thousands of lines, but thankfully that was not the case). Furthermore, management of code was badly lacking as we had different versions of code for different purposes, effectively it was scattered all around in pieces. There was one piece of code which ran a level, then you had one instance of code running the “worm room”; which was basically a rework of the worm room of the splatterhouse coin-op.. (done simply because we could). Sadly, source code for this one has been lost. And then, from 1992, there was an iterated edition which contained additional features which were not present in the Demo preview that was distributed by Triad, such as zombies splitting in two, and zombies dropping down from the ceiling. We have included a video of this version later in the post.

In 1992 managing all that code was a daunting task, but now it felt like it wasn’t bad at all, at least scope of the project felt manageable. Only problem was that no-one remembers what the code actually does, so reading it is like reading code written by someone else. It has to be restudied (decrypted really), which has proven to be challenging, as it mostly looks like a bowl of ancient 10-dimensional spaghetti.

But also, thanks to the internet, there are now resources that were not available back at then, like c64 codebase, and many others.

Memories of Mass Memories

One central feature of Undead was always the super-detailed game background, a belt scroller that would display multi-color bitmap graphics. This would allow for more colorful and graphically varying gaming experience. There was just one technical hurdle to overcome, how and where to store all that background data? 30 years ago there was only one option that made sense – the floppy disc. Well OK, then lets put it all on disc, but background graphics needed for one level are still not going to fit in main memory? Can we somehow stream graphics from 1541 while game is running? Luckily we knew someone who could. Sami “Proton” Louko had written C64 turbo loader at age 13, and was kind enough to teach us how to do it and even use his code in Undead! And it all worked brilliantly.

Fast forward 30+ years. IT field has advanced in leaps and bounds, at least on hardware side. Even our beloved ‘plank’ is enjoying spoils of this enterprise, like Ultimate cartridges and much cheaper memory modules. So a question arises, should we drop floppy version of Undead completely and move on to memory modules? Maybe many people just want the digital file they can put in their easyflash cartridges? This poses a sad dilemma for Undead programmers, do we indeed jump on the new goodies bandwagon, and discard the only thing in the whole project that could, or was 30 years ago regarded as some kind of technical innovation? In the end it was an easy choice. Why would we subjugate the player to ordeal of disk swapping and load times if we have means to avert it? Module version it is.

Having a cartridge actually opened us some new avenues that were previously unreachable; first of all, and most importantly, the very fast mass memory access. You could have 8kb chunk thrown into main memory in an instant, and this could be utilized in many creative ways.

Tools of the Trade

From get-go central part our vision has been not to shy away from writing our own tools if we felt it is necessary. What we really want is a collection of tools that streamlines creation of Undead as much as possible.

If we are able to realize this vision, most of game development work will be done using custom editors; assembling multi-sprite characters, such as 4-sprite main character wielding a weapon, interaction between characters; such as zombies attacking the character, or the player character using a zombie as a weapon, and these will all be assembled with graphics tools that make it fast and easy. No more iterating code in attempt to find the exact spot for that weapon sprite in the exact frame.

Off the shelf tools (of which some are free, some are not) have been very useful for making graphics so far, but they lack some features that would make creating graphics for Undead easier. So that’s why our own custom tools will be used.

Early version (October 2021) of our custom gfx tool which has live editing enabled. The walk cycle is from 1992.

Also for setting game parameters, inserting enemy spawn points, setting requirements for bonus spawn rates, adjusting enemy parameters etc etc require an editor, which we have dubbed “Undead Editor”.

DIY, really?

Why would we want to roll with our own tools, isn’t that like, a waste of time? It possibly is. Embarking on a quest to create your own tools is definitely risky. So let’s call it an investment. And what is the potential payoff? Well that would be quality of the final product, obviously. Effectively we are now spending time we could use to work on Undead, to be able to work on Undead much more effectively later on.

Reanimating the ancient spaghetti

Well that’s all fine and dandy, but how is the programming effort going really? Pics or it didn’t happen!

Undead – the first contact!

Above, defense exhibit A. Very first glimpse of the olden code running on VICE. Compiled with 64tass. You can kind of see it if you squint really hard (don’t…).

..aaand it works again!! Well, sort of

Above, zombies are marching on. Sprites seem to be loading, so that’s improvement. On right side, some custom tool prototype that is probably controlling VICE by feeding it commands via telnet connection.

Old vs new. Or is this new vs old?

Hard at work, intensity at maximum. VS Code is pretty nice.

Forgotten features

One of the biggest highlights of the last year was when an old version of the game was found, which had the zombies being ripped in two. We thought it had been long lost, and didn’t even remember that we had all these features any more. This was salvaged and transferred to a file, which was then tested on real C64 using Ultimate cartridge. We did this not only for nostalgia reasons, but also to test some of our custom tools. This version is one of the very last versions of the game before the development was abandoned in 1992.

Undead – the lost version!

Whats next

More of the same, probably. Work continues on multiple fronts.

To have at least some updated posted on the graphics front (as there has been lot of work done), Miha has made all the graphics for the first level, that can be done without our custom editors. Meaning, all the background art for level is done, almost all of the player animations are done, and lot of the zombie animations are done. So therefore the graphics work is now on hold, waiting for the editors to be completed before proceeding. More about graphics, animations and custom editors in the next blog post.

By the way, there is an article about Undead in the latest issue of Zzap!64 magazine (yes, it has returned). Issue #6 should be available on their patreon page at monday, 31st january; go check it out!

See you later in 2022, thanks for reading!

Starting the development

In this first blog post, Miha is talking about doing the new graphics for new version of Undead. Some of you may want to know the coding related stuff, in short it can be said that Pekka has been doing prototyping, delved into 6510 assembly, examined his old code from 30 years ago, and started work on the new tools.

I can’t believe that we are actually doing this! You see, I wanted to finish Undead since I started it at 1990. And I never stopped wanting, though I admit I wasn’t expecting it to happen any more. But now it does! (if you haven’t seen the old 1990 demo, look at the youtube video here)

Of course, the thing is that in 30 years, lot of things change. Tools change completely, and we as people change. But I still have a soft spot for those 80’s arcade games and movies this game was *ahem* inspired by (we won’t admit any rip off).

As for the game itself, I actually don’t want to change much. I think the core game play was essentially fun. Chopping heads off zombies, and using zombies as weapons is still as much fun as it was 30 years ago; which in my mind proves that we must have done something right! I only need to trim and adjust certain bits – there is a thing or two I’ve learned in my 27+ years of working in game industry and I think I could put that knowledge in use here. As for the story and setting, it’s still going to be VERY throwback to the 80’s macho action – I don’t wish to change that for one bit – and though I might add some extra layers of satire into it, I still intend to keep the serious tone – it makes it more fun!

I did a new game design document – very vague, it’s purpose was to set the scale so that we have an idea of how huge it’s going to be. I was careful to not add too much stuff in the beginning – let’s just first see how this progresses and how much fun we are having. If things go well, we may start adding other features on the top of the core game play. But right now, I want to be realistic about what we can achieve – this was something I refused to acknowledge, when I was 16. I believe it was largely because of this why the project was abandoned, I just could not stop wanting to get more stuff in. This time, we should know better.

So, while the game play is quite good to go for the time being, I needed to figure out the most daunting task; which is doing the graphics. I haven’t done pixel art in years; so I needed to relearn some essentials, and study what I did, and what has been done to see what I can do better (and what I should keep intact)

While I believe that I have mostly improved as game artist, making 2D graphics on very low resolution of 160×200 with palette of 16 colors is so vastly different from doing graphics today, that I had to also learn again how to think with c64 pixels. These days, I do game art with the usual 3D tools; Maya, Zbrush, Substance.. needless to say, it’s a whole different world, and whole different way of thinking! There is almost nothing you could carry from that one world to another. But that’s what makes this so refreshing.

First, let me ramble little bit about the history of doing game graphics. One essential thing that people today may not remember, or even know, the perspective on graphics has changed a lot – while in the 80’s people hated the low resolutions and tried all kinds of antialiasing and dithering techniques to fade away the dreaded “jaggies”, 30 years later retro has become fashionable and jagged edges part of the aesthetic. People also no longer use CRT monitors to view graphics (apart from me and couple of retro enthusiasts), which gives me a dilemma: should I still try to get rid of the ‘jaggies’, or should I just accept them and the “rough” look of the graphics. This is not an easy choice for someone like me.

A screenshot from the original 1990-1992 demo. Graphics by yours truly.

I must say that when I first looked back on the original graphics, they didn’t impress me much. Backgrounds didn’t really look like they represented much information, basically it was nothing but a wall and repeating pillars with empty black floor. In fact, being teenager fresh out of school and having no reference material on the supposed setting (big US city) I had nothing to go on – the pillars on the background were probably inspired by the concrete pillars of my school! So the game actually looked like you were just playing around at our middle elementary school on a break, very appropriate for a 16-year old designer. What I really wanted was a representation of post-apocalyptic metropolis in shambles that has been taken over by the living dead. Since we are streaming fully drawn bitmap images from a disk/cartridge, and are not restricted by the ascii graphic limits, surely I could do better than that?

Eventually I realized that these old graphics made by 16-year old were, technically, actually tap dancing around the c64’s limits in many ways. How so?

As it turns out, even with our 16-color streamed bitmaps, you cannot have more than 3 colors per one 8×4 pixel character space (3 and background color, to be exact) So, even with a bitmap background that you are “free” to draw any way you like, your use of colors is still constrained to these limits. And I was actually putting as much color and shading as possible in these old graphics within these constraints, often at the expense of the image itself.

Other problem with doing graphics for Commodore 64 is that unless you are working with really close-up full screen pictures, shading with such severely limited resolution and palette is going to be very tough – there is a high chance that you may come up with a total mess. Pretty much same goes for antialiasing.

So first, I needed to research games (demos don’t count because they are created under entirely different set of restrictions and needs) that were considered as having “best of the C64 art”, which of course were, to me: Last Ninja Trilogy and all those sports games by Epyx. (I do like Myth very much as well, as it has graphics by Bob Stevenson- but Last Ninja and Epyx games are closer to Undead in their perspective angle, so I will focus on them)

Looking at them, I made several observations. Last Ninja 1 did not bother much with antialiasing or shading; graphics were primarily aimed to be illustrative; it didn’t matter if a tree or a rock was done with 1-2 or 3 colors, as long as their shapes were not blocky in appearance. As Last Ninja’s backgrounds were made with bitmaps, they could afford have larger, more illustrative and detailed look that was less blocky than other games that employed character set-generated graphics.

The Last Ninja (1988) promotional art - MobyGames
The Last Ninja by System 3 (1987) Graphics by Hugh Riley & Paul Docherty

Last Ninja 2 used mainly 90 and 45 degree corners (numbers are not accurate due to double horizontal size pixels but you get the idea, ok?), to avoid biggest jagged edges, but it didn’t concern itself with shading or anti-aliasing either. Last Ninja 3, on the other hand, used dithering which may have looked good on CRT tv’s, but on a modern PC monitor it looks like a mess. Games released by Epyx (California games, World games for example) were also noted and highly regarded because of their graphics. Their first priority was to try to give somewhat believable and colorful representation of “real world” (real in this context means: anything that didn’t look like it was built out from tiny blocks, like 95% of C64 games and 8-bit games did).

California Games - C64-Wiki
California Games for C64 – graphics by Jenny Martin, Suzie Greene, Sheryl Knowles & Paul Vernon
Some of my favourite C64 artwork here. No antialiasing, very little dithering, still looks colorful and great.

This meant that I would aspire to do the same. But I admit that being grown into certain type of mindset in the 80’s, I find it real real difficult to create any graphics that would have hugely jagged edges. Back at then, you were considered “lazy” and “amateurish” if you did that. Many people only stared at the jagged edges and amount of colors on the screen; whether the actual game art had anything to do with perspective, anatomy or proper lighting was inconsequential – as C64 could not easily render any of that in any great detail, within its limits anyway. This would be an enormous mental block to overcome for someone like me who started doing pixel art in the 80’s – I don’t think I can or even want to totally overcome it, but I can try to restrain it and try to stay tasteful, and avoid going overboard with it.

So, I would have to attempt to create backgrounds that represented a decaying, post-apocalyptic metropolis as closely as possible, in a space of 160×200 pixels (actually we used half of that in the 1990 demo, and half of the screen was reserved for menus – because these are whole bitmap images and there was a limit on how much data you could stream out of 1541 disk drive). I wasn’t even sure how I should start this or approach the problem. Luckily, we live in 2020’s and there are vastly more resources available than there was back in 1990. But before I start, I would have to deal with..

Trouble with Perspectives..

Other problem would be with the perspective of the floor and the buildings. If I wanted to do background art that is an actual illustration, instead of lego-like set made of character set-generated blocks, then I would have to deal with the perspective, there is no way around it. So I started with studying the games that inspired this game directly; Splatterhouse, Vigilante and Final Fight. There are no useful C64 games to study, as none of them have custom bitmap graphics covering all of the screen instead of just blocks. Coin-ops don’t have either, but at least they had much more memory at their disposal, so the reference is clearer. I also looked one modern belt scroller, Streets of Rage 4, as that one had completely drawn backgrounds which (apparently) dont look like they were made from blocks.

Vigilante by Irem (1988)
(artist credits unknown)

I was surprised to find out (as I had completely forgotten about it), that almost all of the belt scrollers, the background was forced on isometric perspective based on somewhat around 30 degrees. “somewhat” because the old screencaps on PC monitors are not reliable, due to differing pixel aspect ratios. They are not even attempting to be consistent, I guess due to the fact that they are still made of blocks, if only bigger ones.

Splatterhouse by Namco (1988)
(artist credits unknown)

In Final Fight, I made even more curious notes. The perspective changed after a certain vertical line – the area where characters walked was strictly in the forced isometric grid, but right above that it could change according to where you were in the level. In the beginning of the first level, you could see barbed wire fence drawn on one vanishing point, but after that, the building could be drawn on isometric perspective – opposite to the play area.

Final Fight by Capcom (1989)
Graphics by
Satoru Yamashita, Miki Kido ), M. Okazaki, Yoko Fukumoto, and Asae Nishitsuji

Also curious thing was, that in the play area the objects (like phone booth) actually have a vanishing point, and it was pointing in the opposite direction than the floor grid. Also, the buildings above the play ground also have a “kinda” of vanishing point, but buildings behind them look like as if they have been looked through stronger FOV. The end of the level, is, again, on a vanishing point but on the opposite direction, while the buildings far away are more like cardboard cutouts, their perspective is all over the place.

Final Fight by Capcom (1989)
Graphics by
Satoru Yamashita, Miki Kido ), M. Okazaki, Yoko Fukumoto, and Asae Nishitsuji

The funny thing is that you will be so occupied what happens in the front of the screen, that you will never pay any notice to the perspective in the background. This does not mean that the perspective does not matter; instead Capcom’s artists are very cleverly using the limited resources they have to conjure an illusion of perspective. They correctly are aware that human eye can only pick certain elements in great detail while playing this fast-paced arcade game, while everything else is left kinda “fuzzy”; there is some background there, and it is kinda vanishing somewhere, so it has some kind of perspective all right. This may sound funny, but this is how our vision works all the time- we only pick up limited or incomplete signals from our surroundings, and our brain interprets the rest. So there is no need to make the perspective spot on correct; rather you have to make the brain believe that it is correct by using some very simple tricks.

Needless to say, I have enormous respect for 80’s japanese game developers, and especially those resourceful artists and designers at early Capcom.

So, I made the decision to do the same with Undead. I would keep the play area on forced isometric perspective, but above the play area I would use changing vanishing points depending on where in the level the buildings are pictured. Perspective is solved. The next thing I need to do was to collect reference material.

I collected photo material from Brooklyn using google street view, and then chained those screenshots into level-like montages. Obviously the picture quality was all over the place, and perspectives would change depending on where I pointed my mouse at, not to mention the terribly strong FOV causing kind of fish eye -effect; but this was all right. As this was going to for 160×100 resolution with fixed colors, there was no way I could recreate these as such – I could only use it as a reference resource. I also took screenshots from my 4K blu-ray of Escape from New York to get kind of an idea how the 80’s movies scenes were lit. What I learned was that back then, the movie lighting was based on giving an audience certain kind of feeling, and to help with storytelling – it had very little to do with actual realism. This was important thing to learn.

Brooklyn street montage (source: google street view)

Based on rough idea on what a Brooklyn streets looked like, I used an old-fashioned way of sketching the level on paper. But how long should the level be? How many screens? Very good question. There was no other way around it but to research: I clocked how long it took to play our old 1990 demo, then I clocked from youtube videos how long the first levels of Splatterhouse, Vigilant, Final Fight and Kung-Fu Master took. The results:

Undead preview: 2min (4 screens, one repeated)
Kung fu master: 1min + boss fight (background loops a lot..) (total time 8min)
Vigilante: 1min 20sec + boss fight (7 screens) (total play time 15 min)
Splatterhouse: 50sec (8 screens) (7 stages, total play time 24 min)
Final Fight: 41 sec (3 screens, not all of first stage, total play time 42min)

This would make the overall total play time for undead 18 minutes – if you were a master and could run it through with no mistakes. This was exactly the playthrough time I would be looking for. And now I also knew, that I would need four background scenes, as these would be drawn directly, rather than created from blocks. So, I took the old-school way of sitting down with pen and paper, and did a quick sketch.

Sketch of the first level (rough)

Next issues were solving the scale of the background and the position of the players. This was actually really hairy, and I could only make it work through endless trials and errors. As it would turn out, obviously, was that my rough sketch did not match with the actual scale of the game. At. All.

Scale / Sketch / reference scene composition

This picture may give some kind of idea of the utter chaos I went through. I composited the original 1990 screenshot along with composed photo montage with an inked version of my background, and then proceeded to draw thick outlines through it.

Then, I converted a one image into multipaint, and tested out some pixeling on top of it. It looked awful.

Failed pixel test, one of the many

But that’s ok, you can’t always get it right the first time. In the next attempt, I remembered that these graphics should be simplified representations: not every tile should be drawn on the wall, not every one of them should be shaded or high lighted. Instead, I should use technique employed in the comics; only draw few bricks here and there, and let your brain fill in the blanks. Now its getting better:

Got it!

There may still be too many bricks in the wall, but essentially I just need to find a good balance between detailed scene while not making it too busy.

Next problem was the sprites, the original ones would not work with this any more. As most of the 80’s game artists, I hated jagged pixels and tried to make them as smoothed out as possible, which meant that I needed to use all three colors of it just to hide out jaggies. In turn, the contrast was very low on characters, and I was forced to use black background most of the time. Now I know better, and I know that it is not the rough pixels that make the scene look bad, but rather a poor contrast instead. So, I redefined the sprites quite a bit. I added black color to add shadows, so that the characters would stand out and also fit better to the background. Also, by replacing the main color of main character (brown) with black, I would be free to employ any colors on the background I wanted.

I put old sprites along the new ones to see how they worked on photoshop. New ones look better. And finally, a test on real hardware on CRT monitor, since it may look bit different:

Yes! That’s it! I think I nailed it down. I think I am quite happy with this new look. However, I may have to expand this play area vertically, since as we are now making this a cartridge-exclusive game, we can stream bigger chunks of data than we could have been able from a floppy disk.

That’s about it for creating the new look for the Undead. See you!

Create your website with
Get started