Devlog #8: The Tech Behind the Terminal

Hey there!

If you have been keeping up with all the devlogs so far, you may remember when I detailed the design behind the terminal in Devlog #2. If you are at all curious or want some context behind the design decisions we made when creating the terminal, feel free to check that out. In this devlog, I am going to discuss some of the systems behind the terminal, as well as the additional features that have been added to it since then. 

Beginning with the terminal itself, it is meant to emulate a command line interface like what you would see on computers from the 1980s and 1990s. As you can imagine, trying to recreate a command line interface using a visual scripting system like Blueprints was quite an undertaking, with a lot of interconnected systems required to make it work the way it does now. I used an online tutorial article as my starting point. Check that out here if you are interested. 

From there, I implemented an object directory with a string array for object IDs. These IDs identify which objects can interact with the terminal. If the object ID is not found, an error is thrown telling the user as such. Below is a screenshot of the system in Blueprints:

And another screenshot of how it works in the UI itself:

I also implemented a switch on string with three keywords to be entered before the name of the object: Activate, Lock, and Deactivate. These systems were added so that it would be easier for the terminal to interact with objects which are called from it. For example, the system worked well with accessing and opening the gate in the woods of Genesis. Below are two screenshots demonstrating the system in action:

Alongside these systems, there are also some additional features and big changes that were made in how the player accesses the terminal. Let’s begin with the latter first. The screen below is what the player sees when they first interact with the terminal:

Before, just the terminal screen would pop up when players interacted with the terminal. Now, they can choose whether they want to access the terminal or upgrade their keycard level, which they will be doing a couple of times throughout the game. This screen was implemented partially because I wanted to give players a choice, but mainly because implementing the keycard upgrade system inside of the terminal interface itself would have been too complicated and time consuming.

Speaking of which, let’s get into the keycard upgrade system. It is basically a numbered keypad in which a player clicks numbered buttons to type in a code, which upgrades the level of their keycard. Players will do this at least two times throughout the game in order to gain access to other rooms within the studio building. Below are two screenshots showing off what the system looks like and how it works:

The system works by taking the string input from the button click, then converting it into text. Clicking the Clear button clears any text, while clicking the Enter button takes the input and determines if the code is correct through a branch conditional. ‘True’ returns a message telling the player that their keycode level was upgraded, while ‘False’ returns a message telling them that the code they entered was incorrect.

All of what was covered in this devlog comprises the entire terminal user interface. As the game is now in Beta and moving towards going Gold, there are some small bugs and things to tweak in the coming weeks. This was a long one, but hopefully it was worth the read.

-Ben