Return to “Suggestions”

Post

An Investigation Into Hacking

#1
Edit: The ideas presented here have been scrapped as a proposal for an implementation in Limit Theory. To see a revised proposal of hacking in Limit Theory, follow this link.

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.
In Limit Theory, I see hacking as a form of gameplay in which the player or an NPC gains access to computer systems that belong to another agent in the game. This post gives suggestions for how the design of that form of gameplay. It incorporates ideas suggested in Mechanic #015 of Squidi.net's Three Hundred Mechanics.

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.
IMPLEMENTATION
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
The meaning of these properties and how they affect gameplay will be discussed below. An example template for one of the types of hacking programs is shown in Figure 1.
Image 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
When a program is crafted, it will acquire a periphery with each of its twelve segments either left empty or filled with one of these augmentations.

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.
Image 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.
Hacking suites
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.
Image 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.
Meet the GUARDIAN
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.
Image 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.
Meet the SNIPER
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.
Image 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.
Meet the SUPPORT
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.
Image 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.
Meet the TOWER
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.
Image 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.
Meet the SUICIDE
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.
Image 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.
Meet the COMPILER
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.
Image 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.
Meet the STEALTH
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.
Stealths are complex programs that have moderate mobility, low resilience and deal high damage when they attack. Their attack is immediate and requires no charging. The Stealth will need to be adjacent to an enemy program in order to attack it.
Image 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.
Meet the VIRUS
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.
Image 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.
Meet the CAPTURE
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.
Image 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.
Along with these is the Wall, which can only be compiled by mobile Compilers. They block all movement through the tiles they occupy to both friendly and hostile units, and prevent all damage across them except from friendly Towers. They consume very little computational resources so many of these can be compiled and exist on codespace at once.

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.
Image 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.
Image 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.
Image 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.
Image 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.
Image 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.
An example of a charging Sniper program is shown below. As with compilation, a progress bar will appear around its perimeter to show how ready the program is to attack.
Image 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.
Image 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.
Image 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.
Because of these advantages, the System node is usually the most heavily defended. It is also located very close to the agent's standard compile zone. It can still be a good tactic for an agent to capture periphery system nodes and then terminate the hacking procedure prematurely. Even though it makes itself vulnerable to a hacking attempt, it will have gained control over the enemy's systems that can be exploited to disable or destroy the other entity before it can counter-hack. Even if the entity does counter-hack, allied vessels could capitalise on its compromised state while it is counter-hacking.

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.
Image 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.
Image 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
The smaller circles at the top-right of each program node represents which agent controls the program. The player controls blue programs, whereas the NPC controls orange programs.
Image 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.
Image 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.
ADDENDUM
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.
The semi-automatic option is a nice compromise between those that want more control over fully-automated hacking, but don't want to involve themselves in a time-consuming minigame.

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.
Last edited by ThymineC on Sun Feb 09, 2014 9:03 am, edited 8 times in total.
Post

Re: An Investigation Into Hacking

#2
Yay! I actually read through this one too, do I get a cookie? :P I might make this habit-forming.

Let me make the first statement, I like this. I like the concepts put forth.

Alright, here are my thoughts. Not going to be as long, but knowing me, probably long-winded either way. Sorry in advance.

These are from my notes and may not be in any particular order.

You state that if the communication is broken, then someone's program buffer is offline for a little bit of time. Okay, what happens if I shut down my sensors / comms? Basically, doing the equivelent of 'pulling the plug' (power or network) when my computer gets a virus? I feel this should be a viable defense and immunity against further attempts at the cost of... well, lack of comms, sensors, or anything else reliant on that system. Something like a forceful termination should still cause the attacker the same issue as if the connection was broken (I may not be able to hack them, but someone else might; I'm desparate, maybe I did this on purpose).

As an addendum, how is this affected by power management?

With each type of augmentation, there are three types of qualities. With different things like this, is it possible to have a 'best' and 'worst' combination for each augment? I ask this, because with how many people theory craft things like World of Warcraft, there eventually becomes a 'best build' or 'best skill rotation', etc. If this ends up like that, then there is potential for optimization to the point where someone can not be beat, or someone can not win. I don't want to see someone stuck in a pit just because they didn't build their augments 'right'.

Since hacking is a single 1-to-1, how is this affected by external factors like the presence of an AWACS? What if the enemy fleet has something blocking my signal? Ideally we would want to take that ship out first, but how do we do that if it's doing some sort of fleet-wide jamming? Or hiding?

Next, in regards to the Augmentation 'Stealth', I felt it was a little too overpowered. It is high damage, but it seems like there isn't much protection against it. Other than the 'passing close by' another augment it would be revealed, I think this radius would have to be played with to balance it out. It has high reward, I just don't feel the risk is high enough to compensate for that high reward.

Biggest one; the turn-based concept. You've established that when in hacking mode, gameplay slows down a lot around you. Since this is turn based there are two things I see;

1) Is the AI going to be making moves instantly? If so, then that means the player is at a disadvantage if they don't do their moves instantly as well, potentially eating up real-world game time that could cause another physical ship to destroy mine (more on this later)?

2) Is the AI not going to be making moves instantly (making good AI so it looks like there are some bad players out there)? If so, then would the AI hesitating be seen as 'thinking' or 'stalling' with the latter being on purpose to let his buddy sneak up out from behind an asteroid to kill me while I'm in hackerspace.

Simple question, do movement points carry over. If I have half a movement point left, can I keep that? Or are points lost? (not really a big question, just mechanically curious)

The "I Win" button.

If not having this module installed is the equivelent of immediately falling under control of another ship, then how does this affect exploration? If I fly through a system without one of these (or one that's basic and on automatic), doesn't this equate to an 'I Win' button to the enemy? What's the range of this and line-of-sight considerations? Can they hide in an asteroid just picking off people coming through without one of these modules? If I only have one ship, this would mean instant game-over (and if you don't know where it came from, it seems like you just randomly had a game-over screen; same thing I've said about invisible mines--it becomes perceived as randomly applied damage).

Likewise, if I go through a system with a really powerful one and just set it to auto-hack or whatever, can I just fly straight through, picking up an army behind me because they're defenseless or not defended well enough? Or maybe I want to auto-destruct their systems/reactor, suddenly it means I have an 'I Win' button.

Then, from when I mentioned about with the AI making turns immediately or not, what about me, can I perform the same? Say I engage an enemy in hacking one of my fleet's ships, then while that is going on, launch a missile at the ship from another one in my fleet and use one as the front for another? What if I myself am caught between a missile and a hack?

Now, other than these issues which could probably be balanced out in some way, about the only one that really gets to me is how complex this entire system is. I don't mean complex in a convoluted sense, but I mean complex for a meta game. Realistically, something that you just described could be packaged up and sold in a mobile app store for $1-$3 and I'm sure you could gain a decent following with that alone. I like the game more as a stand-alone game than a meta game for LT.

Why? Because if it requires this much to describe it, it might too much for the layman who may be playing this game. Granted, when it comes to other aspects of the game (such as combat, exploration, economical) it is just as complex, but I think this is because it's all wrapped up into one small package. Hacking is done all within ship-to-ship while things like combat and economy involve a bunch of other systems (each that aren't as complex) to come up with an overall system that is as complex, if not more.

Granted, since those other aspects (combat, exploration, economical) will all have their own respective pieces to accomodate it (holographic interface for combat for example) and I'm sure one could be made for this, I will still have to stand by thoughts that it might be a hair too complex in it's current form for LT.

But don't get me wrong. I'd play it. I'd play it the same way I play tower defense games (read: waaaaaay too much), and I'd find myself cursing that something like this couldn't be put on my phone to play away from the game. I like it, it's very well thought out and makes sense, but I also don't want to play chess with my opponent while in the middle of a dogfight (and I love chess).
Image
Early Spring - 1055: Well, I made it to Boatmurdered, and my initial impressions can be set forth in three words: What. The. F*ck.
Post

Re: An Investigation Into Hacking

#3
FFS, could you include a TL:DR version of your posts for the guys on the run here?

I think the basic concept here is flawed. We're talking electronic warfare here, which in MMO terms usually is "buffs and debuffs". As nicely and elaborately worded as the proposal is, it's IMHO not applicable for the actual gameplay of the Space Sim / RTS hybrid that LT is supposed to be.

It doesn't integrate into the gameplay of either genre. Worse, if it's totally and wholly dependent on the player actively playing (i.E., having the computer do it for you more often than not fails miserably), a luxury that he might not have if he wants to jam his esteemed foe while being under fire. Also, if I can circumvent the entire shebang by assigning it to an NPC/onboard computer, then we're wasting code and time. If it's an option only available to the player, then we face balance issues. If the player is the only one who has to actively defend himself against electronic warfare attacks by playing an obnoxious, non-optional mini game, then we're screwing the pooch as far as gameplay is concerned.

Once more: all things that take control away from the player are to be avoided at any cost. That includes especially hijacking his ship or parts thereof nilly-willy, without any effective means of defense against it.* I don't care if it sounds neat on paper. If you lose your ship for the 20th time to a random hacking attack out of the blue, you'll be pissed. This stuff has potential to be more obnoxious than stunlock rogues and mind control priests combined.

* = If I need 3 module slots to avoid the playing minigame, and the AI only needs one to initiate it, then we're facing serious balance issues. The AI has no problems with playing the game, while quite a few players probably will loathe it. Let's face it: We're NOT here to play chess or any variant thereof.
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.
One simple question: Why the hell would I even turn the blasted transceiver on when I'm in hostile territory?

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.
Just effing no. That way lies madness.
Also, why bother with an elaborate minigame that is so utterly disconnected from the actual main gameplay? For all intents and purposes, you could use LT's standard engine and shader options to generate a "trench run" type attack scenario where you manually pilot the "virus" and try to avoid enemy "ICE"-type crafts and defense turrets. This at the very least would keep with the core skills of the LT player. Research in electronic warfare would directly translate into improvements the virus crafts flight profile, payloads and fitting options.
(And no, I do not condone that version, either. But it's as good a brainfart as the other one...)


That other game with the capital "E" in its name actually has a hacking minigame since a few patches ago. It's a rather jarring affair, as you basically play a minesweeper minigame that has no correlation to the regular gameplay, and most people dislike the mechanic. That it seamlessly continues into a game of "Hungry, Hungry Hippos" afterwards and your success there pretty much determines the value of the loot you get, quite a few people were righteously pissed at CCP for the introduction of said mechanics.
It also required changes to the general gameplay; before the introduction of said game, hacking was based on a random skillcheck over time, and the sites where hackable containers were found included enemy NPCs. Due to the nature of the minigame, those were removed except for one very special case. Bottom line: Mini games and regular pew-pew don't mix.


And then there was that point in the X-series where you were forced to play sudoku in order to complete a story line. Suffice to say, at that point I used a website to solve the POS (as I fricking *hate* sudoku), and had the urge to strangle the Devs long before the abomination that they called "Rebirth".
Hardenberg was my name
And Terra was my nation
Deep space is my dwelling place
The stars my destination
Post

Re: An Investigation Into Hacking

#4
I'd like to suggest that systems could be hacked over a period of say 10 seconds (5 sec upload and 5 sec download) at a distance of say 200 meters. Not only this but the systems to be hacked would not include flight control or weapon systems. Different kinds of Information could be available to be hacked (ship ID, cargo manifold, recent flight logs) but I don't want shields to instantly disappear, or weapons to mysteriously go off line.

I think there are plenty of uses for hacking if you know how to use the information that you gather to your advantage.
Image
Post

Re: An Investigation Into Hacking

#5
I like the concept of hacking, I really do (seeing as I'm a programmer), but I feel like its execution as presented here is a bit off. I guess I could go for the semi-automatic option, but the minigame seems a bit too much like... chess. I know that's not exactly constructive feedback, sorry. However, I also won't pretend that anything I've said here is more than personal preference, so take it as you will.

Addendum: I like the idea of buying modules and upgrading your hacking software and stuff like that, and I do want there to be SOME sort of manual interaction. For comparison, I liked the way Mass Effect 2 handled hacking, except for the time limit: you had to match patterns of code segments while avoiding others. I feel the time limit but pressure on the player the wrong way - there of course needs to be opposition, but it shouldn't have been an arbitrary time limit, but dependent (in the case of LT) on what hacking/antihacking software the machine we're attacking has installed/purchased. If it was something like that where you picked code segments and put them together, I think I'd like it a lot more. In a sense, I guess that's exactly what your mini-game is abstracting away, but I want it to feel like programming instead of just a minigame, or at least have that look. But like I said, just personal preference; I recognise I'm in a vastly different mindset from many of LT's future players because of the fact that programming's my field.
Image
Post

Re: An Investigation Into Hacking

#6
DWMagus wrote:You state that if the communication is broken, then someone's program buffer is offline for a little bit of time. Okay, what happens if I shut down my sensors / comms? Basically, doing the equivelent of 'pulling the plug' (power or network) when my computer gets a virus? I feel this should be a viable defense and immunity against further attempts at the cost of... well, lack of comms, sensors, or anything else reliant on that system. Something like a forceful termination should still cause the attacker the same issue as if the connection was broken (I may not be able to hack them, but someone else might; I'm desparate, maybe I did this on purpose).
Oh yeah, I forgot about considering this, cheers. Often the simplest solutions are the best.

So what stops an agent from just shutting down comms when they see they're getting hacked?

My first idea was to imagine that agents in LT developed a multi-phase hacking protocol, where the first phase (which happens very fast) involves broadcasting a program that prevents the victim's computers from shutting down power to comms, and the second phase (which takes longer) just involves establishing the connection to begin the hacking procedure as already discussed. But then I thought, "Wouldn't vessels/structures just develop a mechanism to physically kill power to comms in response to this?" I imagined this criticism being voiced by CutterJohn in my head. But yeah, it's a good criticism.

So my next idea was more interesting. I imagined that a ship would hack through the use of hacking drones, which are expensive, pretty advanced pieces of technology a few centimetres big. The idea here is that the hacking module actually appears as a turret that you mount in a hardpoint, and it's capable of launching drones at the hulls of enemy ships/stations. Now, in order to work, in order for this to work, the hacking drone has to make contact with the actual hull. So what you'd do is acquire a target lock on the ship/station, aim your hacking module turret towards it, and then do one of two things:
  • If the ship/station doesn't have shields up, you just pull the trigger and launch the hacking drone towards it.
  • If the ship/station has shields up, you will need to find out its shield harmonic frequencies. With that information, your drone will be able to pass through the shield by creating a temporary, weak shield of its own with a matching frequency so that the two shields are fully-synced, as discussed under Shield/Shield Interactions in Shield Harmonics.
If the drone successfully manages to make contact with the hull of the ship/station, it will latch on to it. It will then start pumping out nanorobots that will tunnel through the hull and towards the entity's core where they will try to integrate themselves with the vessel's core computer systems. The nanobots will be wired to the computer systems and communicate with the drone, and the drone will communicate with your own ship's computers.

Then basically what happens is that the entity's comms systems are bypassed completely, so there's little they can do to prevent being hacked by shutting down comms (though there will be other ways to stop it happening, like trying to configure their shields to a frequency that your comms cannot match, so that your drone can't communicate with your ship as the hostile's shields absorb the communication signals; or by moving far enough away from your vessel so that the signals from your drone and your ship can't reach each other).

Doing this comes at a risk, though - if you establish a connection which you then prematurely abort, your program buffer will be wiped and your hacking suite offlined for a period of time. If the victim or another agent tries to hack you and successfully establishes a connection with your computer systems within this period, they will face no resistance and easily gain control of your ship/station.

I imagine hacking drones to be pretty expensive, as they're pretty advanced tech, so it'll really make you focus trying to get the drone to reach a difficult target like a moving vessel. Unless you're super rich and can just afford a tonne of them.
DWMagus wrote:As an addendum, how is this affected by power management?
So the hacking module is now really composed of an internal and external component (the hacking computer systems and the hacking drone turret respectively).
More power allocation to the hacking module will increase the rate at which the hacking drone is launched (it travels faster so it's more likely to hit the target). More CPU allocation will decrease the time needed to establish a connection when the hacking drone reaches its target, and will improve the chances of success if you're hacking fully or semi-automatically.
DWMagus wrote:With each type of augmentation, there are three types of qualities. With different things like this, is it possible to have a 'best' and 'worst' combination for each augment? I ask this, because with how many people theory craft things like World of Warcraft, there eventually becomes a 'best build' or 'best skill rotation', etc. If this ends up like that, then there is potential for optimization to the point where someone can not be beat, or someone can not win. I don't want to see someone stuck in a pit just because they didn't build their augments 'right'.
Yes, out of the quadrillions of variations of each program type, there will be one variation that is objectively best in terms of power, mobility and resilience. However:
  • It'd be extremely difficult to find this program due to the enormous state space of variations and the complexity of the property formulas.
  • The "better" a program is, the more complex it is. That means that even if you find a program that has great power, mobility and resilience, it is likely to be very complex, meaning it will take longer to compile that program during battle and your program buffer will fill up faster, so you can support fewer instances of them at any one time. Additionally, greater complexity negatively affects some of the properties of programs, such as its mobility and resilience.
    • This means that even if knew how to build exactly the program variation you wanted, it still would not obviously be the best program variation to use in all situations, since its (likely) high associated complexity will mean it might not be suitable for strategies that involve spawning large numbers of cheap, quick to build programs. For instance, if you prefer Zerg tactics, you might want to use a weaker but computationally cheaper program, whereas if you prefer Protoss tactics, you may want a powerful but expensive program.
DWMagus wrote:Since hacking is a single 1-to-1, how is this affected by external factors like the presence of an AWACS? What if the enemy fleet has something blocking my signal? Ideally we would want to take that ship out first, but how do we do that if it's doing some sort of fleet-wide jamming? Or hiding?
So, AWACS vessels are vessels performing continual analysis of the battle and feeding useful tactical information to other vessels, right? An AWACS vessel may be able to scan the frequency of signals coming from your comms to your drones and send that information to the vessel/station you're trying to hack. That entity will then be able to configure its shield harmonics to better block the signal between your vessel and the drone, I suppose.

If a fleet has something blocking your signal, I guess then you'll need to find a way to stop it doing that. But I haven't given much thought to a fleet-wide signal blocking system or anything like that so I don't know how that would play out.
DWMagus wrote:Next, in regards to the Augmentation 'Stealth', I felt it was a little too overpowered. It is high damage, but it seems like there isn't much protection against it. Other than the 'passing close by' another augment it would be revealed, I think this radius would have to be played with to balance it out. It has high reward, I just don't feel the risk is high enough to compensate for that high reward.
In regards to balance, think of them just like the Spy in TF2. It is high damage (instant kill from behind) but easy to kill if spotted. If the Stealth is played well (targeting programs that move slower than it, are already in a weakened state and far away from allied programs), they can be very useful. If not played well (targeting programs that are faster than it, in good condition and surrounded by allies), they will be very easy to destroy. They are also complex so you can't build too many of them.

I'm not sure what you mean by "Augmentation 'Stealth'". There is no such augmentation, only a program type.
DWMagus wrote:Biggest one; the turn-based concept. You've established that when in hacking mode, gameplay slows down a lot around you. Since this is turn based there are two things I see;

1) Is the AI going to be making moves instantly? If so, then that means the player is at a disadvantage if they don't do their moves instantly as well, potentially eating up real-world game time that could cause another physical ship to destroy mine (more on this later)?

2) Is the AI not going to be making moves instantly (making good AI so it looks like there are some bad players out there)? If so, then would the AI hesitating be seen as 'thinking' or 'stalling' with the latter being on purpose to let his buddy sneak up out from behind an asteroid to kill me while I'm in hackerspace.
With regards to 1) - that's not how turn-based play works. Your opponent can't make any moves until your turn is over, and vice versa, so it doesn't make any difference how much time you and the NPC spend making your respective moves.

It'd be like 2) anyway - NPCs will play just like players. However, time will pass extremely slowly in the LT gameworld while you're in codespace. NPCs shouldn't try to stall (that would lead to very boring gameplay and time passes too slowly for it to be of much use anyway), and when a typical session is over you'll likely find only a second or so have passed within the actual game world (maybe a bit longer; this is a balance issue).
DWMagus wrote:Simple question, do movement points carry over. If I have half a movement point left, can I keep that? Or are points lost? (not really a big question, just mechanically curious)
Movement points don't carry over between turns.
DWMagus wrote:If not having this module installed is the equivelent of immediately falling under control of another ship, then how does this affect exploration? If I fly through a system without one of these (or one that's basic and on automatic), doesn't this equate to an 'I Win' button to the enemy? What's the range of this and line-of-sight considerations? Can they hide in an asteroid just picking off people coming through without one of these modules? If I only have one ship, this would mean instant game-over (and if you don't know where it came from, it seems like you just randomly had a game-over screen; same thing I've said about invisible mines--it becomes perceived as randomly applied damage).
I see a hacking suite being an essential part of a vessel, just like an antivirus program/firewall is an essential part of having computers today. Ships will be sold with stock hacking suites installed, and any ships you design would probably want to include one (just like you'd want to include drives and a reactor). So in general, yeah, it'd be something almost all ships have at least a stock variety of, but it's not something a player will need to worry about too much if he's not interested in that area of gameplay (he will, however, probably end up royally screwed if he comes up against a decent hacker, but that's no different then neglecting to buy good shields and running into a guy with really powerful lasers).
DWMagus wrote:Likewise, if I go through a system with a really powerful one and just set it to auto-hack or whatever, can I just fly straight through, picking up an army behind me because they're defenseless or not defended well enough? Or maybe I want to auto-destruct their systems/reactor, suddenly it means I have an 'I Win' button.
I'm not sure, but this is a game design problem that extends far beyond just hacking gameplay. I mean, what happens if you acquire very powerful lasers? Then you could just whip your cursor back and forth around the battlefield like you're Willow Smith and dominate the battlefield just as easily. How will super-powerful components by balanced in general?
DWMagus wrote:Then, from when I mentioned about with the AI making turns immediately or not, what about me, can I perform the same? Say I engage an enemy in hacking one of my fleet's ships, then while that is going on, launch a missile at the ship from another one in my fleet and use one as the front for another? What if I myself am caught between a missile and a hack?
I'm really not sure what you're saying here, sorry. :? Could you clarify on this point please.
DWMagus wrote:Now, other than these issues which could probably be balanced out in some way, about the only one that really gets to me is how complex this entire system is. I don't mean complex in a convoluted sense, but I mean complex for a meta game. Realistically, something that you just described could be packaged up and sold in a mobile app store for $1-$3 and I'm sure you could gain a decent following with that alone. I like the game more as a stand-alone game than a meta game for LT.
Yeah, it would be fun to throw something like this together in Java as a standalone thing. :ghost:
DWMagus wrote:Why? Because if it requires this much to describe it, it might too much for the layman who may be playing this game. Granted, when it comes to other aspects of the game (such as combat, exploration, economical) it is just as complex, but I think this is because it's all wrapped up into one small package. Hacking is done all within ship-to-ship while things like combat and economy involve a bunch of other systems (each that aren't as complex) to come up with an overall system that is as complex, if not more.
The solution's simple; I just need to design the other systems to be super, super complex. So that everything remains in balance, right? :P
DWMagus wrote:But don't get me wrong. I'd play it. I'd play it the same way I play tower defense games (read: waaaaaay too much), and I'd find myself cursing that something like this couldn't be put on my phone to play away from the game. I like it, it's very well thought out and makes sense, but I also don't want to play chess with my opponent while in the middle of a dogfight (and I love chess).
Well, you don't have to. The game is there for those that want to go through with it, but you're entirely free to hack without needing to touch the minigame. See Addendum.
Post

Re: An Investigation Into Hacking

#7
When I said Augmentation 'Stealth' I meant program.

I kind of figured you were modeling after the TF2 spy. In TF2 at least, there are limits to the stealth capability; whether it's timed, and the stealth eventually runs out, or the one where it only depletes when you move. Neither of those limitations are there for this program.
It'd be like 2) anyway - NPCs will play just like players. However, time will pass extremely slowly in the LT gameworld while you're in codespace. NPCs shouldn't try to stall (that would lead to very boring gameplay and time passes too slowly for it to be of much use anyway)
Okay, this answers one question but creates a couple more. If we know that time passes slow enough that stalling is not a valid tactic, then that also means that NPC-to-NPC interaction hacking is incredibly quick. What happens if I'm in a fleet battle and don't realize the enemy is hacking the ships that I'm not controlling? Do I have to worry about handling multiple hacks simultaneously? Will I even know if ships other than mine are being hacked until they either explode on their own or start firing on me?
I'm not sure, but this is a game design problem that extends far beyond just hacking gameplay. I mean, what happens if you acquire very powerful lasers? Then you could just whip your cursor back and forth around the battlefield like you're Willow Smith and dominate the battlefield just as easily. How will super-powerful components by balanced in general?
Because one takes skill. My weapons aren't going to auto-fire on any enemy in range. I still have to control my ship, and if I'm a crappy pilot, might not be able to take out someone who has weaker weapons, but can out maneuver me. I think what it boils down to, is that by tossing in this hacking, it trivializes any sort of rock-paper-scissors in every regard; whatever you have for engines, shield, weapons, etc no longer matter. Likewise, there isn't the opposite. Where is the RPS for hacking? It's all internal, but it can take over other ships' external pieces. There is no skill to use automatic hacking and automatically win against anything you're up against.

Which begs to question, what about ship size differences? Can all of a sudden a simple fighter take out a cap ship without firing a single shot just because of a bad A/V on the enemy if I play a really good hackerspace game?

The fact this post is shorter should mean that I understand your counter-counter points.
Image
Early Spring - 1055: Well, I made it to Boatmurdered, and my initial impressions can be set forth in three words: What. The. F*ck.
Post

Re: An Investigation Into Hacking

#8
Hardenberg wrote:FFS, could you include a TL:DR version of your posts for the guys on the run here?

I think the basic concept here is flawed. We're talking electronic warfare here, which in MMO terms usually is "buffs and debuffs". As nicely and elaborately worded as the proposal is, it's IMHO not applicable for the actual gameplay of the Space Sim / RTS hybrid that LT is supposed to be.
I think mini-games/meta-games are excempt from this, since they constitute such a small part of the gameplay. For instance, EVE Online is an MMORPG but it, too, involves mini-games when it comes to hacking (although its hacking minigame is a lot simpler).

Plus, since it's entirely node-based, you can base the game on Josh's awesomely beautiful node interface, which can help it fit the feel of LT. Image
Hardenberg wrote:Worse, if it's totally and wholly dependent on the player actively playing (i.E., having the computer do it for you more often than not fails miserably), a luxury that he might not have if he wants to jam his esteemed foe while being under fire. Also, if I can circumvent the entire shebang by assigning it to an NPC/onboard computer, then we're wasting code and time. If it's an option only available to the player, then we face balance issues. If the player is the only one who has to actively defend himself against electronic warfare attacks by playing an obnoxious, non-optional mini game, then we're screwing the pooch as far as gameplay is concerned.
Three points:
  1. NPCs are treated no differently to the player.
  2. It's assumed that the AI will be intelligent enough to rival the average player's ability.
  3. Josh wants to design systems so they can be played in both a manual or an automated way, like we recently saw with scanners. A player can choose to play manually or automatically, and both will have their own relative advantages or disadvantages. The player isn't forced to play the minigame at all, but doing so will give them more control over the outcome. If they want to go the automatic route, then they will save time but lose an element of control over the outcome, unless they've put a lot of thought into the design of their programs/suites beforehand.
Hardenberg wrote:Once more: all things that take control away from the player are to be avoided at any cost. That includes especially hijacking his ship or parts thereof nilly-willy, without any effective means of defense against it.* I don't care if it sounds neat on paper. If you lose your ship for the 20th time to a random hacking attack out of the blue, you'll be pissed. This stuff has potential to be more obnoxious than stunlock rogues and mind control priests combined.

* = If I need 3 module slots to avoid the playing minigame, and the AI only needs one to initiate it, then we're facing serious balance issues. The AI has no problems with playing the game, while quite a few players probably will loathe it. Let's face it: We're NOT here to play chess or any variant thereof.
I don't see hacking as permanent; a hacked vessel can only remain hacked for a certain amount of time before their systems reboot or otherwise re-acquire control. If my ship got permanently hacked, I'd very quickly get annoyed with the system. If my vessel remained hacked for a few moments, I'd be quite interested to see what would happen. If they managed to take over my weapons, perhaps they'd make my ship fire at allied vessels, or perhaps they'd utilise my scanners to perform scans that their own scanners were incapable of, or they could steal tactical information from my vessel's databanks, or information about me. It'd be interesting to see what an AI did with my vessel, but only a for a little while. I don't think a vessel should remain within a hacked state for longer than, say, a minute at any one time.

You'll never be without a means of effective defence, unless you neglect your hacking suite or go against a very powerful hacker (rare). There will be steps you can take to avoid getting hacked:
  • Keep moving around, so that a hostile hacker can't land a hacking drone on your hull.
  • If a hacking drone does land on you, try to break the connection by modifying shield harmonics or moving out of range.
  • Try to damage/destroy their comms so they can't communicate with their hacking drone.
  • Try to damage/destroy their sensors so their target lock on you is disrupted.
  • Request assistance from allied units.
  • Divert as much CPU as you can to your hacking suite to provide as good a defence against the hacking attempt as you can.
  • If you're willing, play the minigame and try to prevent the AI from gaining access to your systems manually.
Hardenberg wrote:
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.
One simple question: Why the hell would I even turn the blasted transceiver on when I'm in hostile territory?
Well, I changed the way it works anyway (see my response to DWMagus) but to your answer your question, you may want to have a transceiver on so you can communicate with allied vessels.

Hardenberg wrote:
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.
Just effing no. That way lies madness.
Take it up with Flatfingers; he wants a full-on pause for strategic command & control. :P
Flatfingers wrote:Also, why bother with an elaborate minigame that is so utterly disconnected from the actual main gameplay? For all intents and purposes, you could use LT's standard engine and shader options to generate a "trench run" type attack scenario where you manually pilot the "virus" and try to avoid enemy "ICE"-type crafts and defense turrets. This at the very least would keep with the core skills of the LT player. Research in electronic warfare would directly translate into improvements the virus crafts flight profile, payloads and fitting options.
Yeah, you could. You could maybe write up a suggestion about that, if you want. I mean, mine tries to fit with the feel of LT by being based on the node-style UI Josh has going, whereas your idea could fit well because it's similar to the general gameplay of flying vessels about.
Hardenberg wrote:(And no, I do not condone that version, either. But it's as good a brainfart as the other one...)
Haha. Too late. :squirrel:
Hardenberg wrote:That other game with the capital "E" in its name actually has a hacking minigame since a few patches ago. It's a rather jarring affair, as you basically play a minesweeper minigame that has no correlation to the regular gameplay, and most people dislike the mechanic. That it seamlessly continues into a game of "Hungry, Hungry Hippos" afterwards and your success there pretty much determines the value of the loot you get, quite a few people were righteously pissed at CCP for the introduction of said mechanics.

I quite liked the hacking minigame, to be fair, though I didn't get to play it much.

Hardenberg wrote:It also required changes to the general gameplay; before the introduction of said game, hacking was based on a random skillcheck over time, and the sites where hackable containers were found included enemy NPCs. Due to the nature of the minigame, those were removed except for one very special case. Bottom line: Mini games and regular pew-pew don't mix.
I preferred the new system to the old way of hacking.
Post

Re: An Investigation Into Hacking

#10
ThymineC wrote:Confirmed feature for LT2 according to Josh. :D
/signed :thumbup:

But seriously, this is fantastic work. I know it's further than some of you will want to go with your computer systems, and for that, as always, we present automatic modes of control. Don't ever have to worry about it. For those of us computer geeks, this is just...straight-up indulgent, and adds a whole new game inside of a game :geek:

Won't have time for this in 1.0, but someday ;)
“Whether you think you can, or you think you can't--you're right.” ~ Henry Ford
Post

Re: An Investigation Into Hacking

#12
DWMagus wrote:When I said Augmentation 'Stealth' I meant program.

I kind of figured you were modeling after the TF2 spy. In TF2 at least, there are limits to the stealth capability; whether it's timed, and the stealth eventually runs out, or the one where it only depletes when you move. Neither of those limitations are there for this program.
Let's re-design it then. How about the Stealth has a "stealth charge" (represented by a "progress bar"-esque set of circles around its perimeter) that builds up when it's stationary and decreases a certain amount whenever it moves. Then if it runs out, the Stealth will be visible and hence potentially very vulnerable, but it will recharge again if it stays still.
DWMagus wrote:
It'd be like 2) anyway - NPCs will play just like players. However, time will pass extremely slowly in the LT gameworld while you're in codespace. NPCs shouldn't try to stall (that would lead to very boring gameplay and time passes too slowly for it to be of much use anyway)
Okay, this answers one question but creates a couple more. If we know that time passes slow enough that stalling is not a valid tactic, then that also means that NPC-to-NPC interaction hacking is incredibly quick. What happens if I'm in a fleet battle and don't realize the enemy is hacking the ships that I'm not controlling? Do I have to worry about handling multiple hacks simultaneously? Will I even know if ships other than mine are being hacked until they either explode on their own or start firing on me?
Yes, NPC-to-NPC hacking will appear incredibly quick. You'll need a functional comms system for all of your allied vessels so they can reassure each other that they're not compromised. If a vessel does get hacked, and you have functioning comms, your ship (and all the other allied ones) should immediately notice that it's hacked and behave accordingly. As for multiple hacks, I think that a hacking vessel will only be able to support one or a very few number of hacks simultaneously, because every additional controlled vessel is additional workload on the hacking vessel's computer systems. In order to maintain multiple hacks, a hacking vessel may need to allocate a lot of CPU to their hacking module, at the expense of other systems (which can make the hacking vessel itself quite vulnerable to direct attack).
DWMagus wrote:
I'm not sure, but this is a game design problem that extends far beyond just hacking gameplay. I mean, what happens if you acquire very powerful lasers? Then you could just whip your cursor back and forth around the battlefield like you're Willow Smith and dominate the battlefield just as easily. How will super-powerful components by balanced in general?
Because one takes skill. My weapons aren't going to auto-fire on any enemy in range. I still have to control my ship, and if I'm a crappy pilot, might not be able to take out someone who has weaker weapons, but can out maneuver me. I think what it boils down to, is that by tossing in this hacking, it trivializes any sort of rock-paper-scissors in every regard; whatever you have for engines, shield, weapons, etc no longer matter. Likewise, there isn't the opposite. Where is the RPS for hacking? It's all internal, but it can take over other ships' external pieces. There is no skill to use automatic hacking and automatically win against anything you're up against.
Good point, but hacking still requires skill the way I've redesigned it based on your previous post - remember, you will still need to get a hacking drone to reach my hull, which can be very difficult if I'm nimble and my shields are raised. That hacking drone will need to be aimed and launched like a regular weapon. Even then, that hacking module has an associated turret that occupies a hardpoint, where you could have had a laser or something instead. The hacking module will also drain power and CPU which could otherwise be allocated to shields, weapons, etc.

I think that becoming a very proficient hacker will make you into a glass cannon; IF you can get a hacking drone onto my hull, then you'll have screwed me over quite badly in all probability; but if I evade that and manage to dish out damage against you, you'll be more vulnerable and less able to deal direct damage back to me. Also, if hacking vessels can only support one or a few hacks simultaneously, they are not so effective at crowd-control (handling a large number of hostile units), whereas other kinds of ships might be.
DWMagus wrote:Which begs to question, what about ship size differences? Can all of a sudden a simple fighter take out a cap ship without firing a single shot just because of a bad A/V on the enemy if I play a really good hackerspace game?
Your ability as a hacker could be limited by the relative difference in computational power between vessels. If I'm flying a fighter and play a really good codespace game against a battleship, I can capture any system I want, but my ability to sustain control over the hostile unit may be severely compromised by the fact that its computers are vastly more powerful than my own. I might be able to capture its weapon systems and maintain control over them for a few seconds, in which time I could use them to deliver a really powerful shot against another hostile (which would be really cool) but not much more before I lose control.

On the other hand, I do want to be able to specialise in hacking vessels that are specifically designed to be good at hacking despite potentially being small. But specialising in this will make the ship less well-equipped for other types of gameplay, of course. :P
Post

Re: An Investigation Into Hacking

#13
CommanderDJ wrote:I like the concept of hacking, I really do (seeing as I'm a programmer), but I feel like its execution as presented here is a bit off. I guess I could go for the semi-automatic option, but the minigame seems a bit too much like... chess. I know that's not exactly constructive feedback, sorry. However, I also won't pretend that anything I've said here is more than personal preference, so take it as you will.

Addendum: I like the idea of buying modules and upgrading your hacking software and stuff like that, and I do want there to be SOME sort of manual interaction. For comparison, I liked the way Mass Effect 2 handled hacking, except for the time limit: you had to match patterns of code segments while avoiding others. I feel the time limit but pressure on the player the wrong way - there of course needs to be opposition, but it shouldn't have been an arbitrary time limit, but dependent (in the case of LT) on what hacking/antihacking software the machine we're attacking has installed/purchased. If it was something like that where you picked code segments and put them together, I think I'd like it a lot more. In a sense, I guess that's exactly what your mini-game is abstracting away, but I want it to feel like programming instead of just a minigame, or at least have that look. But like I said, just personal preference; I recognise I'm in a vastly different mindset from many of LT's future players because of the fact that programming's my field.
If you're referring to this - it looks really cool. :shock: I can't wait to be able to play video-games again. It'd probably help me come up with better ideas if nothing else. :P Heck, I might have based my own hacking gameplay on that if I'd known about it before.

And I think a large part of LT's fanbase are programmers by the way. I'm a programmer too.

Online Now

Users browsing this forum: No registered users and 5 guests

cron