$50K Smashed! Deluxe CD Unlocked, More Gore, and Lead Dev Spotlight!
3 months ago
– Mon, Jun 29, 2026 at 01:29:47 PM
Hey backers!
The final countdown is on! The Kickstarter campaign is hitting a fever pitch, and we’re right there with you. We’ve got a massive update ready for you today including new milestones, updated gameplay footage, and a deep-dive with our lead programmer that pulls the curtain back on how this beast actually runs. Let’s get into it.
🥳 We hit $50k! The Deluxe CD Add-On is Unlocked!
We just blew past the $50,000 mark, which means the Fatman and Team Fat Deluxe CD Add-on is officially unlocked. Massive thanks to all of you for pushing us over the line!
As an extra bonus for clearing this milestone, we are also adding the digital Fat Adventures coloring book to the digital rewards bundle. This is a free upgrade for all our digital and physical reward-tier backers!
As for the physical CD itself, this thing is going to be absolutely packed. It features Karl O'Janpa’s full original score for the game, plus brand-new tracks from George Sanger and Joe McDermott, the legendary composers behind the original Zombies Ate My Neighbors soundtrack. To give you a taste of what we're cooking up, here is a sneak peek at some of the track titles:
Drop us a comment below and let us know which one sounds like it’s going to be your favorite!
If you want to grab the CD for yourself, you can add it to your rewards right now by editing your pledge and choosing it from the add-on menu.
You asked for more gore...
A ton of you reached out asking for a bloodier, messier wedding, so we got right to work. We’ve been cranking up the splatter factor to make sure the retro carnage feels exactly how it should.
Here is a quick look at how the extra blood is looking in action:
Important Note: This is still a work-in-progress, so we're still refining the animations and particle effects, but we wanted to show you the direction we're heading in.
Dev Chat with Mikhail
Reaching $50k is huge, so we wanted to take a second to highlight the absolute engine driving this project. We sat down with our lead developer and primary programmer, Mikhail Nikishin, to give him some well-deserved credit and chat about how he’s crafting the core gameplay of Lethal Wedding.
For readers who are completely new to Lethal Wedding, how would you describe the core concept and setting of the game in your own words?
Mikhail: "Hi. I am the programmer of Lethal Wedding, and I am the one who does all the technical stuff for the game.
Most of the time, when people think of retro, they think of platformers or metroidvanias. Lethal Wedding departs a little from this. It is a top-down shooter where you navigate the maze-like levels, shooting endless clowns that appear out of nowhere, trying to make them not to do the same with you. Our goal was to make the concept a blend of seriousness and wackiness. They say that getting attacked by clowns isn’t something you get to experience in everyday life, but sometimes you get lucky."
What was the initial origin of the project, and what tools did you use to build the first prototype? Did you begin development directly on Sega Genesis tools, or did you test the concept in a modern engine first?
Mikhail: "I never did any prototyping. I started with the SGDK kit on day one. SGDK is an acronym for Sega Genesis Development Kit, and it is exactly what it says on the tin, a C-based toolkit already containing all the basic routines to quickly draw the backgrounds, sprites et cetera. A fantastic tool, if you ask me.
Some people think that retro development is assembler only, but in reality, C is like “we have to build a car, here are the tools for it”, while assembler is like “we have to build a car, but first we need to invent the wheel, the tools, and our hands”. Besides, you can write assembly code in a C project in some critical places, so it is a win-win. Currently though we only have exactly one asm(“nop”) instruction for the entire project, but that’s a possibility!
Prototyping on a modern engine can help, but it can also backfire. The main thing in retro development is adhering to limitations. You always know that there’s a limitation of “one can not rotate the sprite 90°”, but the limitations like “that’s how many cycles you can work with” are way trickier. Modern PCs and even phones are orders of magnitude more powerful in comparison to Sega Genesis. You can easily end up with something that is simply too computationally expensive for the poor old Genny, and the only way would be then to cap FPS to 30 or something along the lines of that. No one will enjoy playing at 30 FPS. So, prototyping is an excellent tool, but you have to be aware of limitations and pitfalls."
Given the nearly ten-year development cycle, how significantly did the game change from day one to the final version? Additionally, how has your personal coding style evolved over that decade? Have you updated your development tools over the decade, or stuck with your original setup?
Mikhail: "Of course it didn’t take us ten years to work purely on Lethal Wedding. First, we made a game which was fun, but something was amiss. The first iteration looked like the current one, yet the level design was quite bland back then. But it wasn’t only about the level design. That’s the hardest thing to pinpoint: The Feel. It is not quantitive. You can’t measure “The Feel”. It is either "there” or “almost there”, and the latter is not good enough. I’ve had to work on other game prototypes during that time. We needed a fresh look, maybe fresh pairs of eyes, a new perspective. And on the last iteration something finally clicked.
Of course, the big drawback of this approach is the fact that I am essentially working with the legacy code at this point, but that’s how it is. Rewriting the entire game from scratch would have probably taken many more months.
About the development tools: no, they haven’t changed over the years. I still use vim as my go-to coding program. I just keep adding more plugins on top of it. We also have a couple scripts on Ruby that convert the level drawn in an external level editor into the internal data structure - that’s how we avoided writing our own level editing software. Why reinvent the wheel, after all?"
From a development standpoint, how did you approach balancing the artistic styles and design philosophies of external collaborators with the core direction of the game? Did integrating work from other creators impact technical constraints such as sprite limits or background layouts?
Mikhail: "Sadly, this happens all the time. Even more sadly, I am the one who always says “It would have been super awesome, but no, we are not allowed to do that”. It is always heartbreaking to say this line. A good example are the background animations. We could have made them easily if it was necessary to support animated level tiles from day one. Today background animations are not possible due to the fact that I made level data super compressed to pack as many levels into the game as possible, and part of this ultra compression relies on the fact that the background is always static. An artist wants to make an animated fountain? Sorry. Not happening.
Luckily, most of the time though we find some workaround and/or compromise, so no heartbreaking is needed."
What was the toughest technical roadblock you faced due to Genesis hardware limitations? How did you eventually code your way around it?
Mikhail: "It seems that every game has a different roadblock. For this game there were two. The performance and the ROM size limitation. The first one is pretty intuitive: I am working with an almost forty year old console. Pathfinding was a real pain to nail down: enemies should always find a route towards the player, no one likes to see enemies stuck behind the stationary wall. We ended up with an algorithm that essentially works on a 32x32 grid by spreading waves around the players. In each point, enemies check how the wave got here and follow it in the reverse direction. This is a real maze solving algorithm, by the way, called the breadth-first search algorithm.
The second is even more intuitive. While Genesis ROMs are technically not bound by the file size, Genesis itself can only address 4 megabytes of ROM. Technically, you can address more, but it is going to break compatibility with Genesis addons such as Sega 32X and Sega CD, do you remember those? There is a solution which is called a mapper, and there is even one official game that went this route, Super Street Fighter 2. Essentially, the mapper just says “here’s the 5 megabyte ROM, but I am going to cut the last megabyte during the first part of the game, and during the second part of the game I cut the second-to-last megabyte”. Very roughly, but you get the idea. Mappers are extremely common in NES cart development, you would have had to make tiny ROMs for NES if not for them, but since mappers are hardware solutions, carts with mappers are more expensive to produce in comparison to the carts without mappers. Mapper also complicates programming, so we decided to not use the mapper from very early on. And it opened the floodgates of sprite compression, level compression, tileset compression, everything compression. It is very “fun”.
What surprised you most when first testing the game on real hardware versus an emulator? What required immediate optimization?
Mikhail: "Surprisingly, modern emulators are quite accurate. There is one emulator in particular that is extremely accurate, it is called Exodus, an incredible feat of programming. We’ve never had any desyncs in terms of performance on any emulator in comparison to the real Genesis, but Exodus punches even above that.
For instance, in contrast to the PC’s x86 architecture that can read a 2-byte value from the memory if it starts on byte 1, Genesis’ CPU (Motorola 68000) will throw an exception. Most of the emulators never care about slight errors such as data misalignment and proceed as if nothing happened. Exodus does care. It throws an exception like the real Genesis would.
But even Exodus has its limits. They mostly revolve around the Yamaha YM2612 sound chip. Genesis has two sound chips: PSG Texas Instruments SN76489 chip that outputs simple NES-like sounds, and Yamaha YM2612 chip that outputs more refined tunes. I have a feeling that the PSG chip will work with whatever random data you feed it. The YM chip is a whole different story. If something is even remotely wrong, it will hang up the Genesis. No emulator, including Exodus, can emulate that. It means that usually music-related issues are the hardest to detect.
In fact, we are currently debugging a hanging issue that only seems to appear on the older versions of Sega Genesis, and also seems to be caused by the Yamaha chip."
Was the game designed primarily around the standard 3-button Genesis controller or the 6-button layout? How did you approach mapping mechanics like shooting, weapon swapping, and special moves to keep the controls intuitive?
Mikhail: "We always targeted the 3-button controller as main. However, the early control scheme was different. We’ve had the shoot button and the combined weapon swap/reload button, but we’ve also had the Strafe Lock button. One could press it and hold, and the character would keep the shooting direction like a turret. However, during the playtesting I literally never used it, and neither did any testers. Instead, they wondered why this button does nothing and is it possible to bind a direction double-tap to that instead, because some of them kept rolling accidentally. That’s what we did. There is a remnant of this omnidirectional shooting system still present in the options menu, so if you have a 6-button controller, you can try it out.
Unfortunately, we still have one button bound to both weapon swapping and weapon reloading on a 3-button controller. There is no way around that: shoot, roll, weapon swap and weapon reload, unless we want to get back to the tap-to-roll scheme and keep rolling accidentally, which we don’t."
How did playtester feedback help you balance complex mechanics like the "Vow" system and Co-Op mode?
Mikhail: "The most challenging thing to balance was actually the upgrade system. There were a couple upgrades that completely blew everything out of the water, the worst was “reduce all the damage by 3 to the minimum of 1”. A lot of enemies just emit a stream of low damaging bullets, and this upgrade literally trivialized those encounters. We added a cooldown to this upgrade, now it feels a little bit more balanced.
One might reply, but isn’t it okay to just keep the unbalanced options in the single player game? Well, the reality is a little bit more complex. Players can be funneled into using the same overpowered upgrades this way, killing the replayability. Of course we won’t make everything perfectly balanced, and we don’t actually need to, but the most overpowered upgrades are on the chopping block.
By the way, this playtester was me. I am the one who does all the smoke testing, after all. Sorry for that!
Testers found a lot of other similar things, like the Banana SMG that returns the ammo on hit with the conjunction of +35% chance not to consume ammo on shot turns it into the ammo generation machine with literally infinite ammo. This was super fun, but also super confusing and counter-intuitive, so we changed the upgrade to not work with the Banana SMG.
Last and probably the most important thing that our QA team caught. While some of the levels are arena-style levels, boss levels or other special levels, the vast majority of levels are “get to the goal”. And there is nothing stopping you to just roll from start to finish. This problem had a very common solution: adding a stamina bar, but some of us were opposed to it from the very beginning. Testers kept reporting the problem, and we made a quick prototype with a stamina bar. It turned out the stamina bar gave a whole new spin on combat entirely almost without the drawbacks we were anticipating."
Looking back at production, which gameplay system proved the most difficult to implement effectively? At what point did you realize the core game loop was fully ready for the public?
Mikhail: "The most difficult gameplay system to implement was definitely combat. The game is ~80% combat, after all! Pathfinder was a big concern - remember the performance issues. Enemies should be able to find the player, after all, to be a reasonable threat. Then, there is enemy variety. Almost every enemy has its own AI. Of course they reuse a lot of code: pathfinding, movement, shooting are usually done via the same routines; some of the more complex ones usually build on top of the generic ones. But that’s still a lot of work. It was all worth it: I don’t think there’s anybody who enjoys fighting the same enemies over and over.
As for the moment when the core gameplay was ready - I am honestly not exactly sure. As I’ve said already, you can not quantitatively measure the “fun”. You can measure the performance as either the percentage of missed frame deadlines or by just uncapping the frame rate - right now it is around 280 for the empty scene and around 95-100 for the busy 1 player scene with four enemies on screen. You can measure the space usage - right now we have around 146K free that can go out in an instant if we decide to add something new to the game. As for the fun, there’s no such scale. Moreover, fun is subjective, which complicates things even more. There is only a hope that we are heading into the right direction, and we’re trying to follow that hope."
What was the most complex or unusual bug you encountered during development, and how did you fix it?
Mikhail: "The most complex bug was the sudden crash that happened from time to time during gameplay. Those random crashes are extremely hard to debug. You make a fix, and then you start a ten minute testing process just to see that the bug isn’t gone. It turned out that it was something wrong with either the toolkit’s sprite engine or with the way I use that sprite engine. We updated the toolkit to the newer version, and started the long and arduous process of version switch. SGDK isn’t known for its stellar backwards compatibility, so it is better to stick with one version, but sometimes you just have to upgrade. Transition from 1.5.1 to 1.6.5 somehow fixed the issue.
In total, it took around three weeks to resolve that. In the process I fixed a lot more bugs, of course, but still, that’s a lot of time!
As for the unusual bugs, I have a very recent one. We were remaking the upgrade screen, and at one point we needed to introduce a fifth palette. Genesis can only handle four palettes at once, but there is a workaround: you can swap some color midway through the frame output. This is called raster effects, and a lot of games utilize those, take a look at Sonic’ underwater sections. However, there is a catch. When you do the color update, one pixel that is being displayed right now changes the color to that color. One of the testers somehow noticed this pixel, erratically jumping from point to point, and reported it as a low priority issue.
The solution was to wait seventy times in a row so that this pixel “appears” outside of the screen. The only use of an assembly in the whole project, by the way."
Top-down shooters rely heavily on precise hit detection. How did you approach tuning collision boxes and movement physics to ensure the gameplay feels fair while maintaining a classic difficulty level?
Mikhail: "The most important thing to make the bullet-to-enemy collisions to feel fair is to make the hit boxes to be as precise as possible, maybe just a tiny little bit larger on the enemies than needed. All the projectiles have two modes of collision: a simple point when tested against the scenery and an honest rectangle when tested against the enemies. However, it would have been no use unless we do a lot of tests. Some systems are offloaded to different frames: for example, level loading runs three times per six frames (two times per five frames on the European version). Some, but not hit detection. Hit detection is done every frame.
To make this work, I’ve even had to employ some extra trickery. I split the playfield to 32 64x64 blocks, and every player and every enemy can be assigned to one to four of those blocks (we don’t have any collision boxes that are larger by 64x64), adding some leeway to account for the big projectiles. Each projectile only tests against the collisions that are assigned to the block it is in, reducing the collision tests from 2 players to usually around 0 on average - foes miss a lot of the time, after all. We do the same thing to the separate collision boxes on the ground so players can not get through the enemies normally, yet of course this one is disabled during rolling.
This is a very well-known optimization technique, dating back at least to the original DOOM. It is called blockmap there and serves the same purpose: to cull out the amount of tests that won’t connect for sure anyways (albeit it does so in a little bit flawed way in the original DOOM implementation). It gives us a slight performance boost, although right now I am not sure if it was worth it, since the collision checks are very fast anyways."
How did you balance the weapons to encourage players to use the full arsenal instead of just one gun?
Mikhail: "You are spot on, weapon balance was a big issue. We have three base weapon upgrades, and they are super powerful. Once you unlocked all of them, there was no reason to ever use anything else. Nerfing the base weapons felt terrible.
I guess Lethal Wedding is a full fledged DOOM clone, since I am going to bring this game franchise up yet again.
There’s a modern game called DOOM Eternal, and that game has one particular game mechanic: you have to use certain weapons to defeat certain foes effectively. The developers were solving the issue of “why use anything else but the super shotgun”, and some players think that they overcorrected it with the low ammo counts, but generally this approach was highly praised by the community.
Quite similar to our issue, isn’t it?
So, we added a couple vulnerabilities. Heavily armored enemies such as boxing glove clown can be a real hassle to defeat using the basic weapons, but they die instantly if hit by an acid flower projectile. Bearded lady was considered to be a mini-boss, yet now it is a one-shot for a gun of roses. You can still get through the game with nothing but a sawed-off or a revolver just fine except for one specific boss, but if you master the weapon juggling, you are going to get big payoffs in certain situations!
Oh, and we also buffed the banana SMG. A lot. People were so annoyed that banana SMG was super weak, and now it has a niche: it is the only weapon that refunds ammo on hits. You hit every shot and you never run out of ammo for the banana SMG. Couple this with the +4 bonus damage upgrades against certain enemies, and you have tripled its base damage from 2 to 6."
Looking back over the last decade of production, are there any other unique technical challenges, design breakthroughs, or development anecdotes that we didn’t touch on here?
Mikhail: "We haven’t talked about bosses at all. Bosses are like normal enemies, but with a complex AI.
The second boss, the Wizard and his Assistant, currently has 1349 source lines of code, which is three lines of code less than the very final boss of the game, giving it the title of second longest boss in terms of the code base. Understandably, that’s three phases and two characters.
But the hardest one? Hans. The very first boss of the game. Only 640 lines of code, but those were the hardest on a conceptual level. Hans is the only boss that tries to pursue the player across the multiple screens, and he was getting stuck all the time. But most of all, when the player moved from the first floor back to the second floor, that was pretty much a game over for Hans. I almost resorted to making a navmesh entirely for Hans, but luckily, I came up with some trickery to make him work using an existing framework and adding a lot of predetermined covers like a primitive navigation mesh. And some cheeky teleportation too, but don’t tell anyone about that.
Another interesting thing is the fact that in an attempt to optimize the pathfinder we once fully rewrote it on assembler. And then, no matter how hard we tried, we never managed to make this assembly code run faster than the original heavily optimized C code. Whoops.
There are a lot more, but I guess that I should slow down… for now."
After spending nearly a decade on this project, what is it like to finally be in the home stretch of the campaign and preparing to release the game to the public?
Mikhail: "I am very nervous.
We won’t have a second chance. No zero day patches. Once it is out, there is no way back. We have to nail it on the first try. Wish us luck.
And for you all - have fun! And thanks for the support, it means a lot to us!"
Huge thanks to Mikhail for stepping away from the dev trenches to give us a look behind the curtain!
Next up: Console Ports!
There are only a few days left before the clock runs out. Our next big stretch goal is getting Lethal Wedding onto consoles.
If you want to help us hit that milestone, now is the time to lock in your rewards, upgrade your tier, or share the project with anyone who loves classic retro shooters. Let's finish this strong!
-Mega Cat Studios
