Going Home is a turn-based tactical game about three adventurous mice in their quest of reaching a safe haven. Our restrictions was pretty vague, only requirement was to capture the feeling of trust.
Role: Lead Programmer, IT
Span: 7 Weeks in Spring 2020
Team Size: 10 (2 Programmers)
Engine: Unity HDRP
Interaction / Context Menu System
Quite early in the design of the game we had decided that the primary way of interacting with the game would be clicking objects and displaying a contextual menu with the possible actions to take.
My system is divided into three parts:
ContextMenu. The MonoBehaviour that displays the buttons in the world.
ContexMenuTask. Struct representing a task that can be showed by the ContextMenu.
InteractableBase. A base interactable that contains virtual methods for ButtonClicked.
Here is an example of how it works within the game
I designed the system with my team in mind. The designers all knew C# well.
For them to create a new Interactable all they had to do was inherit from the InteractableBase and override a virtual ButtonXClicked for each action they wanted for that object.
The nitty-gritty stuff is hidden in the implementation of the base and it “just works”.
The context menu class is intentionally very simple. Its necessary public methods are OpenMenu and CloseMenu. All it does is bind the menu tasks actions to the buttons. It is shared for all interactable bases which leaves more responsibility for the interactable.
This way when you create a new interactable you do not have to think anything about the menu, the button sprites and actions are all owned by the interactable.
I created the turn-based system for the game. It was a new challenge for me as I have never worked on something similar before. As with the other systems I created for this project, I made it all from scratch without looking at any references at all.
This has its cons but I learn better breaking down the problems myself instead of adapting a solution from the internet.
I created one class TurnManager that keeps track of all the characters in the game.
It accesses each character through an interface
to make me think twice about what I really need to access.
Any implementation of an ITurnPawn needs to define a BeginTurn(), invoke OnFinished when its done and for gameplay reasons define a ForceEndTurn()
I believe this is simple and understandable from an outside perspective. All the heavy lifting is done by the TurnManager.
Movement / Pathfinding
After some struggling within the team about how the pathfinding would be implemented, I proposed a solution with a distance-based limit. With this system we could use Unity’s Nav-Mesh which solved many headaches.
I created a prototype for the new movement in just a day that the designers could start using. This let them get into detail with the level design while I could refine the system in parallel.
With help from a 2D artist I could explain the system visually to everyone in the group which kept everyone on the same page.
The final version shows the cost of a move and the exact route the player will walk. Very close to the original concept.
I had to make a lot of helper methods to make the NavMeshAgent do what we wanted.
They aren't very pretty or optimized but they do what they need to. There was never any performance issues with the pathing or the game in general so I left them like that.
As the project took place during the corona pandemic we had to adapt our way of working. We collaborated using Miro, which is like a big whiteboard over the internet.
This worked very well for us and I believe our good communication played a big role in the end product.
On the last week of the project we got feedback from both industry people as well as students.
Thanks to our teamwork and everyone giving their best, the whole game received amazing feedback.
It was a big relief for me that we did not only make a beautiful and pretty game. Everything was on par with the rest!
The Miro board gave the information we needed at a glance. I always knew what to work on.