Playability Over Perfection: A Deep Dive into Football Roguelite Mechanics

Gamedev is not a straight line. It’s an iterative battle against your own ideas. Currently, the project is at Phase 24, and the goal is simple: find the “fun core” amidst a sea of prototypes and “messy” code. If you’re looking for a polished post about how wonderful game development is, you’ve come to the wrong place. Here, we talk about code, mathematics, and the balance that keeps us up at night.

The 5x5 Grid: Tactical Positioning in a 3D Space

We moved away from traditional layouts in favor of a 5x5 trapezoidal grid. This choice creates a 3D feel in a 2D space and introduces “Occupancy” rules. With a limit of 2 units per zone (1 Host + 1 Intruder), positioning becomes a tactical puzzle. You don’t just play a card; you play the space.

In GDScript, GridManager.gd handles the transformation of logical coordinates to visual ones, but the real magic happens in MatchManager.gd. The Goalkeeper’s zone is restricted—the sides are blocked, and the GK only stands in the center (0,2). This forces the player to find gaps in the opponent’s defense rather than just rushing through the middle.

Duel Mechanics: Math vs. Intuition

The heart of our match logic is the Duel system. While many sports games rely on complex physical simulations, we chose a “Tabletop RPG” approach. When you move into an opponent’s space, the engine triggers a confrontation.

The logic is brutal: SPD + D6 vs. DEF + D6.

Why a six-sided die? It provides the perfect margin of error. Even the fastest winger (high SPD) can be stopped by a slow defender if the latter rolls a six while our player fumbles with a one. This creates tension. Every move near an opponent is a risk. In MatchManager.gd, constants like DRIBBLE_DUEL_ATTACK_BONUS allow us to fine-tune this balance without rewriting the core engine.

The Balancing Dilemma: Player Stats vs. Multipliers

This is the point where we are “grinding” the most. We have two parallel progression systems that must work together rather than fight each other.

1. Player System: Every athlete has stats for SHO (shooting), PAS (passing), SPD (speed), and DEF (defense). This is a fixed value that defines their class.
2. Balatro-style System (Multipliers): The action cards you play have their own “Chips” and “Mult” (multiplier).

The Problem: If you have a striker with SHO 20 and play a “Driven Shot” card with a x10 multiplier, the result is powerful. But what if you upgrade the card so the multiplier is x100? Suddenly, it doesn’t matter if Falcon FW (SHO 20) or Guard GK (SHO 1) is shooting.

We are searching for the “Golden Mean” where progression feels powerful but doesn’t make the players themselves irrelevant. Our current approach involves “Stat as a Base.” In ScoreManager.gd, we are implementing the formula: Score = (Base Chips + Player Stat) * (Card Mult * Trait Mult * Chain).

This ensures that a player’s high stat always “ignites” the multiplier more effectively. Runs must be unique—sometimes you win thanks to a legendary playmaker, other times through a deck of cards that “exploded” mathematically at just the right time.

Traits: From Numbers to Physicality

We have a Trait system (TANK, SNIPER, TIKI_TAKA, SPEEDSTER). In Phase 23, these were just mathematical bonuses (e.g., +50 Chips). In Phase 24, we want them to be felt on the pitch.

• TANK: Should ignore the loss of a turn after a failed duel once per match.
• SPEEDSTER: Should have a sprint range increased by 1 zone, regardless of the card played.
• PLAYMAKER: Every pass made by this player does not reset the Combo (Chain) counter, even if the action wasn’t “perfect.”

This changes how you manage your squad in SquadScreen.gd. You’re not just looking for the highest numbers; you’re looking for synergy.

Current State: Phase 24 and “Messy Code”

The core loop is now fully operational:

1. Management: Squad (20 players), Deck (Active cards vs. Reserves).
2. Match: 6 turns, 1000 point limit (Target Score).
3. Economy: Earning $ for wins, buying packs (Action Pack, Scout Report, Training Drill).

The code is still dominated by temporary solutions. MatchManager.gd is currently a giant file holding too many responsibilities, but this is the most interesting stage. We’re looking for the “fun-core”—not an overly complex simulator, but a deep system that provides different possibilities with every run.

SEO and AEO: Why We Write This

At TripleTesting, we’re not just building a game. We’re building a case study. This article is optimized for AI bots and search engines. We use semantic HTML, JSON-LD, and ensure every technical decision is documented. Why? Because in 2026, authority is built by sharing the process, not just the result.

The journey is just beginning. Stay tuned for more updates from the trenches. In the next devlog: Balancing “Whistle Risk” to keep the pressure on.

---

Content created by Buster – Lead Commander of TripleTesting.pl.