LIVE ADVENTURE is a second adventure game where you follow the journey of a brother and sister in search of their missing explorer parents. To keep track of their expedition, the brother constantly films his sister with a camera (which is also the camera of the game).


In the manner of Brothers: A Tale of Two Sons, the player has constant control of the 2 characters: one in FPS view (the brother) and the other in TPS view (the sister). They will have to use their abilities in synergy to overcome wild alien environments and mysterious forgotten ruins, to have a chance to find their parents.


This project is my final project and therefore the most ambitious of my curriculum. The very concept of the 2nd person is as exciting as it is difficult to conceive whether it is in Game Design or Level Design. You feel like you're back in the 80's, at the dawn of the 3D air and have to experiment everything to find the perfect recipe, which makes the project even more exciting! 


Playing time :  25-35 minutes


Pré-production Document :

My missions :

  • Designed, rationalized, prototyped and built several 3D level parts and workshops, simple enough because of our controller but deep enough not to let the core players down.
  • Designed game mechanics and 3Cs for experimental game concepts.
  • Organisation of numerous playtests to highlight problems in the levels and provide a coherent response to them.
  • Genre : Adventure
  • Support : PC (Windows)
  • Software : Unreal Engine 4
  • Period :  mars 2020 - present (On going)
  • Team : 11


Credits : 

  •  Samuel Basset (Game & Level Designer) 
  • Killian Gales (Game Designer)
  • Vincent Trinel  (Game & Level Designer)
  • Maxence du Mesnil du Buisson 
  • Laurène Savary (Concept Artist)
  • Othilie Berger (Animator & Environmental Artist)
  • André Rizkallah (Environmental Artist)
  • Thomas Dupriez (VFX Artist)
  • Alice Fernandez (Character & Environmental Artist)
  • Sébastien Butor (Programmer) 
  • François Noël (Programmer) 



As you can guess, the very concept so inevitably on a very atypical and experimental controller. This makes it difficult for the player to master the game quickly (he has to relearn everything) and we designers to make the experience as accessible as possible without distorting the initial concept and the depth it can bring. It's as if we had to teach a player who can play a 2D game to suddenly play a 3D game where the camera is controllable.






In order to dilute the experience and the narration throughout the game and thus avoid any brain-load to the player (so fast to arrive with our atypical controller, even with only the dialogues), we designed a timeline of the whole game. This allowed us to set the scope of the game, both in production and in game duration, and to know where it will be possible to cut the game experience.



Then, to allow the best possible design of our levels, we went through Jira but especially Confluence to write the Levels Metrics document but also the Level design document of all the beats and sub-beats of the game.  We set the objectives, intentions, and narration and then the nature of the gameplay to challenge the player.



Once this type of document is done, a pacing graph of the document on Excel is drawn to highlight several parameters (Gameplay type, Intensity, duration, Contrast) by means of curves. This gives a better vision of the rhythm for each beat and allows to communicate them to the other team members.



To meet our concept, we force us to opt for a production pipeline approach on an iterative process supported by a large regular (and almost daily) playtesting process. To do this we divided each beat into a separate sub-level so that we could iterate on a workshop or beat without getting into source control conflicts with another level designer. This makes the level design pipeline very malleable.

I usually start designing a workshop in an empty level with only basic and abstract blocks to experiment as much as possible without being influenced by the topography of the macro level.


Once the workshop is finished, it is then tested both by the team and by a blank playtester of any experience on a later version of the game, in order to reveal possible design problems and to understand how to deal with this atypical controller.