TECHNICAL SPECIFICATIONS:

Engine: Unity.Genres: Action, Adventure, Stealth.Target: Mature players the grew up influenced by Japanese culture, particularly manga and anime from the 80s to the 2000s, looking for a nostalgic stealth experience.Constraints: This is a graduation project, developed by a team of 4 Game Designers and 2 3D artists, over a period of 10 months alongside classes and other academic work.

unique selling points:

The character of Binah is designed to highlight the development of a consciousness. This aspect is supported through both narrative and gameplay.The player character gradually shifts from a main character to a supporting role as he observes the world through intra-diegetic security cameras that they take control of.The game's aesthetic is inspired by 90s cyberpunk manga and anime.

My work:

System Designer and Programmer, I worked on the entire gameplay systems and handled the full programming of the game.To convey Binah’s evolution through gameplay, I researched different AI patterns and narrowed it down to two options: Utility AI and GOAP (Goal-Oriented Action Planning).Utility AI assigns a score to each possible action based on internal variables. It is used to evaluate the relevance of an action.GOAP defines a sequence of actions toward a goal, it is used for planning.The latter felt very promising to me in terms of representing Binah’s evolution. However, it also came with too many issues that would either reduce the impact of the system or break the gameplay flow. For example, the game’s difficulty would have been significantly reduced by allowing the player to simply assign Binah’s next objective and let her execute it. Watching her plan too far ahead in the future also felt off, as her reasoning would become too abstract.So I decided to implement the Utility AI, which fit much better with the moment-to-moment gameplay. Binah can refuse to perform an action, chose to perform a different one , or even act on her own depending on her internal state variables. Utility AI is used in games such as The Sims.I also designed and implemented a precise detection system based on visible body parts and the lighting of AI enemies.
Each bone of Binah’s rig is assigned a target used for visibility raycasts. The position of this target is also used to sample ambient light using Light Probes, defining a visibility score for each exposed limb, which is then mixed up with other parameters such as distance or state to define the detection speed.Unfortunately, the systems mentioned above could not be properly implemented in the levels due to production delays in this part of the development. To compensate, we decided to script certain sequences manually in order to still convey Binah’s progression through gameplay.To make Binah’s movement feel more natural I made them more responsive to her environment and her internal state. I modified Unity’s pathfinding system so that she avoids danger and stress zones by slightly detouring around them. These zones are treated as having a higher cost by the algorithm and can be be placed manually or linked to enemy presence.To make enemies feel less robotic, I implemented a dynamic patrol path system. An enemy that has chased Binah away from his original patrol route will join a new, closer patrol path rather than simply retracing its steps after losing sight of his target.I also handled level blocking, taking into account enemy placement and fixed camera viewpoints. The level was fully playable from start to finish, but could not be fully dressed in time du to delays with previous levels set dressing. And to facilitate level creation, I also developed tools, such as procedural generation for working ladders.

what i learned:

I realized the importance and the omnipresence of Game Design, even in games with narrative ambitions and more passive or systemic gameplay.The scale of the project and the amount of work required pushed me to become more proactive within the team, beyond the tasks directly assigned to me.I also had the opportunity to deepen my knowledge of Unity and programming in general.

TECHNICAL SPECIFICATIONS:

Engine: Unreal Engine 5.Genres: First-person parkour.Target: Players of first-person parkour with contemplative elements.Constraints: The game has been developed in a month by a duo.

unique selling points:

The player is encouraged to go faster and faster. Performing traversal actions grants a temporary, stackable speed boost.

my work:

I mainly worked on prototyping and the development of movement mechanics.I was also in charge of level design and level building. We were lacking 3D artists, so we only requested a limited tile set of a gothic cathedral, hoping to polish this part of the environment as much as possible. I built the entire structure piece by piece. Unfortunately, the rest of the level could not receive the same level of care, and I regret this approach. Triplanar materials had to be applied over blocking geometry to compensate for the lack of assets, with limited success.I also took part in organization. However, as there were only two of us on this project, we underestimated its importance, which is reflected in the unfinished nature of the project.

What I learned:

I became aware of the importance of having a scope appropriate to the size of the team and of never underestimating the project management required. In this project, there were only two of us, and as unxexperienced game designers we had an overly ambitious vision and a lack of proper project follow-up.More than just simply avoiding scope creep, I now make a conscious effort to actively reduce scope whenever possible. This has greatly helped me in my subsequent personal projects.Also, useful note for revisiting the project: we noticed that too much speed prevented contemplation without specific design adjustments. In this version, the adjustment mainly consisted of lengthening straight paths, which created too much downtime.

TECHNICAL SPECIFICATIONS:

Engine: Unity.Genres: Roguelite Top Down.Target: Fans of roguelites, science fiction, and fast-paced gameplay.Constraints: The game was developed by 4 Game Designers over a period of 3 weeks. We had to use Unity for the first time and draw inspiration from the film "Sunshine".

unique selling points:

Dying allows you to choose a permanent upgrade to keep, in exchange for a reduction of your maximum health.

my work:

I was responsible for the game design and balancing of the combat systems, including the player’s abilities, and the active and passive effects of artifacts, as well as enemy behaviors. After establishing a solid foundation, I also handled the implementation of the game’s game feel and juiciness.The camera was a real challenge. Developing on a high refresh rate monitor led me to push the effects too far. The final presentation had to be done on a TV locked at 30 FPS, which highlighted the issue. However, the game was uncomfortable even at 60 FPS due to the camera. The game has since been updated with a less chaotic camera.Another challenge: as project lead, I chosed to take over level production from the person originally in charge of it after they repeatedly failed to deliver anything. And to avoid frustration on their side**, I reassigned them to sound design, a field I knew they enjoyed. Despite the chaos this caused, I am proud to have managed to keep the situation under control.I later learned that they had intentionally sabotaged their work in hopes of switching to sound design by pretending to be done with it. In hindsight, I still believe I made the right decision by reassigning them early. We addressed the issue of self-sabotage after the project was completed in order to prevent any further disruptions.

what I learned:

Since encountering these issues with the intensity of camera effects, I now make sure to test my work in different conditions to avoid overlooking such major and problematic issues again.I also realized too late in the project that the core concept of progression through death was too fragile to serve as the foundation of the game, and that it encouraged players to die regularly rather than persevere. I should have spent more time evaluating this system before validating it.From a team perspective, the group was made up of people who did not get along, and I was also part of the problem. Navigating this environment pushed me to improve my communication skills and management approach, while remaining professional.

TECHNICAL SPECIFICATIONS:

Game Engine: Unreal Engine.Genres: Tower Defense.Target: Tower defense players tired of traditional layouts and fans of Māori aesthetics.Constraints: The game was developed by 5 Game Designers over a period of 3 weeks with support from the 3D artist class. This was our first game development project and the use of Unreal Engine was forced upon us, as well as the theme "Tahiti".

unique selling points:

The play area is distributed across the height of a pillar that the player must protect. Removable rings, which serve as supports for towers, are placed around the pillar and can be rotated and moved vertically. These rings also act as physical barriers protecting the pillar, but they are not invulnerable and can be destroyed.It is also divided into two zones: underwater, where the action takes place, and above water, where the player can upgrade their defenses and passively repair the rings. This separation encourages players to take risks by playing blind.

My work:

The pre-production phase was chaotic, and we struggled to reach agreement. I prototyped many systems to help move the project forward.Once pre-production was complete, I took on the task of organizing everyone’s schedule to ensure we progressed at the right pace. We had already spent a lot of time deciding on a direction and could not afford to lose any more.Additionally, since my team had no experience with the engine, I started the programming alone using Blueprints until my teammates were able to join me on the code toward the end of the project.I also conducted research on the stylized rendering of lighting and water surfaces. These effects were achieved by modifying portions of code taken from tutorials.

what I learned:

This is where I discovered the power of prototyping as a communication tool. It truly helped us quickly break through a situation that felt hopeless to all of us.

TECHNICAL SPECIFICATIONS:

Engine: Godot.Genres: 2D Platformer, Semi-Roguelite.Target: Players who enjoy short experiences, typical of Itch.io players. Suitable for both casual and more experienced players, willing to push themselves to improve.Constraints: This is a solo project developed over 3 months. All of this was done alongside classes and my graduation project, SEPHIRA-03.

unique selling points:

The player balances their own experience in order to fully engage with its message:

"For a healthy personal development, it is equally important to work on defining one’s ideal self as it is to work on the process of approaching that ideal."

They are free to choose how to reach their goal. Their approach reflects their personality, there is no single profile that cannot identify with it.

my work:

As a personal graduation project, I designed and developed IMPROV entirely on my own.I started by defining the core message. After a discussion with a friend on the topic of self improvement I reflected on it and started to think about a way to tell players my conclusion with gameplay. I first thought about genres with an adequate scope, and then I focused mechanics would best support my theme.Once the game and its goals were defined and documented, I started learning Godot as I went along.For the player’s double, I developed tools to record my gameplay. This system was more rigid than an AI system, but also much simpler to implement. I had to wait for the final balancing before recording my gameplay, which was not easy either, as I had to avoid going too fast or too slow.

The Game Design Document for IMPROV is available in Word format at the top of the page. It is a deliverable required by the school, not the living document used during the development of the game. Since I used Notion, I was unable to submit it for this assignment.

what i learned:

This is the project that brought me the most in terms of project management experience.I had to stick to a strict organization system and clear project tracking with Notion in order to complete it within the timeframe I had set for myself. This was not easy, as the game was developed alongside classes and my graduation project, SEPHIRA-03.

TECHNICAL SPECIFICATIONS:

Engine: Godot.Genres: Idle Game.Target: Casual players with hyperactive tendencies who need distractions while doing other tasks, such as working, studying, or watching videos.Constraints: I wanted to use Godot again after some time without using the engine.

unique selling points:

The progression is linked to the dice physics. Advancing in the game makes it increasingly juicy. Random modifiers inspired by roguelites are also added on top to make the experience even more chaotic. They affect physics before influencing stats, reinforcing the core gimmick of the game.Dice Thrower is also designed as a toy. The window remains in overlay above the player’s other activities, like a desk toy, encouraging this sense of proximity and constant interaction.

My work:

The idea came to me while playing Cookie Clicker and realizing that, while the game is fun as it is, it is not really juicy compared to its numerical progression. I thought that adding physics to this kind of game would be great, and while thinking about physics and numbers, dice immediately came to mind. I ran a few tests and discovered that the result was already very fun even without any progression systems.

The project is currently on hold. After a very promising start, I quickly ran into several obstacles that significantly slowed me down and eventually led me to pause development. It has not resumed yet, but it is not abandoned. Here are some details about the project and how I approached it:To begin with, I quickly decided to focus my efforts on game Feel as a priority**, even if that meant postponing balancing work for a while.I set myself the rule that most of my modifiers had to focus on physics in order to stay consistent with the core gimmick. I still believe this was a good decision, however there are not that many meaningful ways to influence physics in a compelling way... As a result, many of my effects ended up being simple variations of one another rather than truly distinct changes.On top of that, there was the issue of balancing. By leaving it aside for too long, I no longer knew where to start, and the idea of balancing such systems became overwhelming. This is the main reason the project was put on hold.Audio implementation was not particularly difficult, but I am very happy with the result, so I want to note that the video at the top of the page includes sound.

What I learned:

I realized too late that it was much harder to balance an Idle Game than I had expected, and the added physics constraints made the task even more complex.

TECHNICAL SPECIFICATIONS:

Engine: Unity, Prototype made in Godot.Genres: FPS, Parkour, Walking Simulator.Target: Players drawn to short experiences with strong themes and contemplative elements, as well as players interested in a high skill expression potential.Constraints: We are developing the game as a two-person team in our free time and are aiming for a 3 years development cycle.

unique selling points:

Everything is designed to encourage the player to never stop moving forward.Narration and contemplation take place in motion. These elements therefore become accessible even to the least patient players, by guaranteeing continuous progression. This is not a compromise, but a thematic and mechanical tool.

Comparison of camera effects disabled and enabled at 00:24

Mobile platforms demonstration

Code free camera effect creation

Interaction demonstration

my work:

Responsible for gameplay design and game feel, I ensured the controls were satisfying by prototyping them in isolation, without any superficial effects.Afterwards, I added camera effects and rebalanced the movements. With additional feedback, we noticed that the character was moving too fast.
Some effects were also added to help players, like a small camera recentering on Wall Run start.Work on Game Feel is still far from finished. The addition of an animated model will further disrupt the current balance. Camera effects are intentionally over-tuned to compensate for the current lack of assets.Worried that my colleague might feel left out regarding creation and tuning of these effects due to the technical knowledge required, I developped a tool allowing for teh creation of these effects without any code, entirely from the inspector using Scriptable Objects.A particular challenge stemming from my custom implementation of movement systems in Unity was supporting moving and rotating platforms.The interaction system for our game had to be generous in order to avoid encouraging the player to stop out of fear of imprecision, remain consistent regardless of distance, and perform well in complex scenes. I therefore designed and implemented a collision free system based on vector comparisons, reducing the reliance on expensive raycasts and reserving them for optional occlusion checks.I also maintain a devblog.

what i learned:

This is our first non-academic project together, and we are thinking big. The importance of a rigorous organization became obvious to us within the first week, as did the importance of documentation.This project is also teaching me to care less about code quality and more about its usefulness. For that, prototyping the game in a temporary engine was an excellent decision.