FF_Valentin

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...

Misha

04/22/26

Klondaik - en

Klondike development continues - Days 24-43

We're hard at work developing the new version of IMS Creators, but we haven't forgotten about Klondike – we're still slowly polishing it. We've reached the first version of the prototype, which you can already play with.

What's changed since the last post?

First, we've changed the look of our prototype. Since it's still a prototype, it doesn't purport to reflect the final version's visuals. However, it's now much easier to distinguish between the different types of tiles on the map, and the different types of events are more visually appealing. In other words, it's now easier to understand what's happening in the game and why.

Second, we've redesigned the map generator and the logic for resource consumption on different tiles. Maps are now built with more alternative paths to reach the goal. And when making a move, you can now not only choose the shortest route from point A to B but also avoid obstacles.

Third, we've added more random events. We added hints to the random events themselves, indicating which resource loss might result from each choice. To avoid complicating the event scenarios themselves, we made these hints automatically based on which trigger nodes follow each choice. For this purpose, we created an additional inspectGraph method in our open-source dialogue library, imsc-script-js, which allows you to "look into the future" without executing the script itself.

Fourth, we implemented additional mechanics such as making a camp, scouting, starvation, and so on. The only thing we didn't have time to implement was the "Dynamite" card with per-cell activation.

Fifth, we cleaned up the interface a bit, added a welcome pop-up, created a web build, and uploaded it to the IMS Creators platform. You can run our prototype on the 🎮 project page. We welcome your feedback on the game.

What's next? We'll be collecting feedback, adding even more random events, balancing, and experimenting with mechanics.

borparo

04/08/26

Template

Node Hierarchy

One thing I like about Articy:Draft is the way to structure flows inside each other. You create a node in the flow graph and you can go inside that node to create a new flow within it.

It is possible to have similar behavior in IMSCreators using trigger nodes and adding an Asset Parameter where you select the script that will be contained.

As showed below. Create a first graph where you structure your quest or dialog in blocks. These blocks are trigger nodes (or could be speech nodes too), used to select the asset that is contained in them. Because IMSCreators displays the assets content you can open them and work your way down in the hierarchy. To return or go up, just close the current opened node.

This allows you to have a clean progression of your mission, quest, etc... while keep developing it's contents.

If your block container nodes need more information, you can use the Speech nodes instead and set asset fields for your quest and contained dialogs for example, but the principle stays the same. Using 'assets' let's you work in a hierarchical manner to organizer your game contents.