Pierre-Louis Faure Game Design Portfolio

Godling

The Game

Godling is a rogue-lite action game inspired by Hades, No Rest For The Wicked and FTL. The player has to explore a persistent map and its respective factions (Fire, Water, Earth and Air), clearing the machines that inhabit it and gain power through perks.

The objective was to make a vertical slice of the game, in collaboration with a team of 3D students.

▼ The Team

GD Team

Axelle JOURDAIN - Producing, Writing, Game Feel
Alexis MANFE-OCHOKI - GD, LD
Nicolas JEAN VICTOR - LD, GD
Nicolas RODICK - Narrative Design, GD
Maiwan OREAC - Programming
Pierre-Louis FAURE - GD, Combat Design

Artist Team

LE COQ Adam - Lead 3D artist
ROUX Lucille - Animation
OLIVIER Léonie - Animation
MNASRI Mayssem - Art Direction
KIRKLAND Liam - Art Direction
COSTE Charlotte - Art Direction
FREMY Evrard - Level art

▼ What I Learned

Working within a much larger group over a longer timescale forced me to be explicit about dependencies and communicate progress proactively, rather than assuming others had context I hadn't shared.
Adopting a Confluence documentation format taught me to structure information for an audience that needs to find things quickly, not read linearly.
Learning to scale down features without frustration was one of the harder lessons. Scope cuts stopped feeling like failures once I started treating them as design decisions with tradeoffs, not just losses.
Organising my own work around deadlines and dependencies made me realise how much design output depends on scheduling: a well-timed deliverable unblocks the whole team, a late one doesn't just affect me.

What I worked On

Game Design

Perk probability system
Main game loops
AI System
Metaprogression

Combat Design

Combat system
Balancing

Perk System

To support the design of our perk system, I created a spreadsheet tool that calculates the probability of obtaining each perk during a run.

The goal of the system was to avoid purely random builds while still maintaining variety. Players can influence the perks they receive by exploring different areas tied to factions, increasing their Favor with those factions. This allows players to guide their build toward specific playstyles rather than relying entirely on luck.

The perk system is organized into several perk trees, where unlocking a perk enables access to related perks later in the run. Because of this structure, predicting how often specific perks appear becomes complex.

To help visualize and balance the system, I built a tool that simulates perk availability based on several parameters:

Favor gating
Some perks require a minimum faction Favor before they can appear in the pool.

Tags
Perks belong to thematic tag groups (damage type or playstyle).
Obtaining a perk increases the probability of receiving other perks with the same tag, allowing builds to naturally specialize over time.

Prerequisites
Because perks form progression trees, the tool verifies whether prerequisite perks have already been obtained before adding a perk to the available pool.

Using these parameters, the tool dynamically calculates the probability of each perk appearing. This allowed us to quickly test different balancing scenarios, estimate how many perks a player might obtain during a run, and evaluate how strong those builds would be relative to enemy difficulty.

Perk Probability Manager

Dynamically calculated probabilities

Example of the parameters on the perks listing

Example of Perk Roll and addition to current character build

AI System

I was also in charge of designing the AI system of the enemies.

When designing the enemy AI, I had to take into account the combat system and its intents, which resulted in specific points in the AI design:

Since the player must analyse enemy patterns and commit to attacks at the right moment to avoid being hit, the attack timings of opponents must be coordinated
The player must also benefit from downtime between each enemy attack pattern, during which they can reposition and land attacks, so as not to be under constant pressure.
The AIs must also be capable of coordinating to perform joint attacks, not merely different attacks executed simultaneously.
There is no stealth dynamic in the game, but enemy AIs still have a detection zone beyond which the player is not spotted, allowing them to engage enemies one at a time when possible.

When creating the AI, we separated it in 2 respective parts :

Global AI (brain) :

Generate attack budget every few seconds, and use it to trigger enemy attacks
Chooses specific enemy attacks
Coordinates attack timing

Individual AI :

Takes care of movement
Repositioning if too close

One of the main issues we had was handling how the AIs would update their actions depending on the player so that it wouldn't miss all its planned attacks all the time. To fix this, we gave each individual AI an "engagement range" that registers them to the brain as available for attacking. This way, the brain only sends attack to those who are close enough to the player.

When we started implemeting them, we chose to use the State Tree instead of the behaviour tree, as its modularity would facilitate the development, allowing us to re-use functional parts present in the player combat system.

Integration is ongoing, the section above reflects the design work rather than the final in-engine implementation.

If you want more information on how the AI functions, take a look at the documentation. (in french for now!)

Combat Design

One of my biggest job was designing and balancing the Combat system.

References & Design Intent

I drew inspiration from two games with contrasting approaches. Hades offered fast, fluid combat but with a moveset I found too simple to sustain engagement. No Rest for the Wicked had more deliberate, weighty exchanges, but felt slightly too slow for what I had in mind. My goal was to find a middle ground: combat that feels responsive and momentum-driven, but where individual attacks carry enough weight to make choices matter.

The Combo System

I based the combat on a 3-hit combo structure, with a dodge roll to avoid enemy attacks. The original design allowed the player to branch between light and heavy attacks at every step of the combo, giving full flexibility over each hit. In practice, this created a system that was difficult to read intuitively. The branching wasn't obvious to players, and the animation workload it placed on the 3D team was too high to sustain within the project's scope.

After playtesting and discussion with the team, I simplified the structure: the first two hits of the combo are fixed light attacks, and only the final hit offers the choice between a light or heavy finisher. This reduced the animation requirements significantly, made transitions between attacks much cleaner, and didn't lose the decision-making the original system was trying to create. The meaningful choice was preserved, just moved to the moment it actually matters.

Animation Tree

I also had to make an anim blueprint to better handle transitions and anim blends. Before, we used a sequence player, which caused problems with said transitions. Making one also made the combo much easier to understand and read.

The Mana Mechanic

To give combat a strategic layer beyond pure execution, I designed a mana system that rewards the player for engaging actively with enemies; landing hits and successfully dodging attacks both generate mana. Accumulated mana can then be spent to empower an attack, with stronger effects available the more mana is used.

The original version of this system was considerably more complex: mana was tied to different factions, and specific combinations of mana types would produce different effects. Over the course of development, I identified this as too difficult to read and too costly to implement cleanly, so I simplified it to a single mana type with a scaling power output. The core design intent was preserved: study the enemy, use their patterns to build resources, and strike in the opening. The simplification made that intent accessible enough to actually work in play.

Godling_Attacks

Collaboration with the 3D Team

Designing the combat system required close collaboration with the 3D team throughout. My initial proposals consistently required more animation work than was feasible, which pushed me to iterate not just on the design itself but on how I communicated my needs.

I produced an asset list for every animation required, specifying durations and functional parameters, which gave the team a clear brief and allowed us to negotiate scope together rather than after the fact.