Card Game | Slice Dungeon
Project carried out as part of my studies. The objective was to create a card game in collaboration with the game design class.
In this project, we were four GDP students. We all contributed to various aspects of the game. Personally, my main responsibilities were implementing the online save system, creating the enemy random spawn system, managing health evolution, and designing the FTUE (First-Time User Experience). I also contributed to many other tasks, but these were my primary roles.
In the game, an internet connection is required to play. This decision is not only technical — it also supports our monetization model.
By staying connected, players know that any items they purchase will be saved and accessible across all their devices. This encourages them to spend, as their purchases feel persistent and secure no matter where they play. To support this, I linked the game to an SQL database hosted on an OVH server. This allows users to log in from any device and keep their progress synchronized.
To achieve this, I set up an Apache2 server with a PHP web interface that connects the database to the game.
In the game, I created several classes to interact with the API depending on the expected response. I developed a "player data" section for the essential gameplay information, a "stats" section for all player upgrades, and a "UI" section that handles the display of interface elements.
When it came to random enemy placement, I encountered an issue right away: I couldn't generate the level from scratch because we wanted to keep control over the available level designs (the walls placed on the terrain).
To solve this issue, I created a map of possible spawn zones for the cards, so I could determine where to place them on the level.
I also created a similar map for placing collectibles within the level.
Once these maps were created, I could spawn enemies and collectibles in the level.
When an enemy spawns, I check the position of its extremities and remove the tiles it touches, since the enemy has a random rotation and a size based on its health and a randomness factor.
This allows me to spawn enemies in-game without them overlapping.
In our game, we manage states through a Game Manager. It allows us to track the current state of the game at any given moment.
To implement the FTUE (First Time User Experience), I built a system based on the same architecture, with additional elements dedicated to FTUE-specific logic.
With the FTUE Manager, we can easily see the current FTUE state and switch between them for testing purposes.
On the Hub and UI side, we didn’t have predefined GameStatus values, so I added the necessary FTUE state changes directly where needed in order to support the FTUE flow properly.
In the in-game FTUE sequence, I used existing game states to trigger context-specific explanations based on player actions. These FTUE actions were launched through the Game Manager, which invoked the FTUE state machine.
FTUEManager.Instance.AddActionToHealthBehaviourList(
FTUEStatus.WelcomeScreen,
() => GameManager.Instance.AddActionToBehaviourList(
GameStatus.LevelWin,
null,
GameManager.Instance.ForceBossLevelFTUE
)
);