This was my first Ludum Dare, and my 4th game jam. As is common practice, this is the postmortem of CWF: Card Wrestling Federation for Ludum Dare 41.

Bill of Materials

Engine: Godot 3

Art Software: Aseprite

Audio Software: Music - Beepbox, SFX - Bfxr

Font: Equipment Extended by Somepx

Caffeine: 1 pot of cold brew coffee, 2 sugar free rockstars

What went well?

Even though the final theme was not on my list, I managed to come up with a concept within the first hour or so. That is one of my biggest fears when it comes to game jams - not being able to come up with something I would want to build that aligns with the theme. Ultimately, it was for the best to have a theme that posed a challenge to me by forcing some outside of the box thinking as opposed to ones I would liked to have had.

Initial sketches of the game featuring Star Man. I definitely pulled inspiration from NES Pro Wrestling.

After deciding on my concept, I managed to get a rough outline of an MVP written down. I then took that, and split it up into an MVP 1 and an MVP 2. MVP 1 was the least amount of features required to have the concept be a complete experience: variety of cards, multiple opponents, multiple ways to win, & at least 2 music tracks and 1 sound. MVP 2 were things I considered nice-to-haves like deck building, more music than title & fight scenes, more move cards, timed matches as a 4th way to win via "hype" system (flashier moves got the crowd more excited), larger variety of text, and more fighters. Needless to say I got through MVP 1 and part of 2.

Early on I made an active effort to have the core combat loop completed. Within about 4 hours, I had that functional within just console output. At this point it was a slugfest with the computer winning most of the time. It was a good sign pinning & alternative methods of victory needed to be implemented or else it was just a "mash the button until you win" sort of game.

You can see here that the interface layout was pretty much sealed early on.

I made sure to try to keep the visuals within bounds of what I knew I could do. I decided early that I wanted to try to mimic the aesthetic of the old NES wrestling games, so I aimed to keep the artwork simplistic and minimize the amount of colors used. I think it actually turned out pretty nice.

Making music this jam was a big deal for me, I have no sense of rhythm and have submitted games to other jams before without any audio. I learned how to use Beepbox for this jam, and managed to get out the title track (listen here) and fight track (listen here). Even though they're simple loops, just a little music can help set the tone for the rest of the game. Bfxr was used to make the sound effect, at the time there is just one used for hitting; ideally I would have made a few and randomized it for variety.

This is the part where the game's visual style started to develop, first with the stamina meters.

A change I made for this jam was prioritizing rest. I made sure to go to bed at a reasonable time so I could wake up in the morning not feeling like garbage. In the past I've been known to work til fatigue sets in, sleep at my desk, wake up and repeat. @rustymonky still brings up when I slept under a table at Global Game Jam since I opted to not leave the venue. Additionally I even took a break to go to my roller derby practice, helped clear my head and get my energy back up to let me work later. Granted I did break this plan and end up working til 2am, sleep til 6am, keep working until I had to go to work, and try to wrap up last minute bugs during my lunch break before deploying.

Another change I decided to work on this time around was to develop a method to make documentation easier. All of the screenshots displayed here were captured by the game engine itself using a piece of a small experiment I did with procedural generation earlier this year. Just because it'd actually be helpful, here it is:

```gdscript

Add this as an autoloaded script for your project

extends Node

func input(event): # Add an input named printscreen to use this if (event.isactionpressed("print_screen")): screenshot()

start screen capture, stores file in user data

func screenshot(): var data = getviewport().gettexture().getdata() data.flipy() data.savepng("user://screenshot" + String(OS.getunix_time()) + ".png") ```

One final thing I was really proud of was my implementation of what I referred to as an "action queue". Originally it started as the method with which I queued up dialogue text. As the game developed more effects, I realized I needed a way to display things in an order even though all calculations occur at once. So rather than just passing up text, I included an array of text (in case a dialogue piece had multiple lines), a sound effect, and who the target was. This allowed me to play the correct animations in order, making the game feel a little nicer.

Early version of the wrestler sprite, color coding the moves was established around this time.

Releasing the game as an HTML build was a huge improvement over previous jams for me. There was a bit of a realization that if I required players to have to download and install the game with nothing but a description & screenshots to go off of, they couldn't even be bothered to download and move on to something shinier. By having the game accessible in browser, I was easily able to get 10x the amount of plays compared to my previous jam entries.

Finally, I streamed almost every hour of development on Twitch. This helped me keep contact with friends who were doing also doing the jam and get some sort of input as to the direction things were going. It was pretty fun too when you got people popping in to see what you were working on. We kept in contact through Discord, allowing us to share early screens and bounce ideas off each other.

What didn't go well?

As always, with any project there will be hitches. This one went quite well, but it wouldn't be a good postmortem without me identifying what could have gone better.

Scoping - Even though I had this project broken down into an MVP, and then a second MVP, there will always be some unplanned work that comes up whether it is iteration upon existing functionality or the fact that I didn't block out any time to do the itch.io page. Not to mention there is always a need to plan for unplanned work, i.e. bugs. There was a plethora of things I anticipated to be quite easy to do, and I'm sure they were, but they didn't make the final final cut just due to time constraints.

Early iteration of the wrestler, I was having an issue drawing hands.

Art - I had originally planned to draw fighters with different costumes, but just as with scoping the project I hadn't anticipated how much effort that was truly going to entail. This is the reason why I made a shift to just do colored fighters and made the feature of them corresponding to a move type. I also made art one of the last things on my todo list, simply because I felt it was where I could safely shave time and not lose as much compared to coding.

Too Random - Even though I made the moves be consistent in damage, I gave an accuracy value which allowed the game be "mash to win, maybe". The accuracy value is out of 100 and has proven to be no better than everything being just pure random. To combat this I should have limited the random successes to the moves that mattered/had additional side effects. Relating to that, I realized after the game had launched that the math used for the submission hold allowed a win where the player/enemy stamina was at 100%.

Bad Timing - The Jam is 72 hours, this is more than enough time - unless you're me and completely forgot about that overflowing into Monday (aka normal working hours). I planned to work within the confines of 72 hours, in reality I got closer to 60. Would the additional 12 hours have made a difference? Probably. Would scoping to shoot for something more like 50 hours have changed my planning? Yes.

Challenger screen, a late Sunday evening addition. The text changes in the final build.

Late stage bugs - In addition to any bugs I may have found, some were found within the final hours before I released it by friends I got to try out early builds. This goes back to getting feedback early; have others play test it as well to see if things flow & make sense to someone who hasn't spent the last 48 hours with it.

Final takeaways

I will try to keep this brief, but I have a few key takeaways: Plan accordingly, scope smaller - If your scope is already small, simplify it even further. This goes double especially when you're working solo.

Take breaks - Getting away from the machine to think about what you've been working on or to just reset your brain can do wonders. Grinding for hours on end can lead you to wasting time while you're fatigued.

Try to work outside your comfort zone a bit - It's a good idea to try to pick one thing you aren't familiar with, and try to incorporate that into your jam project (mine was music). Do not try to take on too much unfamiliar territory; making assumptions about how things can/will work without truly understanding can lead to a lot of unplanned work and mismanaged time.

Get feeback early & often - Even if you're going this solo, you don't have to be alone. Getting early feedback can help you figure out what needs to be clarified or any short comings you may not identify without an outsider's view.

Release for the web - Jam games are typically small. The effort of downloading a random game often outweighs the time to play it. Releasing it as an HTML build (thanks Godot!) lowers that barrier and people will be more inclined to check it out.

Final build. Time to wrassle.

That's it for me! Please check out CWF: Card Wrestling Federation if you haven't already, and I'll see you in the next Ludum Dare!