This was the first time that my team was participating on the LD, and our project GARDEN ROYALE got really positive reviews (thank all of you for that!), so I decided to write a couple of articles to highlight some of the learnings we got.
You can play it here: https://nyamah.itch.io/garden-royale
We are aware that the game is lacking on several elements (bulky shooting mechanics, lack of sound…), but some of the info might be interesting to someone. Here we go:
The very first thing was to brainstorm an overall idea that would guide us through the ideation. We quickly agreed the game was going to be a Battle Royale with a twist:
Instead of just killing others, you would’ve to loot their bases (“gardens”), which would introduce a constant dichotomy between going out for loot and staying nearby to defend your possessions.
And then the first question arose:
SHOULD WE MAKE THE GAME REAL MULTIPLAYER?
From a technical POV, we were a very strong team and I’m sure we would’ve been able to pull it out, but there were two main problems which ultimately made us choose to just put bots.
The first of the issues was user concurrency, since without a significant amount of players at the same time the matchmaking would’ve been very problematic and take ages. This ultimately would’ve made that you played in rooms full of bots anyway so… why bother about the multiplayer at all?
The second point, was that multiplayer would’ve been hard to reconcile with what I call our “alive game design” paradigm.
WHAT IS “ALIVE GAME DESIGN”?
The classic videogame creation structure relies on the designer thinking the entire game and then the programmer coding it, the artist puts the graphics and that’s it. Most of our most beloved titles of our childhood have been created this way, and it is a great way to create a game fast.
Unfortunately, this model is also a very risky one, since by the end of the process you may realize the game was only fun or made sense on the head of the designer. “Alive game design” is the contrary of that.
“Alive game design” means that whenever possible I try to keep the design of my games deliverately soft, and rely on intensive and constant playtesting through the entire process: The critical part of the design is made during the actual phase of gameplay implementation, since that’s the moment where you better understand the value or limitations of your mechanics.
This allows to pivot fast if at any point the fun is lost, or some of the rules start to lose sense or complexify the game without adding any fun. Fun is the ultimate objective.
Our first iteration of the game was quite complex, as you can see on this core loop:
When playing, we quickly realized that the entire layer of managing and customizing your garden wasn’t very fun… you were more worried about the bots stealing your precious water than your plants being arranged making beautiful drawings. Cut.stealing your precious water than your plants being arranged making beautiful drawings.
In order for a weapon purchase system to make sense, matches had to be quite long, and we felt that the people playing games on a jam would prefer a faster product that you could enjoy in 1-2 minutes, rather than a longer experience that – while maybe more rewarding and strategic in the end – would require a bigger time investment.
Finally, the moments where the game was most fun were when a player stole from another the last drop of water and got the last one eliminated, and when you were desperately looking for resources as you were about to be eliminated. Shorter matches based on survival reinforced those moments and made them appear more often than a model based on collecting score (“honey”).
So it evolved into this, which doesn’t look as exciting but – trust us – it’s way more fun:
LEVEL DESIGN
Since you’re all seasoned players, you know that half of the fun on battle royales is to have complex scenarios that you need to learn and master (master where are the best points to hide, to get resources, etc). You know the drill:
Unfortunately, complex scenario shapes were uncompatible with the idea of making the game about bases: if the map wasn’t symmetric, then some players would’ve advantage over others. Our first iteration of the map looked like this:
But, again, after testing we saw that this limited a lot the interaction between players, and it wasn’t incentivizing too much stealing water between bases. Instead, players were mostly going to the central pool, stock up water and then defend like hell.
So that early pick was deciding who would win at the end. Not very exciting and few moments of “DAAAMN!! THAT GUY STOLE MY WATER!!”. So we got this, instead:
Which, while not very fair for the guy on the middle (the human player), it increased the chances of meaningful interactions happening with him.
The last thing that we added, and which created the current “stealth-based” meta, was tons and tons of foliage. At the beginning, the game was like this:
Being able to see enemies from that far away made easy for the player to locate enemy bases… but also made it easy for him to successfully plan a defense, and avoid the risk-reward mechanic by looting enemy bases only when he was sure that his base was not in danger.
Adding foliage created a more confusing situation, and ultimately made the player become more cautious.
Sadly it also meant that there are a lot of “surprise” kills because the AI is fairly good at detecting you, sometimes without letting you know until it’s too late and you’re already dead.
A kill cam or replay is a common technique used in FPS to show that, but it never made it on time.
I hope you had as much fun reading this article as I had writing it! If you did, please give it some love and check out GARDEN ROYALE (https://ldjam.com/events/ludum-dare/46/garden-royale).
It would be great also to have feedback on the article itself, since I want to get better at writing so that I can start a blog on my experiences in game creation : )
Salut!
@JBDev, Nyameh and Tebayoso.
JB-DEV 
One comment