Once again, as we did with BOB last Ludum Dare we’ll try to show some of the process of how we came to idealize Nobody’s Journey and what decisions we’ve made along the jam, what worked and what didn’t, because jams are about learning and sharing as well. I will try to keep it simple as I can and maybe share some useful insights about prototyping this kind of game.

This time we had @drkdavis by our side to give us a hand in Game Design, Balancing and Content stuff, and to help me in some insights on the programming of it all. We managed to meet at my place since we agreed that it’s much more efficient to work physically beside our partners. We didn’t want to “waste” much time thinking about the idea since none of us was that excited about the theme this time, so we came to the “final” idea fast enough to DrkDavis get deep into the mechanics’ design and @RodNasca decide which art style he would do as a benchmark. We didn’t do much of a brainstorm and all the other ideas were pretty “obvious”, so we don’t regret rushing it.

After some hours we’ve already discussed many of the game aspects, like the game loop (cards taking effect on revealing, activation and leaving), art style and programming architecture. I think these three topics can summarize the rest of the post mortem.

The art style was defined early and was the least affected by the design changes. Some of the icons and images changed some times, but the base style was the same all the way. RodNasca was inspired by other “digital casual boardgame”, that was Dicey Dungeons.

Talking about the design changes, that was quite a ride. As the weekend went through, the design flaws of the game became clearer and we had to make choices, fast. We still think the card effects system and card colors aren’t ideal, but it was the easy way out for it during the jam time. Because of that, we tried many card types, effects, and combinations, among the quest system as well. At the end of the day, we’ve settled it as it is now. So sorry for not having the past iterations of the cards now to show you guys.

So we had embraced an idea that was very dependant on content. With this in mind, we’ve used the first 5 to 6 hours just to settle and polish as much as we could what would later be the base of the system which the Game Designer would use to create all sorts of things and behaviors. After minor experiments, we’ve come to this ScriptableObject system based in UnityEvents which are responsible for the cards’ core mechanics.

We could then assign whatever event we might want each card to run in specific points of the game loop. It was just a matter of time for us to think about whatever behavior that came to our minds, just to experiment and use it later.

And with some organizing skills, we could just create as many cards as we wanted, and experiment in runtime any of it. It was the most well used time we’ve could ask for and we could even listen any of us thanking ourselves for this concept lol.

I think it sums up the key points for us in this game jam. It got even longer than expected, so if there were any points of interest or anything that wasn’t well explained, reach to me at @phyrophyro on Instagram, @rod.nasca, @davisnery or comment below.

Just to be a real TL;DR, let me just put some final thoughts:

• When you are unsure of the theme or how to think about it, just choose a convenient idea and make it good later. I assure you that ideas get better with time and it’s the most common thing in the world.
• Think about the tools and usability of who is going to plan the feature. We can’t stress enough how great was to prioritize tools this way. Even if you are the designer and will think about a feature for the artist to make, I’m certain that you can think about how he’ll do it in the best and efficient way possible.
• Try to make it possible to prototype, fast. The more you prototype in the shortest timespan possible, the sooner you will get to the best version of it, so prototyping it might be the first thing of all.