Well, its done. I'm pretty exhausted, but its done. BEHOLD:

https://www.youtube.com/watch?v=jryIzGTofFo

https://ldjam.com/events/ludum-dare/42/a-few-bits-left

It was a fun jam. I think things got pretty intense on Saturday when I was still writing code instead of making a game. But a night's sleep helped me relax enough. As I climbed into my chair and sat down to begin coding Sunday morning, a calm came over me and I just rolled with it.

Initially we were expecting to make the game in GameMaker, which I was unfamiliar with. I spent the days leading up to the jam doing tutorials on the free version of GameMaker 2. The day before the jam my partner alerts me to the fact that the free tier of GameMaker limits you to 15 objects?!! Talk about running out of space! So we unfortunately scrapped GM and moved into Unity.

I feel like the game we made was 'ok'. I think next game jam it would be possible to re-use the code from this jam and make a more interesting game. Most of my time was spent in systems coding, and developing the bones. I was not very familiar with Unity 2D functionality. But thankfully working with sprites and tilemaps is super-simple.

We really wanted to give the game some story and dialogue to drive the player forward, but that didn't happen. This is another system that could be built before-hand, so that the jam could be spent less on tech, and more on the game itself.

I don't know how much 'prepping' before a jam is 'cheating'. If I write a dialog system for a past jam, and re-use the code, is that in the spirit of a jam? It seems like some of the best jam games are from people who've built up a code-base and can focus on the story, art, and challenges.

Also Sunday night I was super happy when I pressed 'Build' for the first time and I had a fully functional WebGL game. I've never done that and put a game on itch.io. WOW that was easy.

While I say the game is 'ok' I am still proud of our accomplishment. Its a complete playable game, and frequently reaching that level of completion is hard enough. I feel like the game's mechanics are well communicated, and there is balance and a bit of challenge towards the end.

We took some time out to really improve the single player version of the game, and also to make a trailer. Tell us what you think!

https://youtu.be/1VbafwjFCQI

Damn, I'm tired, but its starting to come together.

https://www.youtube.com/watch?v=DoCuVXnxDbI

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.