Evil Brain Vs. Ludum Dare 38: the postmortem


First of all a huge thanks to everyone who tuned in for the stream. It being our first dev-related-broadcast we were shocked (OK, some of us were shocked, one of us is stubbornly self-confident) at the number of people who tuned in. 

The game we ended up with is quite odd. The theme for the jam wasn't. Actually the theme, "Small World," was strikingly similar to some themes the LD has had in the past (Including Ludum Dare 37, honestly.) Faced with such a mundane theme, we really wanted to implement it in a weird way in the gameplay. What we ended up with was To The Stars.

To The Stars is a game where you shoot the birds and spaceships above you to turn them into blocks that you climb to get away from a shark. It suffers from the classic gamejam game problem of needing a sentence like that to explain it. 

This is self-explanatory, right?

This is self-explanatory, right?

There was supposed to be a melodramatic typographic intro, introducing the idea of an alien invasion and a reason to leave the planet. We wanted it to look pretty dead serious, offset by the bright and happy pixeltrash aesthetic of the actual game. This is part of why the menus seem so disconnected in the current version of the game.  There were going to be stars as part of the menu that would become the background at the top of the map. Unfortunately, none of that happened due to the timcecrunch of the jam. Other things that didn't happen include a pelican fight and three special guardian UFOs at the top of the map.
What the game is really missing though, is a sheen of polish. 

While we planned to have pixels of various sizes and a generally messy graphic aesthetic, the graphics do not fit together in some ways that could have been avoided with more attention. The main characters and blocks are guiltiest of this, which is unfortunate since they are such pivotal entities in the game.

The blocks in the game presented a particular challenge. Their physics engine caused endless problems, sinking time into balancing weight and friction and constantly dealing with one bad collision bug or another. The semitransparency-to-show-damage scheme was a compromise we resorted to after we realized darkening the blocks just did not work for use visually and our attempt at brightening them instead failed.

Probably the worst problem we had with the blocks, however, was how computationally demanding their collisions became  by the time you'd stacked 50 or so up. To fix this we resorted to converting them at runtime into static objects, depending on their overlap of another block object.  We also eventually had them convert if you jumped on top of them, but this was to correct another bug where your character would not stand flush with the top of the block sometimes. 

So What Happened?

Basically and in general. the way we decided to implement the blocks effed us hard. The decision to use separate animations rather than RGB coefficients to set the colors of the blocks limited what we could do with them visually. The larger unknown of the physics engine reared its ugly head over and over throughout the jam. At least once each day we had to sink hours of development into fixing a new bug that had cropped up rather than implementing new features.

Another problem was exhaustion. This was our first stream of this kind and we didn't fully take into consideration how taxing it would be. Not only did we come into the jam with less sleep racked up than we should have, but we pushed ourselves to spend as many hours as possible on broadcast. The result was a tired, bitchy fog that hung over the entire experience (but especially Rusty) and kept us from reaching even close to our potential as creators and problem solvers.

Bugs emerged because we (but again, just Rusty) were too tired. One of the most time consuming bugs was caused by an unchecked checkbox. To be clear, one that OBVIOUSLY had to be checked. And that was caused during Day 1! The level of mental shambles only got worse as the event progressed. It's a good thing we didn't record the last 24 hours because, no lying, there were tears. 

Lessons Learned -

1: Prioritize sleep before the jam. Make it part of your plans.
I cannot stress enough how important this is. I knew it was, but with the stress of our first jamstream, it got put to the side for higher priorities. THERE ARE NO HIGHER PRIORITIES.
Getting proper sleep and nutrition will directly affect your performance in a game jam EVERY TIME. While pushing through the night, breaking bugs with bloodshot eyes and a big-gulp at your side has become a romantic image in the gamejam community (it goddamn has, don't question me on this, it isn't just me!) the reality is you're always going to be more effective with a steady hand and a clear head. Rest is as essential as food or atmosphere to getting a good "flow" going as you work; and anyone who makes games knows how important it is to get into "the zone" and stay there. 

2: Quit trying to use established physics engines in gamejam games! 
While it always seems like it's going to be a huge time saver, these prefabs always are always designed for a wider system that has nothing to do with my gameplay; and because I had no hand in making them I don't always have any immediate idea what to do when bugs inevitably crop up. This isn't a huge problem most of the time; I can generally trial-and-error my way out of any jamups if I believe enough. But during a gamejam it usually means slapping a huge compromise of a bandage over the problem (great example in To the Stars would be the "locking down" of the blocks) and compromising gameplay to make the kinks of the engine seem like a design decision. A lot of the work that has to go into To The Stars concerns this issue. 

3: Put someone in charge.
If you're working with a team it's worth it to have someone whose only function is to organize efforts as they move forward. Pick your most boring, responsible friend and arm them with a spreadhseet. Constantly add tasks and manage for priority. In our case everyone was involved in asset production so crossed wires were common and pipelining efficiently became impossible early on. Having a centralized list of priorities and time-based goals would have helped immensely and saved us from shouting at each other like a starship bridge under attack. The constant breaks to help each other understand what our next steps should be ended up probably our worst breaker of concentration and comaraderie throughout the jam.
*disclaimer - these are all observations of my own workflow based on my own strengths, weaknesses, and artistic tendencies. None of this is meant as a condemnation or proscription of dev behavior. You do you. 

Does "To The Stars" have a future?

Despite the game's flaws we're actually kindof fond of it. Standby for an upcoming devstream in which we will finish the game live, and prepare it for release as a web game on evilbrain.net

Judging is currently underway for Ludum Dare 38 so if you have a voting account and want to give us some love, head on over to the game's page there.