Terminal Interfacing System
Category: Core Systems Design and Information Access
Context: This was the player’s main brute-force method of interacting with computers, electronics, and information-bearing systems in Data Division. It sat directly between the field loop and the data-processing loop: terminals are where the player accesses, downloads, prints, and routes information before that information becomes something that can be synthesized, sold, or donated later.
What The System Was For
The Terminal Interfacing System is the main way the player interacts with digital infrastructure in the world.
This was one of the more important systems because it turned “accessing data” into something physical and diegetic rather than abstract menu work. The player interacts with terminals, unsecured systems, download points, and occasionally printable information sources. The ideal interaction model was not “pause the game and open a flat UI.” It was closer to intimate device use: tablet, wearable interface, direct cable connection, visible data transfer, and in-world consequence.
The terminal system was therefore the main method of:
- obtaining data
- downloading data to flashdrives
- printing information
- donating information
- selling or storing information indirectly through later systems
Other data could exist as loose loot, like documents found in the environment, but terminal access was the cleaner and more systemic route.
Core Interaction Philosophy
This system should have been simple on paper, but the design choice that made it matter was using a tablet or wearable device to interface with machines rather than a detached UI layer.
That choice fit the subject matter better:
- more intimate with the player
- more aligned with the surveillance / cyberpunk framing
- better for embodied learning
- easier to keep diegetic
It also fit the larger educational premise. If the game was partly about data systems, AI, and surveillance logic, then the way the player touched those systems should itself feel like part of the lesson.
What The Player Can Do
At the interaction level, the player can:
- access a terminal directly
- initiate a download
- use a thumbdrive as a transfer object
- print certain forms of information
- route information into the later workstation / synthesis pipeline
The broader economy behind those actions was:
- selling data gives the player income
- synthesizing data gives the player EXP / progression
- donating information gives the player alignment or ideological points, such as democratizing-tech intent versus feeding surveillance power
So terminal access is not just retrieval. It is the entry point into larger political and progression consequences.
Terminal Component
The Terminal component goes onto the main computer object.
At the object level, the component required a number of designer-set variables. Some of them could intentionally be left disabled or null depending on the use case.
Examples:
isHackingdataDownloadButtonoverrideSecurityprintedDataSpotconnectionPort
If something is NULL, that simply means there is no object reference assigned. That should be handled safely with returns or guards so the terminal does not try to run logic against missing dependencies.
Connection Port and Diegetic Cable Logic
One of the more interesting ideas here was the connectionPort transform.
When functional, this port was supposed to work with an OBI Rope setup that would tween onto the terminal as if a real data cable had been connected between the player’s tablet device and the machine.
That meant the system was not only:
- press button
- get file
It was also meant to visually communicate:
- a physical connection exists
- access is happening through an actual device pathway
- hacking / transfer is embodied in the scene
This also tied into:
isHackinghasBeenHackedwasSuccessfullyHackedoverrideSecurity
Printing
Some terminals can print information.
This was handled through a simple toggle that determines whether a terminal is allowed to print an object such as:
- a stack of documents
- a printed note
- a physical record needed for a mission
When that toggle is true, the designer or level designer has to set:
- the printed object itself
- the transform at
printedDataSpot
That kept the printing system modular instead of hard-coding it into every terminal.
Flashdrive Download Trigger
The flashdrive system depends on the referenced Terminal object. Each terminal can therefore have its own specific download trigger behavior.
Once a FLASHDRIVE is inserted:
- the
gooberSlotreferences that inserted drive isUsingSpotbecomes true- the terminal begins the relevant download / transfer behavior for as long as the player leaves the drive in place
This gives each terminal local ownership over its own transfer logic rather than treating every download station as identical.
Download Progress UI
Once data is downloading to the flashdrive, the player can view a download progress UI while it fills.
This sounds minor, but it matters for feel:
- the player sees the transfer as a timed process
- interruption remains meaningful
- progress is visible
- the world feels more like it has machine state rather than instant magic actions
In the larger loop, this also ties directly into the workstation system later, where the captured drive becomes input for synthesis, storage, sale, or alignment routing.
Interactions Summary
At the simplest interaction level:
- the player can go up to a terminal and press download to obtain information
- the player can insert and retrieve thumbdrives as transfer objects
- unsecured terminals can require hacking or a mini-game before access
- printable terminals can generate physical information objects
This made the terminal system one of the main bridges between embodied interaction and the larger information economy.
Relationship To Other Systems
The terminal system links directly into:
- STIK: Physical Data Theft Mechanics
- Data Workbench System: Processing, Synthesis, and Information Flow
- Interactive Tablet UI: Diegetic Menus
That relationship matters because the terminal is not a standalone mechanic. It is the access layer for the larger project.
Documentation Note
The original technical draft for this system included embedded screenshots and inspector captures. Those source images still need to be cleaned up and exported from the technical-documentation artifact before they are added here as proper portfolio images.