Undead Dev Blog – Returning to C64 title after 30 year break

From prototype to Steam

In this long overdue blog post, I will talk about the current state of the C64 version and development of the PC version. I also talk about setting up the Steam page and some musings about staying true to the vision I got as 16-year old – especially when I found my old design documents from an old floppy disc!

Zooparty 2024 presentation

Undead had it’s first public playtest sessions at Zooparty 2024, where it was playable alongside the PC version – in a rough early state. It almost didn’t happen, since in c64 conversion there emerged some many last-minute bugs that caused lot of issues, and it had to be gaffer taped together to stay at least in a semi-presentable state. But, we have the game running on breadbin Commodore 64, now; first time since 1992.

Undead first playable running on breadbin C64 using Ultimate II+ cartridge for streaming data

Captured gameplay from the C64 version, running on Winvice emulator

Still, the reception was better than I expected (I was so frustrated that I was nearly going to pull out of it altogether). Biggest surprise was that the C64 version had an unexpected super-fan: a small boy, approximately 5-6 years old who became absolutely obsessed with the game, playing it for hours! His dad even asked him if he didn’t want to try any of the other games that were present ? (there were other C64 games and some coin op cabinets, like Commando, competing for attention). Kid’s response: “NO!!”.. and off he went, tapping the button like person possessed. He got over 20.000 points (I only got 1600). Good thing that I didn’t tell them that this game is supposed to have an age rating of 18!

I tried to analyze why this kid got so obsessed with the game, because I honestly was utterly dumbfounded; the demo had in my opinion maybe 2 minutes of enjoyable gameplay. But hours? When there were other games around? I could only come up with following explanations:
-Game starts immediately and is very easy to figure out – press single button to punch
-Zombies probably look quite funny when they wave their arms when they approach the player; perhaps quite like kids having a fight in a playground ?
-Game is hard, in a way that it is very easy to die very fast, but, you can try immediately again.
-Therefore, it creates a very quick loop of “fail fast and try again”, which actually can be addictive if done right. That is what I hope it would turn out to, but considering how frantically the demo was put together, this was not what I expected. Still, it proved to me how important it is to observe the game testing live, rather than just send a demo to somewhere and receiving written feedback.

It also reinforced my beliefs how many modern games are actually dragged down with “bloat”, which means; too many buttons, too many options, too many cutscenes, too many tutorials, which happen when the game tries to cater to largest possible audience, while trying please everyone who whines in the internet. Combine this with casual-level easiness and you have bloated piles of tiresome games that feel like a day job, and with served-on-a-plate “achievements” that mean nothing, since easiness takes away the feeling of any accomplishment. I believe personally that the sense of achievement must form inside the player’s head from his own actions, rather than game telling the player.

Still, the C64 2024 Zooparty demo was rough, so rough that there is no way I will let anyone play it again. Technically, it’s a convincing demonstration of clever coding from Pekka, but as strictly a game, it is too unfinished to be presentable for anything else than a tech demo – a proof that we can (or, Pekka can) do this game on Commodore 64. The rest is just hard work.

The PC version that was on display lacked the most fun element (imho), which was grab / throw / hurl, I had to disable them because they were so buggy at the time. I asked everyone present to try the PC version as well, to check how they did compared to the C64 version. The C64 version has not been developed since that time, but it will get there – Pekka will resume work on it once the PC version is far enough (which is about at this point, now).

Refactoring the PC version

The PC prototype, so far, was largely glued together from pieces of blueprint scripts that I copied and modified from the Udemy course I bought. The tutorials I went through were *great* for figuring out the basics, but not so great for scaling the game. Which means, they only supported one enemy and one weapon and the interaction was not that complex – which meant that anything more complex interaction such as grab was bound to create problems.

This mean that I had to start to go deeper on programming, and had to figure out things like inheritance, components and interfaces. Now, objects such as actors/pawns (ready made building blocks to have quickly a character set up) in Unreal are largely built from inheritance and components by default, because that’s how the Unreal Editor is configured, but I had to really understand what it meant. Interfaces I had to go and learn on my own as they were not discussed in the udemy course. I bought a book (Blueprints Visual Scripting for Unreal Engine 5), because one thing I learned when I watched “professional” programmers in game industry for few decades, was that if you want to have some actual in-depth information, you have to buy a book. “But wait!” you say. “This book will be outdated within a year!”.. yes, possibly. And so is every internet link you got on the subject (and try to search for a link that is relevant only to the version of the engine you got!) But there is also more. I have not seen a single (free) resource on internet that goes through the subject thoroughly, and reliably, unless it’s behind a paywall, and you still can’t be sure if it is going to stay there. But if I buy a book, a well written book, it’s mine forever. Even if the engine gets overhauled, you can still figure out many general programming concepts from it.

The first video clip I made since I refactored the game. Grab and hurl now kinda works, but zombies are losing their focus every now and then (which is kinda funny), and there are also bugs in the zombie states, which make them follow the player even after they die

So, at this moment, I did not know yet if I was going to make Undead *a real game* on PC, or whether the PC prototype was going to be some gaffer-taped sad monstrosity only made to show Pekka how the gameplay and animations are supposed to work. I did not have any expectations, and frankly, I was not sure at all if I could be up to it..

But what happened was that I kept at it, quite persistently, and figured it out. I recreated all the game logic architecture in the game, replaced and refactored everything to my own design, since there were no examples anywhere on how to make a game mechanics quite like in Undead. Almost all the blueprint calls were replaced with interfaces, and other systems like health components were added. So, you can say: I really coded this.

Eventually I noticed something: I can do this. Me, the lowly artist, can actually learn how to code games. And if anyone ever thought I never can – they were wrong. Eventually, all the essential gameplay systems worked. There were some glitches, but they were stable enough. Then, I started to add widgets and score system and UI. All went more or less effortlessly, though Unreal’s Widget editor is a clandestine mess of options (like everything else in Unreal). Some trouble went to figure out how to animate widgets, since unreal does not really support animation for them. Then it was time to start planning enemy attack waves and game progression. I soon hit some interesting dilemmas that were oblivious to me at first glance, but only revealed themselves when I needed the game to behave in a certain way.

Image of the original worm room from 1992 which was actually programmed, but it was lost. I found the bitmap image for it.

Concept art for the reimagined worm room for the 2025 version. Yes, it has more details than C64 can show – this is FINE! I will use this image also for the future 16-bit version

First, it was given that Unreal version has to work EXACTLY like the C64 version, or the design decisions made there would not carry over. The devil was in the details. One of the challenges was that the scrolling in C64 version is streamed from cartridge, like explained previously. Certain amount of data can be streamed in certain speed, which in turn results in v e r y slow push scrolling. In a beat’em up, it’s not a necessarily a problem, since this is not a run and gun game, you can always hold the background until player has cleared the screen. This could be preferable even.
But how to make UE version to repeat the behavior in C64, where scrolling stops? Because essentially, UE is not a 2D engine, and this is very important thing to understand – you can not expect it to show you a 2D screen which behaves like a 2D screen, not to mention a 2D scrolling that suffers from lag caused by data streaming. What you have instead is an illusion of a 2D screen – which means that you have a 2D plane, which is bolted to a camera, that points to the screen, and which is attached to the player character.
So, to stop the scrolling, you had to get the player to walk into a trigger, that will change the focus point of the camera to an invisible box, that is spawned and bolted onto the plane, when you don’t want the scrolling to continue. Then, you have to also spawn collision boxes to the edge of the screen, that will tell the player to NOT walk outside the screen limits. There were no tutorials explaining any of this – there was a tutorial for explaining how to hold the screen scrolling, but everything else I had to figure out myself.

The animated GO! – sign, telling the poor player that yes, YOU NEED TO MOVE TO THE RIGHT

And there is more! I wanted a GO! sign and a finger to point out to the player that you need to walk right now. But how does the game system really know when it has to appear? Reading from player coordinates, right, since the scrolling happens when player passes to right from the middle of the screen. But, they can’t be real coordinates since we are not in 2D engine, so we need to read them from screenspace coordinates, which are read from what the camera sees on the screen.

Screenshot of the technical document I wrote for Pekka, so that he knows exactly what is going on at the game logic. This has lots of checks and filters that may not be obvious when you play it, so it’s good to have them documented for the conversion.

Then, I kept finding more and more details that needed to be implemented so that the game plays and looks good.

Melee weapons needed a health system – otherwise players would just hack their way to the end, and I didn’t want to “solve” it in the “professional” (snort) way, which would have been nerfing the weapon – favourite method of any modern game studio (bleurgh). This is about feeling the power when you wield it! Splatterhouse “solved” this by forcing the player to drop the weapon when they exist the level, which was just stupid. My solution is also ridiculous, but not quite as incomprehensible – at least you can always pretend that the weapon was poorly made. So, cleaver will now break after you land a hit with it 6 times. The health points of the cleaver have to show on the UI.

The Jatimatic needed ammo system that reflects on the UI. So, in the UI, if you see Jatimatic, you can see whether it has an ammo clip attached or not. You shoot the clip empty, and the ammo clip disappears. You have a full clip, and collect another, and you see a small clip approaching. I have always preferred this kind of “show, don’t tell”-kind of UI rather than just showing a text list of your variables. At this point, there were lot of blueprints communicating with each other. Player blueprint checks if player is shooting. Jatimatic blueprint generates the muzzle flash and checks for hits with the enemy. Ammo blueprint checks if the player has collected the clip. Ammo UI widget checks how many clips you have collected. And all of these had to communicate with each other.

One head-scratcher was issues that emerged with the enemy AI when player pawn dies. Issues appeared only after I made the enemies stop attacking when player died.
This was because it looks stupid when they bite on thin air. Which meant they had to removed from the player target. So when player was regenerated, they didn’t pick up on it any more.
And why this happens? Enemy AI checks out where the player is and then names player pawn as the target. If player dies, and is restarted in a checkpoint, the enemies lost their target. This means that at the checkpoint, if enemy had tracked you previously, they would now ignore you. There were ways to prevent it, but they would have changed the game flow and progression from what I intended. Splatterhouse solved this by restarting the whole level, except level one, but there they also cut off the enemy walking area where the checkpoint is, so it does not matter if all enemies are respawned – all those from the beginning of the level can’t walk back at you where the checkpoint is. I guess that works, but it’s a rather crude solution.

I solved it the Capcom way. It is kinda funny to see that japanese developers had this same issue when they were making belt scrollers. Yet you never think about it when you play the game – this is because if the game plays well enough, you never pay attention, you just take everything that happens for granted!
So anyway, solution I chose was that nothing will never be destroyed and respawned. When the player dies, new player will be dropped off the ceiling, and he will knock the enemies underneath him when he lands down, killing or damaging them by impact (this is FUN). And this was obligatory, since otherwise the enemies would have swamped you the second you got up.

Another visual issue was that zombies behaved too much like tin soldiers, not like animated beings, because they were too much in sync, and always flew in same arc when punched. So I had to add craploads of random float ranges everywhere to give careful amounts of variation for their movement to make them look little bit more organic.

And so on, the list of all those little things that need to be figured out to get the experience you want AND to make sure that it plays identical to the C64 version down to the last detail can be quite excessive. And it is quite fun and educating experience as well. Things that are very, very easy to do in C64 can be very difficult to do in Unreal Engine, and vice versa. In some aspects they almost seem like polar opposites. But as Pekka enjoys to figure out how to do things in C64, I enjoyed a lot figuring out how to make them in Unreal Engine. There was one limit where I did not want to replicate the C64 version, and that was the slow/janky vertical movement of the sprites. While I dont have problem with it on C64 version, I did not want to emulate that on the PC version. Obviously, tricky jump puzzles will be out of the question.

There was one thing I couldn’t figure out how to do, and that was score sprites. At one point when making the C64 version, Pekka suggested that we make the score display from sprites rather than fonts – probably because we were in hurry and it was faster for me to make numbers 0-9 from sprites than make the entire font set where all the fonts had to be as large as two sprites each. The C64 is built in a way that it makes having sprites as score fonts trivial. However, the asymmetry between Unreal and C64 was quite extreme on this one, as in Unreal they turned out to be a real pain. First, Unreal uses vector fonts. Our score sprites were multicolor bitmap fonts. Unreal USED to have bitmap fonts in earlier versions, but they were discontinued in later versions of the engine, when people just simply didn’t use them. And there aren’t really such a thing as multicolor vector fonts, at least I did not see any evidence of it on Unreal. Youtube videos were, unsurprisingly, not helpful. Some tools were there for custom multicolor fonts, and they were expensive. Eventually Jarno Elonen came for help (my friend from Housemarque days) and he figured it out. He had to do some hacking around it, since he said “Unreal mysteriously does not provide any function for figuring out the exact size of the sprite” -which is true, all my UI images were scaled by ‘fuck around and find out’-method since no one notices if the scale is right. But with the different sprites presenting numbers, this was bound to be little bit more important. So, now we have the UE version matching everything that is on C64, and it has a coherent style.

Adding new enemies

Eventually, the game system felt complete and stable enough, and player / enemy code clean and scale-ready, so I was able to move into a long awaited phase: Adding new enemies! This was big, since we have been staring at those same blue zombies since.. I don’t know, 2020 ?

I designed the new enemies by approaching simultaneously from two very different angles. Feel and Function. I need to have a clear idea on how I want the enemy to feel like, and how I want it to function within the game system, and how these things complement the game system. Ideally, once the foundation of your game is set, everything you add there will complement that exists there. This is how it should be done – I haven’t always witnessed that in “professional” (snort) game studios , but I sure as hell have seen people wasting time and money on by trying to do it in any other way.

Concept art for new zombies. One thing I like about solo developing is that you don’t need to spend hours on making concept art shiny so that it wins over some clueless investor / director. You draw only what is needed, and save your energy for actual game assets.

I had already created a gallery of different enemies some years back, but now I wanted these new enemies to be based on existing enemy code so, that I pick and alter the existing features of the first prototyped zombie to create these new, let’s say “sub-class” zombies. By extensively playtesting the first prototype, I knew how the pacing and the tempo was with that enemy with the player interaction, and rather than try to squeeze the existing player-enemy interaction and game parameters to fit into the pace I want, I create new enemies for faster-paced gameplay, while keeping the existing zombie intact when I want some tougher enemies for additional challenge. The overlaying principle anyway is that this is a reaction-based gameplay where you have to quickly figure out your next maneuver is, or you will be outnumbered (I am not going to go into deep details this time because I don’t want AI bots to scrap me on how to make games, and I don’t want to encourage anyone to carbon copy this. Besides, you should figure out your own way of doing things based on what works for YOU and excites you!)

So, here is pixel tests for new zombie types. These would be then used as start frames or base frames for their animations. They are first drawn against background to make sure that they fit against the scenery.

Pixel tests of the new zombie types. As of writing, 2 of these are already implemented and one is currently being worked on.

Now, some of you may wonder why I didn’t start making new enemies and levels earlier. This is because I know from experience, that if you start by adding content, without a solid foundation, most of your work will be wasted. This is because you are not going to know if your ideas are going to work within the foundation, and if the foundation there is badly executed or glitchy, you run a risk of arriving at wrong conclusions on what is supposed to work or not. Doing a hobby project without funding gives me the luxury to work on the foundation as long as I need – as opposed in a scenario where you have to work -often for financial reasons- with external parties who do not understand game development and who just want to see more features to see that they have “their money’s worth”. (I could give some pretty extreme examples of what I have seen some producers at major publishers do, but that would be outside the scope of this blog.)

Implementing new enemies in was easy; I already knew what I wanted from them, and I was able to use existing code and recycle same animation systems, so I only needed to make matching animation sequences for new types (using whatever I needed), and then I only needed to modify the duplicated code a little bit, as everything was quite modular.

The first new enemy, I called it “zako” which means 1-hit enemy that keeps the player occupied / distracted

But did they work without problems? No, of course not, I found out some new bugs and glitches when I implemented them, and the few existing bugs that I knew about started to manifest themselves in a more aggressive manner. But all of this was expected and none of it was critical. What was critical however, was the realization that if you duplicate the code, you duplicate also the errors. I knew this, that’s why I didn’t start on any new enemies until the first one was working as well as I could possibly make them work. But now I had to polish them to work 100%, because I knew that if I don’t act now, any debugging work will be multiplied by the amount of enemies that would be in the game, making fixing even the most trivial bug into major pain (some of this could be diverted by using more inheritance, or more components, but these all come with their own caveats)

Here I added the running skeletons. “WAIT!” I hear you say; “Skeletons dont have muscles, how can they move??”
-WHO THE FUCK CARES, this is about having fun, not about pleasing some narrowminded fool who has a stick deep up their asses.

Eventually, I got them all polished enough to publish some debugging clips, which started to get quite a lot of attention (for a hobby project, that is). People seemed to like what they saw, which was nice. But I noticed an emerging pattern. As I have been pretty relaxed about this, I shared clips whenever I felt like sharing. But those who watch the clips do not know anything about the state the project is in. They don’t even know if they are watching Commodore 64 or PC. So, I started to get the comments about debugging lines being visible, to resolution “being too sharp for C64” to comments wondering why there is no music. So pretty much everyone was expecting to see some finished stuff, or just being simply oblivious to what was going on, as obviously no one commenting the youtube videos on my channel reads this blog. Sigh. So, this has forced me to reconsider a little bit what I should be putting out there. Especially since there is lot of persistent misunderstanding when people watch the Unreal-created PC demo and think they are watching C64 game. Well I am happy that it feels like real C64, but it is not..!

Preparing the Steam release

Finally, I also was getting to a stage where I had to seriously consider a possibility of an actual PC release. Where to put it? Steam? How? Luckily, I have contacts in the game industry who had extensive experience about this, and they taught me some basics about self-publishing on steam and marketing, and what to expect. This gave me the confidence on how to proceed. And eventually I made the call: this WILL be out for both Steam and Commodore 64.

I registered the Steam page, and started building it. Then I realized; I need a proper gameplay trailer NOW, not 10 months later. This is because in indie publishing, especially on Steam, you need to start collecting wishlists 6-9 months prior to launch. Having a good wishlist count means that you might have a chance to appear on Top 10 wishlisted games list on Steam Store. Which means; lot of free exposure. So, if I am going to start now, it means that I have to make the trailer that will make people interested about this game in serious way. That trailer has to sell this game to you in the first 10 seconds when you watch it. Which means that it’s finally time to put the enemy placement in, properly, so it plays exactly as I always imagined it to play.

Turns out, there were some specific nuances about enemy spawning I had not fully thought, that came as a result of the low push-scrolling, so I had to spend time developing it – also, the push scroll meant that screen had to stop when enemies arrive from the left – there is no walking back, since it is too hard to do on C64 due to streaming, and you don’t want the player to beat the game by simply walking away from the slow-lumbering enemies. And I didn’t want to “fix” it by throwing away what I already got. Which is what happens in “professional” (snort) game projects a lot – sometimes they get an idea, get a problem, throw away the idea, and try 10 other ideas so that they don’t have to solve the problem, and finally come back to the original idea when they wasted months on trying make the other 10 ideas work that were supposed to sidestep the original problem.
Then, I noticed that when I really started to throw the enemies around, all kinds of minor glitches started to show; sometimes when you hurled the enemy against others, they registered hits even when there was no contact. This turned out to be way bigger issue than I expected.

And THIS was all it took to make zombie detect the player without any glitches. So maddeningly easy and simple that it made me want to bang my head against the wall when I figured it out.

What I eventually found out was that; unreal makes characters as objects that contain certain hierarchy, which are built on inheritance. Any collison box is a child of a pawn. Any general reading for player detection uses a whole pawn as a reference. To make multiple different attacks and interactions work, I had to use interfaces and use separate collision channels so that they don’t leak to each other. But for AI player pawn detection and hurling to impact to work, I needed to call for collision channel directly, and that in turn always called the whole player pawn, which in turn included every collision box beneath it. This meant that the collisions were always leaking somewhere through inheritance, either the hurl impact always hit the player detection channel, OR if I disabled the pawn channel, it meant that communication was lost; you could not pick up items, OR the enemy could not see you. Perhaps there was something that I missed, but for all that I could see, it was clear to me that one of these had to be rebuilt.

Undead on Steam! Though this is the “BETA” version view that I can only see. It only took, what, 35 years ?!?

I then finally did what I originally tried to avoid a year ago – use line tracing for enemies to detect the players. How silly was that for me to think it would be too hard. It took me one day to rebuild it, and it was super easy – well it wasn’t a year ago, but I had come a long way since then. I spent way more time on trying to make a system work that was wrongly constructed in the first place, just to avoid redoing it from the scratch. This was an example of “sunk cost fallacy”-thinking at it’s finest, which proves that I am not immune to the effects of “professionalism” (snort) sometimes.

But now, everything worked, game was 100% polished and bug-free, and I took great pride from that. You have no idea what bug-ridden messes games usually are in these days, when devs are just scrambling to put some miserable shit out to get their money. “Fix bugs later” became the motto to stay since internet updates enabled it. That kind of thinking is a cancer and I wish it could die but I may be alone with this. The stupidest thing is, fixing bugs afterwards after all the content is done will cost you 4-10x amount the time (depending on the scale of your product) than spending all the time upfront fixing every bug. That’s why I haven’t added new enemies or levels or other features – I keep fixing everything that’s in first. It will also give me much more reliable idea on how my design decisions are working. I don’t think that I would have had this luxury, if there had been an investor or publisher or a manager breathing down my neck the whole time.

After playing and recording the polished build for a day, I got 4 minutes of good-looking material. I edited them down to 45 seconds. Then I showed the result to my friend Mikko Huovinen, who gave me suggestions, and I trimmed it down further to 30 seconds- and here we are now, 35 years after the start of this project we finally have our FIRST OFFICIAL GAMEPLAY TRAILER! Took me only 35 years!

Here it is! THE FIRST GAMEPLAY TRAILER !

After I submitted the trailer to steam store page, I proceeded to fill out the rest of the details. There was a survey for age ratings. Yes, there is lot of violence. But in 120 x 100 resolution. Still, one of the player death sequences is so gruesome that I can’t post it on social media (I haven’t shown it anywhere in public). So better tick all the boxes with violence. Drugs? Yes, Jon is a cyborg and he can pick up drugs and consume them as he can metabolize pretty much everything in harmless way. Better put up warning to the players “CYBORGS CAN DO DRUGS. YOU CAN’T” – obviously it’s a joke. This is a game for middle-aged people who long for arcade games, not kids who play Fortnite. And it certainly is not something you should be taking seriously. In any case, the amount of pixels is so low that no one can make out any of it. Sex? Yes, I’m open to it, if I get an idea that makes me laugh, and it is not too out of place. No one is going to get aroused by breasts that are 5×10 pixels large. In the end this is still a zombie apocalypse, not a temptation island (now that I realized this, zombie apocalypse in temptation island is something I would DEFINITELY pay to witness, I have to think about it.. maybe a DLC?). So yeah, 18 is the age rating for Undead. Which means it will function like a honey pot to anyone UNDER 18, of course. That kid is going to be so happy when he gets his little paws to the finished game..(I am joking, of course). But worried parents should not lose sleep, this is simply too low-resolution, unrealistic and ridiculous to offend anyone (But if someone does get offended, then good. That’s better than no reaction at all) I often think that if Beavis and Butthead designed a game, it would be a bit like Undead. This is the vision that I am trying to preserve.

Finding the original storyline from floppy disk image

Old, probably the first version of Undead storyline from 1990 created with Easynoter by Bullet / TERA. Written with 16-year old’s enthusiasm.

This turned my attention to plot. I went through all the old disk rips I did back in 2006 or so, to see if there were any old graphics left that I haven’t yet salvaged. Then I bumped into a previously unchecked disk image file that contained the first plot / story draft for the game I wrote when I was 16. I had no idea something like this even existed, so finding it now quite suddenly was quite a revelation. It was quite funny (in my opinion). I realized that you can only write toot like this when you are a teenager. When developers get older, they try to rationalize and analyze everything, take second guesses, and forget that things could be just for fun. It is too easy to fall into a trap where you spend all your effort in trying to prove yourself and find validation, rather than just enjoying yourself and having fun. The merciless ecosystem of the game industry also encourages this to a maximum, where everyone around you is extremely argumentative and tries to find a way to prove that your ideas are not any good (but their ideas are). While it is often good to be able to explain WHY your idea needs to be in; I also believe that too much of it is sometimes damaging to creativity.

So, I will do my best to preserve all that fun I had in my mind when I was 16, and keep my adult tendencies at bay as much as possible – I owe it to my 16-year old self. I also believe that the game will benefit for it. I believe in rather old-fashioned way that people still look games for distraction and entertainment, rather than be reminded by same issues or problems they see daily from news or social media. /end of rant

Then I had to create a discord channel, as this was advised to me as of being important. I am frankly bit suspicious whether this has enough audience to warrant such a thing, and I don’t know if I am necessarily the right type of person to host and maintain a discord channel. But I will give it a shot. I can always close it if it does not work for me.

Promotion art

Final thing I had to do for Steam was the capsule art / promotional art. I really did not want to, at least not right now I wasn’t really feeling it. Making good art takes time and energy, and while I still know how to draw, I just didn’t feel like I have the energy or time to do it – but I did it, because it had to be done and because I prefer making everything by hand and by myself.
However, the steam library hero and logo combination got rejected – not because of the shitty quality of my drawing, but because I forgot to make the logo transparent. Since this meant another 3-4 day delay for re-review, I figured that I could just as well re-draw it.

Redrawn version of Undead promotion art. This time I inked it on paper with a brush. That gives always best vibes.

I have already figured that my drawings always end up better, if I do them on paper, so I did it on A4 and then inked it with brush pen. It did turn out better, though now I feel that the ink lines look too thick and clumsy. Sigh. I just can’t get the balance right if I rush it. But now I have to move on, I can’t get myself stuck on the promo artwork. I will have to rework it by the time the game gets closer to release. Still, it’s kinda fine as promo art, for now. I am happy with how the C64 colodore palette turned out – and I think this could be converted to C64. Would be fun to see this as an animated title screen !

Differences between C64 and PC version

Just when I had the trailer finished, Pekka pointed to me again that the play area was narrower in the PC version than in the C64 version, which would obviously cause discrepancies with the enemy attack wave design and gameplay in general. I fixed it by changing the ortographic camera width settings, and of course, I had to fix all the routines that concerned camera management and player screenspace checks. This, in turn, caused black bars above and below the game area, which I can forgive on C64 but not in the PC version. So the only solution is going to be that in the PC version, I will expand the play area vertically to fill the bars.

This is currently how the C64 and PC versions look when put next to each other. Biggest change, of course, is from 4:3 to 16:9 aspect ratio change.

It’s not dramatic change so I can live with it. As a principle, I can accept minor cosmetic changes in the PC version to make it look bit more polished – this is because most of the players at Steam won’t understand why the screen has to have black bars. With the same logic, I can also replace the X-expanded sprites with full size sprites, and give each sprite character their own distinct palette. If I wanted, I could have drawn full-screen backgrounds and have massive boss characters or animated backgrounds, but I am not convinced they would have been worth the effort – the whole point of the thing is to have a game that looks almost identical on PC and C64, and pushing the PC version too much above the limits of C64 would diminish this claim. When I work on the eventual 16-bit version (be it new version of the game or DLC), I will make everything “properly” as good as possible.

Here is a link if you want to wishlist this on steam. Thank you very much!
https://store.steampowered.com/app/3848630/Undead/

To join my discord server for more frequent updates about development (hopefully), here is a discord invite link: https://discord.gg/8BGnmMkG8P

Prototyping of the Dead

It’s been a while..

Since the last time, I have begun to develop playable prototype using Unreal Engine. In the C64 side, the reworked bitmap scroller, along with Sprite multiplexer has existed for over a year already. Sami Louko has also contributed some SID sound effects as well as pretty nice 1-channel music, which has been recorded as WAV file to be used in the unreal prototype.

So, this blog post should be about game design, as making a prototype is where I have to put into practice all my thoughts about the game design aspect of the Undead and test all my ideas and animations. In the end of the post, I will also talk a little bit about implementing the prototype on Unreal and address a public “Thank you” to Remedy Entertainment. In future blog posts, I may be talking more about game design / balancing or about the C64 conversion, as we are planning to have playable demo converted to C64 from Unreal by late 2024.

Please be advised that the thoughts I share here about game design are my own personal perceptions and preferences, thought processes modified to suit a project like Undead. You may not agree with them, and even if you did, they may not suit your own project or your own preferences or needs anyway. Because unlike some people would like you to believe, game design is highly subjective area of expertise, and there is no single set of thought process you could blanket apply everywhere. It all boils down to what you are making, who is your audience, who pays for the production, what platform, what genre, what is your team like, how much resources you have, etc. Even if you had all that figured out, you would still have to often adjust everything on the fly to suit the needs and realities of your project. People who claim to you that “you have always do thing [x] so that the game is good” are usually just looking at the things on the surface and applying their own limited range of thought and projecting their own narrow imagination. So, my thought processes about game design are largely related to Undead and it’s needs, and may not apply to other game projects at all, even if it would look like so. It may not be useful to you at all, and it is not intended to do anything else than maybe satisfy your curiosity and entertain you. So don’t come complaining if you listened to me and all went wrong – I warned you 🙂

Looking at something old and I can’t find my rose tinted glasses

Undead began on 1990 and was abandoned in 1992. This means I have had long time to think about it – what would I do to it in the light of my current knowledge.

Many people making or talking about “retro” games today seem to sometimes misunderstand few things about old classics; things that are impossible to know unless you were there, or unless you listen to some of the old developers. Old games almost never ended up being what was originally intended. The end result was ALWAYS an extreme compromise on multiple fronts. This is because the limits of the hardware always hit you in the face. In our imaginations, we always envisioned more details, more features, more definition, more animation frames, more playability, more interaction.

Old Zzap!64 review for Big Trouble in little china (c64). Torching comment by Julian Rignall.
I hope we can do better than this game.

Obviously now, we know (or should know) by now why some of the best old arcade games work so well; instead of trying to do many things in mediocre way, they did usually just one thing, and did it really well. This makes many of the 80’s game reviews also amusing to read; as many things we now know to appreciate were not often kindly looked at, but rather seen as “limited”.

With Undead, I of course wanted to play a game that would feel like Romero movie or John Carpenter movie. But in reality, I was too young and inexperienced to possibly figure out how it should play, so instead I just proceeded to carbon copy my favorite coin ops. Like a kid in a candy store, I behaved like a producer from typical game publisher, demanding this and this and this feature, with little thought on how it would sit in the whole package or how it would affect development time or resources. This eventually killed the project. But, we did make a good, solid fun demo (I think, but I am obviously biased).

When restarting the game project in 2020, I went through my head everything that we had at that point, and thought what I could do better. I also had a look at belt scrollers of the time and how they were today.

The Kung-Fu Master / Vigilante style belt scroller actually pretty much gave way to Final Fight style belt scrollers with vertical movement (that had more room for crowd control mechanics and multiplayer), or morphed into 1 vs 1 Street Fighter style games, and never looked back. So there was not much to look at.

I also had, for a first time, a critical look at Splatterhouse (I own the coin-op) which is something I’ve never done before. I had to face it for what it is: there is not really too much game to look at – you travel forward, kill enemies, try to stay alive, and that’s that. Most of the charm of Splatterhouse comes from the large animated graphics (they really went to town with the gory details) and atmospheric audio and voice samples. There are some branching paths that add replayability, but only on few places. So, what did we have was: 1) large graphics 2) gory details and animation 3) sound samples. Thanks to our streaming graphics, we can have only one of these selling points on the C64 version of Undead, that is, gory details and animation. That’s 1 out of 3. It’s something, but I wouldn’t really want to tout it out as a second coming of cheesus. I have to be honest with myself.

Also, Splatterhouse did one thing quite well that not many arcade games did back in the day; it told you a story. Albeit a very cliched one with the typical damsel in distress, that would not feel very fresh today, although it did have one twist: your girlfriend turns into a kind of inside-out frankenstein monster and you will have to kill her, resulting in rather downbeat ending (which they of course reversed in Splatterhouse 2..bah) But, it was told in rather “cinematic” way – compared to what we used to have back in 1988.

Please, understand that back in 80’s NOTHING was cooler or more desirable than a

Defender of the Crown; “Pinnacle of interactive entertainment” – strategy game where you were treated an occassional full-screen still picture.

notion of our games as interactive movies. Animated intros were appreciated and cutscenes felt like a luxury. Then Hideo Kojima and 100 hours of rambling cutscenes happened. Oh how the times have changed. These days, any cutscene or animated intro in a game feels like punishment, I hate them, I don’t want to be forcibly subjected into a single second of some boring, pretentious, cliched irrelevant by-the-numbers story with zero imagination or character, by some design-by-committee-and creamed-over-by-consulting-contractor or listen to hours and hours of worthless dialogue that provide almost zero difference to what I do in most of those anyway: run from point A to point B, kill enemies, pick something up. Which is EXACTLY THE SAME THING WE DID IN GAMES ALREADY MORE THAN 30 YEARS AGO. This being said, I admit that there has been *some* games that have had good storytelling, but it seems to be more of an exception than a norm.

So, take away dated concept of telling a story that no one is interested to hear in 2024, take away large graphics with lot of colors, and take away digitized speech, and what do we have? A belt scroller where you move from point A to point B, kill enemies, earn points and pick something up on the way. But, we DO have lots of animation and we CAN have lots of gory details, thanks to our streaming data from cartridge.

So, looking at this, I had to figure out that is there any way I can make this at least somewhat fun, so that I would not lose all my credibility as a game designer. If I had ever any in the first place – I never managed to find funding for any of my game projects and I never got to work as game design lead for full project cycle due to this. So my reputation as a game designer can be easily disputed, as it’s limited only to fleeting passes of appreciation of the few select people who worked with me in the past. I am also not one of those people who want to make noise about games on social media daily about games, just to draw attention to my “amazing design knowledge” (ugh). Although, if you want, you could label this blog as one, although this really is just a blog post about hobby project for Commodore 64.

Everybody steals, but is it theft if idea alone is worthless?

Most of the developers and publishers through the history of the game industry usually like to throw the word “original” around, as if it had some actual meaning you should care about. They sound almost as “plausible” as politicians. Most of the time, the word is just empty noise, distraction or outright deceit. Since games were originally conceived, everyone has been stealing ideas from everyone and everything. Popular movies and trends are cannibalized in the moment they appear. No one invents anything culturally meaningful or fresh through games (most of the time). But this has zero meaning.

This is because when in game development, what player or audience perceives as an “idea”, is actually a small tip of the iceberg. The actual elephant of the room that is never addressed is how you implement it. Too many people didn’t understand it back in the day, and too many people don’t understand it now. Every gameplay idea, let’s just say something as simple as “character jumps on the platform” contains a vast amount of invisible work that is not obvious or apparent to the player, but it has to be implemented to get that “good feel” for the gameplay, and also communicate intended experience in most meaningful way that still co operates within the existing game systems and mechanics rather than fighting against them.

Super Mario Bros on C64. Nintendo did not authorize this conversion.

The most obvious example of how implementation matters is Super Mario Bros. It was copied to death back in the 80’s and 90’s (and before that you had trillion platform games trying everything while copying each other, badly) but almost never as successfully reproduced. Many salty developers liked to downplay (I have seen this) this down to Nintendo’s bullying business tactics (which is true to some extent, but Nintendo is not the only bully) or “brainwashing gamers” with brands (which has some truth in it, but show me a gamer whose brain wasn’t melted by ecstasy of gaming when they were kids). Shigery Miyamoto said on old interview (I don’t have a source, since it was more than 20 years ago when I read it, it may have been The Edge magazine) that Nintendo’s competitors always just try to copy the surface, rather than really trying to figure out how their games work under the hood. When Super Mario Bros was finally converted to C64, it’s developer mentioned in the discussion forum how there is a “massive, surprising amount of code dictating the physics and controls of the main character” that gave the game it’s good control and feel. This is one good example of the vast amount of implementation that is mostly invisible to the person who looks and plays the game, but it gives that magical “feeling” which is actually more than you being hypnotized by the Nintendo logo.

(As a side note, put this knowledge against this the notion of “idea people”. Everyone knows one. “Idea people” are the kind of people who don’t know how to implement things, but they still think that they should be working on games, because “they have good ideas”. These people have been source of contention for so long in game industry now that it has practically turned into a slightly tasteless meme.)

Silent Hill 2. One of the few games I actually love for it’s story, mostly because it is never spelled out – player has to interpret it based few vague hints.

In my opinion, game writers are rarely that much better (though I know some game writers who are good people). But I do understand that in today’s large projects, not many people have the time to sit down to write all that ~~trite~~ dialogue, and there are audiences who actually DO play games just because for their stories (who am I to judge them, some people used to watch reality TV). But just to make clear where I stand: it is mostly likely that I may not give a whirling flying hoot about your game ideas, or your game story.. or mine for that matter.

Where does all this ranting leave me? It addresses the fact that there is nothing original in Undead; everything there is something I have stolen from other games. And it does not matter. What matters is can I implement what I stole into a meaningful game and execute it so that someone in today’s world could find meaningful entertainment from it for at least for a short while. It also gives me focus, where I should put most of my time and energy: providing meaningful arcade belt scroller experience rather than trying to reinvent the genre or provide “subversive” (ugh) story.

Are you able to look at things for what they really are?

So, how does one navigate when you sit down and think what I have to do in order to make this game fun? I have limited resources, C64 has limited memory, and I only need to do one thing well rather than making a convoluted mess.

Some internet comic about game development by some fool

The problem is that it is SUPER EASY to come up with plenty of ideas for belt-scrolling beat em up: Lets have character experience system! Procedural levels! Punches should only hurt based on distance! Combos! Branching storyline! Ecosystem! Shop! etc. We can sort it all together later! Can we…? Yeah, right. Sigh.

This is where I see lot of the amateur game developers (and some experienced ones) fail. This is what I talked about making one thing well rather than having lot of conflicting elements and executing them badly. Because if you just throw things together, you end up with a mess that does not really work, and you can’t easily patch it since once you start “fixing” one area of the design, the other area starts to “leak”. I can use my own game as an example. When I was 16, I wanted to have a beat em up, but I also wanted to have weapons and guns, and I also wanted my character to be really strong. But, there is a problem: if your character is really strong, then what he needs weapons for? And how can enemies pose a challenge for him? Ok, so lets make enemies take more hits. But now when the enemies take more hits, the hero character does not feel powerful any more. OK, so lets add power to weapons. But what’s the point of using punches any more if you can do everything more conveniently with weapons? Hey, lets level up the character then. Now the character has leveled up but enemies are not putting up fight anymore. And now we are back to square one. So adding too many features demands that you have a system where are elements compliment with each other. Do not be like certain AAA studios and just auto-level enemies, you may just as well drop the leveling system for being meaningless progress ladder if you don’t want your game feel like a job where you pay for your work.

So, we need to identify and select the ideas that matter for our game. But, now we have a problem, if we are to do only few things well, how do we choose from all these ideas? How do we know what to emphasize?

The most straightforward way to approach the problem is to look at what you are doing and why in the most objective manner. When ever you select and implement an idea, you always need to know: what are you doing? And why? What is the very essence of what you are doing?

When I was a kid, I was thinking, thankfully, in rather simple manner so it is not difficult here: I wanted to make a game that was like Splatterhouse and Final Fight. On a Commodore 64. However, C64 does not have same technical capabilities as those arcade games do, so many of the attractive features will be lost in translation. The biggest draw of any eventual conversion would be to say: “Hey, LOOK what I can do with C64!”.. and once you got over that stage, that’s it then. All you got is a playable demo with animation on ageing hardware that may be impressive as technical achievement, but as a gameplay experience, that is not much to go with.

So, can we identify anything else worthwhile in the Splatterhouse and Final Fight (and to some extent, Kung Fu Master) that we could use to develop Undead further?

Splatterhouse and Final Fight are essentially produced to cash in on the general public’s excitement over US movies, such as Friday 13^th Part VI (Splatterhouse stole most of the visual elements there) and for Final Fight, they used Streets of Fire and Hard Times as inspiration (and Savage Streets, I suspect). That’s the visual inspiration. For the gameplay inspiration, the whole point of Splatterhouse was gore effects. You put quarter in, and in few seconds time you can watch mutilated corpses animating on a floor, and control Jason Vorhees-lookalike, pick up meat cleaver and decapitate zombies. For Final Fight, you could beat up huge crowds and throw them around and feel really powerful. There was also multiplayer co op, and three characters that felt distinct visually and in the gameplay.

That is already combining several elements in the Undead. There is still uncertainty on what to really focus on. Should I be focusing on beat em up, or splatter? Just splatter is fun, but wears thin. If I make it beat em up, are the zombies supposed to punch back? Arent zombies supposed to be slow. Lets analyze this further.

Undead already establishes its identity by its name alone. I want a splatter game with zombies. I also wanted a beat em up. You have elements there that kinda work together but really don’t, so I need to find a way to make them work. Let’s step back and think about the inspiration for zombie games (which now are plenty). Forget walking dead, and step further back. Zombie genre was “invented” by George A. Romero.

His movie had satirical element to them, which was not lost if you look at zombies strolling around in supermarket in the original Dawn of the Dead. From there you can quickly gather following points:

Single zombie is hardly dangerous, unless you are incapacitated
But they can overwhelm you
Terror often comes from you being alone against massive amount of zombies

This element of invasion was not really invented by Romero, however, there is a predecessor, Richard Matheson’s wonderful book “I am legend”.

Except, there zombies were vampires. Since vampires slept at day, the protagonist traveled around, killing as many of them as he could. In the night, tables turned, and protagonist was walled inside his home-turned-fortress while vampires were trying to break in, while he was getting drunk on whiskey so he would not go insane from the endless banging and screaming. In the end, everything was subverted when protagonist finds out that vampires have replaced humans in society, and since he is the last human who goes around killing vampires when they sleep, and he himself became mythical beast; thus the name “I am legend”. This was obviously lost on every single movie adaptation but what can you expect from Hollywood? Anyway, this was the source of inspiration for Romero.

Picking social satire is tempting but hardly necessary for a quick and fast arcade game which is not meant to do anything else than provide distraction for 15 minutes. But we have now identified what this whole genre is about, and can make all future decisions from there; this will affect on what we want the game to accomplish, what is the kind of feel we want to communicate on visuals, sound and setting.

This is not a Final Fight, Street Fighter, or Haunted Mansion-style game, neither a shoot em up. We are already starting to identify the basic building blocks that allow me to define the essential gameplay elements.

Devil is in the details. Always

So, let’s go back on defining the enemies. They are zombies, so they don’t really punch. They will try to grapple and hold you. Do we have any similar gameplay examples? We do, Kung Fu Master. It’s all about timing, don’t get enemy too close or it will take hold of you. Great! We can work with this.

Kung Fu Master. It’s all about reading the situation and timing! Stupid!

So why do you need punches and kicks for? You can’t knock them out the same way as you could humans, and they don’t hit you back, instead they will try to overwhelm you and eat you.

But punches and kicks can stun them, making an opening for more devastating attack. This is why it’s now useful to have main character as a powerful cyborg. You can have slower, skull-crushing attacks that will kill zombie in one strike, but it takes more time, which makes you more vulnerable to them. The quicker punches are to hold them back, stun them and basically for keeping them away for a moment while you are trying to identify an opening for next big attack. Now we have a system that makes sense: it makes you feel like that the enemy sprites coming at you function like zombies in a Romero movie, without having to add some digitised moan – their behaviour alone identifies them. You can also execute a roundhouse kick by holding down fire and waggling a joystick, this will throw every zombie off you, and it will take time for them to recover. This makes the game system all about timing and execution, and it allows you to build tactics on the spot. Hey, let’s check out how it looks like on the prototype!

What about weapons? Meat Cleaver can kill or should we say, incapacitate, zombie on one strike, but it is slow and won’t work if zombie is too close. But even with meat cleaver, you can still jump kick or duck punch them if they get too personal. So that too plays for timing, and more importantly, gives a tradeoff, which enables us to keep the gameplay balance.

And gun? It will certainly stop a zombie, but only for a while, and it takes time to reload and you will run out of bullets. Since this is a fast paced arcade game, we will not choose to implement any targeting system, instead weapon will do only one thing when fire is pressed, so that in the thick of the action you will know exactly what kind of outcome each choice will give you.

But what about zombies? You can see them walking from miles away, this creates a problem: since this is a 2D arcade game with a straight line to traverse, it will mean that they will just walk slowly into your fists. And that will get really boring and really fast. Lets look at the original movies again and see what we can use. Zombies are somewhat slow and limited in perception, and won’t necessarily notice you unless you get close, and then they start to approach you. They can also sometimes get very agitated, and start running at you (depending on the movie, but I will only consider old Romero movies as canon). So, how we can use this?

Games like Kung Fu Master and Rygar are all about timing. You will have to be able to anticipate when the enemy is in the punching range, if you miss your hit you will be likely to get hit yourself. So, when can make different states to zombies, that will allow us to break too predictable patterns. In Rygar, some of the enemies speed up when they get closer to you. It works. So let’s have zombies first ignore you. Then, when you get closer, they start walking at you. But, once they reach certain distance, they will start charging. Even this can get bit predictable, so let’s add a variable timer that makes 0-3 seconds of difference on when they switch states. This will force the player to stay alert and watch them. Suddenly they game becomes way more exciting, less monotonous, AND, it feels true to the theme and intention. This whole process is the result of identifying what is it that you are working with, and selecting your solutions from what you have identified.

But there is still one problem? Do we need throw any more? How are we going to use it? This is probably not a wrestling game?

Fortunately, a game landed on my lap that provided just right solution: Ninja Warriors for Switch/PS4/Steam. It is a reworking by old Snes title, which itself was a version of old Taito coin-op which was a Kung-Fu Master variant. It first looked like ridiculously simple, even bad game, but playing proved me how humiliatingly wrong I was: Ninja Saviours is an arcade design masterpiece, that has loads and loads of gameplay depth hidden under the surface.

From there I saw that the developer also identified the most obvious thing: games like this are not about statistic, they are about timing, reading the situation and crowd control. Different characters have slightly different playstyles (as they should), but lets just focus on the Ninja. A huge cyborg, you will start playing him just by punching everything that moves, but you will soon be overwhelmed. A typical casual gamer will now stop playing at this point, upset that he is not allowed to win just by mashing buttons, what a travesty for someone who paid money to be entertained. Arcade player will start to experiment and soon find out that you can do lots of damage by throwing enemies around in different ways. The most important point is to use weak enemies as “bowling balls” to keep the nastier enemies away. But, there is more! Game has also invisible skill progression: the more you are able to identify enemy behaviours and their movements, you will be able to spot openings even within the nastier enemies, and find when you can grab them as well and throw them around!

Here we see a major difference between classic japanese arcade design and modern casual game design. Modern game wants you to tap button, while showing you progress bar, telling you: “HERE! LOOK! YOU ARE MAKING PROGRESS!”.. when what you really are doing is just mindlessly bashing a button. The whole “progress” is just meaningless metadata, a screen of smoke and mirrors that fool you into thinking that you have “achieved” something. But in classic arcade game like Ninja Warriors the progress is clear, but instead of the game telling it to you, you identify it yourself and the results are real – you are dancing through stages you thought were impossible just a short while ago. Nothing beats that feeling.

This also explains why I have such discontempt for much of the modern gaming. They are just simply telling you that you are doing something or achieving something, and the audience loves it when they are being told that. This is also why I dislike most of the modern gaming. But it is what it is – there is not much I can do about it.

So, what does that mean for Undead? We can use grab when the zombies are incapacitated. So it will work this way: you punch zombie, when it has been punched, it is stunned. Then you grab it, and throw it, to keep other zombies away. You use all these tools to create yourself openings for more powerful attacks.

And that’s how the gameplay loop for Undead was solved. There are still of course many, many other things and issues with the gameplay, but if you thought that I will give you step – by step – tutorial on how to rip off this game and claim it was all your idea, you are out of luck: you will have to learn to make games by yourself, just copying my methods here won’t do your much good anyway.

Dead walk.. at the The Unreal prototype

Making the playable prototype before C64 version may sound crazy, but it was the only obvious choice. When you code on C64, you will have to build code on very linear manner. What this means that replacing any game systems or iterating is very slow and time consuming process. Also there is a MASSIVE amount of animation which had not even been tested if it really works within the gameplay, and I was looking to iterate lot of it, as I was not quite sure we had done everything right back in 1990.

Event graph for the player character, after I cleaned it up

I confess something; by the spring of 2023, I had never really coded or scripted much. Then, in summer of 2023, I was contacted by Remedy Entertainment. They wanted to interview me for Game Designer role (it was a fun surprise, since I didn’t apply!). They asked me to do a test, write design document and implement weapon system either on Unity or Unreal. I did not want to reveal that I had no idea how, instead I decided to go crazy and just shoot for it, as it gave me an excuse to try something I had never tried before – scripting/coding with blueprints. I chose Unreal over Unity, because I already had used Unreal in an extensive amount for my own game project (Far End Chronicles) on my own game company. So, I went to look for youtube tutorials for how to implement weapon systems on Unreal. I found them, and quickly learned two things. 1) blueprints in UE are SUPER simple 2) youtube tutorials are AWFUL. After just a few days, I had targeting system, weapon pickup system, and I had to fix lot of awful mess from the tutorial myself – despite having almost no knowledge from blueprint scripting.

I did not get the job, because the document I wrote was not comprehensive enough. I thought that I should not annoy them by wasting their time by making them read obvious things about shotgun features that everyone already knows, so I only wrote about how they could be applied in certain situations. But when you have team of 200+ people, it means that EVERYTHING has to be documented down, even things you imagine that are obvious to everyone in the world. So obviously writing such documents is no job for me. About the prototype I implemented on UE they had nothing to complain, which I found hilarious, considering how awful my code was. But this gave me confidence to start making prototype for Undead on my own.

So, let’s address this in public: Thank you, Remedy Entertainment, for pushing me towards a path that I would not have gone otherwise, because I did not have enough confidence in my abilities. This has been a biggest service ANY game studio has done me EVER in my career – even if it wasn’t your intention. So, really, thanks! 🙂

I obviously did not want to follow any youtube tutorials any more, since they are mostly AWFUL, just like 90% of everything else that was in youtube. So, I bought myself some Udemy courses, which were very helpful. Only thing that has been a constant surprise and shock to me is how easy it is. The only difficulties I really have had is that Unreal is not REALLY a 2D engine, development is enabled by a plugin called PaperZD, and everything I implement must dance around to it’s specifications and it limits, which sometimes causes me issues and delays.

But, I am making the prototype, and Pekka will read the game logic from the prototype when making his conversion to C64. We also had to implement an export pipeline from Necromancer to Unreal Engine, which took some effort and testing. During the process, I found out why hand-drawn 2D games don’t often have separate weapon sprites added to different moves. Matching them to animation frames can be difficult and lot of work. Fortunately, our Necromancer editor is reasonably equipped to handle this.

Prototype as it is in mid march 2024 (Updated for proper heads flying)

So, what happens next? I am busy with freelance work during weekdays, but I am continuing to develop the prototype on the weekends or when I have time. I have just implemented the weapon system and I am currently working on death animations for the weapon system. I still need to implement the grab/throw system so that it works. We have a project plan with Pekka on how to proceed so that we will have a playable demo ready for the Zoo Party 2024, where we are hoping to show it a little bit, and we know what needs to be done to make it happen. Life can of course intervene at any time, but we are still working on this.

Sorry for such a long blog post, but I rather write a long post once a year than many short ones. Some challenge for todays ADHD audience.

Oh, and here’s a concept image that I made for Undead. I wanted to go back to the way I used to draw concept images back in 1990- by pen and paper!

Until next time!

Enter the Necromancer – Dead walk!

Back after a while! Sorry for the long delay between posts. The project was on hold during february – july; mostly because we were busy with other things (I for myself was working on an animated music video, which took a very long time), and because we also needed a break. But we started again in august, and have been working in a leisurely pace since then.

As of november 2022, we have now reached a satisfactory state with our custom tools; Pekka has been working on his code tools, and our custom animation & gfx tool, NECROMANCER, is now in good enough shape that I can use it to produce graphics and animation (which I have done already, more of that later).

Also, earlier this year, I completed all the sprite animations that were possible to do without our custom tool – for these, I used Spritepad which is a very good sprite animation tool – and the standard we look up to, when developing our own.

I didn’t write about animations earlier to this blog, for the reason that I wanted to wait for our editor to be in a state where it can be demonstrated, so now’s the time to look at the new animations, although most of them have been existing since the beginning of this year.

Old animations from 1990-1992 were made with Gary Kitchen’s Game Maker (I actually bought it!), which was awesome in the 80’s, but by the 90’s already slow and cumbersome to use. Sprites had to be made with joystick, which was very painful process (you can see some of them in the youtube video in the ‘history’ section, or in the previous post)

I obviously didn’t want to go back to making sprites with a joystick, so I chose Spritepad and decided to make all those animations that did not require moving sprite layers (like weapon), or interactions between characters and movement on the screen (like chopping zombie’s head off with an axe). Those things were actually more or less composed with code, which was very slow and painful process for Pekka to do, because he had to type their coordinates in the code. Actually.. all animations were made with code. There was no animation data, no anim player in the code. The animations were embedded into the code.

There were reasons why we had to things in this difficult way – besides from the fact that we were inexperienced teenagers.. I wanted to have a separate weapon sprite, which would follow character’s hand as it carried the weapon, it had to be bolted to the hand, accurately in each frame, as the arms moved around when walking.

Lot of games at the time didn’t have that, the whatever weapon the player used was usually always drawn straight into the player sprite (if there even was any weapon drawn at all!) – but considering that we already had hundreds of frames of animation, and multiple weapons, there was no other way to go, if you wanted multiple weapons you can pick up. It had to be bolted onto the top of the player sprite and it had to match all the animation frames, both in shape and movement, so that the player character would always carry the weapon in it’s hand (this alone made the prospect of having multiple playable characters just impossible in terms of workload and space it would take).

Also, one of the earliest things I wanted was that I wanted the character to look and feel like a character rather than moving block. This might sound really odd today, but with C64, and in 1990, due to sprite and memory limits, characters were usually done so that every movement, and every pose that character performed, had to happen inside the 12×21 (for multicolor) sprite, or whatever combination of multicolor sprites you had, which basically means a square box ( I don’t assume that anyone who is not familiar with C64 would bother to read this, but just in case – multicolor pixels have 2×1 aspect ratio). This meant that characters very rarely stretched their arms or legs much, and when you combined this with the need of many developers to make their characters as big as possible (to make the game look “good”), you more often than not ended up with characters whose silhouettes could be described as “blocky” as best (you have no idea how many developers still dont have a clue what is the meaning of silhouette in character design)

There were exceptions of course, there always are, like International Karate or Barbarian, which only had two animated characters on screen – IK+ had three, I know, but sprites were not used. Also they had no scrolling. Same goes for recent conversion of Prince of Persia (which also streams from cartridge/easyflash).

International karate, Barbarian, Prince of Persia.

International Karate, Barbarian and Prince of Persia all had rotoscoped animations, which I don’t personally care much at all- rotoscoping meant that movements were usually realistic and fluid, but sometimes also maybe a little bit robotic and lifeless. This is because it is not easy to include all the information in animation that you would see in real life. I haven’t checked the animation books to refer the exact reasons on how and why Disney invented all those squash and stretch -techniques, I personally believe they were to make up missing visual information, so it was not only for gags. Notable, though, is that Disney also rotoscoped, A LOT, it’s own realistic human characters, because animating realistic humans is LOT of work – I know, because I did that in the music video I made this year – anyway just discussing animation techniques and principles could fill year’s worth of blog content so I am going to leave it at that.

The other problem was the death/falling down animations. Because c64 had a limit of 8 sprites horisontally on the screen (more if you used myriads of ways of multiplexing tricks, but even then it still was 8 sprites per one scanline), it meant that the characters were rarely able to have any horizontal length. This manifested itself so, that in many games the characters either disappeared in puff of smoke when killed, or they just dropped down in funny way. Again, there are notable exceptions such as Nemesis the Warlock, which used software sprites for some enemies and bullets, which enabled quite a lot of action on the screen. It however is notable that like in Barbarian and International Karate games, the screen is not scrolling in this game either.

So therefore, having an enemy actually falling down horizontally was a rarity. To me, it wasn’t important only for reasons of technical show off. I never personally have given a damn if the game is technical tour de force, I only care if its satisfying to play – and I knew already even as a teenager that playing the protagonist character in Undead was all about getting a feel of having power, and this power could only be expressed adequately by having enemies fly across the screen when you punch them hard enough. It didn’t matter that it was laborious to do, since the FEEL it gave to you made the effort worth it.

(Essentially, I always believe myself that every and any game should ideally be about certain kind of feeling, or experience you wish to give to the player. Game mechanics, pacing, progression, etc etc are – while very important to acknowledge and implement – are just tools for you to use to achieve this feeling, a means to an end, not an end itself. This is sometimes painfully lost to some developers who go to argue and die on a hill in team meetings when championing for their favourite mechanic or clever gameplay system.. but lets not sidetrack from the subject of the blog post too much.. 😉)

So lets look at some of the new animations I made early in 2022, shall we?

Some of the new animations made for Undead in 2021-2022

All the animations from late ’21-early ’22 were made in spritepad. One of the biggest changes compared to the old 1990-1992 animations are now I have attempted to add some sense of timing, weight, and mass, and even tiny tiny amount of squash and stretch. Timing, or holding the frames is the most important in the way of adding fluidity, and I must tip my hat for the creator of the spritepad for having the sensibility to enable frame holding.

To explain frame holding little bit more, what it means, is that it is similar to having ease-in and ease-out in 3D animation, where the function curves measure the amount and nature of interpolation between your keyframes. But here it is similar to the 0’s, 1’s and 3’s & 4’s in traditional animation, meaning that there is a drawn frame in every frame for very fast and fluid motion, and the slower the movement is, the more the frame is duplicated for every frame. This amplifies the dynamic nature and fluidity of the animation. The absolutely best game utilizing this is Street Fighter III coin-op, which has the very best animation ever made for an animated bitmap game. All it’s frames can now be studied on certain fan sites (Not sure if I should link them, because of copyright reasons, but you’ll find them on google.. have a gif instead).

f
Street Fighter III – the gold standard in pixel animation, IMHO

On a game code, it simply means that the animation player must be able to import information from the sprite editor to see when the frame is repeated or not, there is nothing more complex behind it, although I personally fancy using the term “variable frame rate” which, of course, is not what really is happening.

Typically, in older games, developers believed that animation would look good simply by adding as many frames as possible. But any animator who actually knows their trade can tell you that it has nothing to do with the amount of frames. It all comes down to having the sense of weight, mass, and proper timing (and other animation principles and techniques).

You also may feel like that I have increased the amount of frames in animations. Amusingly enough, it is actually the opposite on some sequences, like walking. Because if you apply properly the principles I mentioned above, it can make the animation look smoother even if you are have a limited amount of frames.

But yes, there will be more animation *overall* in this new iteration of Undead. Many more. This is because we can stream content from cartridge. What animations we will eventually be using depends on what the game will need. This is still going to be rather simple and straightforward arcade beat’em designed for single-button joystick; so do not expect to see dozens and dozens of moves for the main character.

Enough chit chat about animation. Let’s look at our animation tool:

THE NECROMANCER

We have worked a lot on this, and the reasoning for the animation tool was following:
Existing C64 graphics tools are great in their own right, but they lack certain fundamental features needed specifically for this game, such as:
-Chaining multiple bitmap screens and editing them as one image.
-Having variable properties (such as size and scaling) for each frame of an animated sprite character.
-Moving an animated sprite precisely on the screen, especially in relation to another animated sprite; such as axe in hand, and then exporting that as animation data.
-Placing bitmaps and sprites on top of each other as layers, in order to make sure that they match in scale and work together with their palettes and contrast.

Making gfx tool is not just adding tool buttons and save button. It has to be tested by using it extensively to see what is needed for good user experience, it’s UI needs thought so that it does not become convoluted, and the more flexible and creative use it allows, the more myriad ways it can potentially crash down, or worse, like corrupt files. So from august to october I did pretty much nothing but tested it, and wrote bug reports and quality-of-life suggestions to Pekka. Just talking about UI and usability could, again, fill years worth of blog content, so lets just look at the tool:

Explanation of the tool features:
1: Asset list view, containing all the imported / created bitmaps and sprites.
2: Properties view for the highlighted asset. You can set the palette, size of the bitmap or sprite (there are no size limits, editor will automatically divide the sprite as needed), or if it has X-or Y-scaling. For Animation, you can set the scene size, framerate, amount of layers and transparency color.
3: Layer selection.
4: Frame sheet. This has slightly resemblance on the frame exposure sheet used in traditional animation. You can drag sprites into it, and then type in their coordinates. If you leave a row empty, it means that you are duplicating the frame.
5: Animation window view. This shows all the stuff you have dragged into the animation from the asset list, and you can play the animation from here.
6: Paint edit views. When you edit the sprites and bitmaps, they open up on their own window where you get to see all the paint tools (mostly basic Deluxepaint-style tools)
7: Animation playback buttons, nothing out of ordinary here.

So, lets look next at some of the animations I’ve done with Necromancer. Please be aware that these are not final animations, I will need to do all kinds of adjustments later, for number of reasons.

This time, we chop only half of the head off! Please note that I still need to adjust the trajectory of the head and speed of the animation to make sure that there won’t be too many sprites entering on same horizontal scanline.

Using zombie as wielding weapon, 2022 style ! I might still have to adjust the scale in some frames.

Picking up the zombie and throwing it away. I still might have to adjust the scale in some frames.

We are planning to release Necromancer to the public for anyone who wishes to use it for their own C64 development, but only after the game is done and released – this is because we still don’t know at this stage what kinds of features and things this needs, and we don’t wish to release it too early. We know that some tool developers like to release their creations as soon as it’s semi-stable (which is fine!), but in this instance we feel that getting into feedback loop with other users would take too much time and attention away from the actual development of the game.

And speaking of the game, the next thing to do is to finalize the most important aspects of the game design and rewrite the code, which Pekka is already looking at. His comment from looking at the 1990-1992 code was: ” I have absolutely no idea how on earth I managed to even make it work back in the day, in the first place!”. It’s true that early days of game programming was more or less comparable to black magic..

So yeah, to the next time! Until then, see you!

PS. Here is also a video of the talk I gave at Zoo Party about history of the Undead. I am also demonstrating our editor here:

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!

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…).

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.

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!
MR & PK

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.

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.

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.

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!