Return to “Suggestions”

Post

Re: An Investigation Into Hacking

#31
Okay, here's a revised version of hacking gameplay. It draws inspiration from the following sources:
  • Behemoth's idea from a few posts back (link).
  • My expansion upon Josh's idea of harmonics (link).
  • Josh's scanner UI (link).
  • Flatfinger's revision of the scanner to display frequency-space (link).
  • My programming language idea for Limit Theory (link).
So, my idea is that you create hacking programs, but unlike the hacking programs that basically act as combat units in a turn-based combat game as I've been talking about in the OP (Warrior, Guardian, etc.), you have real programs that actually do a specific, procedural set of tasks related to hacking, which you create by either pairing systems with actions (e.g. "Modify Reactor") as Behemoth suggests, or by using a more expressive and powerful language to do more complex things such as with ViTheory.

Now, when you've designed the program, you'll need to compile it (program compilation is necessary in order to make sure it's valid and to cast it to an appropriate type of program e.g. business management plan, power/CPU allocation program, etc.). The system then determines a "complexity" measure for the program you've created. A program that involves simply extracting information from the databanks of another computer system will have much lower complexity than a program that's designed to offline scanners, hijack comms and override reactor safety protocols. You store these hacking programs until you need to use them.

So all that is done in preparation for hacking. What follows is a description of what you do when you actually want to hack someone.

Let's say that you spot a mining vessel off by an asteroid field using long-range scanners. Let's also say that you're flying a stealthy hacking vessel and figure the mining vessel might be carrying some sweet ore in its cargohold. You fly up to the asteroid field, and keep yourself hidden behind one of the larger asteroids. The mining vessel hasn't noticed you. However, as a precautionary measure, it has its shields raised to a quarter maximum capacity.

You order your computer to establish a target lock on the vessel, and then get the computer to try to crack the frequency of its shield harmonics. The computer gets your active scanners to perform a frequency sweep of the 10-100 THz range with low-intensity EM radiation, monitoring for returning signals to determine the frequencies of the harmonics. Fortunately, you discover that one region of the mining vessel's shields has a harmonic frequency of 60 THz. You select one of your hacking drones from your inventory, configure its shield harmonic to 60 THz. You take careful aim, pointing your cursor to draw a straight line through that vulnerable region of the shield and straight to a section of the mining vessel's hull. You squeeze the trigger.

The drone - no bigger than a few centimetres - is launched from a hacking drone launcher attached to one of your turret hardpoints. It sails almost imperceptibly across the distance bridging you and your victim. As it approaches the shields of the mining vessel, it squeezes some juice out of its capacitor and establishes a weak shield around itself at 60 THz, making its shields fully-synced with that region of the shield and allowing it to pass through as if there weren't shielding there at all. It touches down on the vessel's hull, latches against it, extends a small antenna, configures its transceiver frequency to 60 THz, and begins establishing a communication link back to your own computer systems. At the same time, it releases small nanobots that tunnel into the hull of the mining vessel and down into its core, where they integrate with its computer system networks and broadcast data back to the drone, which then acts as an intermediary between your ship and the nanobots. Your ship is now beginning the process of establishing a connection with the mining vessel's computer systems, all without it having noticed anything so far.

So far, this entire process has taken less than a minute.

Now, what I imagine is that the core of every computer system of every vessel and station maintains a kind of "IDCS" - identification carrier signal - which is shared among other trusted entities (e.g. drones the computer controls, allied vessels, HQ, etc.) to allow their computer systems to communicate with each other automatically. When one allied vessel or drone or whatever wishes to communicate with another entity that it trusts, it will broadcast its IDCS to that entity, and that entity can then modulate the IDCS with whatever input signal to send instructions directly to the first vessel's computer systems. Because both entities are agreeing on using the same carrier signal, they can re-convert each other's signals into a series of 0's and 1's, whereas if an entity receives signals that are modulated using a different carrier signal, it'll interpret the resulting signal as garbage (therefore avoiding the possibility that the signal will do something bad), and furthermore it will know that an untrusted entity is trying to broadcast signals to it. That'll make it suspicious.

So, when your hacking drone begins establishing a connection with the mining vessel's computer systems, it will try to discover its IDCS. This process will take some amount of time, but it will report back its progress to you. When it has the IDCS, you'll basically need to transmit your virus over, but to get it trusted, you will need to modulate the signal you send over with the appropriate carrier signal - the mining vessel's IDCS.

Now, I want you to think of Josh's radial scanner UI. Here's the link if you want to see it as you read this. Now, based on Flatfinger's suggestion (that Josh is very fond of), imagine that instead of having it display temporal-space (i.e. as a history buffer), what it actually displays is frequency-space.

Now imagine something similar to that, but instead of displaying signals being detected by your vessel, it displays signals being (or that will be) emitted by your vessel.

So basically, every bar you see in that radial UI corresponds to a sinusoidal wave of a particular frequency, right? Now, this really clever mathematician called Joseph Fourier discovered that any arbitrary periodic function can be represented as an infinite sum of sinusoidal waves of different frequencies, known as a Fourier series. See for yourself:
Spoiler:      SHOW
Image
I imagine an IDCS to be a complex, periodic signal. So for instance, let's say that your hacking drone determines the IDCS of the mining vessel to have the following waveform:
Image Now, because what Fourier said is true, you can generate a signal like that by combining a bunch of sinusoidal waves of different amplitudes and frequencies (and phases, but let's not overcomplicate things :P ). So how do you do that? By dragging bars on a radial signal generator element in your HUD. :)

The waveform I posted above can be expressed as: f(x) = 0.2cos(x) + 0.1cos(2x) +0.3cos(3x) + 0.2cos(4x)

So this waveform is composed of a fundamental frequency and the following three harmonics. Let's assume that the fundamental frequency is 60 Hz. So then the second harmonic is 120 Hz, the third is 180 Hz and the fourth is 240 Hz.

Then a workspace will show up containing a Scanner Generator UI element that looks like this:
Image
  • Up = fundamental frequency
  • Left = second harmonic
  • Down = third harmonic
  • Right = fourth harmonic
The height of each bar then corresponds to the amplitude of the cosine wave being produced at that frequency. In the diagram, I've tried to set the bar heights to match the proper coefficients of the cosine terms in the Fourier series of the IDCS, but in actual gameplay it will be up to the player to deduce these amplitudes in order to generate a signal that matches the IDCS. By raising and lowering the bars in the scanner generator UI, they will be tweaking the amplitudes of the harmonics and therefore altering the resultant waveform of the signal being emitted. They have to get it to match the IDCS in order to transmit the virus to the target computer.

I don't expect the average player to be a whiz at harmonic analysis (I suck at it myself), so what will happen is that, depending on the quality of the hacking module and the amount of CPU allocated to it, it will narrow down the ranges in which it calculates the harmonic amplitudes to reside within:
Image I spoke about program complexity earlier. The more potentially dangerous or exploitative your virus is, the more complex it is, and so the more code it likely consists of. The more code it consists of, the longer it will take to transmit it to the other computer, right? So to transmit the virus, you will need to keep your signal generator honed at the other vessel, and making sure that its generating a carrier signal that matches the victim's IDCS. The more complex the virus, the longer you will need to sustain this for in order to successfully transmit the virus.

However, the other vessel will have automatic security systems in place, and these will (among other things) continuously and gradually alter the waveform of the IDCS over time.

So let's say that after a while, the waveform changes to this:
Image This waveform corresponds to the Fourier series: f(x) = 0.2cos(x) + 0.5cos(2x) +0.4cos(3x) + 0.2cos(4x)

So now, your signal generator UI may look like this:
Image Let me explain what's happening here:
  • The green box shows where you would have the harmonic matched very close to what it should be. Keeping the amplitude of that harmonic in that range is what you want.
  • The orange box, which is always wider and encompasses the green box, shows the range at which the harmonic is close but not quite within the right range. Your virus transmission rate will decrease. For instance, if you're controlling four harmonics, and one of them is in the orange zone, your virus transmission rate might be 75% of optimal. If two out of the four are in the orange zone, it might only be 50% of the optimal rate.
  • If the amplitude of a harmonic is outside of this range (shown by a red circle), then that means it's pretty far off where it should be, and the victim computer system will start to get suspicious. The more harmonics are in the red, and the longer they stay there, the greater the risk that your hacking attempt will be detected by the victim computer system.
So in general, what you'll be trying to do is keep your harmonics in the green zone, but those zones will continuously change as the other vessel automatically changes its IDCS over time. The rate at which the IDCS changes will be dependent upon the quality of the network security systems the mining vessel has and the amount of CPU allocated to it. However, your own computer systems will try to do what they can to help, and depending on the quality of your own hacking module and the amount of CPU allocated to it, you will see your harmonics slowly drift towards the correct values even in the absence of your input. However, this is only intended to assist your own efforts, and this drifting process will often not be adequate to keep all of your harmonics in the green or even in the orange at all times.

Josh likes the idea of being able to do things manually and automatically, and this offers a kind of sliding scale of manual to automatic, depending on how much CPU you allocate to your hacking module. The more CPU you're allocating to the hacking module, the better it will assist your efforts to keep the harmonics in check, and the less time and effort you will need to spend making corrections. This means that a hacker with a high quality hacking module and a lot of CPU allocated to it may be free to do other things and only periodically check back to the hacking module to make minor adjustments.

So if you keep it so that your emitted signals matches the IDCS of the target vessel, it'll be able to transmit the virus over to the target system. You'll see a progress bar, and when that hits 100%, the virus will have been fully transmitted and take effect. Like Behemoth said, the amount of time the virus will remain active will negatively correlate with its potency and the complexity of what it's trying to do, to keep things in balance.

I should point out that I've been talking this whole time as if a vessel only has one IDCS. It doesn't. A vessel will maintain a set of IDCS's, some more complex than others, and these IDCS's grant trusted vessels different amounts of control over the vessel's own systems. For instance, a vessel might maintain a simple harmonic just for low-priority, peripheral systems, medium-complexity IDCS's for things like databanks holding fairly important data, and perhaps scanners, and highly-complex IDCS's for things like reactor-control systems, weapon systems and life support. This will mean that if you're trying to transmit a virus that extracts basic data, you may only need to worry about matching an IDCS with four harmonics. If it's controlling sensors, it might be six harmonics. If it's controlling a reactor, it might be ten harmonics that you need to worry about.

One last point that matters more to immersion than gameplay - the actual waveforms and harmonics are meant to be interpreted as abstractions for vastly more complex waveforms. Where the player has to deal with four harmonics in gameplay, you can imagine that the actual waveform might be composed of 4 million harmonics. This is because even the crappiest computer today would easily be able to deduce the Fourier series of a waveform based on just four harmonics.

Going back to the mining vessel example quickly, you will have designed and compiled a fairly low-complexity "open cargohold" program, matched a pretty simple IDCS that the vessel uses to grant trusted entities access to its cargohold and other systems of a similar security clearance level, transmitted your virus over in no great amount of time, and then as soon as the virus is transmitted, the miner's cargohold will pop open. You fire up your engines, swoop right past the miner and channel all of his cargo into your own hold. You kick your H-drive into cruise mode and fly away into the night. Well done for successfully looting a miner without having to kill him. What a nice guy you are! :thumbup:

So, why all this?
  • It's far less mini-gamey. Really, it'll feel pretty similar to scanner gameplay, the way Josh showed it in the last video. But instead of detecting signals and interpreting bars on a radial UI, you'll be emitting signals and controlling the bars on a radial UI.
  • It's more appropriate for an action game. You won't be popped into a tower defense game or anything like that. You'll be orientating your vessel in the right direction, making sure you remain hidden, etc.
  • There's no need to run the game in slo-mo. Time will pass normally while you're doing this. If you're doing this in the middle of a battlefield, you'll probably want allies to help keep the heat off of you as you hack.
  • It still allows for the possibility of upgrades, both offensively and defensively.
  • There are precautions and steps that can be taken by both you and other agents to better defend against being hacked.
  • It's a hell of a let less time-consuming.
  • It fits the feel of Limit Theory a lot better.
  • It's not OP - like Behemoth suggested, the more powerful a virus is, the shorter it will remain active for.
  • It's honestly not as complicated as it may sound, what with all that about Fourier series and stuff. Just make sure the bars stay within the green boxes and keep your ship pointed in the right direction.
  • It's simpler for Josh to code.
Last edited by ThymineC on Sun Feb 09, 2014 7:25 am, edited 1 time in total.
Post

Re: An Investigation Into Hacking

#32
First off, let me say you had me at Fourier Transforms (it was actually one of my favorite pieces in my major to deal with and was incredibly nifty).

Second, I like this interpretation much better for gameplay.

Last, when you started talking about stealth, I started thinking about some other things. Since you mentioned TF2, it sounds like we could abstract the idea of hacking to be similar to the spy class on TF2. Get in close, but can do massive 'damage'. Just by adding the drone, you've suddenly made it much more in-line with the game and it 'feels' much more cohesive to everything else. You're adding skill and you're not making it an 'I win' button.

Definitely needs a little tweaking but I can't put my finger on it. Either way, I like where this is going. :thumbup:

P.S. You should still make that other game, otherwise I might be tempted to. :think: :wave: :D
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

#34
I'm always a fan of treating "that's impossible" as fun design challenges. :) So what about this notion that a hacking game and fun tactical action are incompatible?

Honestly, I share that view... but maybe that doesn't require dumping the idea of a hacking subgame entirely, or relegating it to a crew-operated mechanic.

What about hacking as a purely pre-combat activity, as Thymine implies in the first part of his updated suggestion?

If you happen to be in stealth mode and you spy a target, you'd get to try dropping some devious payload into one of their ship's subsystems. (Option A: a hack is a one-time deal that is always detected. Option B: you can keep hacking their subsystems until they finally notice the effects of your intrusions.)

Once you're detected, hack time is over and you're in standard flying-and-shooting tactical mode, probably because they're pissed and are eager to unleash flaming death in your direction.

Assuming the hacking mechanic itself is fun, would this structural wrapper address some of the concerns that hacking would be a bad fit for the action part of Limit Theory?
JoshParnell wrote:If someone wants to try to design a "real" hacking subsystem, e.g. having some kind of unix-like terminal and having to write / run programs, try to gain shell access on the enemy ship, search for OS vulnerabilities, deploy exploits, etc....feel free :) I'd love to read a design doc for that, but I have a feeling it would be rather difficult to make it approachable for the general gaming population. Just a feeling though!
Well, there's Quadrilateral Cowboy....
Post

Re: An Investigation Into Hacking

#35
I like the revised proposal.

I feel like it would be much easier to integrate into the other gameplay of LT than the original proposal - like it fits the whole feel of the game better.

I don't know, it just grabbed my attention in a way the original proposal didn't.

Now, is there a way you see the player being able to defend against the mechanic (maybe a "Scramble IDCS" button you can mash when you think you're being hacked?)
- The Snark Knight

"Look upward, and share the wonders I've seen."
Post

Re: An Investigation Into Hacking

#37
Just_Ice_au wrote:Now, is there a way you see the player being able to defend against the mechanic (maybe a "Scramble IDCS" button you can mash when you think you're being hacked?)
Several ways.
  • Precautionary (pre-detection):
    • Allocate more CPU to your network security infrastructure. That will allow the computer to use more complex IDCS's that vary faster.
    • Allocate more CPU to your antivirus software. That'll increase the odds of detecting a virus being transmitted.
    • Allocate more CPU to sensors. This will also increase the chances of detecting the initial frequency sweep (if that happens).
    • Switch to "manual" scanning mode (like we saw in Josh's latest dev update). You may spot patterns of incoming signals that are suspicious and worth investigating, but the computer might not think to notify you about if doing automatic scanning.
    • Keep shields raised, allocate more CPU to them, and make its harmonics use a more complex profile. This will mean a hostile will need to take into account your shield harmonics, and it's likelier to find this task more difficult the more complex your harmonic profiles are.
    • Keep yourself moving - the more you move about, the harder it will be for a hostile to:
      • Land a hacking drone successfully on your hull
      • Keep their signal generator pointed in the right direction when transmitting the virus
  • Reactionary (post-detection):
    • Allocate as much CPU as you can to the network security infrastructure. This will try to scramble the IDCS's as fast as possible.
    • Allocate as much CPU as you can to your antivirus to render the virus innocuous.
    • Manually adjust your shield harmonics to attempt to cut off the link between the hostile and its hacking drone.
    • Rotating your ship to try and cut off the communication link.
    • Move your ship to try and get it out of range.
    • Launch drones to scour your hull and destroy the hacking drone.
    • Find, scare off, damage or destroy the hostile.
    • Notify allies.
    • Notify the authorities in the system and hope they respond quickly.
    • Before the virus takes effect, pre-emptively cut power to systems you're worried the virus might affect.
      • Note: some viruses can be programmed to automatically reroute power to the systems they wish to affect, but at the cost of much higher complexity and the need for the hacker to match the IDCS that regulates control over the reactor (a high-complexity waveform). The virus complexity is higher because it will need to control reactor power distribution. The only defense against this is to stop the reactor producing power completely, which will kill power to all systems (unless the virus has gained full control over the reactor).
    • After the virus takes effect, cut power to systems that you see have been compromised.
      • Note: some viruses can be programmed to maintain the current power distribution to the systems they affect, preventing the victim from modifying the distributions to those systems after the virus has taken effect. This comes at the cost of considerably higher complexity (but less so than in the case above) and the need for the hacker to match the IDCS that regulates control over the inter-system communication infrastructure (a moderately high-complexity waveform). The virus complexity is higher (but not quite so high as above) because it will need to block access of the victim to the reactor power distribution to the affected systems (although it won't need to control the reactor itself). The only defense against this is to stop the reactor producing power completely, which will kill power to all systems.
Hacking will probably be in favour of the hacker before detection, and very much in favour of the entity getting hacked after detection. The hacker's aim will be to try to remain a low profile as well as possible, while the victim - if he's worried about getting hacked into - will try to remain as alert as possible.
Post

Re: An Investigation Into Hacking

#38
Also, an analysis of how the revised hacking gameplay would appeal to different types of players:
  • Uninterested players will not have to worry much about hacking at all most of the time. This is because ships will come pre-installed with stock antivirus and network security systems that will provide a basic form of defense against hacking. For instance, I don't worry much about hacking or being hacked when I'm using my computer; I just have a basic antivirus installed (Avast!, Windows Defender, etc.) and most of the time that's fine for me. It only really matters if I'm being careless, or if I encounter a fairly proficient hacker.
  • Tactical players will enjoy having a hacking program designed, compiled and ready to use. They'll be the ones sneaking around the victim or the battlefield, lining up their hacking drone launchers, initiating the transmission and keeping the signal generator pointed in the right direction and the waveforms properly matched. This is all heavily action-oriented, heat-of-the-moment play.
  • Operational players, such as those in command of a squadron or fleet, will be treating their subordinate vessels as resources or tools to be used for specific purposes and to assist each other in achieving a set of short-term objectives. Hacker vessels will be part of their toolset, and they will produce orders such as "hack that capital ship over there to disable its shields for half a minute while these bombers go and take out its missile launchers". These people don't care about the how so much as the what.
  • Strategic players, such as those involved in controlling multiple fleets or operating their own empires, will be looking at the big picture. They may be interested in having ships capable of hacking for very specific purposes. They may recruit R&D labs or negotiate with other agents/factions to acquire the hacking programs most suited to their strategies, or may enjoy designing those programs themselves to have them maximally tailored to their requirements. They'll also be scouring the market, using research modules or research labs, or negotiating with other agents/factions to acquire good hacking modules or even entire hacking ships. They'll basically be in charge of all of the logistics associated with developing hacking programs, modules and vessels and getting them to where they need to be.
Post

Re: An Investigation Into Hacking

#39
Hi everybody!

My first post :shock:
Here are some random ideas about hacking (edit: now hidden, because maybe a bit too random)
Spoiler:      SHOW
  • Hacking mini-games could have random/procedurally generated game mechanics. So the player is always surprised with a new puzzle/task, sometimes with time running out. They could be variant in difficulty - depending on ship size and strength of effects. It needs to look somehow technical and futuristic and it could require logic / problem-solving, rapid smashing of different keys, short-term memory, finding something hidden etc ...). It could also be designed to be impossible in some cases, and it is up to the player to notice that. I think the possibilities are endless here, but I don't know if its really possible to program something like that. But at least there could be a variety of different mini-games for different types of hacking. ThymineC's Fourier-Transformations and turn-based mini-games could both be included, theoretically.
  • It would be fun to hack a ship, jump into cockpit view of that ship and fly it against the nearest asteroid :twisted: (because this is overpowered, the chance of gaining full control via hacking, even for a short period of time, should be < 1% or so)
  • Hacking could be used to acquire information about ship strength, weapons, cargo, specific weaknesses etc. - to see if its a good idea to fight and maybe plan how to fight. This kind of hacking should - if successful - go undetected, so you can still surprise your opponent; but: regular scanners could also be able to acquire these info - maybe not for all ships?
  • concept of "system compatibility": some ships are so alien, they can't be hacked. I think combat should be more about flying around and shooting at stuff, not hacking. So maybe, when scanning a ship, in many cases you only get a marginal note stating that the computer system isn't compatible, so you probably can't hack it. But if it IS compatible, it also means that there is a chance of the NPC trying to hack you. So you should maybe activate some kind of "cyber defense system" - which should also have some disadvantages, like not being able to go to cruse mode and high energy demand.
  • hacking errors: confusing or funny error message, or some kind of "blue-screen" in your HUD

If we don't want mini-games (because they have nothing to do with "real hacking", or because any computational task like Fourier-Transformations could be done fully automatically by the computer, or because they "break immersion"), we could leave the actual hacking to our ships CPU, and the role of the player would only be to make tactical decisions/risk management:

For example, the player scans the ship, and gets a list of "hacking opportunities" generated by the CPU, somehow mapped to a holographic image of the opponents ship (with lines connecting each procedure to the system(s) it effects); every "hacking procedure" could be listed with the following values:
  • strength of effect (e.g. 30% energy reduction)
  • probability of success (hacking might not be successful, even if it remains undetected)
  • speed (time before any effect occurs)
  • endurance (time the effect(s) last)
  • stealth (probability of being detected, even before any effect occurs; if you are detected, the enemy might send extra energy to its cyber defense system, attack you with regular weapons or try to escape)
  • vulnerability to counterattacks (if stealth has failed)
  • energy requirement of your cpu
  • maybe more - don't know - gets quite complicated
  • ... and a fancy name (like "brute force attack on node 253.C" or "medium-size nanobot key logger" or "exploiting security hole 21574b in secondary shield generator"), the name and all values could be procedurally generated and somehow balanced.
  • There could also be hacking procedures that have no direct effect, but - if executed successfully - enable (multiple) new hacking procedures (e.g. "fake subspace antivirus update" --> enables subsequent virus intrusion of Virus A, B or C); multiple "hacking steps" could also be presented in a (node-based) grid - alongside the holographic image of the NPCs ship (hacking grid similar to eve, but 3-dimensional)
  • If you are being hacked by an NPC (hacking still in progress, but detected), there can be additional hacking procedures available for you (because hacking makes vulnerable - see above)
The player then chooses one or more hacking procedures, and activates them;
then he sees some kind of status bar for each of them, somewhere (small) on the border of the HUD; there is a countdown showing the time until the effect will occur
  • during the countdown, the values can still change, and the player can cancel the hack(s) if they seem less and less likely to succeed (or take more time than expected, or if stealth goes down and your vulnerability goes up), and make new attempts instead
  • If above values (strength of effect, probability of success etc.) aren't fixed, but instead have a defined range (e.g. speed 30-10 sec., strength 30-40%), and influence each other (e.g. higher speed reduces strength, because the hack is more "superficial"), the player could adjust them during the countdown
  • So for example, if the player is impatient, he can increase the speed, so the countdown jumps from 30 to 10 sec., but that also means the effect will be - for example - less powerful, less lasting, and/or more likely to fail. Also, some graphs could show how these values are all connected, and the player could adjust them (in the predefined ranges) to adept to his tactics, maybe even during fighting (so yes, this is developing into some kind of mini-game)
The above "choose hacking procedure, activate and change values"-mini-game could even be combined with another mini-game or with procedurally generated mini-games:
Some of the hacking procedures have mini-games (indicated with an icon in the list/map of procedures to choose from), and others don't.
So if you have no time for mini-games (because mini-games don't stop time, and you are in the middle of a fight), you choose a hacking procedure that doesn't require any, activate it (quickly, in mid-flight) and just let it sit in the border of your HUD. But if you have time and are in the mood for it, you choose a hacking procedure that requires a mini-game, and at some time during the countdown (maybe even multiple times, or every time you adjust some of its values), it pops up. (edit: NPCs forcing the player to defend themselves in mini-games would still be problematic)

Of course, I don't expect any of these things to be implemented, its just fun to fantasize. I don't even "need" any kind of hacking in LT.
ThymineC's Fourier-Transformations are probably more practical - but I had to post this
Last edited by Apollo13 on Tue Feb 11, 2014 7:54 pm, edited 10 times in total.
Post

Re: An Investigation Into Hacking

#40
Hardenberg wrote:The suggestion of a pausable mode for the RTS game in that specialized case makes sense - it's a crutch for the player, since he, as opposed to the CPU, is limited to giving out one order at a time, so I'd approve of that.


I disagree. That is one of my biggest complaints. Why is hacking special that it gets a slow time? If the player is supposed to be controlling it, then he should be controlling it realtime, instead of getting it as an essentially free action. Can I pause the game to aim my guns, pilot my ship, give orders, etc? If no, why is hacking special? Because the player isn't fast enough? Then the player shouldn't be doing it.

Even more importantly, how can I defend from a hacking attempt with non hacking tactics(fighting or running) if the hacking takes place in an abstracted time frame? Could I ram straight into a hostile fleet, engage my insta hack, and take over their dreadnought?


Speaking of hacking as a whole, I'd much rather the functionality of disabling ships and equipment belong to the ships themselves, for 3 reasons. 1st is just plain old personal preference, but that can be ignored. 2nd, it is inherently balanced, since disabling weapons take the place of normal weapons, whereas you could presumably have a well armed hacking ship, since the hacking ship only needs computers. 3rd, you can see it happening in game, realtime, and understand what is going on. If I run across 2 NPCs in hacking battle, I have no idea what is going on. If I see one is blasting the other with precision lasers to take out its shields, I know exactly what is going on.
Post

Re: An Investigation Into Hacking

#41
CutterJohn wrote:Speaking of hacking as a whole, I'd much rather the functionality of disabling ships and equipment belong to the ships themselves, for 3 reasons. 1st is just plain old personal preference, but that can be ignored. 2nd, it is inherently balanced, since disabling weapons take the place of normal weapons, whereas you could presumably have a well armed hacking ship, since the hacking ship only needs computers. 3rd, you can see it happening in game, realtime, and understand what is going on. If I run across 2 NPCs in hacking battle, I have no idea what is going on. If I see one is blasting the other with precision lasers to take out its shields, I know exactly what is going on.
I guess you're referring to the original post and not the revised proposal that I posted afterwards.
Post

Re: An Investigation Into Hacking

#42
CutterJohn wrote:
Hardenberg wrote:The suggestion of a pausable mode for the RTS game in that specialized case makes sense - it's a crutch for the player, since he, as opposed to the CPU, is limited to giving out one order at a time, so I'd approve of that.


I disagree. That is one of my biggest complaints. Why is hacking special that it gets a slow time? If the player is supposed to be controlling it, then he should be controlling it realtime, instead of getting it as an essentially free action. Can I pause the game to aim my guns, pilot my ship, give orders, etc? If no, why is hacking special? Because the player isn't fast enough? Then the player shouldn't be doing it.

Even more importantly, how can I defend from a hacking attempt with non hacking tactics(fighting or running) if the hacking takes place in an abstracted time frame? Could I ram straight into a hostile fleet, engage my insta hack, and take over their dreadnought?
I love being misquoted, really. The above comment was regarding a statement that Flatfingers suggested a pausable command mode (for I, too, complained about the forces time dilation) for the RTS command interface, which would be a deliberate decision by the player to pause the gameplay, AS OPPOSED TO THE SUGGESTED FORCED SLOWDOWN IN A HACKING EVENT.
And I stand by that decision - it's a frelling single player game, RealLife™ happens and I see no harm in giving the player the option to a) pause the game if and when he wants to and b) issue orders while paused. It's a crutch, yes, but given the intended scale, doing everything in realtime while having to wrestle with the user interface is a distinct and annoying disadvantage.

I'm still strictly against any slapping any kind of FORCED slowdown/time dilation one the player, no matter how noble the reasoning behind it. That stuff is annoying. Loss-of-Control type annoying.
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

#43
Hardenberg wrote:I love being misquoted, really. The above comment was regarding a statement that Flatfingers suggested a pausable command mode (for I, too, complained about the forces time dilation) for the RTS command interface, which would be a deliberate decision by the player to pause the gameplay, AS OPPOSED TO THE SUGGESTED FORCED SLOWDOWN IN A HACKING EVENT.
Apologies, I misread.

And I stand by that decision - it's a frelling single player game, RealLife™ happens and I see no harm in giving the player the option to a) pause the game if and when he wants to and b) issue orders while paused. It's a crutch, yes, but given the intended scale, doing everything in realtime while having to wrestle with the user interface is a distinct and annoying disadvantage.
Sure. My concern was not so much that the hacking orders could be given while paused, but that the hacking orders were carried out while paused.
Post

Re: An Investigation Into Hacking

#44
Here are some ideas about what could happen if the player gets hacked by NPCs.
This is unrelated to the actual hacking gameplay (e.g. mini-games) - I'm only talking about the resulting effects:
Spoiler:      SHOW
Effects could be temporary, or persistent (if persistent: repair needed at a station, or maybe repair via mini-game).

control: (= game over?)
  • NPC controls one, multiple or all ship functions
  • (sub-)system disabled
energy:
  • max. energy (of specific system, or in total) reduced
  • energy distribution changed
  • energy (-distribution) changes periodically (like engine stutter or a flickering shield)
  • thrusters or weapons become less responsive
flight: (too annoying?)
  • some of the RCS thrusters malfunction: they get activated randomly or continuously, so the player needs to make course corrections
  • RCS thrusters don't work on one side: e.g. to move (edit: yaw) "left", you have to roll 180° and then use the thruster on the other side
  • inverted flight control (up/down left/right swapped)
  • assignment of keys changes, and is locked in the game options; gets back to normal automatically after some time
weapons:
  • weapon(s) fire randomly / in random directions
  • auto-aim gets disabled
  • turrets get stuck - to aim the player now needs to move the whole ship (maybe impossible)
  • a missile (or swarm of missiles) is reprogrammed to turn around and target its origin
sensors:
  • hacked sensors pick up false signals of approaching enemy ships, to scare you away or to confuse you
stealing:
  • NPC silently installs malware on players ship, that transfers a small amount of credits to him, every time you buy something from a station
  • NPC steals a ship the player currently isn't using (so better park it in a station?)
HUD: (this I like)
  • HUD "crashes" and needs to reboot
  • HUD and/or board computer gets flooded with randoms numbers, symbols or strings of code
  • existing words in HUD get replaced by random alien-symbols (maybe some kind of "alien translator malfunction")
  • all numbers (like speed, distances, energy levels) are converted to binary
Post

Re: An Investigation Into Hacking

#45
I would like to propose a simplified alternative to that which Thymine is suggesting in this thread. This is still very rough and a work in progress so feel free to offer ideas as to how I can better the concept.

Computers form the backbone of the Limit Theory universe. Every ship, station, and colony depend on computers for day to day interactions. Information is stored in one of three kinds of files. Log files which are used to record interactions, system files which contain data on the systems a ship or station possesses, and normal files which consists of data about physical goods such as amount of cargo, assembly chips and blueprints on the vessel.

Log files keep track of interactions within the universe. These interactions range from general communication data, to sensor data about a newly discovered wormhole. These log files are the easiest and most available data a hacker has access to. In general Log Files simply record what events have taken place between one ship and the rest of the world. They are usually stored in plain text and only accessed by individuals to verify that a particular task has been completed.

System files contain data about a ship's systems. This data includes IFF, weapon, shield, and engine status as well as hull strength and power distribution data. Add-on programs, such as scanners, are also stored as system files. Some of these files are more difficult to access than others, but all are difficult to modify without detection.

Normal files contain information about a ship's cargo including blueprints, assembly chips, its scanner data, and other data not covered in the two above file types. Normal files are easier to access and modify than system files but are also the easiest to detect changes within.

Colonies and stations may contain databases which may contain criminal, bank, and stock data. This data is stored as a series of normal files which is usually protected by several defensive programs.


File protection classification:

Class 0: Data is available for all to see once a connection is made.
Class 1: Data is password protected.
Class 2: Data is password protected and a monitor program is installed on the system.
Class 3: Data is password protected, a monitor program and firewall are installed on the system.
Class 4: Data is password protected, a monitor program and firewall are installed on the system and at least one proxy computer separates the targeted computer from the end user.

Most ships use class 2 security systems which uses the monitor program to trace the hacker the moment the password begins being hacked. The trace continues for the duration that the hacker is on the system. If the trace completes the hacker's ship is identified and flagged as hostile by the monitor.


Hacking consists of using various programs to copy, delete, or modify data. There also exists programs which are used to bypass proxy servers and firewalls.

Firewalls prevent unauthorized users from hacking a password field which allows viewing access to all other file types.

Proxy servers disallow editing, copying, and deleting of all file types on the targeted system.
Image

Online Now

Users browsing this forum: No registered users and 11 guests

cron