Terminals

[hhas]

In [re]creating story terminals, we need to decide:

1. Terminal aesthetic. Do we use low-tech monospace green-screen, c.f. M2 and Alien:Isolation, with deliberately limited palette, typography, and pixels? Or do we use modern graphic design: proportional fonts, high-res art, and Environment-specific color schemes (Hab/Sci/Eng/Secret)? We should minimize/eliminate non-functional chrome: these are working interfaces on a working ship, not LCARS eye candy on Enterprise D.

2. Mechanical delivery. Do we use manual paging or auto-scroll? For touch control we can use tap+swipe gestures to control Terminal, e.g. drag finger slowly upwards and the text will continue to scroll at that rate. For keyboard/gamepad, it’ll need its own keys. Do not overload existing movement gameplay keys to control the terminal display.

3. New content. Unlike M2–3, M1 Terminals did not contain pictoral information. (Map checkpoints were rendered on the fly same as in Automap.) Assuming M2–3 become DLC, we want visual consistency across all. At the same time, we don’t want to create too much work for ourselves or bore users with lots of padding, so we might decide to average one (non-map) visual to every 2–3 screens of text, and in M2–3 remove some of the less interesting/non-useful visuals.

Notes

• We may override primary and/or secondary trigger to activate terminal (and other switches) when directly facing it and in reach, eliminating need for a separate Action control. (One of the merits of first-gen shooters is [most] used relatively few keys—player movements, firing, and maybe an action—compared to later games that could have dozens of controls to memorize. “Trivially easy to learn” is a selling point for us.)

• Touch controls and radar must remain visible and usable at all times. As in M2, Terminals do not suspend gameplay while reading so touching a non-reading control (or turning away from the physical terminal screen) will auto-dismiss the Terminal view. When a previously accessed terminal is accessed again, if it was exited before being fully read it may resume from where the reader left off.

• The Terminal display will overlay most of the free screen. It might or might not use a [partially] translucent background, c.f. Inventory view. We’ll need to experiment with that.

• Once a Terminal is fully read, we can add it to the Inventory as a recorded message. That allows players to replay all/some of its message at any time. This saves the user having to backtrack to the physical terminal if they forget a level’s objectives (that’s just frustrating and doesn’t advance game or gameplay). Stored messages should be automatically deleted/archived once a level is completed to avoid UI clutter.

• Ideally each physical terminal in game will display its terminal’s login screen message (plus any static interference effects, dirt and blood spatter, etc applied on top). The login screen is the first screen that appears in the Terminal overlay view for ~1sec, after which the message auto-advances to the first page of content. If the player exits a terminal before it is fully read, we might update the physical terminal’s texture to “continue” displaying the last screen read. (If the terminal isn’t re-accessed within, say, 30 seconds, it should reset to its opening message.) This creates a continuity between the physical terminal and the close-up interactive view presented in overlay.

Stretch goal

English-only text is the MVP, same as in M1–3. If we are able to add translations for common languages, that may broaden the game’s audience beyond fluent English speakers.

If we can include one non-English translation of Arrival’s terminals in Demo, that should be sufficient for Proof of Concept. Something easy like Spanish is a good choice there.

Typography gets harder the further east from Europe we go. If we pursue multi-language support beyond Demo, we’ll have to try creating some (e.g.) kanji/katakana/hiragana terminals as a proper stress test before committing for sure. I’m guessing Godot’s RichText control will not handle much beyond European scripts, requiring pre-rendered screens for Middle and Far East languages.

Multi-language is 100% predicated on generous funding. Even with community assistance it’ll cost.

Next steps

Design the login screen that displays on all physical terminals. This will contain the Marathon logo and original text identifying the terminal’s type and location. Basic brand identity.

Create several visual mockups of low- vs high-definition screens in AI/ID/PS, using existing Terminal text, so we can decide the right aesthetic and text-to-pictoral balance for MCR. Use existing M2 term text and assets for this design process: don’t start making new terminal pictures while experimenting with design and layout. Once we have the look, we can decide how best to technically implement it (e.g. all screens pre-made as raster images, SVG, mix of Sprite and RichText controls, etc).