upper safe zone
Assistant Game designer at Ishtar Games
As an intern for 3 months at Ishtar Games, I worked on the upcoming DLC for The Last Spell alongside Victor Ternisien, a game designer who has been involved in the project for several years.
lower safe zone
upper safe zone
Project overview
This third and final DLC for The Last Spell concludes the development of the game released in 2023 (after two years of Early Access) by bringing new challenges and rewards to add even more replayability. This DLC is therefore not a continuation of the previous two, which added a new race (dwarves and then elves) with their own weapons and unique map.
Production time: 3 months full-time (on my side)
Genre: turn-based strategy
Engine: Unity
Number of players: Solo
The team:
-
4 game designers
-
2 developers
-
1 artist
-
1 producer
lower safe zone
My role
During these three months of internship, I assisted my supervisor Victor Ternisien with various design tasks related to the development of the DLC. I was responsible for testing and refining the game's balance, but I also participated in design discussions, the integration and testing of new content, and the collection and analysis of player feedback.
upper safe zone
Game description
Key Art of The Last Spell
The Last Spell is a TRPG roguelite game developed by Ishtar Games. Released in 2023. You play as The Commander, leading a group of rare and customisable heroes tasked with defending humanity's last bastions against hordes of monsters that attack every night.
During the day, players must fortify their city, manage their resources, upgrade their team and build defences. At night, the game becomes an intense tactical battle: they must face waves of enemies on a turn-based grid, trying to prevent the monsters from reaching the magic circle that the player must protect at all costs.
The ultimate goal is to survive long enough for the mages to cast The Last Spell, a spell capable of eradicating all magic and saving what remains of the world.
lower safe zone
upper safe zone
DLC Overview
The first two DLCs add content in the form of two new races, each with new weapons, unique perks and a new map. This final DLC takes a different approach, adding new systems linked to a new god to challenge players, who will be rewarded with bonuses, items and weapons to create ever more powerful combinations.
The DLC revolves around three systems, a new meta progression and a currency: Memories. These Memories allow players to purchase Epiphanies during the game. There are two ways for players to earn Memories: by completing Divergences and Ordeals.
Divergences are optional challenges that impact the next night.
Exemple screenshots from official communications
Ordeals, on the other hand, are short-term challenges that appear during the night to give the player an additional bonus of Memories upon completion.
Epiphanies are bonuses such as new perks, items, or weapons to strengthen heroes. They are linked to a new meta progression: Eposes.
Eposes are challenges that the player must complete in order to unlock new Epiphanies.
Example screenshots from official communications
Systems interaction diagram
Example screenshots from official communications
lower safe zone
upper safe zone
Balancing
Balancing in The Last Spell is a constant endeavour, due to the complexity and interconnectedness of its systems. Certain dominant strategies may emerge naturally, sometimes contradicting the design intentions.
As the DLC introduced several mechanics that had a direct impact on difficulty, I was actively involved in balancing them to offer both a new challenge for experienced players and a manageable difficulty level for more casual players. Playtesting played a central role in this work, thanks to a variety of player profiles that allowed us to test balancing decisions against very different play styles.
The approach differed depending on the system.
Ordeals
Ordeals are based on objectives to be accomplished within a limited number of turns. Each objective had to be achievable under normal playing conditions, without being trivial. In order to obtain consistent values, I began by defining minimum and maximum limits for each type of possible action (damage inflicted, enemies killed, resources spent, etc.).
I designed a reference table that allowed me to identify the constraints specific to each action and establish initial theoretical values. Using a rapid generation tool, I then tested numerous configurations in various situations in order to refine these values. After the feature was implemented by a developer, I handled integration and in-game testing to verify that the Ordeals were consistent with the design intentions.
Divergences
Balancing Divergences, whose penalties affect an entire night, proved to be more complex. Time constraints did not allow for exhaustive testing of every combination in real conditions. I therefore based my analysis on my in-depth experience of the game and on the systemic impact of each penalty.
Some penalties could be relatively strong without being game-breaking, such as those affecting situational statistics (e.g. multi-hit), while others required a much more cautious approach. This was particularly the case with Divergences that increased the presence of Bulky monsters – particularly tough monsters whose impact could quickly become critical. The aim was to create real tension without unfairly compromising the player's chances of survival.
Bulky
Adjustments to the Eposes
Feedback from playtests also highlighted issues with balancing and readability in the Eposes. Their progression was initially based on highly repetitive and unengaging actions.
Following this feedback, the objectives were reworked to make them shorter, more specific and more decision-oriented. For example, generic objectives such as ‘inflict a large amount of damage’ were replaced with more targeted challenges, requiring the player to exploit specific mechanics (such as inflicting a high amount of damage in a single hit under certain conditions).
lower safe zone
upper safe zone
Content creation
During my internship at Ishtar Games, I was regularly called upon to create new content to enhance existing systems or replace elements deemed irrelevant in the game. These tasks followed a recurring process, ranging from needs analysis to integration and testing.
The first step consisted of a period of reflection and analysis. After studying the existing content and the experience offered to the player, I proposed several design ideas, deliberately exploring a wide range of solutions without any immediate constraints in terms of technical feasibility. These proposals were then discussed with my internship supervisor and the other game designers in order to select a relevant direction or develop a promising idea further.
Once the solution was validated, I moved on to integrating the content (mainly via XML files), followed by a phase of iterative testing aimed at adjusting specific cases and preventing potential bugs or exploits. When certain ideas exceeded the technical possibilities available without specific development, I would write a clear document for the developers, detailing precisely the requirements and scenarios in order to limit back-and-forth communication and the impact on their schedule.
1. Ideation
2. Conversation
3. Integration
Case study: replacement of the "portable bridge"
Winged
The portable bridge was an item obtained through an Epiphany linked to a flying enemy, the Winged. The initial intention was to allow heroes to cross holes in the environment. In practice, this item was rarely used: the maps had few holes and, above all, creating a passage also benefited enemies, which often put the player at a disadvantage.
The decision was therefore made to replace this item, a task that was entrusted to me.
Analysis of the associated enemy
The Winged is a mid-tier enemy that players encounter regularly. Its statistical profile is relatively standard, but its behaviour is specific: it favours the flanks of the map rather than the centre, forcing players to spread their heroes out to cover a larger area. The bonus associated with the item therefore had to remain moderate while reinforcing this gameplay dynamic.
This analysis led me to a reward linked to mobility, consistent with the tactical role of this enemy.
Search for solutions
Several ideas were explored and then discarded (conditional damage bonuses, passive movement point increases, regeneration mechanics), either because they were too generic, too powerful, or already used elsewhere in the game.
The approach chosen was to create a variant of the existing Jump Over skill, offering reduced cost and alternative effects depending on the target. The aim was to offer a more flexible and attractive mechanic, while remaining consistent with the theme of mobility.
Integration and iterations
During integration, certain technical constraints necessitated a simplification of the initial effect. The skill was ultimately adjusted to inflict area damage upon landing after a jump. Although this result deviates somewhat from the original intention, testing showed that this version offered a competitive, clear and fun bonus that could be used in many situations and by all heroes.
lower safe zone
upper safe zone
Monitoring of closed beta tests
Shortly after I joined Ishtar Games, the second closed beta for the DLC was launched. Lasting two weeks, it brought together around thirty players, including participants from the first beta and new testers, in order to gather feedback on both the evolution of the content and the initial understanding of its systems.
Players had access to dedicated Discord channels and forum. As an assistant game designer, I monitored discussions to identify recurring bugs, misunderstandings about the design, and main points of friction, without intervening so as not to influence the feedback.
Finally, a structured questionnaire was sent out at the end of the beta to gather targeted feedback on the game systems, interface, and balancing. I took part in analysing this data, cross-referencing quantitative responses with qualitative feedback from discussions.
One of the major challenges of this phase was sorting through the feedback. Not all of the feedback was necessarily relevant: some contradicted the design intentions, while others involved excessive production costs. This prioritisation work gave me a better understanding of the importance of the overall vision of the project and development constraints in decision-making.
As beta periods are particularly intense, I learned to organise the reading and analysis of feedback in a rigorous manner, dedicating specific time to it each morning before the daily meeting. An interim patch was also deployed to fix the most critical bugs, ensuring more reliable feedback when completing the final questionnaire.
This methodology was applied to three closed betas of the DLC, then extended to an open beta scheduled for early 2026, whose main objective was to identify the last major balancing and stability issues before the final release. For such a complex game, these supervised playtests proved essential in improving the quality of the DLC without overburdening the development team.
lower safe zone
upper safe zone
Content integration process
In order to be fully operational during my internship on The Last Spell, I had to learn the content integration process used by the team. All of the game's rules and content are defined via XML files, allowing for a clear separation between the work of game designers and developers, while limiting technical conflicts and facilitating project organisation.
XML files are based on a tagging system that defines the behaviour of game mechanics. My job was to understand and use these tags to modify or create content by precisely adjusting their parameters. Thanks to detailed internal documentation and regular practice, I quickly mastered this integration logic.
In particular, I incorporated a large number of perks (bonuses applied to heroes) using a three-step process.
Defining the perk
The first step was to define the perk in the XML files: its variables, triggers, effects, and link to the conditions for obtaining it. This phase required a good understanding of the existing systems in order to ensure the perk was consistent with the other game mechanics.
1.
Localization and readability
The second step concerned localization. The aim was to formulate the effects of the perk precisely so that they were clear, explicit and usable by the player. This work was similar to writing board game rules: each formulation had to avoid any ambiguity, as this information has a direct impact on the player's strategic decision-making.
2.
Testing and debugging
Finally, the last stage was dedicated to testing and debugging. I tested each perk in a variety of situations to check its robustness, identify any bugs or exploits, and evaluate the game feel. These tests were sometimes supplemented by feedback from my internship supervisor and other game designers.
3.
Throughout this process, I communicated regularly with the developers, whether to answer technical questions or to formulate specific requirements when certain features exceeded the capabilities of XML. This collaboration gave me a better understanding of the technical constraints of the project and enabled me to adapt my design proposals accordingly.
lower safe zone
upper safe zone
Post mortem
What did I learn ?
Professional experience within a small team
Active collaboration with designers and developers
System analysis and maintenance of thematic consistency
Analysis and sorting of player feedback to define actions
Balancing work as a systemic task with adaptation of methods according to systems
lower safe zone
upper safe zone
The company
Ishtar Games is an indie studio based in Lille (France). Formerly known as “CCCP”, they previously made the “Dead in” games (Dead in Bermuda, Dead in Vinland, Dead in Antares), and The Last Spell. They love games that are complex, mix different genres, especially with an RPG component.
Ishtar Games is built, run, and founded by gamers. Because of this, they are passionate about being true to themselves and crafting games that not only hold their values, but are also games that they would like to play themselves.
Their games won’t hold your hand; they will challenge you, test you, and require your dedication and investment to master. They strive to create experiences that are both beautiful and thought-provoking, while also being disturbing and dark. Their gameplay might be violent and aggressive while telling a delicate and honest story. Or their artwork may be beautiful and engrossing while depicting a dire and depressing reality. Just like their namesake, the Goddess Ishtar, they pair things that might not typically be seen together.