BPM - Devlog #2 - GDD use case with IMS Creator
-> link to devlog#1
From Discussion to Formalization
One of the key challenges during this jam wasn’t technical; it was alignment.
With four contributors actively engaged, naturally, everyone starts doing game design on its own. 😅
This is both a strength and a risk. It creates constant questioning and helps uncover design flaws early, but it also means that each person tends to develop a slightly different mental model of the game at any given time. After our first major pivot, when we stripped the prototype down to its core rhythm loop, we realized that keeping that alignment intact would be critical.
To address this, we relied heavily on a tool: https://ims.cr5.space/
It is a game design documentation tool that helps teams formalize mechanics, systems, and progression in a structured and readable way. Beyond documentation, IMS Creator supports structured data tables that can be exported as CSV or JSON, enabling designers to manage balancing values directly in the design document and share them with the development pipeline.
The goal was simple: Turn our evolving ideas into a clear, shared, authoritative version of the game design.
For each important decision, I would formalize it in the game design document; it would be validated by the game designer, then shared with the rest of the team as a reference. This process introduced something we were initially missing: a single source of truth.
Instead of saying, "in my opinion, this is how the mechanic works", we could say "this is how the mechanic is defined in the GDD”.
IMS Creator was especially useful to lock down and iterate on our core gameplay loop, which we revisited multiple times throughout development. Every time I had to rewrite the core game mechanics, it helped clarify edge cases, remove ambiguities, and ensure consistency between design, code, and visuals.
Bridging Design and Implementation
Another very interesting aspect of IMS Creator was its ability to go beyond documentation and move toward something more “production-oriented.” We used it to create structured data tables describing game objects properties. These could be exported as CSV or JSON directly in our GITHUB repository with the idea of integrating them directly into our Unity project.
This was a more industrial approach to game production that we wanted to experiment with in this game jam.
In theory, this creates a powerful workflow:
- Balance the game in the design document
- New data gets synchronized in the game project
- Launch the game within the engine
- Test and repeat until you get the game feel right.
By the way, what do you think about our game?
→ https://flowerfield-games.itch.io/bpm
Next 'jam, we'll definitely try to get further into this production pipeline.
A prototype becomes a game when everyone agrees on what it is. Documentation is how you get there.
BPM - Devlog #1 - Pivoting after day 1
Overview: setting up a good 3-day-long game jam
BPM, Bionica Pro Mortalis, is our entry for Ludum Dare 59, a 72-hour game jam taken place in April 2026. This edition, the theme was Signal.
In this Devlog, I'll try to share some interesting details about how we managed to get that prototype in a very limited time, and what lessons we learned.
About us. We are a team of four:
- Jérémy - Game Design, concept Art, asset production, UX & UI Design
- Justin - Art direction, animation, integration, sound design, VFX
- Simon - Game Development, integration
- Valentin - Documentation, , Devlog, & Localization
When the theme was announced, we explored three main ideas, using a whiteboard to pitch each concept to the team:
- A tower-defense puzzle game about blocking signals
- A signal-driven rhythm combat game
- A static survival arena with invisible enemies detected through sonar signals
The signal-rhythm combat concept stood out as the most promising idea, and it fit well with our DNA. Let's focus our effort on character design, yay!
First vision: an action-based duel... or so we thought
Our references were clear:
- Nidhogg for confrontational duels with swords
- Final Fantasy IX – Theater Fight scene for dramatized duels with timed input
We wanted to make a fencing game with powerful visual and sound feedback on the character actions. The theme "signal" fed our imagination with cyberpunk vibes. The characters are animated bodies that are attached to a medical device that provides life and monitors their biometrics, i.e. the signal.
Before rushing to production, we spent time defining the scope of the game with the typical matrix:
- Must have: what we must do so that the game is playable at its core
- Should have: what we must do so that game is good and interesting
- Could have: what we could add for a incredible game (out of gamejam scope)
- Won't have: helps to define the game, defining what it is not.
In the first early-stage prototype, two characters were on screen. They could move, aim their attack, strike, and parry. Actions were resolved in real time in a versus-fighting style. Both characters were connected to ECG signals, which visually and sonically reacted to health points loss.
Basically, it was a single-player versus fighting game with limited action. The signal was more of a side concept to fit with the theme.
On paper, everything was according to the plan. In practice… something felt off.
Identity Crisis: Action Game vs Rhythm Game
Very quickly during playtests, we noticed a problem. In the team, we realized each one of us had a very different vision of what the game is and what it will be. What's fun and also difficult in a game jam is that everyone is involved in game design. Sometimes you dive in production with some interpretations from the previous brainstorm sessions.
“It's actually a rhythm game”
“Nah, it's a fighting game with some rhythm mechanics thrown in as a bonus”
“So what's the point of moving, if all you can do is attack and block anyway?”
"What's this game about? What's our selling point?"
In the early playtest sessions, players were reacting to visual output from the characters with real-time decision-making and freedom to act whenever they felt like. They were not playing the signal. The ECG was a visual and audio distraction, not the core of the gameplay. Players performed actions independently of the signal, undermining the entire theme.
What's fun is that we realized later on we wrote that the game won't have rhythm mechanics, whereas we were naturally drawn toward designing this way because of the game jam theme signal.
Guys, look at what's written on the fudging board-! 🤪
The Pivot: When the signal became the main character
The solution did not come from adding mechanics. It came from removing them. One by one, we stripped the game down until we reached a state where we could identify that core loop that suits us just fine:
- Removed movement
- Removed attack directions as spatial positioning
- Removed clashes (that worked as Rock, paper, scissors)
- Removed real-time decision-making
What if the signal was not feedback… but the main character instead?
That was the turning point. We realized that as long as the player could act freely, the signal could never truly impose its rhythm. So we removed freedom, and we made the signal the main character and started to build features around it.
After pivoting, the key factor was documentation... but that, folks, is for another devlog entry...