Captain Hookfoot
Captain Hookfoot is a point and click adventure game created for my Game Studio 1 class in the spring of 2021. It was made in six weeks with a team of seven people. It is inspired by games such as Pajama Sam and the Monkey Island series, as well as films like the Goonies. It is a verticle slice of a potentially bigger game, with each puzle showing a different potential mechanic, such as interactable screens, dialogue, and item combining. It is a very narrative heavy game, with a colorful cast of characters to meet and interact with.
Features I built:
System architecture
Object interactions and controls
Database integration with Sqlite Browser
Designer friendly implementation tools
Narrative systems and textboxes
UI implementation
Architecture Overview
Early on in development I created an outline the basic class structure that the game, and importantly the interactable objects would take. Firstly there is the Player, which persists through scenes, and holds a log the UID of any Clickable objects that have been interacted with. It also is the parent of the persistent UI, and thus is the main interface to UI functions, like adding inventory items. Other classes can access those functions through a Player singleton, which also serves as letting us add other player objects to test in different scenes without having them interact with each other.
A diagram I made early on, showing how classes would be divided.
Clickable Nodes and Databaser
The base class for each of the objects the player interacts with is the Clickable node. It inherits functions from the IPointer handlers to allow for clicking, as well as our Databaser. The Databaser class was made to hold all of the code involved with interacting with .db files, which are used to store all of the dialogue (123 dialogue lines and 61 interaction based lines). The Clickable node also has virtual functions for both right and left clicking, called LookAt and Interact, with children of Clickable overwrite.
Two dialogue sequences, as seen in the database file.
Interactable Nodes and the EventManager
Interactable Nodes were hard to develop. The goal of them is to have a number of different possible states, and be able to have different goals to advance said states, at which point the state change affects the environment. To ease the puzzle implementation process, I utilized Unity's PropertyDrawer function to create a custom Inspector interface and allow for easy setting of states and state changes. The state changes were handled by invoking a Unity Event, like a button would. To simplify Interactable's code, the functions invoked lived in various StateObserver classes in the EventManager.
The Interactable Node component as seen on the Inspector.
Pickup and InventorySlot Nodes
Pickup nodes were pretty easy to develop, as most of the inventory adding is handled within the Player and the UI scripts. Pickup Nodes primarily facilitate the beginning of the process. When an item is picked up, an InventorySlot is created, which handles setting and using items. Their Interact functions has two parts, setting the active item if none is active, and combining items if one is already active. In the game, this is seen in the bucket mixing puzzle, as the player pours multiple liquids into a bucket to create something acidic enough to melt a cage.
A puzzle that requires you to combine clues.
Location and Display Nodes
These are fairly self explanatory and simple, but significantly different enough in function to warrant their own subclasses. Location nodes simply call transitional functions to move over to the inputted scene. Display Nodes are similar, but connect the player to a different part of the same scene, by changing the active camera. These are used less for scene transitions and more for giving the player more ways to interact or examine objects. In our vertical slice, we use it to examine the combination lock on a desk, allowing the player to zoom in and interact with the lock mechanisms.
A puzzle utilizing the Display Node to show a combination lock.