IntiQuest team’s proposal for a new mechanic for their Storyquest (Core:threadbare)

[LauraFoglia]

Hi @manuq @wjt and team! Victor Daniel, Andre Renzo, Alvaro Ivan, Dulce María, and Cristhian Diego, while working on their Storyquest, came up with a new mechanic to include in their third minigame. They even drafted several alternative ideas in case the first one turned out to be too different from Threadbare’s style.

Here’s the English version (original in Spanish attached).

Narrative Summary

In a village, two young people (Bryan and Charlie) experience a strange earthquake that makes all the inhabitants —including their loved ones— disappear. They encounter a mysterious white entity that seems to be behind it all and start following its trail through the village.

---

Proposed Idea for the 3rd Minigame

After solving a few puzzles, they find the entity, but it escapes, leaving behind an enemy (details may vary) they must fight in a turn-based battle.
Bryan fights using a piece of wood (obtained at the beginning), while Charlie relies on his cat (recently found/rescued).
Once the enemy is defeated, the outro of the story begins.

---

PLAN A1

A turn-based combat system is to be implemented in which both protagonists participate (unlike the previous minigames).
The camera and perspective remain the same, only zooming in on the combat area.

Features:

• Action Menu (for now, only the “Attack” option)
• Attack and target selection:
  • Bryan attacks using his wooden stick.
  • Charlie attacks using his cat’s paws.
• Health system: Life bars and damage received.
• Defensive system: Reuse the existing “Parry” mechanic from Threadbare, used only during the enemy’s attack turn.

---

PLAN A2

If having both protagonists participate in combat proves too complex, narrative elements can be used to incapacitate one of them, resulting in:

• A 1 vs 1 battle (main protagonist vs enemy)
• All other previously proposed aspects remain the same.

---

PLAN B1

If implementing a full turn-based system is not possible, the “battle” could be purely defensive.
Both protagonists would remain static (similar to turn-based combat) and could only parry or dodge attacks (new mechanic) until the enemy is defeated.

Features:

• New defensive mechanic: Dodge, available only during the battle. It allows players to avoid unblockable attacks.
• Two types of rhythmic enemy attacks:
  • One that can be parried.
  • One that can only be dodged (new mechanic).
• Two buttons assigned to each character (Parry / Dodge respectively).
  Both would be attacked and defend simultaneously if possible; otherwise, one at a time.
• Instead of life bars, reuse the existing attack return system (countering a set number of attacks to make the enemy disappear).

---

PLAN B2

If, again, having both protagonists participate in the “battle” is an obstacle, the same narrative tactic as in PLAN A2 would be used — removing one protagonist — resulting in:

• 1 vs 1 rhythmic battle
• All other previously proposed aspects remain the same.

---

PLAN C

If implementing the new Dodge mechanic or the combat concept altogether is not feasible,
the minigame would be purely defensive (Parry-based), similar to other Threadbare projects.

Propuesta de Minijuego 3.txt

[manuq]

@Vadito2904 @Andrle0600 @Zer0LoL @AMAI1505 @Cristhian036, ¡hola!

Plan A1: when you say "both protagonists participate", I understand that this is not a 2 players experience, right? It is still single player and the player can control 2 characters, one at the time. From the features I understand that you want a "Japanese RPG" style, where the actions are selected from a user interface menu. Keep in mind that Threadbare is an action RPG inspired in classic Zelda games. So you would be deviating from the game genre. That means that the systems included in the project won't be very useful for you. It sounds ambitious, but they're welcome to give it a go.

Plan A2: Is it still turn-based? I don't understand how this makes it easier. The complexity is not in the amount of characters but in making a different game genre.

Plan B1: Sounds promising! Seems action based, with the 2 characters not moving and 2 input actions assigned to each. Just keep in mind that you can't add input actions to the project, but you can reuse the existing ones. For example one character could use "move_up", "move_down" and the other "move_left", "move_right".

Plan B2: Same as A2, I don't think that having 2 controllable characters in the scene is the difficulty here. Check this test I did with 2 players, is as easy as duplicating the node.

Plan C: No problem with that.

Here is another idea:

• There are 2 characters, but only one can be controlled at the same time (walk, run, repel).
• There is a timer (say 20 seconds), on timeout the character that can be controlled changes.

For the earthquake, you can call CameraShake.shake() from a script, as an easy way to shake the camera (the ink combat uses it). Or even add a Shaker node to the scene to shake anything:

Grabacion.de.pantalla.desde.2025-10-29.17-43-27.webm

[Zer0LoL]

Hello @manuq , good evening. Thank you for your response. To clarify a few points, I considered both Plan A2 and Plan B2 because the mentors emphasized that it's not possible to change the game's camera (first-person or other types) and that multiplayer is not an option. While I don't consider it multiplayer per se, since both protagonists are used at their respective moments, not simultaneously (whether in turns, defending, or dodging), this narrative technique has been used so far to ensure only one character is controlled in each minigame. I'm using games like Final Fantasy as an example for this specific minigame because it maintains a single-player experience, but you can use the other characters. It's not part of the plan for any of the minigames to allow you to use all the functions with both characters at the same time (walking, running, fighting, etc.), just to be clear.

With all that clarified, I'd like to know if it's allowed to try and develop this idea (mainly the turn-based combat) or if it deviates too much from the threadbare concept (or if I'm breaking any rules). Your opinion would be a great help! :D

And thanks for the earthquake script :)

Thanks also for the ideas! The timer idea could be interesting to analyze.

[manuq]

Hello @manuq , good evening. Thank you for your response. To clarify a few points, I considered both Plan A2 and Plan B2 because the mentors emphasized that it's not possible to change the game's camera (first-person or other types) and that multiplayer is not an option.

Your mentors are right, Threadbare uses a top-down camera and the game controls are for a single player.

While I don't consider it multiplayer per se, since both protagonists are used at their respective moments, not simultaneously (whether in turns, defending, or dodging), this narrative technique has been used so far to ensure only one character is controlled in each minigame.

👍

I'm using games like Final Fantasy as an example for this specific minigame because it maintains a single-player experience, but you can use the other characters. It's not part of the plan for any of the minigames to allow you to use all the functions with both characters at the same time (walking, running, fighting, etc.), just to be clear.

With all that clarified, I'd like to know if it's allowed to try and develop this idea (mainly the turn-based combat) or if it deviates too much from the threadbare concept (or if I'm breaking any rules). Your opinion would be a great help! :D

Yes, again: it sounds ambitious, but they're welcome to give it a go!

As a player I would wonder why the controls are so different in this minigame. Maybe you can justify that the characters can't move because they are in a single tile?

[manuq]

I just want to mention that the implementation of this mechanic is now in the game, in Story Quest "After the tremor". Great work, @Zer0LoL and team!