Way back in April 2016 I worked on a Ludum Dare game known as “My Strange Alien Friend”. To my knowledge, this game no longer exists, and at the time, I wrote a rather damning postmortem. However, I held off posting it because I didn’t feel that it offered a conclusion. It was just negative. Tomorrow I will be taking part in Ludum Dare 39 for the first time since Ludum Dare 35. So I feel that now is a good a time as any to finally share that postmortem.
Earlier this year a couple of my old Montreal game jamming buddies and I decided not to let the oceans between us get in the way of indie gamedev passion. It was time for us to jam again. Upon discovering that the Global Game Jam doesn’t exactly endorse remote jamming, we decided to try Ludum Dare instead.
Ludum Dare 35 - "Shapeshift"
Typically within post-mortems, I like to break down what I personally believe went right and wrong. However, as I don’t feel enough actually went right, I’m going to just talk through my experience, and perhaps try to reach a conclusion as to why I feel that we failed.
It had been a while since I had last taken part in a game jam, especially within a group. Working in isolation for so long on Jack B. Nimble, I’d gotten used to my own company and workflow. I hadn’t needed to communicate my thoughts and ideas, let alone understand anyone else’s. That’s where the first cracks began to form.
I mentioned in my post-mortem of No Evil, that brainstorming without the full group can cause some pretty serious problems once development begins. If someone is absent from the initial conception phase, they experience less ownership of the game’s foundations. That can quickly make a jam feel like a job.
Due to time zone reasons, I was asleep during the initial discussions and brainstorming session. This concerned me at the time, but at that point, it seemed that we had to keep going with a ‘get it done’ mentality, without worrying too much about the details. This was a mistake. And likely fueled by my desire (read: obsession) to start the creation process as soon as possible to better deliver a polished experience.
From an art point of view, I wanted to use this jam to exercise my vector skills and do something abstract, rather than my usual pixel-based efforts. Unfortunately, when I awoke from my slumber, I found that the discussion and design document were rather heavy on the suggestion of character and form for the game. Sure, I could have paired things back and suggested a different direction, but I didn’t want to waste valuable time waiting for my team to wake up, so I started working on assets based on what I had read from the design document.
As I scanned the document to build my asset list, my gut reaction was that the scope was too wide. I felt that I could deliver the artwork in time, but didn’t have much confidence that it would be implemented. This is where a discussion would have helped. It would have been beneficial for the team to have an open channel of communication while I sketched out some rough designs on paper, and at that point we could have talked through implementation and scope. This way we could have had full team approval and considered what references we could use and work from.
Form follows function
Now let’s talk about references. I’m a visual designer. I care a lot about scene composition and consistency, but my experience tells me that you should always nail the function before applying a form. You know, form follows function. This is an extremely difficult rule to follow in a jam, due to the compressed schedule. You simply don’t have time to follow this mantra and achieve a polished experience. Especially if you’ve spent all of your time iterating on a base mechanic without having integrated the visuals (or at least proven a pipeline).
For speed sake, assets and features need to be worked on alongside each other. So usually, I would build assets that would marry to behaviours used in other games. For example, if I was to say “a wall jump like Super Meat Boy”, it’s pretty easy to get everyone on the same page from an aesthetic and mechanical point of view. The way I see it, those other games exist and they already went through pre-production and had their fair share of failed attempts. Why not just work off the back of their R&D and use them as a reference?
Unfortunately, our references were all very different, and there was a failure in communication as to the priority of the various aspects of these references. This was ultimately is where I believe we clashed.
This is fine
I began building assets using a mixture of references such as Super Mario Bros. 2 and Metroid. I also built some of these assets with some of those game’s behaviours in mind. Unfortunately, I hadn’t properly directed these intentions to the rest of the team. So when I delivered a static mock-up, they liked what they saw and carried on working. Because for all intents and purposes they looked fine. Good even. The problem, was that I wasn’t stating how I felt that the assets should be used, and the team weren’t telling me how the would be used. It was a real breakdown in communication.
I feel like we all just had blinkers on, focusing on our individual tasks with an “everything is fine” mentality. By the time that I had finished the art and audio, I realised that very little of the game that was actually functional. Anything that was functional was extremely buggy. This put a huge downer on the whole experience. I was happy with the art I had created, but annoyed at how bad it looked in game.
Diamonds in the rough
I’m not sure if there’s a link to the game out there, but I won’t be sharing it here. Everything about the game itself is a sore subject. I personally class it as a failed game design experiment and an example of poor development process.
Though to be fair to the project, it wasn’t all doom and gloom. I feel that the game’s design (while out of scope) was perfectly valid, and actually pretty cool. And from my point of view, I grew as an artist. Having worked in the Game Boy colour palette for so long, I had gotten a little too used to only using 4 colours. This jam pushed me to try new things. You know… using some colour! I really was rather fond of those assets…
So, looking back, I feel that I to needed to work closer with the team. I needed to collaborate on the design by offering compromise early when I felt that we were out of scope. This would have better informed the code and resulted in better asset integration. I also feel that I needed to give clearer intentions towards code when it came to asset integration and mechanical implementation. What more can I say, it was a learning experience.
I hope this trip back down memory lane helps people in some way. Just remember, communication is king, and keep an eye on the scope of your project.
Wish me luck for the next jam!