Another fairly big post. Grab popcorn and/or wrenches.
OUTLINE
Lately one of the areas I've been thinking about with regards to Limit Theory is hacking. Hacking is where an agent gains unauthorised access to a computer system for the purposes of:
- Finding data.
- Modifying data.
- Deleting data.
- Gaining control over systems/resources.
- Stealing the property of other agents.
GOALS
The proposal has been designed with the following goals in mind:
- The system should expand upon the variety of gameplay options available to the player during combat.
- The system should provide an additional type of role the player could assume, or augment the possibilities for other roles.
- The player should be able to hack at both an automatic and manual level.
- Gameplay should be implemented to match the feel of Limit Theory.
- The system should make it so that the player and NPCs are treated equally.
- The system should allow for the possibilities of upgrades.
- The gameplay should look visually appealing.
- The gameplay should be intuitive.
- There should be some risk involved in hacking.
- There should be suitable rewards for successfully hacking.
- The hacking mechanic should benefit from being tied in with an infinite-variety crafting system.
This is how I believe hacking in Limit Theory could be handled.
In Limit Theory, vessels and structures will be built on complex systems that are handled by computers. Other agents may wish to gain access to those systems in order to get access to information, obtain control over something or commit theft. To facilitate this, these agents need some means of gaining access to those systems. In turn, the agents that control these systems need a means of defending them. This proposal details treats hacking as a kind of combat-oriented gameplay, and explores offensive preparation, defensive preparation and the interaction between the two.
Programs
Hacking and counter-hacking involve the creation of hacking programs. These are software entities that are created by combining libraries and code modules that behave as sub-components within the framework of an infinite-variety crafting system, such as the one proposed in Additional Thoughts in Research and Production. As with other types of items that can be created through this kind of crafting system, these programs will have properties that will vary depending on the particular combination of libraries and code modules of which they consist and the particular methodology used to combine them.
Hacking programs consist of two parts; a core and a periphery. The core defines the program's type and its baseline characteristics. The periphery consists of augmentations, which will be discussed in detail in the following section.
In general, a hacking program has the following properties:
- Power
- Mobility
- Resistance
- Complexity
- Integrity
Figure 1: A possible template for warrior programs. (direct link)
However, this is incomplete, since this only covers the properties of the core of the program and not of its periphery. In addition to these, the periphery of a program will have its own associated property values that will combine with these to yield the overall characteristics of the program.
The player and other agents in Limit Theory will need to utilise the research system to gain proficiency in areas of knowledge relevant to programming and hacking in order to create these types of programs. The more proficiency the agent develops in these areas, the better hacking programs the agent will be able to create. An agent's proficiency in these areas will have other effects upon their ability to hack, and this will be discussed below as well.
Augmentations
Programs will not only vary in terms of type and baseline characteristics, but also in the structure of their periphery. Two programs with identical cores can be very different from each other if their peripheries are structured differently. The structure of a program's periphery is determined by the type, quality and organisation of components called augmentations that compose it. Augmentations improve different characteristics of the program, but also increase its complexity.
The periphery of a program is divided into 12 segments. Relative to the program's core, there are three segments arranged upwards, three downwards, three to the left and three to the right. Augmentations occupy one segment of the periphery. The direction that the augmentation is slotted into matters. An augmentation that is slotted into a segment above the program's core will affect interactions in that direction, and so on with the other directions.
There are three types of augmentations, and three qualities of each type:
- Armour - increases the resilience of a program.
- Armour I
- Armour II
- Armour III
- Mobility - increases the movement rate of a program.
- Mobility I
- Mobility II
- Mobility III
- Power - increases the ability of a program to perform its role.
- Power I
- Power II
- Power III
A program with any given core characteristics will have 1 trillion variations (although many of these will be functionally quite similar to each other e.g. some will simply be 90 degree rotations of others, which has little (but still some) effect on gameplay). When factoring in variations in the program core as well, there could be quadrillions of variations of each program type, and the player (and other agents) will discover these through exploration of the state space via the crafting system.
An example of program with a particular configuration of augmentations is shown below. Vacant augmentation slots are represented by white.
Figure 2: An example of a program with augmentations. (direct link)
The program in Figure 2 will have greatest offensive capability to the up and right, greatest mobility to the left and down, and greatest resilience to attack from the left and right.
Establishing Connections
In order to begin hacking, an agent will need to operate a station or ship equipped with a hacking module. These are special modules that can be installed in a vessel or station and provide the ability for the controlling agent to establish a connection with the computer systems of another vessel or station. This process requires time and for the vessel/station to have a target lock on the other entity.
Once a target lock on the entity has been acquired, the hacking vessel will need to remain within a given distance from the other entity. If the entity is within this distance, it can initiate the hacking process by establishing a connection between its own computer systems and those of the other entity. While the hacking entity remains within this distance, a UI element will appear showing the progress of the connection establishment and the estimated time until it succeeds. If the hacking entity moves beyond range, the signal quality will rapidly weaken and the hacking entity will need to quickly move back within range or else the attempt will fail. Even if the hacking entity moves back within range in time, some progress will likely have been lost, extending the estimated time until the hacking process completes.
Additionally, both entities (the one hacking and the one being hacked) will need functional transceivers for this process to be possible. If either entity shuts off its transceiver (or either transceiver otherwise stops functioning e.g. due to damage) before the connection establishment process is complete, the hacking attempt will fail. In general, an entity will not know it is being hacked unless it is actively scanning signals reaching itself and recognises a pattern of signals corresponding to the ones broadcasted during a hacking attempt, or if it has sufficiently advanced counter-hacking software installed.
Once a connection has been established, neither party can disable the connection without incurring penalties unless specific conditions are met. This will be discussed in detail below. Establishing a connection allows for hacking programs of both parties to engage each other in codespace, and to gain control over each other's computer systems.
Hacking can then be performed in two ways:
- Manually - here, the player will be overseeing all aspects of hacking as it occurs, controlling their own programs and responding to the actions of hostile programs in the form of a turn-based combat game. While this is happening, time will pass within the LT gameworld at an extremely reduced rate.
- Automatically - the player can opt to let the vessel/station computer handle the hacking procedure. The outcome of the hacking attempt will depend upon the amount of CPU allocated to the hacking module (among other factors). For more on allocating CPU, I recommend looking through CPU Allocation.
In order to have a defense against hacking from other agents, or to be able to offensively take control over other agents' computer systems, an agent will need to have a hacking suite installed in its computer systems. A hacking suite is a collection of specific variations of the different program types. A hacking suite can contain up to one variation of each program type, and the program variations it is based on will be those that the agent will be able to compile and use during combat in codespace.
Hacking suites can be produced by the agent by compiling program variations together, or can be purchased off of the Software market. This means that a strategic-minded player who likes to be in control of everything and value careful planning can spend time trying to produce a hacking suite tailored to their requirements and preferences, whereas a player less interested in careful planning can buy a standard hacking suite off of the market and plug it into their computer systems. The quality and worth of a hacking suite is determined by the characteristics of the program variations that it is based on.
It takes time to install a hacking suite in computer systems. Therefore, the agent commits to whatever program variations the suite is based on when he hacks or is hacked by other agents; he cannot change what variations are used during the hacking session. This keeps the choices he makes and strategic planning meaningful.
In addition, hacking suites can also be used to specify configurations of programs in codespace, and programs will be produced and moved into these configurations before any hacking occurs as a preparatory step. In this sense, agents can build up their own "forts" in codespace in order to be best prepared for a hacking session.
Meet The Team
After a connection has been established, there are a variety of types of programs that can be used in order to eliminate the other party's offensive or defensive ability, gain access to their computer systems or prevent unauthorised access to your own. Each of these programs behave in different ways, have different characteristics and require different conditions to be met in order to be deployed. In codespace, they are visualised to the player as nodes. There are ten regular types of programs in total. In addition to these, a special kind of program called a Wall can be compiled.
Meet the WARRIOR
This is the basic "melee" unit of the bunch. They are relatively simple programs that do not require a lot of computational resources or time to deploy in codespace, and hence can be produced in a relatively large number. They are capable of performing moderate damage over short distances, can move at a moderate rate and have a moderate amount of health.
Figure 3: The Warrior program. (direct link)
Program characteristics:
- Low complexity.
- Short-range immediate offensive ability. Moderate power.
- Moderate movement rate.
- Moderate resilience.
- Power augmentations increase damage per attack.
The Guardian is similar to the Warrior, but it has much greater resilience at the cost of more limited offensive ability and less mobility. It is slightly more complex than a Warrior and hence fewer of these can be deployed by a given agent with a given set of resources in codespace. It is primarily used to absorb damage that would otherwise end up being applied to another allied program.
Figure 4: The Guardian program. (direct link)
Program characteristics:
- Relatively low complexity.
- Short-range immediate offensive ability. Low power.
- Limited movement rate.
- Very high resilience.
- Power augmentations slightly increase damage per attack.
The Sniper is an offensive program that causes fairly high damage to other units at long-range. Unlike Warriors and Guardians, this attack is not immediate and requires a certain number of turns to charge. Along with the Tower, the attacks of Snipers ignore allied walls. Snipers move at a moderate rate, have a mediocre resilience, and are fairly complex programs.
Figure 5: The Sniper program. (direct link)
Program characteristics:
- Fairly high complexity.
- Long-range charging offensive ability. Quite high power. Friendly walls do not block damage.
- Moderate movement rate.
- Fairly low resilience.
- Power augmentations increase damage per attack and rate at which attacks charge.
The Support program lacks offensive capability, but is able to repair damage caused to the cores of other programs over time and increase their charge/activation/task completion rates. It is quite a complex unit and has moderate movement rate. It can repair a limited number of allied units that are in adjacent tiles to it. It has low resilience.
Figure 6: The Support program. (direct link)
Program characteristics:
- Fairly high complexity.
- Repairs damage caused to adjacent, allied units.
- Moderate movement rate.
- Low resilience.
- Power augmentations improve charge boost effect, repair amount per turn, and number of allied programs that can be repaired concurrently.
The Tower is a special kind of program that can only be built by a mobile Compiler program. It is a complex program, and is unable to move. It is similar to the Sniper in that it is capable of delivering damage over long-range, but requires charging to do so. Along with the Sniper, It is also the only type of unit whose attacks are not blocked by friendly walls. The damage caused by a Tower is generally higher than that by a Sniper. It has high resilience.
Figure 7: The Tower program. (direct link)
Program characteristics:
- High complexity.
- Long-range charging offensive ability. High power.
- Stationary.
- High resilience.
- Power augmentations increase damage per attack and rate at which attacks charge.
The Suicide is a unit that is compiled specifically to destroy itself among a group of enemy programs to cause damage to them. Its attack causes high area-of-effect damage, but can only be used once. It moves quite fast and has low resilience. If it is destroyed by another unit, it will not cause area-of-effect damage to other programs. Its attack can cause damage to allied and enemy programs. It is a complex program.
Figure 8: The Suicide program. (direct link)
Program characteristics:
- High complexity.
- Can cause high area-of-effect damage to other programs in its vicinity by destroying it.
- High movement rate.
- Low resilience.
- Power augmentations improve damage caused by destroying itself.
Compilers are the mobile "engineers" of the program suite. They are capable of creating other programs in the middle of codespace, including two types of programs that cannot otherwise be compiled: Towers and walls. They have no offensive capability, moderate movement speed, very high complexity and low resilience. In order to create other programs, they need to enter "deployed" mode, which takes a turn. When a Compiler is deployed, it is able to compile other programs in adjacent free tiles around itself, up to its concurrent compilation limit. When deployed, a Compiler is stationary and cannot move. It requires one turn for a Compiler to undeploy itself. It takes a certain amount of time for units to be compiled by a Compiler, just as it is in the ordinary case of program compilation. If a deployed Compiler is destroyed or undeploys itself while compiling programs, those programs will not be created.
Figure 9: The Compiler program. (direct link)
Program characteristics:
- Very high complexity.
- Is able to compile programs anywhere in codespace. Needs to be deployed to do so.
- Is the only means of producing Towers and walls.
- Moderate movement rate when undeployed. Stationary and unable to move when deployed.
- Low resilience.
- Power augmentations improve rate of program compilation and number of programs that can be compiled concurrently.
The Stealth is an offensive program that attempts to deal damage to other programs by avoiding detection and catching the entity controlling them by surprise. Stealths will remain unseen by enemy units unless:
- They pass within very close range of an enemy program, or an enemy program passes within close range of them.
- They attack an enemy program.
- They sustain damage.
Figure 10: The Stealth program. (direct link)
- High complexity.
- Unable to be seen as easily by enemy programs as other programs.
- Deals an immediate high-damage attack to adjacent enemy programs.
- Moderate movement rate.
- Low resilience.
- Power augmentations improve damage dealt per attack.
The Virus is the only program capable of converting a program belonging to the enemy to its own side. Viruses are complex, slow-moving, low resilience programs with very limited direct offensive capacity. On each attack, they can only deal a small amount of damage to an enemy program. However, each attack carries with it a certain probability of infecting the enemy program. An infected enemy program will have a countdown timer associated with it, and if that countdown reaches zero, the program will be converted into a friendly Virus program. An infected program can move about as normal but cannot use any special ability. A program can destroy an infected friendly program before the conversion occurs.
Figure 11: The Virus program. (direct link)
Program characteristics:
- High complexity.
- Limited direct offensive ability, but can infect other programs. Infected programs will eventually become friendly Virus units unless destroyed beforehand.
- Slow movement rate.
- Low resilience.
- Power augmentations improve the chances of infections occurring per attack, and how soon an enemy program will be converted after infection.
The Capture is a very special type of program. It is the only program that is capable of capturing hostile computer systems in codespace. It is very complex, moves quickly, has no offensive capability and low resilience. In codespace, a Capture will need to enter the same tile as an enemy system in order to begin capturing it. This process will take a certain number of turns, and if the Capture is destroyed in this time or moves off of the tile, all capturing progress will be reset to zero.
Figure 12: The Capture program. (direct link)
Program characteristics:
- Very high complexity.
- No offensive ability.
- Is the only program capable of capturing enemy systems.
- Fast movement rate.
- Low resilience.
- Power augmentations improve the rate at which enemy systems are captured.
Codespace: the Battlefield
All of these programs will interact with each other and the computer systems of the hacker/victim in an area called codespace, which is an abstraction of the parts of the entities' computers in which programs are actually interacting one another.
When a connection to another entity has been established and the player has opted to hack manually, the game will bring up a grid, and this grid represents codespace. At the bottom left and top right corners of codespace are two two-by-two areas that are known as compile zones. Both the player and the other agent will initially compile their programs in these zones. Later on, if either agent is able to produce Compilers, they can be used to set up mobile compile zones in codespace.
The codespace does not necessarily have to be devoid of programs at the start of a session. As mentioned previously, hacking suites can specify initial configurations of programs in the controlling agent's own region of codespace, and when the hacking session begins, the agents will find programs already setup according to these specifications.
The action is entirely turn-based, so the player and the agent will take it in turns to move their programs around codespace and perform actions with them. Each program can only move a limited number of tiles or perform an action once per turn, but an unlimited number of friendly programs can be ordered per turn.
The player and the agent will have a limited program buffer which places a limit on the total complexity of programs deployed in codespace at any one time. More complex programs will consume more of the free space of the program buffer and take longer to compile (to become active and controllable in codespace). The size of the program buffer is a variable property of the hacking module.
Movement
All programs will be able to move a certain number of tiles per turn and rotate in 90 degree increments, except for stationary ones such as Towers and deployed Compilers. The number of tiles that a program can move per turn is determined by its core mobility characteristic and the total contribution of its mobility augmentations. Some programs may be able to move only 1 or 2 tiles per turn, while others may perhaps be able to move over a dozen. Moving from one tile to an adjacent tile costs one movement point. A 90 degree rotation (where a program remains in the same tile and changes its orientation) costs half a movement point. Rotations can be clockwise or anticlockwise, so no program will ever need to expend more than one point on rotation per turn. Programs do not need to spend all of their movement points per turn, and some actions may prevent a program from making further movements even if it has movements points left, such as attacking another program.
For instance, a program that has a total mobility characteristic in a particular direction of 4.5 will be able to, in one turn, move 4 tiles and rotate 90 degrees clockwise or anticlockwise, or move 3 tiles and rotate a full 180 degrees (and have half a movement point leftover).
The movement capability of a program varies depending on the direction it wants to move in. The base mobility characteristic of the program's core allows it to move equally well in all directions (up, down, left and right), but mobility augmentations can make it so that programs can move more tiles in one direction than another. For instance, a program that has a Mobility III augmentation allocated to one of its right-facing augmentation slots and no mobility augmentations in its left-facing augmentation slots will have +1.5 mobility in its rightwards direction relative to its leftwards direction, and so be able to move 1 tile more and make one additional 90 degree rotation per turn. Each cardinal direction has its own associated mobility point "pool", so that a program that can move up to three tiles to the right in a turn will still be able to do so even if also moves up, down or to the left in the same turn.
When a program is selected by the player, a boundary will appear around the program showing which tiles it is capable of reaching. This boundary may extend across half a tile; programs cannot move by half a tile, but this represents that the program will have half a movement point remaining if they move to a tile just within the boundary. An example of this is shown below.
Figure 13: An example of a movement boundary for a program. (direct link)
The program in Figure 13 is capable of moving two tiles upwards or three tiles downwards, leftwards and to the right. In addition, it will still be able to make a 90 degree rotation if it moves three tiles down or three tiles to the left. In the bottom-left corner of its movement boundary, it will have half a movement point left in both the leftwards and downwards direction, allowing it to make a full 180 degree rotation if desired.
Compilation
Programs can be created in codespace by selecting a compile zone, which can be either the standard two-by-two area that the player and the agent have throughout the session in the bottom-left or top-right corners of codespace respectively, or an eight-tile area that surrounds deployed Compiler programs. With a free tile in these zones selected, the player will be able to select a program to build. There are up to ten different types of programs that an agent can choose to create, which correspond to the ten types of hacking programs. Only one variation of each program type can be used during a session, and these variations would have been decided upon by an agent before the hacking session began, based on the hacking suite the agent has installed in their computer systems. The choice of which program to compile can be presented to the user in the form of a radial selection menu.
Depending on the circumstances, the agent may not be able to compile some or any programs in codespace. The agent will not be able to compile a program if its complexity exceeds the remaining space within its program buffer. Other programs in codespace that it owns will need to be destroyed (either by the controlling player or during the course of combat) before another instance of this program can be compiled.
When an agent makes a selection, the program will begin compilation within the tile that the agent selected. Compilation will take several turns and during this time the program cannot be controlled. The program will appear faded out and a progress bar represented by a series of circles will be present around its perimeter that gives an indication of how far compiled the program is and how many turns are left before the program will be fully compiled and hence controllable. An example of this is shown below.
Figure 14: An example of a program being compiled. (direct link)
Hostile programs can target programs that are being compiled, and if a compiling programs sustains any damage during the compilation process, it will be destroyed. The controlling agent can also choose to cancel compilation of a program, and it will be immediately destroyed then as well.
In order to use a Compiler program to create other programs, the Compiler will need to be deployed. As explained in Meet The Compiler, this will take one turn. When the Compiler is deployed, a zone will appear around it when it is selected. This is shown below.
Figure 15: A deployed Compilers and its associated compilation zone. (direct link)
The controlling agent can then choose to begin compiling programs with it, up until its maximum concurrent compilation limit is reached.
Figure 16: A deployed Compiler being used to create other programs. (direct link)
Compilers are also the only way of producing special programs like Towers and walls.
Figure 17: A deployed Compiler being used to create Towers and walls. (direct link)
Combat
Programs with offensive capability will be able to inflict damage to the cores of other programs. All programs will have a certain integrity value which is initially equal to their core's resilience. If this value reaches zero, the program is destroyed. All offensive programs will have a certain attack radius in which they are able to attack another program. An offensive program will need to move within this distance of another program to attack it if it is not within that distance already. "Melee" programs like Warriors will only be able to attack programs in adjacent tiles, whereas long-range offensive programs such as Snipers and Towers will be able to attack programs at greater distances. Attacking consumes one movement point, and will end the program's turn even if it has movement points remaining afterwards.
Attacks may also require a certain amount of time to "charge" before any damage is inflicted against another program. Programs like Warriors and Guardians can inflict damage immediately against other programs, whereas Snipers and Towers will require a certain number of turns to charge their attacks before they deal damage. A program will need to enter within the attack radius of a charging-attack program before that program can charge up its attack against it. Once this attack begins to charge, the first program will not be able to escape the attack when it eventually happens even if it moves outside of the charging program's attack radius, unless it is able to find cover before the attack occurs. A program can seek cover in the following ways:
- By moving to somewhere where a wall exists between itself and the charging hostile program. If the charging hostile program is a Sniper, the wall will provide cover regardless of who controls it. If the charging hostile program is a Tower, the wall will need to belong to the same agent as the program seeking cover in order for it to block damage from the Tower. Recall that damage from Towers can pass freely across friendly walls but not across enemy walls.
- By moving behind another friendly program. The damage dealt will be applied to the other friendly program in this case. This is why Guardians are valuable programs.
- By moving other friendly programs between the charging hostile and victim program. This is the main intended purpose of Guardians.
Figure 18: A charging Sniper program. (direct link)
If a charging program moves, sustains damage or is destroyed before its attack is fully charged, the attack is cancelled. A charging program cannot move while it is charging.
The outcome of a combat situation between two programs not only upon their types and core characteristics, but upon the direction in which the attack occurs. Based on the structure of their peripheries i.e. the configuration of augmentations they use, programs may be more effective at dealing damage in certain directions and resisting it in others.
An example of a combat situation between two Warrior programs belonging to different agents is shown in the diagram below. This is what the controlling agent of the bottom program would see.
Figure 19: An agent's view of a combat situation between two Warrior programs. (direct link)
An agent will only be able to see the augmentation configurations of their own programs, as this is tactical information and keeping this information about enemy programs hidden makes for more interesting gameplay. A "God's eye" view of the same situation might look like what is shown in the diagram below.
Figure 20: A God's eye view of a combat situation between two Warrior programs. (direct link)
Figures 19 and 20 show the bottom Warrior attacking the top Warrior. You can see from these diagrams that the bottom Warrior program is attacking in its most effective direction, as there are two Power II augmentations slotted in those directions, and a Warrior's offensive capability is improved by power augmentations. The top Warrior is weakly defended in this direction, as it has only a single Armour I augmentation in the direction from which it is getting attacked. This is therefore a very favourable configuration for the attacking Warrior.
Armour augmentations operate by reducing the damage sustained by attacks coming from a particular direction. If no armour augmentations exist in the direction a program is sustaining damage in, it will sustain an amount of damage equal to the raw offensive output of the program along the direction in which it is attacking. If a program sustains damage from multiple directions, the damage reduction is calculated as the average of the damage reduction in all concerned directions, rounded down to the nearest integer.
System Capturing
The various computer systems of both the hacking and victim agents will be visibly represented and vulnerable in codespace. They will appear as stationary nodes within each agent's region of codespace with names such as Scanners, Reactor, Navigation, Databanks, Weapons, etc. These system nodes can be captured, and if captured they will grant the capturing agent control over the corresponding systems of the other agent for a time after the codespace session terminates. Capturing a Scanners node will allow an agent to manipulate the other vessel's/station's scanners and get data back from them. Capturing a Reactors node will allow the agent to control the other vessel's/station's reactor, either to shut it down and disable the other entity or overload it cause damage/destruction of the other entity.
There is a special system node just called System. It is special because capturing it "wins" the battle for the agent that captures it:
- It causes the hacking session to be terminated without the capturing agent incurring any penalties. If an agent attempts to terminate the hacking session prematurely, it will cause their entire program buffer to be wiped (all their programs will be destroyed) and their hacking suite to go offline for a certain amount of time (e.g. 1 minute), during which the agent will be vulnerable to a counter-hacking attempt or to being hacked again. If an agent is hacked while their hacking suite is offline, it will be as if they have no suite installed at all (i.e. very bad for them).
- It automatically causes all other system nodes to be captured i.e. the agent that captures the System node will be able to control all the systems of the other vessel or structure; life support, shields, weapons, etc.
- It causes the other agent's program buffer to be completely wiped.
In order to capture a system node, a particular type of program is needed, called a Capture. These will need to be safely escorted to an enemy system node and then stand on the same tile as the system node for a set number of turns for the capturing process to complete. It will have to be defended during this time, and if it is destroyed or moves off of the tile, the capturing process will fail. Agents will be able to re-capture their own system nodes with their own Captures if they have been previously captured by the enemy agent.
Figure 21: A Capture approaching an enemy system node. (direct link)
As with program compilation and attack charging, system capturing has its own progress bar associated with it, which will appear around the Capture as it stands over the enemy system node.
Figure 22: The progress bar that appears as a Capture captures an enemy system. (direct link)
Example
An example of codespace during a combat scenario is provided in this section.
There are two agents, the player and an NPC. Both have hacking suites installed, and the player has a hacking module installed as well. The player gets a target lock on the NPC, and begins establishing a connection to it. The player is nimble and manages to stay within range of the NPC as this connection is being established, and the establishment is successful. The NPC's hacking suite had encoded for a program configuration already, so the player finds that it already has walls, Towers and other programs established in its region of codespace. The player begins producing some of his own programs within his compile zone, and moves them around the compile zone in order to stage an attack against the NPC's programs and and capture his system nodes.
The diagrams below show a simplified representation of what this would actually look like. The grid is a lot smaller than it would be in practice, the player's hacking suite is assumed to not have a program configuration (so the player starts off with nothing but a compile zone in their area), and there are only a few system nodes shown in the NPC's "fort".
Figures 23 and 24 use the following abbreviations for the different program types:
- WR = Warrior
- GD = Guardian
- SN = Sniper
- SP = Support
- TW = Tower
- SU = Suicide
- CO = Compiler
- ST = Stealth
- VS = Virus
- CP = Capture
Figure 23: A simplified example situation of codespace during a hacking session. (direct link)
The player and NPC will be able to control their programs during their own turns. Figure 24 demonstates this.
Figure 24: The orders given by the NPC and player during their turns. The player moves after the NPC. (direct link)
During the NPC's turn, one of its Compilers finishes creating a Tower in its fort, a Sniper is repositioned and a Warrior unit is moved downwards by two tiles. In the player's turn, a Guardian finishes compiling, a Virus is repositioned, a Compiler is moved right two tiles, and a Warrior is ordered to move in front of the enemy Warrior moved during the NPC's turn and attack it.
GOAL FULFILMENT
This section details how the proposal meets the specified requirements for a hacking system in Limit Theory.
- The system should expand upon the variety of gameplay options available to the player during combat.
- Combat in Limit Theory is given more variety because battles will be waged not just in physical space with lasers and particle cannons but in virtual space between programs. There can be vessels dedicated to hacking other vessels, and additional tactics may arise in fleet combat that capitalise on hacking gameplay.
- The system should provide an additional type of role the player could assume, or augment the possibilities for other roles.
- The player (and other agents in Limit Theory) will be able to assume the role of a hacker, with a craft dedicated to breaking into the computer systems of other vessels or structures. They can use this to obtain valuable information, to deny access to information to others, to modify information in order to manipulate the behaviours of other agents, or to control the systems of other vessels/structures. They can also assume the role of a counter-hacker, who exists to defend against and thwart the attempts of other vessels that attempt to hack.
- The player should be able to hack at both an automatic and manual level.
- The proposed system for hacking allows for both manual and automatic gameplay, and this is detailed under Establishing Connections.
- Gameplay should be implemented to match the feel of Limit Theory.
- By basing the hacking system on the idea of combat between computer programs that are represented as nodes, I believe the proposal could match the feel of Limit Theory.
- The system should make it so that the player and NPCs are treated equally.
- The proposed hacking system ensures that players and NPCs are not treated differently with regards to hacking. All hacking attempts between two NPCs will be "automatic", but the in-game effects will not be any different to what would happen if done "manually" as would be possible between a player and the NPC.
- The system should allow for the possibilities of upgrades.
- There are ten types of hakcing programs, each with 1 trillion varieties. These will differ in quality from each other (and many of these will not obviously be any better or worse compared to others, even if they are very different). The program buffers used within the hacking modules can be upgraded to have larger capacity. The connection establishment process can also be upgraded so that it is more resilient, operates over longer ranges and establishes the connection faster.
- The gameplay should look visually appealing.
- By relying on the node-based engine that Josh has developed, I believe the gameplay could be very visually appealing.
- The gameplay should be intuitive.
- The gameplay is based on a tactical turn-based combat model, meaning it should be intuitive to players who are familiar with these kind of games.
- There should be some risk involved in hacking.
- If an agent attempts to hack into another entity and successfully establishes a connection, they will be committed to maintaining that connection until they have captured the enemy's System node. Aborting the connection prematurely will cause the agent's program buffer to be wiped and their hacking suite to be offlined for a period of time, making them very vulnerable to being counter-hacked. Additionally, hacking works both ways, and the "victim" may gain the upperhand and hack into the hacker's own systems during the course of the session.
- There should be suitable rewards for successfully hacking.
- Successful hacking will reward the player with the ability to control the various systems of another entity.
- The hacking mechanic should benefit from being tied in with an infinite-variety crafting system.
- Programs, hacking modules and hacking suites are all created using an infinite-variety crafting system as proposed in Additional Thoughts in Research and Production.
BFett raised some good points in IRC, so I'm making a few changes.
I'd like to have a third option that's sort of between fully-automatic and fully-manual hacking. Not everyone wants to go through playing a minigame each time. EVE Online makes you do it, but their minigame is a lot simpler and less time-consuming than the one I propose. On the other hand, these people don't want to just let the computer handle everything; they still want to have some control over what happens.
So here are some options:
- Fully-automatic - you lock onto the other entity, establish a connection, and then the game brings up a window displaying the target ship/vessel with all of its systems overlaid that you are able to hack. You pick whichever systems you want to hack (or the entire ship/station), which essentially tells the computer "I don't mind how you do it, but I want you to hack into this and that system (or the whole thing)".
- Semi-automatic - the idea here is that you create and install a hacking protocol program. This is a program where you specify exactly how you want the computer to hack. You give the exact systems you want hacked into, their relative priorities, the order you want them hacked, etc. The computer will try to follow this program as closely as possible. Unlike the hacking programs in the hacking suite, these programs are actually "real" programs, in the sense you code them using a programming language like ViTheory (as proposed in Limit Theory Programming Language) as oppose to creating them procedurally using an infinite-variety crafting system.
- Manual - this is where you involve yourself in the combat minigame and control everything yourself.
This is how I see the system appealing to different types of players:
- Long-vision/strategic players will probably set up R&D labs to explore the state space of the 10^120+ hacking suites that can possibly be created, and so find a hacking suite that's tailored as well as possible to their purposes. They will probably give a lot of thought into the hacking procedure they want as well, and code an effective hacking protocol program to get the computer to do what they want if they go with semi-automatic hacking. On the other hand, the minigame offers great strategic-thinking opportunities, so they strategic-minded player may entirely forego writing hacking protocols and instead enjoy controlling everything manually.
- Medium-vision players may conduct some research into developing hacking suite, but may prefer to look on the software market to get pre-made hacking suites, or perhaps research some hacking programs and mix these with hacking programs bought off the software market to combine into a hacking suite that is partly based on original hacking programs and partly based on market-bought hacking programs. They may prefer to alternate between fully-automatic hacking, or writing simple programs and going with the semi-automatic route.
- Short-vision/tactical players will likely not want to spend a lot of time researching into hacking programs and suites. They may just buy a good hacking suite off of the software market. They are likely to be attracted to manual hacking, as this offers the most tactical gameplay opportunities.
- Uninterested players can simply acquire a lot of money through some other means, buy a really good hacking suite and go fully-automatic with hacking. With a powerful hacking suite, they can afford to relinquish the edge that the additional control of semi-automatic or manual hacking affords.