# Intro
"Bitrunning" is a new job role added to the supply department. It centers on short, dungeon-esque maps that are rinsed and recycled. It is designed to be multiplayer, rewarding teamwork, and encouraging players to interact with the station while not in the primary content of their job.

### Strengths
- Brings new, highly expandable content
- Exceptional control over domains- rewards, difficulty, costs
- Does not disconnect players from the main game loop
- Plenty of source material- netrunners, matrix, deus ex
- Shuffled maps and bonus rewards for replayability
- Unique antagonist included
- Limited retries and damage link for extra challenge

### Goals
- Creating an engaging role
- Fostering teamwork
- Staying semi-connected to the station
- Creating challenge and risk

### Anti Goals
- Bears zero risk, like mech piloting or ai piloting
- Leaves the occupants totally vulnerable
- Removes players from the game loop, or is in simulation the entire time
- Internal items affecting external game balance (but not necessarily vice versa)
- Permitting vdom ghost roles to consistently grief
- Vdom negatively impacting the round: Costing threat, causing lag

## The job
Bitrunning is designed to accomodate 2-3 players on station. Their job loop consists of booting in domains, entering them and completing puzzles or challenges, then returning with rewards (or dead). Their primary theme is black leather, 90s-tech, cringey attire. Effectively, they are JP from Grandma's Boy.

## The equipment
Bitrunning requires a minimum of four things to function:
1. A quantum server. This is the primary machine that handles all the operations on the virtual domain. It keeps count of players, available domains, points, randomization, and offers API-like procs. It loads domains until they are shut down, and has a considerable cooldown between reloads.
2. A quantum console. The computer console offers the UI to players. It keeps a list of available domains, and offers buttons which link to exposed server endpoints.
3. A net pod. This device houses bitrunners while they are inside the virtual domain. It is designed to shield them so they are not defenseless. It cannot be opened but through raw damage or forceful crowbar- both give express alerts to the occupant to give them time to prepare.
4. Receive turfs. These are areas marked via map that the server will look for when attempting to transport crates. If in range, it will generate a crate with a randomized amount of contents.

## Generated Domains
These are the map templates loaded into the world. They are designed to be short, though players can choose to remain in them until the server shuts them down manually. For performance sake, they should not extend beyond 75x75. Generated domains have the following contents:
1. A safehouse, which is the player start and gear area.
2. One (1) loot crate, which exists somewhere on the map.
3. The content. Generally, maps have a puzzle or combat focus.

## The safehouse
Safehouses are modular maps which are loaded onto the generated domain. They exist for players to gear up, send loot (marking completion) and exit via escape ladders. They have the following contents:
1. Exit areas. The amount of these determines the amount of retries/respawns into the domain entirely. Each avatar costs 1 tile.
2. Send areas. The encrypted crate, or goal of the map, is delivered to this zone in the safe house. Doing so marks it complete for every player inside.
3. Gear. This is entirely up to the safehouse or the map itself. As they are modular - use at your own discretion. You can use a mostly empty safehouse but place gear inside the safehouse load zone while editing the domain itself, or preset the safehouse with its own gear (ex: lavaland bosses)

## The avatar
The strength of bitrunning is in the avatar connection. When a bitrunner lays in a net pod, it creates a mob in one of the exit zones of a safehouse. This is an entirely separate mob from the rest of the round, which does not interact with or see the light of day elsewhere. When the domain is complete, it is deleted entirely.

Connecting to an avatar as a player links the damage between the physical presence and the avatar. As a caveat, not all damage in game is directly translatable through apply_damage (for instance, fire stacks). However, it is intended to translate 1:1, damage upwards only. Healing your physical character does not heal your avatar, and vice versa.

While connected to an avatar, if it were to die by any means, you will be forcefully disconnected, causing brain damage. If you are pryed out, the netpod is broken, or the server is broken, you are forcefully disconnected.

The design behind this was to create actual danger so that players weren't corpse-flopping through domains. The server gives ample downtime between domains to heal up and socialize before it is ready again.

## Safeties
Piloting is not intended to be a death trap for any bitrunner. The netpod offers protection against environmental hazards (much like stasis beds) and direct damage until it is destroyed.

If someone were to attempt to pry a netpod open or damages it past 50%, the occupant gets a notification describing the situation, and informs them to exit.

The role itself is not designed to have the office stuffed into maintenance either- for mapping consideration, they should be near or connected to cargo bay, with windows, so that they are somewhat in line of sight. This also offers the convenience of short travel to bring rewards to cargo, orm, etc.

## Rewards
Rewards from the job come in three forms.
1. Server points. Each domain costs reward points (stars in the UI) to deploy. Each domain awards points at preset amounts, with domain randomization offering one extra. Stopping a domain for any reason does not award points.
2. Materials. There are rewards given after each domain based on several factors: Servo tiers, additional players, spawned (player) threats, domain randomization and domain reward points all contribute to the final count.
3. Extra loot. Domains have the option of an associative list "extra_loot" which spawns each path at a given amount. Usually this is used for memorabilia, like plushies after certain fights.
4. Vendor rewards. There is a vendor (currently the "NexaCache") that handles points for bitrunning, or NP.

## Antagonists
The virtual domain is given unique antagonist roles designed exclusively to interact with bitrunners. To the players, virtual domain antagonist roles are short lived roles that are meant to either die, goof off, and be killed within a few minutes. This is effectively a free pass to chase down and kill bitrunners.

The first is "Cyber Police" of the Cyber Authority. There's a bit of old memey reference there, and it's somewhat cringe. They are themed as part of the computer system designed to expel bitrunners.They are offered martial arts (carp) and are immune to most natural environmental causes. They are not intended to be long run, kill-the-server-pop antag, and they are killed the second someone shuts down the domain.

VDom antagonists are never intended to escape the simulation unless there is a serious balance consideration before implementing this feature. Currently, there is no way for them to do this. Code-wise, generated domains are iterated over to search for NPC mobs, alive or dead, excluding some that would be detrimental (like megafauna). Mobs can be disposed of in hazardous regions, making cybercops somewhat preventable.

Lastly, virtual antagonists should not take round threat from dynamic unless they have the capability of coming on station.

## Design consideration
While creating bitrunning, the goal was to ensure that bitrunners stay engaged on station in a "semi-offstation" role. There is downtime inbetween events, which can cycle until round end, rather than being a "do your basic chore and leave" role. Despite teleporting elsewhere, they are still attached station side and are very capable of returning when needed.

This avatar-link concept forms a barrier between the content inside the virtual domain and the station. Unlike VR or gateways, nothing travels across unless explicitly set in code.

The design flaws of VR were brought up to me several times during implementation. I took extra precaution to not mimic the same mistakes of VR. It was not an influence in this project nor was any part of the code copied from it. I scoured over every single issue that caused the original VR to be closed, and found only 1 similarity, which I covered with cached_actions.