Heading Home is an 3rd person adventure game where you play as the head of otherwise broken robot, crashed on a foreign planet.

Left all alone, you have to explore the planet and use gadgets to find your way home again.

                Engine: Unreal Engine 4
Production Time: 5 Weeks
                   Team: 3 Designers
                              6 Artists

Heading Home is an 3rd person adventure game where you play as the head of otherwise broken robot, crashed on a foreign planet.
Left all alone, you have to explore the planet and use gadgets to find your way home again.

                Engine: Unreal Engine 4
Production Time: 5 Weeks
                   Team: 3 Designers
                              6 Artists


  • The player should utilize the environment and their ingenuity to progress forward.
  •  Let the environment be the conduit for the narrative and give the player a sense of adventure.


Project manager & scripter. As the project manager, my time was split up between management and development, which meant a lot of responsibility. To fit into that role, early on I started prototyping the game’s core mechanics and later took on smaller features and functioned as the link between artists and designers, solving any technical issues we faced and assisted the team in any way I could.


Early on in the development we decided that the player should interact with the environment as means for progressing forward. We also decided that the character would be solely a head, thus jumping and shooting projectiles would be its main capabilities. So, the question wasn’t so much of “how”, but “what” would the player shoot? To figure out what would be most suitable, I made several prototypes.


Since mechanics and environment were supposed to go hand in hand, we first considered that the player themselves would be able to modify it.

That lead me to start working on a prototype that would manipulate an area, in this case make everything bouncy.

The idea was to give the player the ability to make themselves and other objects bounce around, in essence moving them around and giving the player a potentially very entertaining mechanic to explore and traverse with.

One of the earliest prototypes of the bounce pad, affecting a area and physics objects.

The final version of the bounce pad.

The prototype showed promise in the way that the player bounced off the surface according to the surfaces normal vector. This aspect of the prototype was kept since it fulfilled the objective of utilizing the environment to traverse. Eventually the area of effect was removed aswell as moving physics objects since it wasn’t a reliable way to solve any potential puzzles.

The final result of this mechanic became what we called “bounce pads”. A gadget that stuck to walls, projecting a force field that would bounce the player in the opposite direction.


The magnet started out as our new attempt of manipulating the environment. It consisted of two parts, one being a tether, the other being the magnet itself. The tether was the anchor point to where the magnet would pull itself and any physics object it was stuck to.

The idea of being able to pull something using the environment was a big draw to us, but the two step process of first tether and then placing the magnet became confusing and didn’t fit into the game.

Early prototype of tether and magnet used to open a blockade.

The final version of the magnetic vacuum.

We decided to move away from trying to create puzzle solving segments and instead focus on the journey of the character, setting the focus back on getting you over the obstacles.

So instead we came up with the magnetic vacuum. A complete opposite of the bounce paddle, instead of launching you away, this vacuum drew you into it, making it possible for the player to reach new hights and cross wider chasms. We also presented the player with opportunities to use both tools together, making them feel resourceful and clever.


The environment played a large role in the making of this game. It was core to the narrative we wanted the player to experience and the games core mechanics were tied to it. This proved a challenge since this meant that scene composition was directly tied to the puzzle platformer aspects of the game.

However we were able to use that connection and turn it into our favour. Level design principles involves giving the player direction through subtle means, adding lights and creating lines that guides their view. To build on those principles we use the environments angles and shapes to let the player know what to do and where to go.

The platform's angle leads the player to look for a way upwards and a boost with the bounce pad.

Both of the players tools, the bounce pad and magnet stick to surfaces and project from its normal, so by just tilting the surface we guide the players view and the tool they should use to get there.

The pictures taken are from the final segment at the end of the game that I made, highlighting these tricks taken into practice.


Throughout the journey the player encounters various different environments and challenges. To enchance those segments we created tracks to fit, some were more upbeat, others were slower and more ominious.

However for the more challenging parts it was uncertain how long the player would stay in each of them, so to counter the music from going stale, we chopped it into several pieces and made them dynamic.

To fit these cases, I made a music manager that was responsible of playing the music and keeping track of the what was previously played to prevent it from repeating the same one over and over again.



To give the little robot some character we added faces that it could swap between, expressing different emotions to the actions they were performing and something little extra for the player to discover for themselves.


I was responsible for adding all of the audio into the game. To my help I had one of our artists who created the music and sound effects that I could implement. One


As the project manager it was my responsibility to look after the group and make sure we met weekly goals. To accomplish that I set up a agile development workflow that included:

  • Defining what the team needed to complete for the weekly deadlines, based on the progress currently made.
  • Organizing and moderating daily meetings where every team member reported their work from yesterday and their planned work for the day.
  • Solving and avoiding any bottlenecks and motivate team member collaboration to help get important tasks done.

I also was in charge of pitching the game at the end of every week to teachers and industry guests. To prepare I took part of student arranged pitching sessions where we all gave feedback to each other before finally pitching infront of a jury consisting of industry veterans from EA DICE and Starbreeze.