High Level Code Overview

While all of the code for this project is viewable in this repository and most of it is commented or self-explanatory, I figure it may be of use to include a high level overview of the code design and layout for this project. It can be hard to get a big picture when all you have in front of you is a bunch of files and lines of code. Most of the game systems are separated by directory and namespace, which are used as a way to section off code based on the systems it is used for.

Interaction

Every type of interaction (except for the phone and PC) can be found in the Interaction folder. They can also be identified by their implementation of the IInteractable interface. In the editor, interactable objects will contain one of these components based on their purpose. For example, a door would likely use SwitchRoom while a document on a table would likely use PopupItem. During gameplay, interactable objects will be 2D objects visible to the player and the player can click on them to do various things like reading, talking, traveling, or completing assignments.

Phone and PC

The phone and PC both have a set of apps which they can run, some of which are shared between the two (such as emails). Most of these apps have two scripts associated with them:

• A backend, which handles loading to and from disk, parsing input, running dialogue nodes, etc. This is typically a ScriptableObject.
• A frontend, which builds the UI, displays the data given to it by the backend, and handles player input. This is typically a MonoBehaviour attached to a prefab.

Much of the app data, such as text conversations, emails, contacts, etc are saved to disk in JSON format under the Assets/GameData directory. This allows data to be persistent between game sessions and allows for non-programmers (such as writers and designers) to view or add content for apps using a human-readable format.

Assignments

This contains the Assignment class itself as well as an AssignmentManager that handles saving, loading, organizing, and running certain actions on assignments. There is also an AssignmentDisplay component which can be added to a canvas content area to show the current assignments.

The idea behind the design of the current assignment system is that assignments operate mostly autonomously of other game systems. They will listen for their own criteria, activate and deactivate themselves when need be, etc. All that other systems will likely need to do is fetch their data.

As a result, the Assignment class is a bit meaty. It listens to GameEvents for certain things to happen and sees if those actions match any of the criteria for either activation or completion. If it does, it marks those criteria as fulfilled and will either activate or complete itself depending on what it's looking for and if all criteria have been fulfilled. It also keeps track of time for timed assignments, and will automatically fail itself if the assignment is not completed on time.

Characters & delegation

Much like the Assignments system above, the Characters system consists of three primary parts. The Character class includes attributes about each character and manages the assignments they are delegated. CharacterManager manages all the characters and their loading. The CharacterPortrait is the visual representation of the character which the player can interact with.

More info about the assignment delegation system can be found here.