I feel pretty positive about my latest LD entry: Eat. Sleep. Rave. Repeat. I decided to do this jam solo (although I did have animation help from my friend Raj). Each jam comes with a number of lessons learned, ranging from technical to project management to design. So here are my key takeaways:

Narrative is fun. Flavor is fun.

On friday night I wanted to end with some concepts and a succinct pitch. A vision that I can use for the rest of the jam. I spent friday night drawing, writing, and gathering reference. Here's my ref board I used for the rest of the jam:

Keep It Moving

Part of jamming for me in the past sometimes revolves around finding the Holy Grail of game mechanics. A unique hook that will drive the game and get people hooked. This is a totally legitimate direction, but I decided instead to focus on a number of small, simple mechanics: dialog, interactions, and light platforming.

The game starts in your bedroom, where we teach the basics of interaction. It unlocks a new interaction, which unlocks another, which unlocks another. This keeps things moving forward, and bringing in bigger and wackier events.

State Machines: My Unsung Hero

Man, did I use a lot of finite state machines(FSM) in this game. A big thanks to MonsterLove for the simple state machine setup I used. Practically everything was a state machine. And I don't really think I Golden Hammer-ed it much.

In the past I might have said something like 'If the DJ's dance counter is greater than a threshold, then move the bouncer out of the way.'

But in the FSM paradigm instead I'd say: 'If the DJ is in the Jamming state, then move the bouncer out of the way.'

At first glance this doesn't seem like a big change. But what it does is define everything as interacting black boxes. We're less interested in specific variables, and more interested in the abstract state of a unit. This is easier to work with, and also way easier to communicate.

And I don't mean communicate to team members, but to your players. I mean that a state of 'jamming' vs. an arbitrary collection of variables means much more to the player. I can communicate to the player visually a 'jamming' state in a much more interested way than a bland UI defining that he has X dances out of Y.

Even More State Machines

In addition to the state machines for the various objects, I made a number of state and sub-state machines using Animators that corresponded to the FSM states.

Using Prefab Variants for Data!

There is a school of thought that ScriptableObjects in Unity are really great. I believe this stems from Schell games' tutorials on the matter. I personally could never understand why I couldn't just prefabs with monobehaviours instead. And i've been doing that for years without issue. It has a number of advantages to using Scriptable Objects which may make for a great article someday, but suffice to say that in both inheritance and composition it has advantages.

But this weekend I realized: You can create a data template with a prefab, then override vars with prefab variants! This allowed me to define the defaults for how 'crowd emitters' would enter the dance floor, and create variants for each stage. I will most likely be using this technique more moving forward.

Well this is already longer than I wanted, but hopefully this was interesting. Thanks a lot and I hope you enjoy playing Eat.Sleep.Rave.Repeat.