Fernando Sansberro
- 14 ago
- 23 Min. de lectura

The Game Design Process of Slidemagi

The purpose of this article is to detail the design process we employed in the creation of Slidemagi, a turn-based strategy game featuring some unique mechanics. It aims to illustrate how we can generate ideas and effectively work with them. Additionally, it traces the evolution of these ideas in a manner that allows readers to relate, aims to inspire budding designers, and emphasizes that game design is a methodical process, rather than a mystical gift from the heavens.

Slidemagi [1] is a turn-based strategy game developed by Batovi Games [2], in which units move by sliding the lines of the board. In this game, you are a Mage who, using your deck of cards, can summon spells or create units with unique abilities to fight under your control.

Fig 1: The slide mechanic of Slidemagi.

The First References

Slidemagi started as an attempt to create a casual puzzle game with some innovative mechanics. During the 2010s, we focused on developing casual games, and it was my study of game design that drew my attention to the "emergent gameplay" of merge games like Triple Town [3]. With the rise of match-3 games, many interesting mechanics and ways of playing emerged. At that time, we wanted to invent a puzzle game with some innovative ideas.

In researching these types of games and their mechanics, we came up with the first rule to prototype. We decided to use the line-sliding (slide) mechanic from Chuzzle [4] to bring two objects together, triggering some kind of action.

Fig 2: Chuzzle (left) and Chaos: The Battle of Wizards (right).

On the other hand, we always wanted to make a turn-based strategy game like Chaos: The Battle of Wizards by Julian Gollop [5], a duel of wizards where units are created using spells.

Throughout this phase, there was always a doubt whether the game would be a puzzle to solve situations or if it would be a strategy game. Finally, instead of making a puzzle, we decided to create a turn-based strategy game, a duel of two mages, but with original mechanics drawn from casual games. The main mechanic was going to be moving lines, hence its name: Slidemagi.

Note: The game's main mechanics will form what is known as the High Concept or Pitch. This is the brief description of the game that we will communicate everywhere, to anyone who asks what the game is like. In this case, the high concept consists of 1) moving lines on the board, and 2) a duel of two mages who create units and cast spells.

The Search for Mechanics

When designing a game, we take the elements or mechanics we like most from other games or genres and combine, modify, simplify, or exaggerate them to achieve the gameplay we want (at least in an initial idea, at this stage).

In the case of Slidemagi, the game primarily adopts the mechanics of Chuzzle, along with elements from tactical games like Chaos: The Battle of Wizards, and certain elements from Chess [6].

During the brainstorming phase, we can think of any idea or mechanic, but when it comes down to actually designing the game, we need to consider how each mechanic aligns with the objectives we set for the game.

The premises we set for ourselves are: 1) The game must have a low barrier to entry, 2) It has to be simple. The rules cannot be complicated to understand, and 3) It's a game with a thoughtful pace, but it needs to be dynamic and intuitive (like "casual" games).

In tactical games, units have classic mechanics: movement range, action points, various attributes, there are spell cards to use at any time, etc. As we mentioned, we want a simple game, we don't want to memorize different movement ranges, have units with many attributes, or with complicated combat rules.

Fig 3: Chess. A perfect game.

The other reference is Chess (as a player who competed in Chess in my youth, I know well how it works and what makes it addictive, to the extent that studying the game in books is even a pleasure).

Chess is a wonderful, and we might even say perfect, game. But it has two fairly significant barriers to entry: 1) Learning the movement of all the pieces and some "strange" rules like castling, en passant capture, and the 50-move rule for draws (tie), and 2) Once we learn to move, we don't know what to do. We have to learn to "think". This involves being able to visualize combinations of moves "forward" (being able to visualize the board in your head). This takes time, but it becomes the most fun part of the game (remember that "fun" is a concept that is different for each person).

Years ago at Batovi Games, we developed Ajedrez y Leyendas [7], a game for the Plan Ceibal (One Laptop Per Child project) in Uruguay, which teaches how to think in Chess, and the game was used for a National competition. Slidemagi was designed with a lot of prior experience regarding chess and its learning process, as well as the experience gained in the casual gaming world.

In Slidemagi, all this knowledge would come together.

Fig 4: Ajedrez y Leyendas by Batovi Games.

While developing the Chess game, we received a call from some guys who were making a "Chess 2", called Ajedrez Omnia [8], and they wanted to pitch it to us to convince us of its production. We met them at the office, and they explained that the game was played on a 10x10 board and included new pieces: a catapult, a wall, a dragon, etc. Nothing out of the ordinary, and I didn't have the heart to tell them, "I'm not going to program a prototype to see if I like it." However, there was one very interesting piece: a Wizard, who could teleport to any square, and immobilize the adjacent pieces! The Wizard couldn't capture pieces; immobilizing is the only function of this piece. I thought that piece was fantastic, and it triggered me to think, "What if many pieces did something unique like that? It would make an excellent game. It would change the strategy significantly. There was something to explore there... A lot of time passed since that moment, but the idea kept circling in my head. Visits to the Chess Variants [9] website to look for pieces with new mechanics became frequent.

All this was the seed for laying the foundations of Slidemagi's core mechanics: Chuzzle+Chaos+Chess.

Note: It is very important to have the main premises defined because then each mechanic considered must be discarded if it does not align with them, and we must work only on the mechanics that reinforce the main premises.

Summary of the Development Process

The project began with several prototypes to validate and (especially) discard ideas in "hobby mode" (at night, outside of the studio's daily production). The game has a lot of personal work invested in game design, and then, once in production, the contribution of the entire team significantly improved the game.

Later, in 2015, an eight-month prototype was developed (by one programmer and one artist). This prototype served to validate the general idea, but many rules remained open. After that, it was continued in my free time (at night) over several years (some days dedicating a few hours, other days a few minutes, and some days not at all, with very long periods in between when I dedicated myself to other projects). But this game was always on my mind. It was a game I wanted to make at some point.

In the following years, also in "hobby mode," I developed it from scratch, refactoring everything and discarding things that didn't work in the prototype testing. I switched the game to pixel art because that was the art I could do on my own.

In 2023, talking with my partner, Roque Papa, and discussing the need to "change air" and take a break from soccer games (after intense years developing Pixel Cup Soccer [10] and Charrua Soccer [11]), we decided to put the game into production at the studio. Roque asked me to include pre-rendered 3D art (something Roque is an expert in producing), to make it isometric (because it would visually look better), and he asked me to be open to changing rules.

The final project took a full year of development, starting from scratch. The result is truly amazing. It was much better than what I had imagined when working alone.

Note: The game designer must be able to listen to ideas and suggestions and try to interpret what is behind them to improve the game, instead of trying to defend yourself and explain why something is the way it is and cannot be changed.

The First Prototype

The prototype was developed in Flash very quickly (using assets from Oryx Design Lab [12] to focus solely on the rules). At that time, mages created units, and only the lines of the mages could be moved (the units are moved with the line). The idea was to try to place a unit next to an enemy so it would attack them. Moving the line could pass the unit to the other side of the board (cyclic displacement).

Fig 5: The prototype of Slidemagi developed in Flash.

I tested this prototype with my son (who was a boy at the time), and he looked at me as if to say, "Dad, why are you making this game?" I felt silly. It wasn't working; it was impossible to place a unit wherever you wanted.

Note: It's better to prototype quickly and fail, so as not to waste too much time. You can prototype on paper to avoid programming, but if you can program, it's much better because you can quickly test alternatives that sometimes can't be done as well on paper. Of course, it depends on the game.

Evolution of the Rules

After testing the prototype, it was clear that the units also needed to be able to be moved. Upon analyzing alternatives, and since we decided we didn't want a high entry barrier, we discarded any idea that involved movement range or different movements for each unit. Moreover, it was necessary to differentiate from the existing strategy games, as there are hundreds of very good ones out there.

So, we defined a rule that would have a degree of constraint: "All units will move in a straight line". A constraint rule is something we decide must be this way and do not reconsider (meaning, we can't doubt its existence). This is based on the theory that the game can be fun with this rule, even if it might not seem so clear at first. Of course, this doesn't always work, and a lot of judgment and intuition are needed to define such a rule.

In this way, if all units move in a straight line, it eliminates the entry barrier of how to move (as happens in Chess). Movements and attacks in diagonal, movements with a range of action, etc., were discarded.

The idea was for the game to have the depth of a strategy game but be very easy to manipulate to eliminate the entry barrier.

The Second Prototype

The second prototype had the following rules: The mage moves his line, and all the units in the moved line attack (this gives more power to the mage's movement). The units could walk and would only stop when they encountered something (a mechanic similar to a Tilt Maze [13]). This prototype was developed in Unity [14].

Fig 6: The second prototype of Slidemagi developed in Unity.

Of course, this didn't work either. There was no way for the units to end up where the player wanted. It was a failure.

Then, it was decided that the units would walk (always in a straight line) to whichever square they wanted. The way to move is: you click on the unit, the squares where it can walk appear, and it walks there. In theory, you can reach any square of the board in two moves.

These rules were going to constitute the basis of the design at this point: 1) Mages move lines, and all the units in that moved line attack, 2) Units walk in a straight line, and when they reach their destination, they perform their action.

Fig 7: The modified prototype with the walking units.

How to Get Ideas and Game Mechanics

Throughout this process, which we can refer to as the project's pre-production phase, we conducted several brainstorming sessions. These could range from simply spending a few hours working alone and thinking, to organizing gameplay sessions where we listened to the team's opinions. For this game, we also conducted exercises in game design classes, where students were tasked with "creating a unit and a spell for Slidemagi”.

Note: A brainstorming session should be conducted receptively and collaboratively in a creative process, where the suggested ideas or mechanics are listened to and analyzed. For each idea (no matter how outlandish it is), try to understand the reason behind their suggestion, attempt to incorporate that idea into the general concept of the game, and most importantly, for each idea or mechanic presented, think of alternative ideas (combine them, modify them, think about their opposites, exaggerate them, simplify them, etc.).

Fig. 8: A brainstorming session with students from the game development career.

When suggesting mechanics or adding them to the list for evaluation, not everything is acceptable, to simplify the refinement process later on. Any developer is a creative individual, likely well-read on game design, and understands why each mechanic works, including its pros and cons. Sometimes, this knowledge is intuitive, having come from playing many games. Therefore, it's important to exercise some judgment when suggesting ideas.

For instance, not everything is suitable for the game. If, for example, we start with the premise that the game must have a low barrier to entry, anything involving action range, complex attributes, and the like is automatically ruled out. It was up to us to filter these out so as not to affect sensitivities.

In Slidemagi, the mechanics evolve into a list of units, spells, and types of squares to be defined. During the time dedicated to brainstorming, numerous strategy games and collectible card games (CCGs) were examined, sometimes going through their entire card listings, in search of inspiration for units or spells that could work in the game.

Finding units or spells for this game was not straightforward, given that the game lacks complex attributes, action ranges, or the classic elements of strategy games. Any spell of the type "expands its action radius" or "increases its defense", of which there are thousands in games, would not work. On the other hand, what was sought were mechanics that were "a bit different", for example, A spider that shoots webs and traps the enemy, while an adjacent friendly unit can free it.

Cleanup and Testing of the Ideas

After the brainstorming process, with the passage of time and several iterations of the ideas, we settled on the following mechanics to be considered:

Units with special actions. For example, An Ice Elemental freezes whoever it hits, a Spider shoots webs and traps, a Scorpion poisons on hit, and the poisoned unit loses life per turn if not healed, a Medusa petrifies the enemy, a Hypnotist converts adjacent units to our side, etc.
Any trapped or frozen unit is more vulnerable to hits (x2).
Units standing next to a trapped friendly unit free them.
When a unit dies, it leaves a skull (as if its soul is there), which blocks the moved line, limiting possible movements. A Necromancer can revive the dead, and units can destroy skulls with one hit if they wish.
A Golem is immune to arrows and functions as a movable wall, while also having a strong attack.
Several common spells like healing, increasing attack, poisoning, etc.
Units have a facing direction and hits from behind count double. When a line is moved, the units turn and face that direction.
Several layers to add complexity for expert players: For example, 1) units have a magical alignment with the world or a light/dark cycle that makes them perform better at certain times and worse at others, 2) some units are weak against others, for example, living vs. dead or natural vs. magical, etc.
Action points to move each turn. It could be many moves in general, or some moves per unit, etc.
There are gems to collect on the board that grant new spells.
Squares with special symbols that grant powers when stood upon.

Fig.9: Checkman (Zilec-Zenitone, 1982).

Note: Any mechanic seen in another game can work if it aligns with the defined premises of the game. For example, when a unit dies and leaves a skull that blocks the lines, this was inspired by the game Checkman [15], an arcade game from 1982, which has nothing to do with the genre of our game.

The Third Prototype

In the prototype we had at this moment (created in 2015), several unresolved issues were detected during testing. The idea was to make a prototype from scratch, partly because the previous one was old, a lot of time had passed, and the rules were going to change significantly. On the other hand, I was working on it as a hobby, in my available time outside of the studio work (which takes up almost all week), basically at night, or on weekends, if possible.

I decided to use a pixel art style, because as a programmer, it was a style I could manage for the placeholder art, and this way, we could focus solely on the gameplay.

Fig.10: The third prototype of Slidemagi.

This prototype aimed to have the rules finally validated so that the game's production could begin at some point.

One of the main issues with the current version was that there were multiple action points (several moves) within each turn. Thus, a player who thought things through could execute a series of lethal moves (for example, moving a unit to a square that increased attack power, and then moving it next to the enemy mage to kill them). This made the game very frustrating for those who thought less, and there were also very even matches that lasted for tens of minutes, ending suddenly due to such a combination.

The UI was complicated. There were movements to flip the unit facing that did not consume action points, and players adjusted all units facing before moving. This made the game unbearable, waiting for each unit's direction to be adjusted at the start of each turn.

Another issue to be resolved was that when a unit moved to a square, it had to be defined if any action could be performed, or if only one action could be taken according to some rules. In the current prototype, when a unit moved to a square, a menu appeared to choose what to do (whether to hit the enemy or not, whether to shoot, etc.). This was very complicated to manage.

As we want a game that is simple to manipulate, it was decided that only one action would be performed, but the rules should be clear so that the player knows in advance what that action would be. When a unit walks and reaches its destination, where it can perform various actions, which one does it execute? This led to countless hours of drawing, analyzing rules trying to make them intuitive, and finally, something understandable was reached. With these rules, a Game Design Document (GDD) was written, specifying the order of attacks.

Fig.11: The GDD explains the action rules of the units.

Related to movement, there were also issues to resolve. Can walking units pass through objects? Can flying units shoot over trees? Can they fly behind an enemy and attack from the back? To simplify the game, it was decided that no unit can pass through another, including objects. Of course, objects can't be small because that would suggest you can walk over them, but we're talking about games, so a gem will be the size of a unit. We're already accustomed to these kinds of things in games.

In the current prototype, when the mage slides a line, units appeared from the opposite side. This was impossible to visualize for some players and very frustrating when someone made that move and attacked. This was discarded, and it was made so that units block movement (just like the skulls).

Note: When evaluating discarding ideas or making changes, it's not advisable to think about how much development time or lines of code will be wasted. Everything should be aimed at improving the game. Of course, this isn't particularly easy for those with a programming background. Related to this, it's advisable to try writing code that's flexible to rule changes and, of course, to write extremely clean code and document absolutely everything.

The Fourth Prototype and the Final Rules

In 2023, we decided to put the project into production at Batovi Games. Being more mature, we began to review all the rules. My partner, Roque Papa, is heavily influenced by casual games. So, the first thing he said to me was, “Why does the mage move the lines and the units walk? Why don't all units move the lines?”

That day I thought about running away and throwing everything away since I had thought, “Mages are powerful and that’s why they move lines, units walk,” but being more mature, I applied the constraint rule and said: “You’re right! If everything moves the same, it’s easier to manage” (and with that, half of the code lines would disappear, but since I had programmed them, I would be the only one crying).

Note: At some point, we must let go of ideas that seem brilliant (and possibly are) in favor of reinforcing the constraint rules we set for the game to improve it. We should try to analyze them, and defend them if we want, but also know when to let them go. Sometimes it helps to look at the game from a distance as if we didn’t know it.

Naturally, this meant throwing away a lot of work, and many things wouldn’t work (for example, going to attack a unit in the same line, or standing on special squares). When presenting this problem, Roque suggested a spectacular idea that would completely improve the game: when a line is moved, and a unit gets stuck at the edge, everything squeezes together. The squares move under the feet once things are pressed against the edge. In this way, a unit in the same line can move closer to attack or can place a deadly square under the feet of an enemy.

Fig 12: The squeeze mechanic when sliding the line.

This, in turn, solved the issue that flying units no longer made sense if the units didn't walk. Now that units can be squeezed together and have a deadly square placed underneath them, flying units would be immune to the ground, and with that, they regained their purpose.

There was also much discussion about whether skulls or units should block movement because it wasn't clear why they did. It was also unclear why if a skull blocked the displacement of the line, why trees or units didn't do the same.

Since it had already been decided that the displacement would not be cyclical, things at the edges would either block or fall off. On the other hand, if a unit could be thrown off the edge, why couldn’t all of them be thrown off? We decided to test with rapid prototype versions, making constants in the code to test every combination of rules (a great achievement by the team programmers).

After some matches, things ended up squeezed against the edges, so we decided that units could not be thrown off the board, but objects could (just one). This was always a source of debate in the team because it wasn't uniform; a unit could be thrown, but not an object, and why could only one be thrown and not all of them? Animations were made for characters about to fall, to show they couldn’t fall, but the problem remained latent.

It also became difficult to count squares and know at a glance (i.e., without having to think too much) how far a squeezing movement could go. It was not possible to visualize mentally the positions ahead, something that is necessary for strategy games of this type.

In the previous prototype, when a unit died, the Necromancer could revive it, recovering it as it was. This meant the player had to remember which unit was which. To simplify, Roque suggested that only zombies be revived, to simplify the game. The zombie, once dead, completely disappears, freeing up that square.

Fig 13: The Necromancer raising the dead (making zombies).

After many tests, it was decided that no unit or object should fall off the board's edge. Since units fall into holes, water, or similar squares, and the dead, once revived, don’t leave a skull behind (later changed to a grave), the board gets cleared.

Throwing a unit off the edge would return the card to the deck. It was a way to get rid of an enemy. If the enemy was weakened by hits, it kept its energy when returning to the deck. All this ultimately made it hard to understand; it wasn't clear if a unit was created with full energy or was one that had returned to the deck. Moreover, in the tests carried out, players abused this mechanic. I particularly thought it was a brilliant idea for the unit to return to the deck, but I let it go, and instead, it was decided that all units would block the edges. No unit could be thrown off the edge, to make everything finally clearer and to allow for better movement previewing (if the unit was going to fall off the edge, it was much harder to visualize).

Another major change from the previous prototype was suggested by Mathías, a programmer on the team, who suggested that instead of only the units on the moved line taking action, all our units on the board should do so. This made the game much more strategic, making the units fight more. This also solved the problem when we moved a line, placing an enemy within range of another unit (for example, an archer above), which, as it was on another line, did not shoot. Now with this change, it does shoot. Each unit at the end of the turn performs its action in the four directions.

We also discussed a lot about the number of units and spells the game needed to work. The way it’s designed, each unit has its pros and cons, so some units or spells work better against others. This makes the game, or the need for spells infinite. But it was necessary to define a "minimum set" with which the game would be equally fun, and then define which units would be unlocked.

Note: The core gameplay must be defined as soon as possible. All other ideas to be produced should support this. The game must work with both a few and many elements.

Another series of discussions and back-and-forths revolved around whether spells can be used across the entire board, affect the whole board, a specific area, or if they are cast in a line, etc. For example, when defining a spell (like casting fire), when applying the possible shapes, we have the options of affecting a straight line or affecting an area.

After multiple tests that lasted months, it was decided that all future spells would have both forms, with different costs. However, for the type of spells chosen for the first version of the game, in their initial levels, casting fire is in a straight line, and the rest of the spells affect an area (poisoning, healing, etc.).

Note: In these types of games, it's quite challenging to achieve uniform criteria and symmetry (for example, the number of line or area spells). The solution is to think that this will be resolved in the future (by adding other spells with all possible combinations and different costs). A lot of work is needed to achieve the best possible outcome for the current moment.

Action points per turn were eliminated, aiming for a dynamic game. This way, each turn involves moving a unit or casting a spell, achieving dynamic gameplay (this could even introduce very fun modes of moving intuitively in a few seconds, as is the case with Blitz Chess [16]).

Finally, other discussions included the use or absence of randomness, the different types of squares, the spells and units to include in the first version of the game, and the assembly of the card deck and its mechanics.

Random and Chance

Having randomness in the game is a way to introduce uncertainty, making it so that a player doesn't solely rely on their skill to win. When a player is competitive and has a better grasp of the game, they desire fewer random elements in the game.

In the third prototype, when a unit attacked, the chance of successfully hitting was calculated using the classic formula: if attack + RND(1,5) > defense + RND(1,5), the hit is successful. This had two problems in our game. The first was that we had to communicate this formula, and people needed to calculate the chances of hitting successfully. The second was that if a movement was made, and the hit wasn't successful, it felt frustrating.

We then decided to eliminate this chance from attacks, making it so the unit always hits successfully, thereby favoring those who make the attack move. This incentivizes moving units across the board and making attacks.

Nonetheless, the idea of having some randomness in the game was maintained with the concept of the current hand of cards. Out of the sixteen cards we can bring to the game, five are dealt that we can use at all times. When one card is used, another is dealt. This randomness must be compensated with skill if the hand doesn’t favor us. If the hand we get is very bad, we can discard a spell and lose the turn. Having a hand of five cards favors the replayability of the game.

Squeeze, Trap, and Release

In the third prototype, there were squares with symbols, and when a unit (which at that time could walk) stood on top, it would gain some power (for example, healing, strength, immunity, etc.). However, in the current version, units slide their row and cannot choose to go to a square that gives them benefits. This was a point we debated a lot because it was an important part of the strategy.

Now with the squeezing mechanic in place, allowing specific squares to be placed under the enemies, we had to think about types of dangerous squares with mechanics that affect enemies. The idea is to position oneself in lines with these types of squares and dominate the line so that if an enemy is placed on it, we can place the special square beneath them. Flying enemies are immune to the square effects.

After a brief brainstorming session, we came up with the following types of squares: a hole (the unit falls and returns to the deck), poisonous water (the unit sinks and gets poisoned, losing energy each turn until freed or dies), quicksand (the unit gradually sinks until it disappears unless freed), spikes (the unit dies), etc.

Any unit trapped in one of these squares is vulnerable to attacks, and to free them, you have to perform another squeezing movement, moving another one of your units and squeezing the one to be freed, placing a normal square beneath them to get them out.

Form Follows Function

To compile the list of units and spells, we typically start with an action, for example, "poisoning", and then we think about a unit and the spells.

For instance, the unit that poisons is the scorpion, the spell Poison Cloud releases a poison affecting the area, and the spell Poisoned Arrow fires a poison shot in a line. Considering all the combinations, we set up a table in a spreadsheet where we fill this in.

Fig: 14. One unit for all possible combinations of attributes.

As always, spreadsheets are a game designer's best friend. We create a spreadsheet to place all the combinations of attributes. This way, some units will naturally come to be, for example, a unit that shoots will be the archer.

Continuing with the example of "poisoning", we need a normal unit (scorpion), a unit that shoots poison: a snake. Then there will be some that are harder to assign a form to (for example, a melee flying unit that poisons when attacking, another ranged flying unit that shoots poison). It could be a flying snake or an insect.

Note: When defining mechanics, is good to follow the rule "form follows function," mentioned in Scott Rogers' book Level Up! [17] (that is, first define the attributes/mechanics and then think about the form it will take). This way, it's much easier to get ideas in an abstract form. It's much easier to find a representation that executes the defined mechanic than trying to do the opposite.

Bringing these possible combinations of units and actions into a spreadsheet forces us to think about the overall balance before creating units that don't contribute to the game's strategy.

During development, we evaluated whether we could choose any card from the deck we prepared for the match, or if the cards had usage costs, required colored gems, etc. All these ideas were discarded, and the initial idea of the deck with a current hand of five cards survived, following the premise that the game should be as simple as possible to understand (though complex to master).

When selecting the cards to assemble the deck with which we play the match, we decided to limit it to sixteen cards, to limit the duration of the match. A cost was added to the cards to prevent players from only choosing the best ones, requiring balance in selection. We also limited the number of duplicate cards to five to avoid making the game monotonous (especially considering that the game has online multiplayer, and we need to care for the user experience).

Conclusions

All the developed prototypes and the brainstorming sessions to think about the rules to find interesting mechanics, and to assign them to units and spells, worked out. We obtained a fairly original strategy game with some rules that are very rarely seen in these types of games.

Naturally, this process of continuous iterations takes a lot of time and effort and is only justified if we are seeking original mechanics. The idea of "iterating until finding the game" doesn't apply to developments with fixed timelines.

The advice here is that the game designer should try to undertake this journey of prototyping and iterating on mechanics outside the production phase, or even the pre-production stage of the project. It's essential to work in an environment completely free from pressures, one that fosters creativity (this can even be during nighttime hours, at home, relaxed), before even considering moving the project into production (with its costs and time pressures). This is the best way to achieve innovative mechanics.