This is a write up detailing my personal experiments, trials, and tribulations of Ludum Dare 44. For the uninitiated, Ludum Dare (to give a game) is a 48 or 72 hour game jam where participants are given a theme and then tasked with building a game from start to finish in the allotted time frame. The compo portion is 48 hours, no teams, and published source code. The Jam portion is 72 hours, teams, and source code is not a requirement.

The Goals

I set some interesting goals this time around. First and foremost, I wanted to see how well our team would do with noone leading the charge. I didn’t take notes, write tasks, document plans or features, or set goals. Second, I wanted to work in 3d, as we haven’t published anything in 3d yet. Very straightforward.

https://ldjam.com/events/ludum-dare/44/coinus-accumulus

Brainstorming

The theme this time around was “Your life is currency.” The inclusion of the word “your” in the theme was a huge sticking point for a lot of people, including us. Our brainstorming session, or as we like to call it in-house: mindphooning, went fairly quickly, lasting only about 2 hours. Ludum Dare has a theme selection process that involves three rounds of theme voting, and then a final round for the winners from the last three. Our process is to take the list and jot down some quick and dirty first impressions before the event starts. This gives us a base to work with, where we can immediately start talking about mechanics.

Once the theme was released, we reviewed the list and saw that we had… Well, we had basically nothing. The best idea from the list was “pitfall but your bodies persist” and the next idea was “health insurance simulator.” We ended up scrapping the entire list and ran with something on a whim. The conversation was something along the lines of: “So you’ll play as a coin.” “And do what, pick up currency?” “Katamari style?” “Ok let’s just go with this.”

The First Night

We did a small bout of pre-planning. DJ mentioned he would jump on enemies. Dan started modeling out a coin or two, then to valuables. I started with the character controller. We had decided that the quickest way to do the art pipeline was with vertex colors on simple meshes.

By midnight we had a working prototype. You were a coin. The coin rolled around and picked things up. As you picked things up, you grew larger and could pick up more things. Everything with a mesh calculated its volume and requirements thus could be picked up. We had a game and all we had to do was add more stuff.

After these basics I worked on getting the movement to feel right. This was actually some pretty intense tomfoolery. The player, a simple coin, is actually five objects: - The player itself, which housed the controller and rigidbody. - The Z pivot, which was used for tilting the coin left and right as you turned to give you a proper sense of movement. - The X pivot, which was used to rotate the coin as you moved to give you a sense of forward or backwards momentum. - The collider. - The ground check trigger.

I started with a full physics implementation of the coin. Anyone who has written a character controller in Unity knows that physics is your enemy. Real world gravity and friction just don’t feel good to play in. Starting with the physics implementation told me what I needed to do, which I then pulled out of real physics and tried to make it feel good. The player itself doesn’t actually spin as it’s moving forward, but the X pivot (which has the mesh renderer) does. The player doesn’t actually tilt when turning, but the Z pivot does. The player object itself only moves forward, backward, turns, and jumps.

In retrospect, the collider and trigger should have been moved up to the root level so that they weren’t affected by the non-physics actions like tilting and rotating. This would have helped with FPS for the physics simulation, though the impact was negligible for this particular project.

The Rabbit Hole

After I had a working character, Dan handed me the first round of models. Two coins and a few jewels. I dropped the coin in for the player and realized that Unity doesn’t have a built in shader for vertex colors. This threw a wrench in the whole “speedy art pipeline” idea. So I started writing a shader. Getting this basic vertex color shader up and running only took a couple hours at best. One major weakness in my skill set is writing shaders. But I did it. I had a working vertex color shader, and I was proud. I called Dan over to have him take a look and he said “The coin isn’t shiny.” Oh.

Thus began my descent into madness, which lead into the next morning. It took me an embarrassing amount of time to get shininess to work on the shader. After it was all said and done, I had spent about eight hours working to get the coin shiny. This wouldn’t be my first foray into wasting time, either. Immediately after this, I spent another six hours or so trying to get diffuse lighting working on this shader. As a little aside - we didn’t end up with specular or diffuse in the final game. This was over half a day wasted. Giving up on lighting, I decided to press forward on the gameplay.

Dan had a whole slew of items ready to go, including a whole dungeon kits with tiles and walls. I mapped out a basic level and we liked where it was going overall. Unbeknownst to us, there was a major problem brewing that we wouldn’t address until the next day.

A Bit About Katamari

In any Katamari game, you play as a sticky ball. The object of the game is to roll up as much stuff and reach a set goal size for the level, usually accompanied by a timer for pressure. As you collect items, you increase in size, which allows you to pick up larger items. The cycle repeats. Everyone once in awhile you reach a “breakpoint” where your katamari levels up, accompanied with a zoom-out of the camera and a pop-up telling you that you can enter a new area. Why does this happen?

As it turns out, this is used to get the game back to sane values, load in larger areas, and generally do maintenance on the game state so things stay in control and reasonable. Well, as reasonable as a Katamari game can be.

A Wasted Day

During the level design process I kept running into one issue over and over again. The player got out of control. There were a number of contributing factors to this: movement speed, camera position, number size limits on objects with large volumes, player scale. The one thing I couldn’t answer was how to reel the player in. I spent the better part of the second day tweaking numbers, adding multipliers to change value scales, and generally failing. I was focusing on the details and not the game.

A small part of me wanted to give up on the idea, call the whole project a wash and change the game idea. I stepped back and laid on the couch, taking the opportunity to watch some gameplay from various Katamari games to see what secret sauce I was missing. That’s when it dawned on me - our player never leveled up.

From an architectural perspective, this level up system is pretty advanced. It involves loading in new, large objects and unload old, small objects. It also involves resetting camera values, player scale and volume settings, and any other maintenance that needs done. Unity has some support for this built in with additive scene loading and unloading, but this is at best a partial solution for the whole problem. We were reaching the end of the second day.

Sunday night. Very little had changed the entire day, and I didn’t think I’d have time to change the architecture of the project at this point. So I asked what the team thought. Should we go for pure katamari and focus on the systems, scrapping all of the AI work DJ had done and shifting all focus on getting loading working, or should we scrap most of the katamari system? We decided the best route for the success of the game was to do the latter, and thus it became a 3D platformer.

Super Secret Shader Stint

Our game looked terrible. During the previous day, one of the largest complaints was “I can’t see through this stupid bookshelf.” I had extended the shader a bit to discard geometry that was close to the camera, but after I wrote it I realized I could just increase the near clipping plane in Unity to get the exact same effect. I knew I could do better, so I got up in the middle of the night. With my newly grown shader muscles, I set out to add dithering to the cut. This worked marvelously and made me think of the latest Mario and Zelda games, which made me want to try my hand at the lighting again. This time around I discovered how to write custom lighting, so I wrote up a bit of toon lighting. Then I went back to bed.

The Final Push

With a fresh vision we hit the ground running, trying to glue as much of this together as possible. We really rode this one out to the max. Thanks to Unity’s timeline feature, we were able to put together an opening cutscene in about 30 minutes. DJ’s enemy system wasn’t implemented in the main level until about 3 hours before the deadline, where we had to pause with level design so that he could implement it. We then rode level design out right up until submission hour. The game wasn’t even able to be won until about an hour before the deadline.

Why Are You Telling Me Your Life Story

This was all leading up to the big takeaway from this Ludum Dare: You need a manager. Whether that person is yourself or someone dedicated to the role, it is vital to the success of a project.

There were many moments where I found myself flying blind, problems in front of me but no guidance or priorities. There were moments where Dan didn’t know what to work on next because he didn’t know what was important or what would make the cut. There were moments where DJ wanted his work to get implemented but we weren’t ready to add it because the scene was checked out willy nilly.

A manager’s role is to give you the tools you need to be effective at your role. They’re to provide you with direction when you’re lost. A manager should identify potential issues and work to find a solution before the problem presents itself. We didn’t have any of these things.

It’s easy to get lost in a sea of “what if” scenarios, but I can confidently look back and say that we would have had almost a full extra day of development had I taken any time at all to lead the team.

So How Was The Game

Overall, I think we succeeded. We’re all very competent in our own areas and, at the end of the day, we were able to pull it together to make something that was largely enjoyable. While looking over the comments we’ve received so far, a few points stand out that very clearly illustrate our running out of time, not having priorities, and not thoroughly testing. Had I stepped back to assess the situation, those would have been improved.

On future projects I intend to make sure someone is holding the reigns at all times, even if that someone isn’t me.