Manne Cederborg

Gameplay Programming / Systems Design


Title: Coming Home

Company: Futuregames Academy

Platforms: PC

Period: Developed as a student project during 7 weeks

Designers: 4

Engine: Unity 5

Responsibilities: Systems Design, Gameplay Programming (C#), Level Design


Coming Home is a point and click adventure game with an interesting story and challenging puzzles. The game features a day and night cycle where the player can use the sleep function at any point to let time pass. Depending on the time of day, the environment changes and actors perform different tasks.

Gameplay Media



This is a standard point and click adventure game. The player is only allowed to use left and right mouse buttons to interact with the world. Depending on what the player is currently hovering the mouse over, the action changes. I built a robust system in order to communicate this to the player.



Since the game had a very large scope, it was important to add new puzzles, NPCs and objects to the game with writing minumum code. With only 7 weeks, writing specific code for each object in the game would have taken too much time. At the same time, we didn't want the player to solve the same sort of puzzle over and over again.



The solution I used for this was an interface-based inheritance system. This implemented base functionality all objects in the game could make use of and allowed for an easy system to make new NPCs or objects in the world. I implemented five different base interfaces.


  • IAction - If the player can interact with an object.
  • IInspect - Inspect an item, giving the player some additional information about it.
  • IMouseCursor - Used for highlighting objects and changing the mouse cursor graphics.
  • ITalkTo - Activates dialog that can be set in the editor.
  • IUseItem - Specific actions when items are given.


To make it easy to design a new NPC or object in the game, I made three base classes that could be inherited from.


NPC (NPC Base)

Used by all characters in the game that the player is able to talk to. I implemented code for walking around and pathfinding (e.g. the rat NPC).


Interactive-Object (Item Base)

This is an object in the world that the player can interact with and it will perform an action. E.g. When an action is used on the backpack, the player will pick it up and enable the inventory.


Noninteractive-Object (Inspect Base)

This is often used for objects in the background that the player can inspect to give some information (e.g. an unreachable waterfall in the background).




If you inherit from one of the base classes, some basic settings are exposed in the inspector. In this case, after creating a new item, the designer can easily change the animation played when picking up the item. When the player hovers over an item the mouse cursor changes. The designer can change the mouse cursor displayed using a dropdown menu.

Example Code Palm on Beach

What could have been made better ?

  • Animations and sound should be included in the design from the start. I came up with the idea to play different animations depending on what kind of object an action was made on. The script controlling the player character had to be more or less rewritten to support a callback from the object telling the code which animation to play.


  • The player character used Unity's own pathing system. This, however, caused issues late in the project development when I realized the system sometimes moves the player to random locations on level load. I initially thought there was not much I could do about it, since I didn't have access to the code. I had to make very ugly fixes to force the player back to the correct location. Trusting software you don't have the code for can easily destroy a project. It was lucky it didn't give us more issues.


Event System


The game contains a lot of information that needs to be saved. Every time the player walks to the next scene or uses the sleep function, a new level is loaded. I needed to keep track of objects already picked up or events that had occured.



The game keeps track of both object position as well as rotation and whether events has been triggered. Depending on if an event was triggered, some dialog and responses can change.


I used a singleton class to act as a global script. This script is never deleted when changing a level and is the first script to be loaded by the game. It was perfect for the task of storing all information related to the world. Events are all stored in one hashtable where the identifier is an easy to identify string. The three main functions used for keeping track of events are :




All interactable objects in the game are handled as events by the parent class. When the item spawns in the world it will first check and see if the event has been set to done. If so, it means the player has already picked the item up and it will destroy itself on load of a new level.


Save Game

With this system, I can easily create a save/load game feature. To do this, I would serialize the event table and write it to a file on the hard drive.



Store Puzzle

All puzzles rely heavy on the event table, this video shows one of the more advanced puzzles I scripted for the game. The player needs to pickup an old Mayan mirror on the shelf, but trying to do this while the shopkeeper is looking will result in the player getting thrown out of the shop. If you interact with the correct object, the shopkeeper will get nervous and give the player a moment to pick up the item without being noticed.


Will add the event to the hashtable with supplied eventID. If it already exists, it will return false.



Will mark an eventID in the table "done".



Will find the event and return the status.

NPC Paths

To give life to the characters in the game, I created a simple waypoint system. It's easy for the designers to setup walking paths and select different walking modes, such as random, loop and patrol. This is all done using editor tools that I scripted.


This system could also be extended for special scripts like the shopkeeper in the previous video.




Example Code Backpack on Beach

What could be made better ?

  • The system used was very simple and easy to use, but it was also easy for the designer/scripter to reuse the same eventID and cause unknown issues. A check or naming convention would ensure the same name is not used twice.


  • Splitting the event table into more tables, such as one for events and another for objects in the world. This can speed up the time to fetch data from the tables.



Manne Cederborg