In this blog post I talk about what went on from late 2025 to late 2026, completion of core game mechanics, refactoring and making the game more stable, first testing round, then the process of enhancing and reworking the game to PC version, and finally entering the production phase.
Finally I will talk about how it transitioned into actual arcade machine, and the unveiling of the arcade version at Zooparty 2026. I also talk about how recent developments in game markets and game industry made me change my plans.
It’s been a long time since I made the last post, again. I have been simply too busy. It was also my intent to not write another blog post until I have finished the game, but lot of things changed during our road. Most importantly: Undead is now a real arcade machine, assembled and sold by Reprocade ltd. This alone was significant enough to warrant a new blog post. I try to give some of the reasons on this blog.
Completing Core Game Loop
First thing that happened after last blog post that I realized that since I now have complete control as how this game is going to shape up, I want to add all the features I had wished on the many decades I spent thinking about this game. It was not the case of wanting “everything and kitchen sink too”, more like a very definite set on certain mechanics and interactions.
People always assume that I am just “making a splatterhouse clone for C64”, because is what hobbyists and first-time developers do, when they begin on their first game project. Take a game they like and attempt to reproduce it. To a certain extent, it was also true when I started to put this together with Pekka back in 1990, we attempted to recreate a mix of Final Fight and Splatterhouse.
However, what people still may not always realize is that in the between, I spent three decades in game industry (I have credits for 15 published games on Mobygames, feel free and check it out yourself) and picked up a few things along the way, including very definite picture what you need to implement in a game so that it is fun to play, does not feel too repetitive, has replayability, and scales to more skilled players. Most people assume that you get it simply by adding content. Many people in game industry imagine it as well.
So, being now the programmer of the game, I started implementing things I personally found most important.
I began by adding the weapons “I always wanted but was afraid to ask from Pekka”. I made the pipe and 2×4, and made their death animations context sensitive. This means, if you smash enemy on front of the window, it will go through the window. When I shared clip of this, it became a massive hit, scoring over 500 likes and it also sharply boosted my wishlists. The amusing thing with this is that it is EXACTLY a kind of feature where I would have experienced a pushback in game studio, because it does not really add to gameplay – its just fun and it adds immersion. But these are important.
Then I implemented a chainsaw which splits enemies into two pieces, I wanted the upper pieces of enemies still crawl towards the player, which required me creating a new subclass of those enemies. Again it was work that was worth it.
Then I made throwable items and guns you can pick up shoot with. I have now roughly five distinct weapons / weapon systems that have different feel on the gameplay and add more ways for the enemies to die colorfully. Each weapon adds tremendously to the animation workload, but again, it’s a kind of workload that adds also a lot to the “feel” of the game.
Much of what happens in the game, and the work I have since done, is invisible or not obvious to the player however. I mentioned them in my last blogpost. Some of these are things that players wont notice until they play for hours, such as score hit multiplier, rank system and dynamic difficulty. These all may perhaps sound a bit complicated, but the code running these is necessarily not – it’s all just design and intent.
The intent is that game measures how well you play, and scales the difficulty up and down depending on your performance. This can be very polarizing feature, but that’s because if it’s not done well, it will feel unfair to the player, making it feel like it punishes you for success. My dynamic difficulty is different, it prevents more experienced player from getting bored and gives some relief to players who clearly dont yet understand the game systems.
You must forgive me for not describing in detail how these mechanics work. This is because someone could these days just prompt my desciption from this prompt into claude if I make it too detailed and descriptive. Although it won’t guarantee any promptslopper a better game experience, I would still feel quite annoyed if it happened.
All that I could say is that the common misconception I had from term “Rank” is that it’s a “judgement on player”. But it is not a school grade. I am following a Japanese arcade convention of Rank; meaning that it telegraphs the difficulty level of the game, while being also a reflection on what the player can or can’t handle. I know there WILL absolutely be players who are going to get confused with this. Let them. Everyone who loves and knows deeply japanese arcade coinops will immediately know what it means. Rest can read the game instructions or figure it out by playing – it’s not rocket science.
So, after I included rank system, hit counter, hit counter timer, visualization of the hit counter level reached and tied game parameters to it, I had quite lot of fun trying to get to S++ level and then trying to stay alive in it.
Then we discussed with Pekka about the level timer. I knew for a long time that we need something to force player to move on. I was thinking of either some monster chasing the player, or player autodestructing when time runs out, but then Pekka pointed out that having a time counter on the top UI was no longer possible on C64. I dont remember the exact reason, was it sprites running out (due to sprite score) or some other timing issue (bitmaps and sprite multiplexing was already taking lot of available time).
Then Pekka suggested an energy level that was running out. I agreed wholeheartedly, after all, character is supposed to be cyborg so why not giving him a “Cyborg problem” – his batteries would be running out, which then would mean that he needs to find items that give him more energy. That “recharge as you go” system works already quite nicely on Sega’s classic Wonderboy.
But since we already were on that path, I realized, after implementing an energy timer, that there is some unused room on the top of the UI – why not add another timer there. I remembered the recharge timer in Ninja Saviours, and decided that the character needs Special Attack that clears the whole screen when you hold the button, and it can be activated only when the charge is full. However, if you take a hit, the charge is cleared, so it is a bonus weapon only for players who are able to stay alive -without taking any hits- for a certain amount of time. There are more detailed and context sensitive nuances on these mechanics than what I wrote here, but I’ll skip that because I can’t give everything away.
Then I needed to implement a nice looking special attack animation that can still be doable on C64. There were no more free sprites, but no problem, you just clear the screen of everything else. I love the 3-way lightning attack on Capcom’s Ghouls and Ghosts, so I created a special attack based on that. I also want the character to hold up his weapon while doing so, to give it a proper He-man feel, but of course it added to workload because you need to add an animation state and frames for all weapons for this frame. However, I believe it contributes so much to the atmosphere that it is worth it.
Then I wanted to add functionality to all the items I had already designed 2 years ago. I want this game have lot of items, perhaps a bit to the direction of games like Bubble Bobble, but to avoid multiplying my workload. So, I create items from components, like if I want the item to increase some stat, I created a component which raises this stat, and if I want component to have certain effect, then I created a component to have that effect, and then I just assembled the item code from these components I created. I have 12 sufficiently distinct items now, but I can later create fairly easily huge number of variations out of this setup.
Then, I realized that I had not considered how the character should react when it gets hurt during crouch state, so I added crouch state it’s own hurt and death animations.
After I did all these and few more I decided that it is now time to put a feature lock on it, while I still am able to maintain the code. Even though this is the first game I have programmed myself, I have watched enough “professional programmers” to know how important it is to be able to maintain and scale what you have made. I knew, of course, that I would have to add things later, but this meant that I can only do so if it is absolutely mandatory in order to complete the project.
But I did not want to start making new enemies yet – I wanted to test this to see if this thing stays together. You wont’ be able to see if everything works all right just from your own playtesting because as a tester you may already be settled on certain playstyle that may not necessarily trigger conditions that cause bugs. So playtesting was in order.
Refactoring and testing process
I began playtesting by giving steam keys to my friends, letting them play it, but it was a disappointment. Not because game was buggy, but because they played it only once or twice and said “it’s fine, no bugs”. Well, it’s not fine, there are lot of glitches but the fun part is that they don’t always show up. So single playthrough won’t tell you anything useful. However, not many of my friends are really able or willing to go through the *real* playtesting process which is actually lot of work. This was unfortunate but I should have been able to expect it – most of the people dont really understand what playtesting actually is. They think its just “play game and have fun and report all the funny stuff”.
Fortunately, I knew some maniacs from Shmups forum who live and breath arcade beat’em ups, and I asked them. Thankfully, I began to have some results. One of my tester recorded videos of his playthrough on steam and was able to pinpoint massive amount of problems on collision hit detection and state machines.
I had issues of enemies sliding towards the player on the ground despite they were supposed to be dead. What made this particularly painful was that their behavior was created with Unreal’s behavior tree, which is an obtuse black box for me. I fixed as much as I could, but the problem persisted.
After much hassle I found the root of the reason – delay nodes. I may have mentioned them on my last blog post, but even back then I had no idea how poisonous they were for complex animation systems. See, delay is very simple and easy way to instruct the CPU to hold on until certain amount of time has passed. But the issue is that in Unreal, if you jump away from that function path before it has gone to the end, the ticking delay node still exists, and once it has gone through the delay, Unreal will perform what comes after it whether you want it or not. Hence, chaos. The Udemy course for making games makes all it’s examples with using delays because they work very well for extremely simple 1-button games where player and enemies usually have only 2 or 3 states. It achieves it’s goal of teaching game logic in simple form that can be learned and understood by beginners. But if you begin to increase complexity, you are going to have problems. This means that none of the kids trying to make their dream game from Udemy course are not going to cut it unless they teach themselves more programming features like interfaces, timer handles and event dispatchers.
Eventually I realized that I have to get rid of nearly ALL of them. I replaced then with event timers and timer handlers, moved some of the animation logic into the animation frames where a certain frame can initiate an Animation Notify State. I rearranged the general architecture. Eventually I managed to squash the issues, but there still was an issue of enemies not always activating a proper animations when they were thrown. But at least they knew when to stay dead!
Pivoting away from C64.. why?
I will address here why no progress has been happening on C64 since the Zooparty 2024. We had already agreed with Pekka that it is better to finish this on PC before making it on C64, making the C64 version essentially a conversion.
Then few things happen to me simultaneously. First, I began to see some discontent when I was posting screens to C64 user groups. Some people were really annoyed that I was posting Unreal screenshots. I had pm’s telling me that they are not going to even play the PC version, they just wait for C64 version. In generally, people were first told that we make this for C64, but then they hear that it is being made for PC, they don’t understand the reason and feel let down, disappointed and annoyed.
At the same time, Pekka had a personal tragedy happening in his family which I won’t disclose here (out of respect to his privacy), but which meant that he no longer had the time and energy to do the C64 version at all – and I do not know if the situation is going to change. If I had not started making this for PC, this would have ended the same way it ended up on 1992, where I had been left with a pile of some graphics and unfinished demo and dreams that were picked from storage only to be broken once again.
But now, to add on insult to injury, I received private messages where people were telling me that what I do on PC is now fake and not worth their time.
My only reaction at that moment was to not reply to them while I quietly thought that they can go and.. well, you know. I am doing this game for myself, and if making it for PC is the only way possible then so be it. But I am not going abandon the C64 style, because I want this to be TRUE to the identity of what I had in 1990. Pekka also told me that I should make the PC “my directors cut” where I don’t have to worry all the time is something can be implemented of not. If I want to implement them, just implement.
Then two more things happened. First, youtube video came up where someone discussed the game clips had shared (because I had shared freely and openly my work in progress clips because I did it for fun) and playing the great investigator, this ..person showed on his video how he found debugging messages “which reveal that this is running on Unreal, not C64!”.. it probably never occurred to him that if I was truly trying to “deceive” poor C64 community then perhaps I would have wanted to hide those debugging messages. Apparently he felt it was his public duty to “show the public the truth that C64 version is cancelled”– well, the C64 version is not cancelled, but it is indefinitely on hold. First because I am not going to even think about it until the PC version is completed, but also because I do not know if Pekka is able to resume work once the time begins.
There is also a real existing risk that if I don’t have available programmers to do that conversion at the time when this is ready, then there is a possibility that I may be eventually moving on to the next project and then I will be too occupied! But it is not my intention to let that happen. I want it for C64 just as much as everyone else, I am making all my design decisions thinking “how can I make this on C64?” – if I didn’t, this game would be quite different already.
Then another disaster happened. There exists a C64 game news website, and it’s owner decided to share some of the clips I shared of the new gameplay mechanics.. with AI generated images of my artwork. I lost my cool completely. I blew up. This was the biggest insult anyone has ever done to me. I loathe AI slop images already for reasons that should be clear enough for anyone, but even allowing AI slop images of my game could genuinely hurt me in serious way if they spread and public starts to think they were authored by me – this could destroy my reputation. I sent immediately cease and desist letter to this website with a mention that I could enforce takedown notice on a basis of copyright infringement. Images were taken down.
I started this transparent sharing of my free time project on social media just because it was fun to share everything I do, but when I began the AI apocalypse had not yet happened. However, this was the last straw which made me decide to stop sharing anything on social media any more. I was also getting worn down by some toxic people picking fights with me on C64 groups acting on bad faith that I was “deceiving them”. I am not a C64 programmer, I am doing what I can to make C64 game happen with someone I trust (I won’t make games with strangers, my 30 years of experience in game industry taught me that much. At best I could use unknown as outside contractor with no ownership on the game itself). And if that is not possible, I will scrap it together on my own hands with whatever I can (except AI – it has to be with my own hands, not with some clanker). Putting all my free time on this for years on end already takes toll enough, and the last thing I need is to get grief from some ..person on the internet.
So, complete social media blackout was the next step. I still kept giving text updates on what I did, but no more screens or images. My work was now off limits to public and I don’t owe them anything. I also don’t have the time or energy or motivation to explain all of this to some troll on social media, who is typically just trying his luck on my scalp using what I shared on bad faith basis. I also don’t need AI sloppers stealing my work, I have enough grief and hardship already without some low-effort lazy fool thinking that they are “improving” my work with their slop.
Enhancing the PC version
So, now I had the thankless task of figuring out how to enhance PC version. I knew that redrawing it for 320×200 resolution was out of the question for the simple reason that there is absolutely no way I would be willing to rework thousand frames of animation in completely new resolution. Necromancer also only supports 160×200 resolution. But what was fun thing to find that due to small programming oversight, Necromancer allows you to put all the colors from C64 palette in a single sprite, allowing each sprite to have their own individual palette. You have no idea how much frustration the sprite color limits caused me. Being able to pick the colors I want (out of the existing C64 palette) is a godsend. So I decided to enhance the colors for all the existing thousand animation frames. This was faster process than you may think, and it also enabled me to clean up few things on the way. The original C64 sprite animations are not thrown away but kept safe.
I also added some specific animation effects that were out of the question for C64- due to there not being enough available sprites on screen, namely motion blur effects for throw and hurl. Then I added visual effects like small clouds of dust when character lands on the ground, or bigger cloud of dust when characters falls on the ground horizontally. I also redrew all X-expanded sprites as the horizontal double sized pixel trick was no longer necessary. The final thing was to rework the background and UI.
On C64, the hard limit for background was to have only a half of the screen area, because that’s the upper limit on how much graphics data can be streamed from the cartridge. Now I was able to have full screen, so I can make it look more like an arcade game. I also removed the ugly box UI which was created out of necessity for the C64 version, and created more modern-looking masked UI on top of the screen. I went back to my 2021 reference source materials to fill up the missing bits from top and bottom of the screen. One thing I was unsure to the end was if I should make the cars to be 1980’s models or 2020’s models which are quite different. But I was too tired and felt too much pressure so I just had to move on, so I simply used what cars the google street view gave me. I could get the 1980’s models simply by getting images from any 80’s movie I have on my bluray collection, but that would take too much time.
Then I added parallax scrolling and front layer objects, and dithering mask so that pixels of characters would show through the foreground objects, so that they don’t obstruct the gameplay too much. Now, I could have just faded them out in real time, but even if it’s possible on PC, I absolutely refuse to use visual tricks that would steer too far away from what C64 can do -I want visual consistency, and I am going full in with my vision of “Commodore 64 but what I wished as teenager that Commodore 64 could be”. Or just “C64 on coke”.
Around this time, I changed completely how the enemies are generated on the map. Previously they were just placed into the map, but arcade game like this needs lot of enemies on extremely tightly controlled pace, which is further enhanced by the dynamic difficulty. So I created dynamic difficulty spawners which spawn enemies from several different data tables. I wont go into details, but if you study any good arcade games, you will figure out yourself how these work. I also made items spawn out from data tables.
Then, the final and most dramatic improvement came from initiation of Jarno Elonen, my friend, old colleague from Housemarque and contributor in many projects I have done in my life. I asked him to do CRT emulation for me, but a good one, I just did not want lazy scanlines. He said that to really make CRT emulation look good and proper, I should have a true 320×200 rendering in my game. To avoid confusion, I should point out that even in multicolor mode in C64, the pixels move in 320×200 grid, not 160×200 grid. So instead of game just pretending to be C64 in PC, it would have pixel perfect scrolling rather than sub-pixel scrolling. It would also enormously benefit the C64 conversion, because the movement would match more closely what C64 can put out.
What Jarno pulled off looked amazing, his CRT emulation was way better than what I had seen in other games and really enhanced the look of the game. I know there are people who do not like CRT filters in their pixel games, but I believe this is because most of the time these are not done very well. Here is a video example. This was the last video clip I shared before I began the media blackout:
One important thing you should know is that the CRT filter is not enforced, but optional, AND it is NOT featured on arcade version at ALL. This is because the arcade version is built from ground up to work on JAMMA standard interface plugged into CRT tv monitor.
Moving to production phase
So, I was FINALLY, FINALLY in the phase where I could make new levels and enemies, which was a relief. But where to start?
The worm room, obviously. This was our “Lost level” from 1992, one of the final things we did with Pekka before the game was abandoned. I always lamented losing the disk where it was. Now, obviously it was inspired by Splatterhouse, but I found out that the boreworms in Splatterhouse were not exactly original creations by Namco either, but actually lifted straight from a B-movie called “Parasite 3D”. That was reason enough to keep them. I designed them after my own style and taste, of course. They also have more precise collision now compared to our 1992 version; only their teeth pixel area will hurt the player, which made the game more playable.
Other significant improvement was that they also have distinct death animations, cleaver will slice them in two, pipe will smash them to a wall, jatimatic and special attack will make them explode.
This took me roughly 3-4 weeks. Then I began making the Mutant Man & Mutant Mountain I had sketched 2 years back. I had no other reason than simply really wanting to make it. I still want to keep my “amateurish” approach of not giving a damn when that scene is supposed to occur; I am planning to have dynamically branching levels anyway so I can just throw it almost where ever in the Brooklyn area where I see fit.
I began making them by creating block art; simple shapes that I used while I was fleshing out the logic. I literally made it up as I went along, tinkering with blueprints until I had something I was happy with. I am not going to explain their behavior here in detail, but I show some making of-images and the final screenshot from arcade cabinet. One important thing to note is that also in this stage, I begun to get rid of Unreal’s behavior tree and perception tool for enemy movement which I hated, and begun scripting them with Logic Driver Pro. Later I also returned to zombie enemies and began to slowly take the state machine logic away from behavior tree and into logic driver pro. I am still in the middle of this process, Logic Driver Pro is just simply so much better and more reliable.
Once I had the Mutant Man and Mutant Mountain play with the blockout graphics in a way that it felt fun to play, I began the production of their actual sprite graphics. The process is significantly different to small enemies due to the reason that these are EXTREMELY laborious to make, and you want to make sure that you dont waste time on something that is not working. I used the technique I developed myself on Terramarque back in 1994; I created a line art version of the blockout using my drawing as a reference, and then created manual “onion skins” of it when creating the main key frames, then I made inbetween frames until I was happy with the timing of the movement.
After I completed the line art, I pixeled the frames, manually with hand and mouse of course, based on the reference frame I created on the monster before I animated it.
The end result was a really nice looking epic boss fight. Again, I am not going to explain how it’s mechanics work, or show footage, but I will show the screenshot from the arcade cabinet again:
Then it was time to move on a new level. The end of the first screen shows stairs going to underground, so, of course, the next level would be underground. I went to look for photo and videomaterial and found some pretty good stuff shot from Brooklyn high street subway station. I did a concept drawing for it, but realized that most of the useful material would come from the reference photos and videos anyway, so on my pen drawing I just studied how I am going to break up the perspective, and after I figured that out I just followed the footage. I added some atmospheric light effects – the game does not have light sources, but you can fake it with other means. It is possible that this effect can not be translated to C64.
I could have skipped corners here and just made the tube train the next level, but I decided its actually fun to follow a real brooklyn subway structure, which is 3 floors; entrance, mezzanine and then the actual rail platform. I recycled the worms and added scrolling version of the continuous enemy spawner since this is a scrolling level (I have different versions of enemy spawners for different types of spawning for different game rules and conditions). There are lot of details commanding the gameplay pacing which players have no clue about, and the common misconception is that if game feels simple and effortless to play, it was effortless to make. But it is the polar opposite.
For this level, I added another lighting effect. At this time, Jarno returned again and proposed me a C64 tone mapping system – meaning that I can fade the screen to black by using only C64 palette. But instead of fading it with just three colors, I uses the whole palette. We created a “palette ladder” system to fade bitmap images smoothly into black. It was of course not without problems, but we came through. I used this to enhance the lights changing effect on the mezzanine level, I think its quite neat.
I dont know if it can be done on C64, but it goes a long way on making this more authentic on many different levels. I am not showing the light effect publicly, I just show the mezzanine level simply to show that it exists.
Few weeks earlier, I had realized that since this has evolved to be a true 320×200 game, this could run on CRT tv.. so I asked Toni from Reprocade if he wants to make arcade version of it. He said he would look into it. Around the time I had completed Mezzanine level, he came back with solution.
Pixel perfection with arcade hardware
So, Toni had a plan for custom arcade hardware. The main draw of the arcade was that it is JAMMA compatible and you can play it from REAL CRT TV, which is something you cant do very easily at home. This is for number of reasons. But generally this set me up with few demands:
-Game had to run on linux for easier JAMMA connection setup
-Hardware and OS had to be able to put out 15khz
-Hardware had to be made from parts that are commonly available
-It has to fit inside JAMMA cabinet and shouldn’t be ridiculously expensive
We tried it first on custom built i3 PC, which had “arcade VGA” card installed on it, but game did not boot: turned out that the graphics card was too old and needed OpenGL, and Unreal 5 – which the game was made on – had deprecated OpenGL. The card did not use Vulkan, which was Unreal’s de facto graphics driver for Linux. So then we tried Raspberry Pi 5. This time, the game booted, but fell on it’s face on initialization, with GPU showing 85% usage. And I had actually optimized this game – a lot – But, it seemed to me after much research that Unreal 5 as a default is just *too much* for raspi 5.
Then final chance came from newly released custom linux OS, which supported 15khz output AND vulkan driver. One of the guys at Reprocade was not amused to see that it was actually decompiled ripoff from the Groovyarcade OS which he had been contributing on – it just happened to have support for Vulkan drivers. So we agreed to use it temporarily and then to move to Groovyarcade OS once a new version of it is released.
There were many other things I had to work on with the arcade version – you just CAN’T put PC game on it and expect it to be a good experience on arcade machine. Lot of stuff had to be made. I created -out of necessity- options menu (which turned out to be the most difficult and laborious programming effort I have done so far) for selecting different display options and audio options, which was useful when testing the arcade hardware. I also made the game to reconfigure itself, initiating different controlling drivers and stuff that would work better on the arcade linux version. In the end I also ended up having different controlling mapping contexts for 3-button cabinets and 4-button cabinets!
At the same time, I was also having a lot of other work on my plate because I was having new music for the game made by Ari-Pekka Paljakka and around 100 new sound effects by Thomas Bendt. Just coordinating all the needed sound effects and mixing them and making them play properly took me weeks. So there was a month of delay before I was finally able to make the rail platform level, which was the very last thing I made before the Zooparty 2026 playtest. I also added a new enemy, zombie dog which loves to eat vomit.
Coping with the Great Slopocalypse
My original plan was to release a trailer on october just before Zooparty, then this blog too, at the same time with the trailer, then update the Steam page with new screenshots and description. Then few things happened simultaneously.
First, work on the arcade hardware was completed little too late – at the very last possible moment. All my effort was spent to simply getting it to work, while incorporating all new music and sound effects in. It was lot of work, and there was no way I could have been able to release the trailer before the zooparty. Trailer also brings other areas of work with it; such as sound mixing, updating the Steam page, making the japanese localized version of the trailer AND the Steam page, then trying to push the new trailer, new blog, new link to Steam everywhere.
Then, around the same time, I began to see reports of indie devs who suddenly got their game cloned by AI bros who used new version of Claude to make rapid clones. I saw enormous amount of games suddenly getting decompiled and cloned and ported to different platforms. And then I saw complaints how mediocre their quality was. All of this after all my hard work was just too much for me. So it was not enough that I would get despised for not being able to make the game for real C64 – due to circumstances outside my control – but I could also get ripped off, and cloned. So getting spat on the face is no longer enough, you will also get torn apart and pillaged. At the same time, I noticed the C64 scene increasingly getting filled with slop games and ports that were put together in a weekend by people who had very little experience or understanding about games. Then the posts showing footage of these got usually likes by people who had similarly little understanding about what it takes to actually make games, just on the basis of watching a video that takes no more than 15 seconds (that amount of time tells you nothing about the game). Although there was also very polarized reception to these efforts, it still lead to me a low point, which made me momentarily ask myself if I even want to deal with so-called “C64 hobbyist scene” any more.
I guess there is no need to tell you at this point that I dont use AI to generate assets to my game. I love making things with my own hands, why would I want to outsource all the fun to a machine that is owned by some corporation I can not even trust?
But the point is that this made me seriously question everything I was doing. I was wondering if there was a point of making this any more even. I wondered if I should quit everything and just go dig pits or something. After much thinking about it and discussing, I eventually came into following conclusions
-AI can be very powerful tool if its given to someone with knowledge
-These so-called “capable” people are very rare though, and 99% of the people pushing out slop are just “tourists” – and they are everywhere.
-Someone could rip off perhaps a some kind of similar beat em up to Undead, but they would fail on many different aspects. This game has A LOT of small detail which makes sure that it feels good to play, you cant put AI to do it, it’s design and design has to be authored by human. What I mean is that every ripoff of Undead would be inferior clone.
-This game is also a very niche product, so its largely questionable if anyone with actual skills would even bother to rip it off.
-There is also a huge number of audience which absolutely HATES everything made with AI – thanks to the slop bros – and this segment could value my slow handcraft approach.
And finally, Meta pulled a fast one by blocking me from sharing more than 2 links a month, unless I pay. Meaning that since I refuse to pay for Meta, I could not share a trailer in October, even if I had one ready and wanted to.
So, there was to be no trailer. The game would be revealed in Zooparty and people visiting it would see the game in motion for the first time – on a real CRT tv screen.
Zooparty 2026 public playtest session
We somehow managed to make the machine work just before Zooparty. It was begun a little bit too late, and I had to drop out a couple of features I really wanted in; I wanted highscore table, demo attract mode and player statistics. I will put them to the machine as soon as I can. The game works fine on the arcade prototype, but it’s not still quite as fast as on PC, I would say it runs on 90-95% speed. No one noticed it though – you need to have lot of hours on PC to notice the difference. It is quite playable on it’s own right, but I am hoping to optimize it further.
I was very nervous for going to show this game at the Zooparty, I had not shown any of the game’s new look in public because I have been on self-imposed media blackout, and I was worried that people are still going to despise me because it’s not on C64. But fortunately, no one complained when they saw it in action and got to experience it with their own hands and see it live.
To say that the reception was warm would be an understatement. I lost count on how many times people came to me and said that it “looks stunning” and “amazing” and incredible, and they also liked how well it played. I watched everyone who played it, because this gives me far more valuable information on how well I managed to balance the gameplay. Most of the players who played on first time had game over on the second level, which was my intention – this is where I want first time players to have their first game over.
There was one or two players out of dozens who just refused to understand that using roundhouse kick gives energy penalty, and they did not even try to use punch, so they died because they spammed roundhouse kick. This may sound controversial, but I am actually happy with this – if you do not bother to figure out how the game works and just mash a button, it is only a god given right that you will have no chance. If everyone had failed and died and walked away, then I would have know that I have a real problem here. But if 1 out of 20 walks away frustrated not understanding what happened, then my opinion is that this is not a problem – this game simply is NOT for everyone, it demands you to figure out how things work. Game even shows you a small “-10 energy” sprite floating above the character when you lose energy, but because the game throws you huge amount of visual information, it will take time before you begin to pick up details like that. Again, this is how I want it.
There were couple of players who I immediately noticed to be experienced arcade players. They got to fourth level on their first try (!). These same people complimented me how good it felt to play and how the challenge felt just right. I guess that’s a pretty good validation there.
The “superfan” I mentioned from my last blog entry also returned. Again, he got obsessed with the game and pounded it for hours. Situation was bit amusing because we had to stick a “K-16” note on the proto cabinet, implying that game is not recommended for minors, but it’s a case of a guardian approval really, and his dad watched the game and approved it. So no issue there. But the little guy was crazy good and he was able to conjure edge cases and glitches I had never been able to manifest myself! In the end I asked the little guy if he wants to see a secret shortcut to the bossroom so he can see Mutant Man and Mutant Mountain. “I found it already!” was his answer. Served me well, for daring to doubt the master!
Thankfully also, the game never crashed. I thought it did at the beginning when the screen went still couple of times, but it turned out that I had just simply forgot to disable the pause function from the start button! Doh.
All in all, I know that Zooparty is very niche event, and this is for niche audience, so there is no knowing if the warm reception would happen on other places. But I am still hoping that we can continue testing the cabinet on public spaces.
Plans for the future
So.. what next? Trailer? When? Game? When?
I don’t know. But I do know there won’t be a trailer for a very long time.
My reasoning is this: the most important reason for putting out a trailer is that you are trying to sell people something. If you are selling them a game, you need to be able to tell them when it is out. I do not know yet when this is coming out. I don’t have a clue. And now since these insta-backports with Claude are a reality, it means that I have to coordinate the launch for ALL platforms simultaneously! This means that I can’t put out a trailer until the game is nearly done.
“Marketing experts” on internet argue that you need to put out trailers and clips all the time and keep growing your audience as you go, and to me this is now outdated – first of all, there is very little reason for people to follow you when there is no game out – and all this caused was that we drowned in a sea of trailers and general noise when every amateur began to promote their own little thing. There was an argument that AI is the “great democratization”, but no, game engines like Unreal and Unity and asset stores already democratized all development. AI has only multiplied it thousandfold, up to insufferable levels, thanks to AI sloppers who dont understand what they are doing.
This means that any public attention I am ever going to get is a very brief limited window, and a new trailer may give this game a chance in spotlight only once. It may not happen for a second time until there is some considerable update to the look and content, and as far as I am concerned, only upgrade is what I have now – so I have only one shot.
This means: no trailer until the game is done and I know the release date. There will be no public demos or play testing on Steam either. I am doing testing and promotion with the arcade hardware only. I want this to be like it was in the eighties, where the only way to experience new games was to go into public space, seek out the cabinet and play it. No going through endless youtube videos, just EXPERIENCE the game live as a physical product on real hardware and see for yourself. At best you could only get a small image on a magazine or maybe even a blurry clip of someone playing the arcade machine on tv. This is how I want to promote my game before trailer – put it out on arcades, test it there and have the machine collecting statistics. I may have already lost the “visibility competition” in indie game market, but who cares if the whole gaming market is going down in flames anyway. I would rather just focus on what I think is unique and what I truly care about. Only reason to make this game is the love for it, anything else is worthless.
Closing thoughts
Well, that was my hour on the soap box. Thanks for reading. I will not be writing another blog entry for a very long time. I need all my focus on making this game, there is still a long road ahead of me and I can only work on this when I have free time between clients.
I sometimes wondered if this blog was good idea to begin with, or if I was giving too much away, or if I came across as someone who thinks bit too much of himself. Turned out, it was actually really good that I did this, because I have now very detailed documentation that prove my authorship in the case that someone wishes to accuse me of slopping with AI, or if someone makes a ripoff of this and I need to prove that I made the original (I still dont believe Undead can be ripped off very convincingly, but those AI tools really have improved dramatically, so I must be ready for anything).
In any case, anyone who has been following this already has figured by now that I have not and will not use AI tools to make code or graphics for this game, and I have forbade my audio guys from using them. I don’t hate AI tools just because they exist (even though for some that is reason enough, thanks to blatant copyright theft and environmental issues), I hate their rampant misuse and because they give a little actual value to me compared to the grief. The only useful thing they can provide to me is that they can give me documentation about Unreal Engine – and thats it.
This being said, if Pekka or some programmer who is actually experienced and skilled, wants to use them to help themselves with C64 conversion a little bit, I don’t think I would object as long as it’s done carefully, vetted with skill and the end result is not shit slop. Any AI bro who contacts me saying “Bro I make a conversion for you in a weekend with Claude lol” will be blocked immediately, I promise this.
Another thing I can say from the arcade version is that Reprocade Ltd will manufacture and distribute it. If you are interested on purchasing a copy for yourself, or wish to get a cabinet for your arcade, contact them.
The rest of you can still wishlist this on steam, and follow me on discord or other social media, but I may be writing less updates because I need to watch out for my energy. Making this game is a lot of work, especially since I am making this on my own, and I need to look after my health as well. And no, I do not take any offers from any outsiders who wish to help with this . If I need someone to help me, I will ask them myself. Sorry, but I know from my long game industry experience that growing the team count does not always make things smoother. And now it’s worse when any stranger can be potential slopper. This was a very diplomatic way to put it. Let’s just say that I have lot of reasons why I wish to make this game alone.
If I manage to complete this game and put it out, I will write a next blog post. Until then, take care and thanks for reading this far. And thanks to everyone who tested this at Zoo Party!
