Rémy MASSELOT
Technical Game Designer
Projects
Games For KIPSTA
June - July 2024
Internship
As Game Designer
Developement of 3 games from idea to prototype
Prototyping on FIGMA
Playtesting with the target audience
Etienne Redouin - Design Director at KIPSTA
"The internship objectives have been achieved, and even exceeded.
Efficient and relevant teamwork. Consistent listening skills and initiative demonstrated each week (a pleasure to manage). Knowledge effectively utilized and shared.
Well done!"
Pakke-Is
June 2023
School Project
As Game / Narrative Designer
3C Design + Balancing
Gameplay Mechanics Design
Enemy Design + Combat System
Dialog Writing
Cutscenes
HDR
HDR
3C Design + Balancing
Gameplay Mechanics Design
Enemy Design + Combat System
Level Design
Narrative Design
RISTAR Reboot
Features
Pitch
Ristar is a 2D platformer released in 1995 on the Mega Drive, developed by Sonic Team and published by Sega.It received positive reviews for its colorful graphics, smooth animations, and innovative gameplay.
However, due to the launch of the 5th console generation the same year, Ristar had limited visibility. In addition, the lack of dynamism and fluidity of the controls have been widely criticised.
Project design goals
Make a reboot of a retro platformer with 30 years of advancements
3C Design for a platformer
Prototyping on Unity using C#
Context
To highlight my skills in 3C Design, I needed a platformer with lightweight gameplay focused on movement and a single core mechanic. Make a reboot of a retro game is the best way to demonstrate my understanding of the evolution of the industry and gamers. Through this project, I showcase 30 years of industry advancements such as hidden mechanics or the new needs of players.
Process
I began to rework the State Machine then polish each state. For each step, I proceed in 3 sub-steps.
1. Analyse Ristar 1995
2. Theorical diagrams
3. Integration in Unity

State Machine
I began my analysis with the state machine. I focused on 3 levels of states: in the air, on the ground, and on the wall. For clarity in the diagrams, I ignored the damage and death states, as they are linked to each of the other states.Here is a simplified state machine of Ristar with these three levels of states. One aspect criticized in the game was its lack of dynamism, part of this problem comes from the relationships between states.
Ristar 1995

Problem 1: To reach the wall level, the player has to grab a ladder. This constraint creates a disconnection between movement states. Grabbing a ladder can be avoided by using collision detection. In my reboot, the player can still grab a ladder to reach the wall level, but I improve movement fluidity by adding a connection that doesn’t require player input.Problem 2: While moving along a ladder, the player cannot jump or grab. This breaks the movement flow by forcing the player to stop before performing another action. To restore this flow, I allow the player to jump and grab while moving along a ladder.Levels are designed around climbing and combat. Their construction encourages the player to switch between these state levels, which is why developing these connections is essential to addressing the lack of dynamism.
Ristar 2025

The sequence of movement actions is more dynamic and faster without changing the movement speed value.
1995
Grab a ladder to reach it
Stopping to jump off a ladder
2025
Reaching a ladder by collision and Grab
Jump off a ladder even while moving
Grab
I decided to give priority to polishing the main mechanic, the Grab. Good sensations are made with good animations, so I wanted to have new graphics and new animations to improve the sensations you get from it. I redid an illustration I'd found on the internet in Illustrator and made its skeleton in Spine to work with dynamic animations.
ILLUSTRATOR

SPINE
UNITY
This first test allowed me to check whether redoing all the animations would take too much time or not, and yes it did. The optimal choice was to work with sprite sheets found on the internet and to use the unity line renderer component to expand the arms.



Ristar 1995
In the original game, the player is limited to 8 directions to grab because of the Mega Drive controller. When on the ground, the character stops and the player can grab for longer by holding down the button. He can't do it in the air.
On a vertical ladder, an animation is played when the player presses the grab button. This action is not used for gameplay purposes, but only to enhance the feel of the game. On a horizontal ladder, nothing happens.
To compensate for the lack of precision in aiming due to the 8-direction limit, the character's hands are aligned with the enemy's position when the hands are extended close to the enemy.
Standing on the ground, when the player is aiming downwards, the arms are extended towards the front of the character.
Ristar 2025
With the new joysticks, the player can grab in any direction. I've chosen to keep the hidden mechanic that aligns the position of the hands with that of the enemies to avoid being frustrating, but rather to be permissive with players' little mistakes.
The grab mechanic works but their is something that could be improve. When the player grab in the air he cannot maintain arms extended. This constraint create unecessary difficulty to grab elements positioned high up.
To make this situation easier, I've lengthened the time taken to grab items placed high up by allowing the player to keep his arms straight even when in the air.In my version, the aiming orientation and movement orientation inputs are independent of each other. If the player aims at the back of the character, the character turns to the side of the target direction.
The player aim with [Right Joystick] and extend the arms with [West Button] or [Right Trigger].
I give the player 2 inputs to complete the mechanic. Few inputs are needed in this game, so I can give the player several inputs for the same mechanic. This increases the feeling of freedom in the player's controls and adapts to different types of player.

Camera
The camera moves slightly in the direction the player is aiming. When the player grabs, the camera moves more in that direction and then returns to its initial position when the player changes state.This behaviour further immerses the player by focusing on the action the player is performing.
Technique
I can tell the difference in code between the spine and non-spine versions. My code adapts easily in case I want to go back to the spine version later.
To extend the arms, a Ristar sprite without arms is displayed with an animation that changes according to the orientation in which the player has aimed. Then, for each arm, a Game Object containing a Line Renderer is activated. In the Update, I update the position values of the 2 points of each line renderer with the positions of the shoulders for the index points [0] and the positions of the hands for the index points [1].
The final position of the hands is obtained by adding to the position vector of the shoulders, a direction vector which is itself the product of the value of the normalised aiming input and multiplied by a variable (float) of the distance to be reached by the hands.
The hands move to the final position using a DoLocalMove to effectively control the trajectory of the hands and the length of time they travel along that trajectory.

A game object used to detect the elements follows the hands at mid-distance. From this game object, several raycasts are sent in the direction of the hand trajectory. I can change the parameters for distance, number of raycasts and angle of range.As soon as a raycast collides with an interactive element, a sequence of actions is launched depending on the element detected.
WALL
As in the original game, the character is propelled towards the caught wall and then plays a rebound animation then, goes to State Fall.
STAR HANDLE
The character goes into State Hang. More details on METEOR STRIKE.
ENEMY
The character goes into State Hang. More details on RELATION WITH ENEMIES.
LADDER
As in the original game, the character is propelled towards the caught ladder and then switches to State Climb.
If nothing is detected, the player can hold down the button to keep the arms extended for a limited time and then the hands return to their original position.
In my version, the player can also release the button earlier to cancel the grab, and the hands will immediately reposition to their original position without waiting to reach their final position.
Jump
Ristar 1995

In the original game, the player has limited controls on the jump. He only can choose the direction of the jump and change this direction in the air with the input movements. If the player does'nt use the input movements, the jump will be vertical.
The distance of the jump is just enought to over obstacles like this one. The player isn't sure if his jump will succeed before the end of the action. It gives an unnecessary amount of randomness to a mechanic that's supposed to rely on the player's precision and skills.
Ristar 2025
With my reboot, additionnaly to the air control, the player can control the distance of the jump with the input movements and by staying more time at the apex holding the input jump. He also can cancel the jump by releasing the input jump earlier. And to enhance the feel of air control, I used dynamic gravity, the player can fall faster by going downward with the input movements.

Staying more time to the apex answers the need of increase the time to grab an element positioned high up. This integration is complementary with the action to maintain the grab in the air. To don't affect the maximum distance of the jump, I increased the speed of the time to go to the apex.To remove randomness in this mechanic, I increased the maximum distance of the jump to give to the player a real sensation of succeed when he over an obstacle.
Thanks to these changes, the player could easily anticipate the end's position of the jump.
Additionnaly, I improved the game feel by being more permissive with the player adding corner correction. I also integrated coyote time and jump buffering to facilitate jumps between several platforms.
The player jump with [A] or [Left Trigger], he controls the movement with [Left Joystick].
With the same intentions as the Grab, I give the player 2 inputs to complete the mechanic.

Camera
The camera moves slightly upwards when the character reaches the apex of the jump. The camera returns to its initial position when the character enters State Fall.When the player increases the speed of the fall by heading downwards. The camera moves to create more space below the character. This allows the player to see the obstacles below him and anticipate the next actions to be taken, as well as enhancing immersion by following the player's movements.
Meteor Strike
Ristar 1995
The time spent loading the meteor strike is longer than the time spent playing with this mechanic. The reward is not worth the effort.To load the meteor strike, the player must first grab a star handle and then hold down the move input in the direction the character is facing while holding down the grab input.The player must wait for the character to turn around the star handle quickly enough before releasing the grab input and propelling himself in the direction the character is facing at the time of release.
When the character is ready to enter state meteor strike, he turns too quickly to anticipate the direction in which he will begin his flight.
If the player releases too soon, the character is propelled with less power and goes into state Jump or Fall depending on whether he is facing up or down.As well as having a very short duration, the flight is difficult to control because of the rapid movement speed. The player has no time to enjoy exploring to find the hidden places in the level.
Ristar 2025
To make it more satisfying to play, I've rethought the proportions of time between the effort required to obtain the meteor strike and the time spent playing in meteor strike state.I've shortened the loading time slightly and increased the sign that informs the player that loading is complete. This way the player no longer has any doubts about loading and doesn't feel obliged to do a few extra rounds of handle star to make sure he has loaded the skill.The controls for using the handle star are the same as in the original version. But in my reboot, when the grab input is released to switch to meteor strike, time is slowed down and the character performs a full turn before switching to meteor strike and being propelled in the direction the input was released.
During this turn, the player can decide to switch to meteor strike earlier by pressing the jump input. As well as boosting the power generated by the handle star, slow motion allows the player to choose precisely in which direction he wants to propel himself.In order to make the controls more manoeuvrable, I've reduced the speed of movement in flight. I've also lengthened the time spent in flight to allow the player to take full advantage of the sensations provided by this mechanic.
The player grabs the star handle with [X] or [Right Trigger].
He turns around the star handle with [Left Joystick].
He releases the star handle with [X] or [Right Trigger].
He enters in Meteor Strike State with [A] or [Left Trigger].
He controls the flight with [Left Joystick].
This mechanic requires more inputs than the others but these are controls that the player already knows.

Camera
I use the camera as signs and feebacks to enhance immersion by intensifying the player's actions.When the player grabs the star handle, the camera shakes slightly and centres the star handle in the middle of the screen. The more the meteor strike loads, the more the camera zooms in on the star handle. When the meteor strike is fully charged, the camera shakes moderately and zooms in slightly but more sharply on the star handle.When the player releases the grab input while charged. The shot zooms in on the character and as he releases the star handle, the camera shakes sharply and the shot switches to full view.
In flight, the camera shakes very slightly and positions itself to leave space in front of where the player is heading.When the player releases the star handle without entering the meteor strike state, the camera returns to its jump state behaviour.
Walk
Ristar 1995
The character cannot run. This choice is in line with the main intention, which is to place greater emphasis on reflection and puzzles with slower movements.
Acceleration speed is instantaneous.
Ristar 2025
I wanted to keep the intentions of the original game. I've kept the mechanics as they are, with the same movement speed, but I've taken advantage of the joystick in the new generation controllers to give the player precise control over their speed.
The movement speed varies according to the value of the movement input.
The player moves with [Left Joystick].

Camera
The space on the screen is larger on the side towards which the character is facing. As the player moves, the camera moves to enlarge this space.
Climb
Ristar 1995
The movement speed on the ladders is the same as the speed of movement when running. Acceleration is instantaneous.
Ristar 2025
As with walking, I'm taking advantage of the new controllers to give the player more control over acceleration. Movement speed varies according to the value of the movement input.
As mentioned in the state machine section, the player can enter state climb by grabbing or colliding with a ladder. To get out, the player can either reach the outside of the ladder or jump off it. In my reboot, the player can jump off the ladder both when stationary and in motion. The trajectory of the jump depends on the value of the movement input and the type of ladder.On a vertical ladder, if the player directs the movement input downwards, the character will be propelled downwards and enter the Fall state. If the player directs the movement input upwards or if the input value is null, the character will be propelled upwards and enter the Jump state.On a horizontal ladder, the character will enter the Fall state. In this state, the player will be able to control movement in the air as explained in the Jump state. This design choice corrects the fact that in the original game, when the player propels himself from a horizontal ladder, the propulsion curve is difficult to anticipate, which creates randomness in the character's controls.
The player moves with [Left Joystick].
The player jump off a ladder with [Left Trigger] or [A].

La nouvelle entrée vers l'état de climb en collision permet la création de nouveaux ateliers. On pourrait imaginer des échelles verticales plus rapprochés.
Camera
The camera moves in such a way as to leave more space on the screen towards the direction in which the player is moving. When the player stops, the camera refocuses on the player, leaving a more open space towards the direction in which the player was moving before stopping.
Relations with enemies
Ristar 1995
After grabbing an enemy, the character's hands follow the enemy's position. If the character is in the air, they fall until they hit the ground. If there is no ground, the character hangs from the enemy. Depending on the type of enemy, he either falls with it while hanging or stays in place.To hit the enemy, the player must release the grab input. The character is propelled towards the enemy and hits him. It then follows a propulsion curve that places it opposite where the enemy was located. If the enemy dies, it transforms into a ball, is propelled in the opposite direction to the character's trajectory and bounces against the edges of the screen, then disappears as it exits towards the bottom of the screen.If the player collides with an enemy without grabbing it, the enemy inflicts damage. After taking damage, the player is invisible for a short time, with a visual sign informing the player of the duration of this effect.Certain elements, such as spikes, inflict damage on the character as soon as they make contact, even when grabbed.
Ristar 2025
In my reboot, I changed the character's bounce when he hits an enemy. With this new curve, the character is propelled upwards and the player can control the curve to move left or right. This change makes the mechanics more dynamic, accompanying the player as he moves rather than making him return to a fixed position. Thanks to this design choice, the rhythm of the actions is maintained and the player can continue progressing through the level without stopping.This new approach to mechanics opens up new possibilities for stages. We could imagine a situation where several flying enemies are lined up, and the player could move from enemy to enemy easily by controlling the propulsion curve.
Camera
When the player takes damage, the camera shakes slightly.The camera shakes slightly when the player grabs an enemy. To reinforce the impact, I've added a camera shake at the moment of the strike. To accompany the movement of the propulsion curve, the camera moves to create more space at the top of the character and then returns to its original position after the character has reached the apex of the curve.
Iron Man Controller
Games for KIPSTA
Untitled Forklift Game
Features
Pitch
Untitled Forklift Game is a 3D forklift-style arcade controller in a puzzle game.Drive a forklift and wreak havoc on your worksite by honking and moving crates with your forks.Say NO to work by tackling your own tasks!
Project design goals
Prototyping on Unity using C#
3C Design of a forklift
Context
I started this project during the Global Game Jam 24 with the topic "Make me laugh". After these 2 days, I had a functional forklift controller but no good gameplay situations to drive it. I decided to continue this project by adding levels and polish. This game is inspired by forklift tournaments and Untitled Goose Game.
Overview
To create my vehicle quickly, I started with a free car controller from the Unity Asset Store.
I modified it to match the desired design by merging it with a 3D model of a forklift found online.The game is designed to create absurd situations.
I didn't have time to create an interaction system between multiple characters as we can find in Untitled Goose Game, so I focused entirely on the 3Cs.The player can raise and lower the forks, wich are used to lift crates. He has the ability to honk in order to make fallen objects bounce. And he have the choice between many camera angles like in AAA racing games.
Thus, even alone in an environment normally populated by superiors and colleagues, the player enjoys causing chaos on the worksite while accomplishing his objectives.
Driving
Mapping Control
The player can move with [WASD or ZQSD].

To move forward, the player must press and hold [W/Z]. The forklift accelerates and maintains its maximum speed as long as the key is held down.
To move backward, the same logic applies with the [S] key.To turn right, the player must press and hold [D]. The rear wheels gradually turn to the left.
To turn left, the player must press and hold [A/Q]. The rear wheels gradually turn to the right.
Steering wheels
The steering wheels of a forklift are located at the back. In narrow spaces and at low speeds, this placement improves the vehicle's maneuverability by reducing the turning radius.
This unconventional driving setup, combined with the control of the forks, is the reason I chose to undertake this project.While the corresponding key is held, the steering wheels gradually rotate to a maximum angle of 40°. This adjustment allows for easy direction changes at low speeds without losing control at maximum speed.To enhance the driving experience, a smoke VFX is emitted from the steering wheels as the forklift turns and changes direction. This effect adds a dynamic and engaging element to the driving experience.
Speed

The forklift reaches its maximum speed in under one second.The maximum speed is carefully balanced to allow seamless progression through stages without wasting time on movement, while still being manageable in narrow spaces, such as between shelves.

When the player releases the acceleration key, the forklift decelerates and quickly comes to a stop.
This rapid deceleration enhances maneuverability during tasks such as stacking crates.
Improvements
The driving lacks dynamism and responsiveness. Adjusting the balance for faster acceleration and deceleration, along with adding slight vehicle shakes as visual feedback during starts and stops, could enhance the arcade-style driving experience.
FORKS
Mapping control
The player can raise and lower the forks with respectively [UP and DOWN arrow].

To raise the forks, the player must press and hold [UP arrow]. The forks will continuously rise until they reach the highest point. When the player releases the key, the forks stop moving.To lower the forks, the same logic applies using [DOWN arrow].
Scale
To improve maneuverability during crate transport, I lengthened the forks. The final length allows for transporting a crate while leaving some margin for error.Additionally, I increased the maximum height the forks can reach to enhance the arcade-style feel of the controls.

Actions
I see the forks as arms without elbows or hands.From this perspective, this mechanic presents three main actions to the player:
- Lifting an object
- Pushing an object
- Tipping over an objectThis mechanic challenges the player’s dexterity and their ability to manipulate objects in a 3D space according to the game's physics.
Lifting
Pushing
Tipping
The object's air friction is designed to give the player time to reposition the forks while they are lowering.When the player lowers the forks, the crate on them will fall slower than the forks' descent. This gives the player time to adjust the forks and prevent the crate from losing balance.
Improvement
This mechanic could benefit from improved clarity by displaying the elevation level of the forks.This information could be represented diegetically using lights on the forklift to indicate whether the forks are at their lowest or highest position.Another, more precise solution could be a non-diegetic approach, such as a vertical slider with a cursor that rises or lowers proportionally to the movement of the forks.
HONK
Mapping control
The player can honk with [SPACE].

To honk, the player must press [SPACE]. The interaction is similar to a car horn in real life, but the sound has a limited duration. The end of the honk is independent of the player's control.To enhance its impact, I assigned this interaction to the largest key on the keyboard. This key can be pressed with the thumb, which is not used for any other actions.
Why add a honk ?
There are two main reasons:It can be difficult for some players to properly upright an object tipping over using the forks. The honk provides an alternative way to rotate an object.A secondary goal of the game is to wreak havoc on the worksite. The honk is an effective way to knock boxes off the shelves.
This mechanic is represented by a honk to tie it to driving a forklift. Most people are startled when they hear a honk unexpectedly. I used this idea to represent the mechanic: objects near the forklift "jump" when they "hear" the honk.When "jumping", they are propelled slightly upward and rotate in the direction the forklift is facing. The intensity of the rotation depends on the forklift's YAW orientation relative to the object's orientation.Each object reacts differently to this effect depending on its mass and angular drag (physical properties adjustable in the Rigidbody). This effect extends over a spherical area centered on the forklift.As feedback, a smoke VFX spreads across the ground around the forklift to indicate to the player that the honk has been used. The honk is locked until the smoke dissipates, lasting about 0.4 seconds. This prevents potential bugs if the player spams the key. The scale of the objects affected by the effect performs a slight bump to distinguish them from objects that were not impacted.
Improvement
Most playtesters who fail to position the desired object correctly after several honks become frustrated.To avoid this unintended frustration, one solution is to make the effect automatically orient the mission-critical objects (colored crates) correctly while maintaining the visual presentation (propulsion + smooth rotation). For other types of objects (cardboard boxes), the propulsion and rotation effect could remain random.
CAMERAS
Mapping control
The player can change the camera with [LEFT and RIGHT arrow].

To get the previous camera, the player must press [LEFT arrow].
To get the next camera, the player must press [RIGHT arrow].These interactions need to be quick and accessible. Assigned to these keys, this functionality allows the player to use their index finger and ring finger, which are otherwise unused.
Why several cameras ?
To simplify control, the player does not manage the camera.The camera must continuously allow the player to see the forks, which are the main element of the game. It should be oriented to keep the forks visible while leaving enough space on the screen for the player to anticipate obstacles by seeing what lies ahead of the vehicle.As the player moves between shelves, the view may often be obstructed by obstacles if the camera remains static. To address this issue, I decided to position the camera at different viewpoints. If the player's view is obstructed by an obstacle, he can switch to another camera angle that provides a clear view of the action.
Why more cameras ?
The different viewpoints also allow players to enjoy driving the vehicle from various angles, similar to AAA racing games. I found the contrast amusing between the camera angles, which showcase the vehicle in a dramatic way, and the vehicle itself, which is anything but impressive. Typically, people want to admire beautiful vehicles from different angles. From this perspective, the idea aligns well with the jam's theme.These different viewpoints are not just for humor; they are also functional. They provide better control of the vehicle and its forks depending on the situation.
Additionally, they serve as a reward when the player completes a mission.
Improvement
To strengthen the connection between the camera and the vehicle, one solution is to adjust the camera's tilt upward or downward based on the elevation of the forks. This improves the readability of the action, especially in first-person view, and also indicates when the forks have reached their movement limit, as the camera's orientation is constrained by it.To make the driving more dynamic, a falloff in the camera's movement speed could be applied during the vehicle's start and stop phases.For smoother driving, the camera could follow the vehicle's trajectory by slightly rotating when the vehicle changes direction. Widening the field of view would help anticipate obstacles and make the driving experience more enjoyable.
Feel free to play it on Itch.io!
Pakke-Is
About
My name is Rémy Masselot, and I am a 5th-year student pursuing a Master's Degree in Digital Creation with a specialization in Video Games at Piktura. More specifically, I am specializing in Technical Game Design, with the goal of becoming a 3C Game Designer.Throughout my studies, I have gained experience in various fields such as Programming, Art, Game Design, and Project Management. This multidisciplinary background has given me a better understanding of my team members' needs, which has greatly improved both my communication skills and my Game Design approach. I am adept at adapting my design process to fit the production's resources and the creative vision of the game.For me, teamwork is the most important factor in creating a successful product. This is why I pay particular attention to my documentation to effectively communicate and bring my ideas to life. I am also familiar with SCRUM, a production methodology based on sprints and milestones, which I use to organize my work.In my design process, I leverage a variety of tools such as XP Pillars, Player Personas, Core Loops, and Fast Prototyping. When I encounter challenges, I use techniques like mind mapping or 10-minute exercises focused on specific situations to find the best solutions. Thanks to my patience and flexibility, I am not afraid to iterate or start over multiple times to achieve the desired result.
