Setting up the Game’s Core

Parts of the requirements were to make it a 2-player game composed of 3-minute sessions finishing on a high-score ranking over the multiple days of the festival.

Each play session was short, but there were other considerations to keep in mind:
– The players were varied in terms of possible age and previous gaming experiences. Mainly young children and the grandparents accompanying them, but also potential young couples, teenagers, experimented players… Anybody could come and play!
– The game was projected onto the façade of the Agora de la Danse. This meant there were around 500 spectators per game, and the game had to be visually interesting for them too. Players were waiting in a queue before their turn came, and observed the game beforehand.

Photograph of the final projected game on the Agora de la Danse façade.

We rapidly decided to opt for a cooperative game instead of the usual versus fighting. The goal was then “A game where the players are the ones in control of the flow“.
The game gives out some random output, but from there it’s up to the players to coordinate and get the better score.

After a few days of brainstorming, we had the final idea: “Complete a sequence of items in order, but you have to exchange items“. This design forced players to talk together and make decisions as they individually cannot do much.

Final look of the game. One player (in red) is stuck on the top floor, the other (in blue) on the bottom floor.

Iteration, Iteration, Iteration

We had just four weeks to make the game, so the keyword was Quick Iteration.

First, design iterations before going into the code since that was even faster than prototyping in our situation.
The gem-exchanger Snakes weren’t our first idea; we thought of elevators that automatically changed floor every 10-or-so seconds. But on top of being hard to justify why players couldn’t be transported, it also removed agency from the players. It would end up as a waiting game for the elevator to do its stuff, which is a bad idea in a timed game!

Then, we did playtest iterations: The game was tested every day by the whole team, and we constantly took notes on feedbacks but also how they played. We also had other members of the class and school try it out multiple times per week to gather the bigger feedback pool possible.

Signs, Feedback, Affordance

Our target audience was in a weird casual middle-ground: Mainly kids and the grandparents accompanying them, but also gaming adults or teenagers! The game had to be easy to understand, but they also would’ve seen it multiple times before playing since they had to wait in a queue beforehand, so some depth was still necessary.
We wanted the players to think about strategies they could employ when it’s their turn to play.
On top of that, we had to strike a balance between easy to understand while playing and interesting enough to watch for the public sitting in the bleachers.

How to make the game visually full and pretty while not being too complex nor noisy?

I used what I called the “Index of Complexity“.
The human brain remembers things by creating connections between individual elements. Many separate items are hard to remember, but if they are grouped together and linked intuitively, it’s easier to recall (that’s why mnemonic devices are so powerful!).

The “Complexity Index” of the game, first version (left) and final version (right). Notice how everything became more interconnected.

By putting all elements of the game in a graph and linking them together, we could see how many individual islands we had. The less islands the better.
Link those islands together, and we could have a system that’s easier to remember and comprehend: Gems don’t just spawn randomly, they’re brought by the Roots! If you see one you’ll think of the others and the game feels more coherent.
By having a game with a lower Index of Complexity in its mechanics, we could add more visual flair and still have something that felt easy to understand.

We also made a Sign & Feedback document where every single item or mechanic in the game would have its associated visual and auditory feedback. Since the overall Design of the game is simple, we had the time to put in some attention to details.

Scoring texts have their own color: Default is white, Sequence is yellow, Synchro is blue, Final Rush is red. Just one of the details put in the game.

Some of the signs, feedbacks and other visual things we added include:

• The current gem has a white blinking outline and moving arrow in the top UI, and its mask has a whirling background and particle effect…
• There’s a separate directional light just to add a rimlight and aid readability.
• The wooden bridge moves a bit when the top player walks on it.
• There’s a giant bird flying above the Kilimanjaro in the background.
• Gems have a cartoonish “sparkle” particle system to attract the eye to them even when idle.

Overall, Bas Haut Bab is still a really important project to me. Because of the amount of visual polish we were able to include for sure; but also because it is my first “public” game, shown to thousands in total and which was successful enough to come back for future installments of Cœur de Ville en Lumière.
Plus I think it’s a cool game too.