Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Kyzrati]

This has been a hot topic on the chat, and it would be more valuable as a forum discussion where we can get a wider variety of opinions and leave a better record of any arguments.

There is a potential balance issue with the so-called "hackware snowball" being a rather OP strategy for those who can get it rolling. As early as half way through the game we have Cogminds stacking half a dozen or more powerful hackware, essentially owning terminals and, more importantly, other robots.

To start off the discussion, here are some of the potential approaches that have come under varying levels of serious consideration:

• Hackware integrity is very gradually lowered over time as a result of successful hacks. (Not as easy to explain thematically, but that's not too important here.)
• Increase mid/high-tier hackware ratings, thereby raising the depths at which they can be fabricated (fabrication being the most common way to obtain hackware).
• Using multiple hackware has diminishing benefits (i.e. each additional hackware's effect is reduced more than the last). (This puts a general cap on what is possible and makes high-end hacking that much easier to balance.)
• Hacking gets harder across the floor as more of it is successful, essentially introducing another form of clock. (This one's pretty in theme.)

Note that this is mostly with reference to robot hacking, because machine hacking is pretty balanced as is, with much less harm in allowing god-tier hackers to practically own the machine network.

That it's focused on robot hacking might suggest some alternative solutions:

• Make some of the very high tier special robots non-hackable (as Behemoths are now). (<-already planned for Alpha 13)
• Add at least one more higher difficulty tier for robot hacking. (<-already planned for Alpha 13)
• Put a hard cap on overload and assimilation chances, regardless of hacking capabilities.

I don't like to take power and options away from the player, and do like the idea that players can become extremely effective hackers, but it seems a little overboard when Cogmind can destroy or assimilate practically anything without worry.

In any case, the response to this will probably be gradual, starting with the adjustments most directly targeting the combat-hacking strategy, but maybe some of you have other input?

Edit: Several of these changes, most importantly including the hackware progression nerf discussed later, were made in Alpha 13, as detailed in the release notes.

[mindreader]

Not a big fan of those changes.  It feels really arbitrary.

We've found that shooting is too powerful.  We've some alternative solutions:
* Make some more robots unshootable.
* Make high end robots that are still shootable more difficult to shoot at.
* Put a hard cap on shootability, guns that exceed this limit will not shoot.

I personally have never been able to snowball.  It is all I can do to get more than three piece of hackware in place.  I feel like it is only people who are good at owning the game that make this work as it currently stands.

That said I'm only really in favor of either diminishing benefits or a per floor hacking clock.

[Vectis]

Another option would be to cause datajacks to lose durability on use.

I only recently considered serious attempts into hacking, and I've always considered it a matter of the machine network and hostile manipulation first and foremost. When I first considered datajacks, I didn't look at it as a "combat situation option" hardly at all; instead, I saw "ally making machine." Given the extra amount of information and map control I had due to hacking the machine network, I saw allies as a sort of extension to that specific metagame. They could be used as distractions, scouts, room cleaners, escape options, sentries, so on and so forth; at the very least, it was quite different from the firepower I would consider them in combat builds.
The problem I ran into with datajacks, though, was that it was nearly impossible to reliably use them early on. As I practiced hacking builds more, I would favor melee weapons over datajacks in nearly every case. After reading the Discord chat, though, I saw that datajacks seemed to be entirely ignored in every instance other than late game snowballing. In my understanding, they are entirely unappealing to players without detailed knowledge of the snowballing process, yet a game breaking one-size-fits-all strategy for those who do. Perhaps this could stand to be leveled out.

Hacking builds already have access to a reasonable strategic combat option: regular weapons. Datajacks don't need to be kept as a sustainable source of power; on the sliding scale of short term verses long term, it would seem out of place if they were. If the emphasis was taken off of their relevance as a weapon and shifted towards something which becomes more important in the information game, the hacking snowball problem could be solved without sacrificing the novelty of the build. And best of all, machine hacking (which in my experience is spot on  ) would remain unscathed by the re-balancing!

As far as details go, datajacks could take a number of forms. What makes sense most intuitively to me is a more reasonable chance of hacking success with a very limited number of uses. This would force players to decide whether or not an encounter warrants their "emergency" datajack, for one, which would turn their use into a tactic rather than a strategy. Furthermore, it would provide fledgling hackers (Perhaps -8 onwards) with additional tactical options. A valuable "charge" could be used on an excavator, or it could be saved for an emergency. Cogmind could make an attempt to assimilate an isolated Warden to provide limited security or escape options. And finally, late in the game, an assimilation-based attack on research would be impossible to pull off regardless of hacking suite snowballing, returning those floors to a more reasonable balance. This could prove a far more engaging experience for hackers than the late game steamroll.

Another element of robot hacking is the varying difficulty between robots. A serf, for instance, serves an entirely different purpose than an administrator, and a hunter serves a different purpose than a warden. To stop the weaker robots from being devalued, perhaps more difficult robots could require more durability instead of being more difficult to hack. This would provide more options for Cogmind while balancing every robot assimilation decision it (they?) makes: Four serfs could be argued to be just as valuable as one warden.

Hackware could interface with a limited-use datajack in an interesting way too. System shields could catch up to their more popular brethren, hacking suites, by allowing additional uses of datajacks. Allowing this would also emphasize their relevance to hacking in particular over other types of builds.

The biggest problem I see with this sort of implementation is that it would go against Cogmind's limited-consumables approach. If datajacks were turned into expendable candies to be stockpiled while being readily available, that could cause tedium issues of its own. Still, it would be less tedious to manage datajacks than hackware. I could imagine the frustrating hackware-fabricating rat race continuing even if they started to lose durability over time.

Spoiler (click to show/hide)

All of this being said, there's a lot of spoilers involved with the hacking metagame which alter my perception of it a bit. While I've found some unauthorized hacks, like Decoy and Overload, there are many more I'm staying away from until I discover them in the game. Botnet, detonate, and the one that acts like a sensor array are all very good examples of seemingly important hacks which don't show up in my games. (I'll find the buggers ANY DAY NOW  ) Likewise, the lore provides a great deal of insight into the information game. The most valuable thing I took away from Warlord, for instance, wasn't the trojans but the description of squad dispatches and garrison functionality. There also may be more to hacking that I don't even know of. While a lot of this doesn't have to do directly with robot hacking, that's my background as far as that entire aspect of the game is concerned. Perhaps the current state of datajacks make more sense given some spoiler knowledge. And besides, the machine network and robot hacking are closely related, since they come from the same build archetype.

Disclaimer: I haven't... Well... Won, per say. I still have a lot of the game to figure out. My perception of the "way things work" is likely a bit distorted, is all: My current understanding can only get me as far as -1.

[zxc]

Great post.

I wonder if perhaps

Make some of the very high tier special robots non-hackable (as Behemoths are now). (<-already planned for Alpha 13)
Add at least one more higher difficulty tier for robot hacking. (<-already planned for Alpha 13)

is enough for Alpha 13, and then we can reevaluate?

[Kyzrati]

Not a big fan of those changes.  It feels really arbitrary.

Changes are only intended to affect the late game, because two of the best players have found a strategy that works to basically become invulnerable (plus it's possible to get as much hackware as you want around mid-game). It would be nice if the combat hacker approach remained viable but also challenging.

There's no need to have any significant impact on early or mid-game hacking.

Another option would be to cause datajacks to lose durability on use.

Heh, one of the best Datajacks in the game actually does that

That type of limitation is also where the extremely high matter consumption comes in for Remote Datajacks, and it's one of the best limitations that works pretty well as is. Giving all melee Datajacks a similar limitation could be effective--hadn't thought of that one yet.

Of course it's possible to circumvent this via fabrication...

The problem I ran into with datajacks, though, was that it was nearly impossible to reliably use them early on.

This is certainly true. By design they're no so useful when you first find them, at least not for combat purposes.

In my understanding, they are entirely unappealing to players without detailed knowledge of the snowballing process, yet a game breaking one-size-fits-all strategy for those who do. Perhaps this could stand to be leveled out.

Right, so that's what this process is aiming to do.

Hacking builds already have access to a reasonable strategic combat option: regular weapons.

This is actually not quite true, because dedicated hacking builds will only ever have their first two weapon slots, which is insufficient for mid/late-game engagements. They need to either avoid hostiles entirely, hack robots to destroy them, or get allies to do that for them. Combat with only two weapons keeps Cogmind at a disadvantage (except in special circumstances, of course, like builds that can massively buff their two weapons via utilities, but those are outliers).

As far as details go, datajacks could take a number of forms. What makes sense most intuitively to me is a more reasonable chance of hacking success with a very limited number of uses. This would force players to decide whether or not an encounter warrants their "emergency" datajack, for one, which would turn their use into a tactic rather than a strategy. Furthermore, it would provide fledgling hackers (Perhaps -8 onwards) with additional tactical options. A valuable "charge" could be used on an excavator, or it could be saved for an emergency. Cogmind could make an attempt to assimilate an isolated Warden to provide limited security or escape options. And finally, late in the game, an assimilation-based attack on research would be impossible to pull off regardless of hacking suite snowballing, returning those floors to a more reasonable balance. This could prove a far more engaging experience for hackers than the late game steamroll.

I like the premise, but what about fabrication? Or maybe it's just a case of balancing it so that even an inventory full of datajacks will have sufficiently limited uses to not be worth taking up so much space just for that.

Another element of robot hacking is the varying difficulty between robots. A serf, for instance, serves an entirely different purpose than an administrator, and a hunter serves a different purpose than a warden. To stop the weaker robots from being devalued, perhaps more difficult robots could require more durability instead of being more difficult to hack. This would provide more options for Cogmind while balancing every robot assimilation decision it (they?) makes: Four serfs could be argued to be just as valuable as one warden.

Hm, another interesting proposition... I like the idea, though this would mean that hackware would no longer play a role (or as big a role) in robot hacking, which is kinda unfortunate!

Hackware could interface with a limited-use datajack in an interesting way too. System shields could catch up to their more popular brethren, hacking suites, by allowing additional uses of datajacks. Allowing this would also emphasize their relevance to hacking in particular over other types of builds.

Oh I see, so you did connect it here... Yeah, this is sounding neat

About your spoilered comments, I wouldn't worry too much about secrets/lore you haven't discovered yet impacting your opinions on this topic. All of that stuff really has to do with machine hacking, while robot hacking is overall a much simpler affair that is laid bare through your first interactions with it.

Excellent input, Vectis!

I wonder if perhaps

Make some of the very high tier special robots non-hackable (as Behemoths are now). (<-already planned for Alpha 13)
Add at least one more higher difficulty tier for robot hacking. (<-already planned for Alpha 13)

is enough for Alpha 13, and then we can reevaluate?

This is what I've been thinking, yes. The intention has been to make any changes gradually, though the OP lists a lot of the possibilities we were talking about. And since the issue is fairly isolated, even just those two changes could make a significant difference to the late-game combat hacker (especially depending on how far I go with it).

[zxc]

A slight bump in the difficulty of acquiring hackware schematics and fabricating them could be good too, maybe a +1 rating to hackware? Or increase it by a lot but have another way of reliably getting hackware / schematics - DM?

[Widmo]

I agree with the strategy being severely overpowered to the point of becoming killjoy. I was nearly invulnerable since end of floor -6 and if I had read the thread earlier I presumably could come close to this on end of -7. The problem is not really limited to late game. It simply reaches absolutely ridiculous proportions there.

Vectis explained why this has been unnoticed for quite some time very well. Datajacks' low chance of successful penetration causes most people to ignore them. If datajacks quality (negatively) affected hacking chance instead of accuracy people would have more fun using them and such things would have been noticed earlier, possibly before becoming so large problem.

For the original suggestions:

• Hackware integrity is very gradually lowered over time as a result of successful hacks. (Not as easy to explain thematically, but that's not too important here.)
• Increase mid/high-tier hackware ratings, thereby raising the depths at which they can be fabricated (fabrication being the most common way to obtain hackware).
• Using multiple hackware has diminishing benefits (i.e. each additional hackware's effect is reduced more than the last). (This puts a general cap on what is possible and makes high-end hacking that much easier to balance.)
• Hacking gets harder across the floor as more of it is successful, essentially introducing another form of clock. (This one's pretty in theme.)

Decomposing hackware would affect the well balanced machine hacking. I am afraid it would also suck mightily. Decomposing datajacks sound interesting but those can be farmed from programmers making it hardly a limited resource.

A slight increase of ratings accomplishes only slowing down the snowball without really addressing the core problem. It will make it more difficult to get the ball rolling but overpowering effect is going to remain. I think this is not what you want. On the other hand big increase severely limits the hacking game for machines.

Diminishing returns could work well, although I do not think you want this to kick in directly for the hackware itself. Mixed feelings here but this is my favorite option from those stated.

Hacking getting progressively harder is in theme but is also somewhat likely to suck some fun from the game for Cogminds with only some hacking capability. Meh.

• Make some of the very high tier special robots non-hackable (as Behemoths are now). (<-already planned for Alpha 13)
• Add at least one more higher difficulty tier for robot hacking. (<-already planned for Alpha 13)
• Put a hard cap on overload and assimilation chances, regardless of hacking capabilities.

Making robots unhackable is a sad solution and I despise it very much. It is good to know you also dislike taking options away.

Higher tier hacking difficulty is fine! I would also make converting programmers a tad more difficult. I think a base -5% would be just right.

Putting a hard cap is already there - the 95% maximum chance. Lowering it further may end up seeming like a crude approach. Avoid?


Here comes some more food for thought!

Overload:
The main problem with this is the instant kill mechanic. Lighter version of core overload could deliver damage to the core itself. Maintenance bots should succumb completely each time from a single hit as everything currently does. Others might take a constant damage. For example around 20 points should be nice. Maybe add single point to this for each 10% over 100% chance. This would allow you to make Behemoths hackable again! Overloading them becomes possible but requires sizable matter supply for remote datajacking. Still a workable plan but no longer an easy kill.

I think swarmers should also go down in a single hit that way.

Assimilate:
ADOM's bard has a similar thing. They have music skill which works as "make pets from any kind of animal fast" card. It requires high skill levels but it is very easy to attain on purpose. The problem of ally army is solved by having a maximum number of pets. Presumably the number is determined by character's charisma. The more pets you have the more difficult is to have another one join you. Otherwise the animal is pacified but not made pet.

You might like to use something similar here with some in-game rationale. Suppose the Cogmind when reprogramming Identify Friend or Foe database has to encode there every signature of ally formerly assimilated. This makes assimilation progressively more difficult. Also it would make sense to vary the effect depending on "signature complexity".

Below when using rating I refer to schematic rating, not effective sum of part ratings.
* 1% times rating for every noncombat bot assimilated. This means you hardly feel the effect of assimilating some maintenance entities as cannon fodder. Operators, researchers, machinists and other such noncombat bots will make a dent in your assimilation chances as their ratings are higher.
* 2% times rating for every regular combat bot reprogrammed. The better your army the harder is to have more. As it should be. Assimilating a bunch of bots is still doable but this cannot become a huge army. A cohort, yes.
* 3% times rating for every specialist class combat bot in your entourage. They should be special! Their equipment is also so well chosen it deserves an upgrade.
* 4% times rating for prototype robot assimilated. It definitely should be possible to have an Alpha 7 or Stiker serve you. First time this happens it feels so good it would be a shame to make those unhackable. Two such bots for good hackers and three or four with some luck for elite hackers. If someone goes evolving utility slots for hackware only it could be more but such Cogmind opens itself up so much in other departments it could be excusable.
* A flat 50% for behemoths? Behemoths should be difficult to assimilate.

New suggested options:
Format hack for robots. This essentially wipes their IFF database turning them berserk, attacking everything in sight. They could also switch targets at random every turn. If robot is corrupted have the corruption amount dictate chance for turning neutral. Robots without weapons will not attack anyone but will still be considered enemies by the AI.

General suggestions:
Programmer's chance to deflect hack attempts on allies should be triggered before menu of options is presented. This makes them more of a threat to combat hackers and improves quality of life somewhat. It is a bummer to choose something and then be notified your choice effectively did not matter.

Currently unhackable bots:
I can't quite figure out why, but no one's ever managed to hack a MAIN.C Builder or Armored Robot Carrier.
Zionite K7-V23YC

Builder: I figure you forbade hacking them to avoid assimilation and using build command to for example wall off exits and garrisons to completely own the place. A sensible goal but in that case only disallow assimilate leaving other options open. Optionally have builders' analysis mention something along this:

"Due to plethora of architectural schematics required to be embedded in builder memory I needed a compromise in design to keep fabrication costs down. Model 05 features no IFF database because it can perform well enough without one and as a result Derelicts have been unable to reprogram it in the field. Unfortunate side effect is groups of U-05 Engineer keep eagerly working in the middle of combat zones until they attract enemy fire. Currently most of my research effort is dedicated elsewhere thus as temporary compensation for this flaw distress signals sent by U-05 are prioritized by reinforcement dispatch center."

Weak point of this explanation is when unaware accidentally shoot builders no reinforcement squads are dispatched.

ARC: I actually have successfully reprogrammed this one. Hint: garrison trojan. After trojan installation bait MAIN.C to send you an Assault squad. :-) You can take this as a bug report but I wish you turned this into a feature. Allow hacking ARCs please!

Overload: In low effort version standard overload is followed with bot unload. This neither leaves four doors on ground nor additional matter. Instead you can harvest the wheels (man, I like armored wheels!), engine and storage unit.
In greater effort version bots inside escape with ~90% chance otherwise getting blown up in core meltdown. For those who escape have non-fliers and non-hoverers fall taking strong impact hit. Even some fliers/hoverers could have some chance to take impact damage. Start off all surviving bots at warm temperature.

Assimilate: Works as it currently does with the difference it is explicitly allowed. This means when it deploys you still get hostile unaware! It is on Cogmind to push it down a chute or hide it somewhere so it does not unload. Even then a stray patrol might find it and boom! Two patrols.

[zxc]

Your posts are great! A lot to go through and digest.

I agree with the strategy being severely overpowered to the point of becoming killjoy. I was nearly invulnerable since end of floor -6 and if I had read the thread earlier I presumably could come close to this on end of -7. The problem is not really limited to late game. It simply reaches absolutely ridiculous proportions there.

You might be the first person to exploit combat hacking at such an early stage of the game. Normally I try to avoid enemies at that stage and just continue to build hackware until research branches. This sort of combat hacking has been possible for several alphas, but wasn't really seen until last alpha and in particular this alpha. I could guess at the reasons:

• Not many people focusing on hacking.
• Datajacks were considered weak for a long time.
• No one had really tried pushing the limit of the hacking snowball, though we've been aware of the massive potential ever since fabrication was overhauled.
• There was a particular datajack introduced in one of the last few alphas which sparked serious interest in combat hacking (I'm guessing you didn't find it or didn't exploit it to its full potential because it's nuts and you would be raving about it).
• Until this alpha, having allies around massively pushed the alert level up. This alpha also accidentally overnerfed alert in general.
• Prototype bots were only introduced in alpha 11 (AFAIK?), and they make for the juiciest assimilation targets.
• Recalling extermination and assault squads was bugged and not possible until this alpha. Extermination squads interfere with hackware farming in factory, while assault squads are unhackable.

In many ways, it's a perfect storm.

Decomposing hackware would affect the well balanced machine hacking. I am afraid it would also suck mightily. Decomposing datajacks sound interesting but those can be farmed from programmers making it hardly a limited resource.

My guess is that neither would have much of an impact on someone focusing on snowballing, but both would introduce another complication and some unpleasantness for many players.

A slight increase of ratings accomplishes only slowing down the snowball without really addressing the core problem. It will make it more difficult to get the ball rolling but overpowering effect is going to remain. I think this is not what you want. On the other hand big increase severely limits the hacking game for machines.

Slowing down the snowball is desirable, as it's easily the most reliable way to win right now, even if you ignore combat hacking entirely. I suggested a small change rather than a large one because snowballing hackware is actually quite fun and we wouldn't want to completely get rid of it I would think. It wouldn't limit the hacking game for machines, though. You can find enough hackware to really control the game well. Snowballing just reaches that point earlier and allows total abuse of machines and bots.

Hacking getting progressively harder is in theme but is also somewhat likely to suck some fun from the game for Cogminds with only some hacking capability. Meh.

I really don't think it would. We're talking making hacking harder when you're completely controlling the game. Small-time hacking ought to be unaffected. How exactly you achieve that, I'm not sure. Perhaps excessive assimilation can result in Main.c patching robots and making their systems more resilient to hacking attempts.

Making robots unhackable is a sad solution and I despise it very much. It is good to know you also dislike taking options away.

I have to say that I agree with this. You've convinced me that it's really not fun. On the other hand, I started to regard behemoths as dangerous terrain to be avoided. What if the game introduced immobile turrets which shoot at hostiles (you)? They could be quite rare, but importantly, unhackable, and it would fit thematically. You could perhaps have a turret be attached to a nearby terminal as well, guarded by an operator... perhaps you could hack it that way .

Higher tier hacking difficulty is fine! I would also make converting programmers a tad more difficult. I think a base -5% would be just right.

This is one of my favourite solutions. If you require the player to snowball hackware (and snowball well!) to be able to assimilate the best of the late-game enemies, well, wouldn't that be great? But I'm talking about increasing the difficulty of hacking in general, not just lowering the success cap. I like the 95% cap and would prefer it stayed there. A small-time hacker shouldn't be able to have a chance of assimilating an Alpha 7. You should need to have +100 to hacking success to have any hope of assimilating it. Etc.

Putting a hard cap is already there - the 95% maximum chance. Lowering it further may end up seeming like a crude approach. Avoid?

Yep.

The main problem with this is the instant kill mechanic. Lighter version of core overload could deliver damage to the core itself. Maintenance bots should succumb completely each time from a single hit as everything currently does. Others might take a constant damage. For example around 20 points should be nice. Maybe add single point to this for each 10% over 100% chance. This would allow you to make Behemoths hackable again! Overloading them becomes possible but requires sizable matter supply for remote datajacking. Still a workable plan but no longer an easy kill.

I think swarmers should also go down in a single hit that way.

I don't like this so much. It makes combat hacking more like actual combat. However, maybe it could be a time bomb of sorts? Or perhaps, if overloading gave 1000 heat to the target or something?

Another thing is that combat hacking is weak against large groups of enemies, such as swarmers. You have to deal with them one by one. You can increase the incidence of these enemies to have a subtle effect on combat hacking.

Assimilate:
ADOM's bard has a similar thing. They have music skill which works as "make pets from any kind of animal fast" card. It requires high skill levels but it is very easy to attain on purpose. The problem of ally army is solved by having a maximum number of pets. Presumably the number is determined by character's charisma. The more pets you have the more difficult is to have another one join you. Otherwise the animal is pacified but not made pet.

You might like to use something similar here with some in-game rationale. Suppose the Cogmind when reprogramming Identify Friend or Foe database has to encode there every signature of ally formerly assimilated. This makes assimilation progressively more difficult. Also it would make sense to vary the effect depending on "signature complexity".

Below when using rating I refer to schematic rating, not effective sum of part ratings.
* 1% times rating for every noncombat bot assimilated. This means you hardly feel the effect of assimilating some maintenance entities as cannon fodder. Operators, researchers, machinists and other such noncombat bots will make a dent in your assimilation chances as their ratings are higher.
* 2% times rating for every regular combat bot reprogrammed. The better your army the harder is to have more. As it should be. Assimilating a bunch of bots is still doable but this cannot become a huge army. A cohort, yes.
* 3% times rating for every specialist class combat bot in your entourage. They should be special! Their equipment is also so well chosen it deserves an upgrade.
* 4% times rating for prototype robot assimilated. It definitely should be possible to have an Alpha 7 or Stiker serve you. First time this happens it feels so good it would be a shame to make those unhackable. Two such bots for good hackers and three or four with some luck for elite hackers. If someone goes evolving utility slots for hackware only it could be more but such Cogmind opens itself up so much in other departments it could be excusable.
* A flat 50% for behemoths? Behemoths should be difficult to assimilate.

Having a limit of some kind on number of allies might be interesting. However, having allies impact the alert level more would achieve the same effect and would be cooler I think. You might have to face an altogether different kind of snowball: the alert snowball! Not seen since alpha 11! In one of my alpha 11 runs, and the first time anyone had really tried combat hacking much, I assembled a nice army in testing, but the alert level got out of control and I had to bail in a hurry:

All allies:

Spoiler (click to show/hide)

And now, they're all dead, and everyone here is an enemy:

Spoiler (click to show/hide)

Also, I think the effect of allied operators on hacking success could be nerfed, at least to diminishing returns like botnets.

New suggested options:
Format hack for robots. This essentially wipes their IFF database turning them berserk, attacking everything in sight. They could also switch targets at random every turn. If robot is corrupted have the corruption amount dictate chance for turning neutral. Robots without weapons will not attack anyone but will still be considered enemies by the AI.

I like this one a lot. Basically frenzy in DCSS.

General suggestions:
Programmer's chance to deflect hack attempts on allies should be triggered before menu of options is presented. This makes them more of a threat to combat hackers and improves quality of life somewhat. It is a bummer to choose something and then be notified your choice effectively did not matter.

This this this! So many times I've been completely mystified as to why my hacks failed after I chose an option. "How could 95% success fail this often?"

Builder: I figure you forbade hacking them to avoid assimilation and using build command to for example wall off exits and garrisons to completely own the place. A sensible goal but in that case only disallow assimilate leaving other options open. Optionally have builders' analysis mention something along this:

"Due to plethora of architectural schematics required to be embedded in builder memory I needed a compromise in design to keep fabrication costs down. Model 05 features no IFF database because it can perform well enough without one and as a result Derelicts have been unable to reprogram it in the field. Unfortunate side effect is groups of U-05 Engineer keep eagerly working in the middle of combat zones until they attract enemy fire. Currently most of my research effort is dedicated elsewhere thus as temporary compensation for this flaw distress signals sent by U-05 are prioritized by reinforcement dispatch center."

Weak point of this explanation is when unaware accidentally shoot builders no reinforcement squads are dispatched.

I like this.

I thought it was intended that you could assimliate ARCs via reprogram. In any case, I think the robots that burst out of an allied ARC should be allied to you. I don't see a problem with ARCs being unhackable. They're probably the most thematic bots of the game to make unhackable. At least you can let them unload and hack the bots that come out.

[Sherlockkat]

Lot of good suggestions in this thread!!

If I had to pick a couple of changes from Kyzrati's list to implement in alpha 13. It would be

i) Increase mid/high-tier hackware ratings, thereby raising the depths at which they can be fabricated (fabrication being the most common way to obtain hackware). *I would also suggest increasing the rating of the adv. remote datajack*
ii) Add at least one more higher difficulty tier for robot hacking. (<-already planned for Alpha 13)

I am not a big fan of nerfing the reliability of the combat hacker once it has reached its final form, even though I suggested some of the changes in that list (prototype "unhackability" and assimilation hard caps). Partly cause you need that reliability, otherwise that build has nothing going for it when you hit command. It is sufficient for access, but you can clear access easily with less extreme build.
So, in my mind, the way to nerf the combat hacker is to control when it comes online. Right now, it is ideal for the player due to the fact you can get it running before you hit research branch. The way to delay the build would be to increase the number of fabrication targets: Currently in my runs, the fab targets are
a) hackware (early/mid factory)
b) flight units (Situational, depends on what you find)
c) datajacks (-4 and -3 due to schematic restrictions, you can get lucky in -5 and download it or find it lying around in factory or a chute)
d) other situational items (sensors for e.g)

Increasing hackware rating will shift a) from early/mid factory to mid/late factory which will slow the build down significantly. Flight units are getting nerfed, so that will probably have an impact on fab meta game. Increasing the datajack rating will definitely affect how quickly the build comes online. Sure, you can get lucky and take down a sage or find it lying around. But that's true for any item in the game. The situational items that you want to fab are also key. It is somewhat hard to operate without sensors, even for a combat hacker.

Adding one more tier to robot difficulty also has a significant impact as it pressures you to get more hackware which will make things even more tighter at the factory stage where you are fabricating things. In order to counterbalance this a little bit, I would suggest that some of the factory branches contain reliable hackware. The hub_04(d) (and maybe even the arhcives) is a good branch for that. Warlord's stash and Zhirov maybe. There is already a way to get late-game hackware from DM, but that's a bit rng.

[Widmo]

• There was a particular datajack introduced in one of the last few alphas which sparked serious interest in combat hacking (I'm guessing you didn't find it or didn't exploit it to its full potential because it's nuts and you would be raving about it).

Spoiler: that one datajack? (click to show/hide)

Are you thinking of guided remote datajack? I lost that one in delayed machine explosion. I assumed it was stable because it did not blow up for like five turns. It sure was nice for a short time while it lasted. Most probably it has far greater potential than I see there because I was only slightly impressed.

A small-time hacker shouldn't be able to have a chance of assimilating an Alpha 7. You should need to have +100 to hacking success to have any hope of assimilating it. Etc.

I think this is best approach.

The main problem with this is the instant kill mechanic. Lighter version of core overload could deliver damage to the core itself.(...)

I don't like this so much. It makes combat hacking more like actual combat. However, maybe it could be a time bomb of sorts? Or perhaps, if overloading gave 1000 heat to the target or something?

It is true my suggestion kicks hard into the overload hack feeling. On the other hand one shot kill is way too reliable to leave it without consequences.

Another thing is that combat hacking is weak against large groups of enemies, such as swarmers. You have to deal with them one by one. You can increase the incidence of these enemies to have a subtle effect on combat hacking.

Indeed, it will be subtle. Typically I wait until sufficient robot fodder to shield me is available. Then those are attacked first providing cover and ample opportunity to convert first swarmer/grunt. I choose one closest to me so that only a few enemies have chance to target me. The converted one will become next target so I concentrate on hacking another one but choose one with highest core integrity from now.

Having a limit of some kind on number of allies might be interesting. However, having allies impact the alert level more would achieve the same effect and would be cooler I think. You might have to face an altogether different kind of snowball: the alert snowball! Not seen since alpha 11! In one of my alpha 11 runs, and the first time anyone had really tried combat hacking much, I assembled a nice army in testing, but the alert level got out of control and I had to bail in a hurry:

Agreed, having alert rise high would solve all that much better. No matter how strong Cogmind's forces eventually MAIN.C will prevail like it did with Sigix.

Also, I think the effect of allied operators on hacking success could be nerfed, at least to diminishing returns like botnets.

Is this not the case already? I read somewhere the bonus is +10, +5, +2, +1, +1, +1, +1, ...
All I can find now is changelog entry for bugfix in Alpha 4 saying Operators after the fourth were giving nothing instead of +1.

I don't see a problem with ARCs being unhackable. They're probably the most thematic bots of the game to make unhackable. At least you can let them unload and hack the bots that come out.

If you look at it that way ARC could be regarded as a dumb vehicle whose core has no autonomy. Makes sense to forbid hacking but in that case you are right reprogram trojan should either not work or have ARC carry allies.

Slowing down the snowball is desirable, as it's easily the most reliable way to win right now, even if you ignore combat hacking entirely. I suggested a small change rather than a large one because snowballing hackware is actually quite fun and we wouldn't want to completely get rid of it I would think.

Increasing hackware rating will shift a) from early/mid factory to mid/late factory which will slow the build down significantly. Flight units are getting nerfed, so that will probably have an impact on fab meta game. Increasing the datajack rating will definitely affect how quickly the build comes online.

Hmm. Improved tier has rating four which makes it available at -7 where fabrication first becomes available. At the extreme this means fabbing regular system shields and hacking suites could be skipped entirely at lowest factory level. If improved hackware (and subsequently advanced and experimental tiers) were shifted to higher rating this would leave makeshift hackware to fit very nicely at rating four. I like this! Color me convinced.

[Kyzrati]

Whew.

Making robots unhackable is a sad solution and I despise it very much. It is good to know you also dislike taking options away.

It still might be necessary, though, because some of the individual robots are simply too powerful to have on your side. This is one of the reasons (aside from their excessive size...) that I prevented Behemoth hacking from the very start. But in later releases as I added more powerful prototoypes, since no one was doing much robot hacking anyway I decided to let them be hackable and see what would happen. We've now seen what happens

Assimilate:
ADOM's bard has a similar thing. They have music skill which works as "make pets from any kind of animal fast" card. It requires high skill levels but it is very easy to attain on purpose. The problem of ally army is solved by having a maximum number of pets. Presumably the number is determined by character's charisma. The more pets you have the more difficult is to have another one join you. Otherwise the animal is pacified but not made pet.

You might like to use something similar here with some in-game rationale. Suppose the Cogmind when reprogramming Identify Friend or Foe database has to encode there every signature of ally formerly assimilated. This makes assimilation progressively more difficult. Also it would make sense to vary the effect depending on "signature complexity".

An interesting possibility!

New suggested options:
Format hack for robots. This essentially wipes their IFF database turning them berserk, attacking everything in sight. They could also switch targets at random every turn. If robot is corrupted have the corruption amount dictate chance for turning neutral. Robots without weapons will not attack anyone but will still be considered enemies by the AI.

Yeah I was considering adding this exact thing a while ago. I've just been too busy to do any new hacks and wanted to get the basic system finalized first--because until very recently no one was doing robot hacking, there hasn't been any anecdotal evidence to base balancing on, whereas now there's a flood of it! Hence this thread

Once the system is set, we can certainly add several more interesting hacks with special effects (although let's not get ahead of ourselves--overloading and assimilation are the big ones to consider here).

General suggestions:
Programmer's chance to deflect hack attempts on allies should be triggered before menu of options is presented. This makes them more of a threat to combat hackers and improves quality of life somewhat. It is a bummer to choose something and then be notified your choice effectively did not matter.

That's... possible, simply implying they're preventing you from accessing the system in the first place. (Although I don't see how it changes their threat in any way.) One drawback: You won't get to see the percentages (or is that what you mean by an increased threat???).

Builder: I figure you forbade hacking them to avoid assimilation and using build command to for example wall off exits and garrisons to completely own the place. A sensible goal but in that case only disallow assimilate leaving other options open. Optionally have builders' analysis mention something along this:

Yes, to prevent building (a command which I just recently removed, too) and the insane strategies it enables--the AI feature exists, but I never made it available because it would end up becoming a different sort of game that would require too much additional special case work to enable :/ (but I did originally want it in there, because fun )

The game currently doesn't support individual hacks being available/unavailable, hence how it's currently handled. There are only settings for "everything," "manual only," or "nothing." I could change it to give finder control, though, if really necessary...

ARC: I actually have successfully reprogrammed this one. Hint: garrison trojan. After trojan installation bait MAIN.C to send you an Assault squad. :-) You can take this as a bug report but I wish you turned this into a feature. Allow hacking ARCs please!

Yeah I allowed ARC hacking via garrisons because their contents would still be hostile, which was actually intended (someone asked about this a long time ago, and also just a few days ago as well...). The hack was mostly intended to be used against investigations and reinforcements, which don't come in ARCs, whereas using one hack to take over an entire assault is a bit powerful, plus it makes some sense that you reprogram the carrier but not the individual robots inside.

But hacking ARCs directly is still a bit OP, in my opinion, since it would allow you to turn away entire assaults and patrols directly. I guess if it's difficult enough it's okay, so maybe one day after the rest of robot/combat hacking is balanced we can reassess their value in a new light, but not now--too early.

• Until this alpha, having allies around massively pushed the alert level up. This alpha also accidentally overnerfed alert in general.
• Prototype bots were only introduced in alpha 11 (AFAIK?), and they make for the juiciest assimilation targets.

These two are really big, especially the first. I didn't make mention of it, but for Alpha 12 I actually put a pretty tight cap on how allies affect the alert level, because I wanted to see what would happen when players are allowed to have a lot of friends without too many consequences. Again, we have now seen what happens

Simply raising that again (as I intend to do) will have an impact--you'll be back to seeing more assaults again. Of course this alone doesn't completely solve the problem since once you're eventually an unstoppable hacker, the assaults are just feeding you

Hacking getting progressively harder is in theme but is also somewhat likely to suck some fun from the game for Cogminds with only some hacking capability. Meh.

I really don't think it would. We're talking making hacking harder when you're completely controlling the game. Small-time hacking ought to be unaffected. How exactly you achieve that, I'm not sure. Perhaps excessive assimilation can result in Main.c patching robots and making their systems more resilient to hacking attempts.

I agree with zxc here that the impact wouldn't be so broad, though assimilation having said affect would be an even more targeted change...

Higher tier hacking difficulty is fine! I would also make converting programmers a tad more difficult. I think a base -5% would be just right.

This is one of my favourite solutions. If you require the player to snowball hackware (and snowball well!) to be able to assimilate the best of the late-game enemies, well, wouldn't that be great?

This one change alone does seem like it could have the largest impact on all of this.

The original hacking defense tiers were developed before any of these prototype variants existed, when the most powerful thing in the game was a Behemoth, which couldn't even be hacked. Assimilating other things like Hunters and Programmers was fine and all, but they aren't exactly all that amazing on their own and will die before long. Prototypes on the other hand... they've changed the whole calculation here.

Having a limit of some kind on number of allies might be interesting. However, having allies impact the alert level more would achieve the same effect and would be cooler I think. You might have to face an altogether different kind of snowball: the alert snowball! Not seen since alpha 11!

I agree with the alert level being a more natural limiting factor here, which is how the system was intended to work in the first place, actually. As mentioned before, though, I overnerfed it in Alpha 12, which is where this really got out of hand.

Also, I think the effect of allied operators on hacking success could be nerfed, at least to diminishing returns like botnets.

That's how they've always worked. (The exact values are given in the manual under Allies > Benefits.)

This this this! So many times I've been completely mystified as to why my hacks failed after I chose an option. "How could 95% success fail this often?"

Okay, okay.

[Widmo]

General suggestions:
Programmer's chance to deflect hack attempts on allies should be triggered before menu of options is presented. This makes them more of a threat to combat hackers and improves quality of life somewhat. It is a bummer to choose something and then be notified your choice effectively did not matter.

That's... possible, simply implying they're preventing you from accessing the system in the first place. (Although I don't see how it changes their threat in any way.) One drawback: You won't get to see the percentages (or is that what you mean by an increased threat???).

Sorry, I should have written perception of threat. Having hacks be defended immediately creates appearance of competent enemy. The effect is clouded by annoyance when it happens after making an irrelevant choice. I view not seeing percentages each time hack attack is thwarted as actually good.

[Kyzrati]

Gotcha, yeah we'll do that.

As for everything else discussed so far, we'll start with the obvious simple adjustments that will probably have a rather large impact, and go from there. (I also get the feeling this has only come up due to the inadvertently radical changes that appeared all at once in Alpha 13...)

[Kyzrati]

An update on this: While I'll still be starting out with some of the more obvious improvements that were planned anyway, regarding allies I just discovered a serious bug (oversight) in the code introduced in Alpha 12:

I practically zeroed the base value that determines how much allies increase the alert during combat, because it was supposed to be added to each ally's level (a new feature so that better allies will increase the alert more), but, uh, that latter part was never done! That's why having allies is doing very little to the alert, oops...

(I had assumed it was just because I'd lowered the values, which I had done and that was intentional, but the effect of that "missing code" I never finished took it to the extreme. I'll have to factor all this in to the values coming up for Alpha 13, as my original Alpha 12 numbers may actually have been correct, just not fully implemented so we can't know for sure :/)

[Kyzrati]

I was just now implementing some of the hackware changes, and another possibility hit me, one that hasn't been discussed yet: What about reducing the effectiveness of high-tier hackware in general?

The hacking bonus scales up rather quickly as is, and the original purpose behind that design was to allow you to continually, and noticeably, improve your hacking capabilities without expending too many extra slots. But if players are going to stack so much of it... it's worth considering lowering the rate of increase. After all, you do get 18 more slots throughout a run, which obviously players have no qualms about filling up with hackware. This change would strike directly at the heart of what makes the snowball so effective against everything--stacking, without nerfing it completely. This isn't something I plan to do now, just another thought to add to the pile.

For example, right now we have
+10, +15, +20, +25, +30, +35.
What about
+10, +13, +16, +19, +22, +25

Of course, it would also make that lone piece of hackware that some non-hackers like to equip that much less effective later on. (I'm suddenly having a sense of deja vu, so I wonder if I've mentioned this somewhere other than this thread before?)

(I also like the simpler nature of incrementing by 5 for each, but that's probably less important here.)

[Widmo]

I was so surprised I briefly skimmed the thread again but no, there is no mention of this approach. What you suggest might be succesful, although I am unsure what to think about it. Certainly something to keep in mind though.

[Kyzrati]

I'm still looking at exactly how difficult the new robot hacking tiers should be, and I think I may have to make those hackware value changes as well. Mainly because your winning run reached a whopping +170% offensive hacking bonus, which is even above the average "good hacker" level of around +100-120%. It's hard to balance otherwise.

This would bring the +170% you had down to a more reasonable +130%, while having a less serious impact on the other hackers, like wins that show a +120% would become +96%. (Though there are also Operator and botnet bonuses to consider here.)

It would certainly still be possible to get those high numbers again, though more slot sacrifices (or the really awesome rare hackware) would be necessary.

[Widmo]

My peak actually was +200% offense. Data Miner can go whine in a corner. That was on last factory floor if I remember correctly. It was a golden period of treating terminals like buffet tables. Take what you want in whatever amounts. At one point I was collecting schematics until I got bored by straining to remember part names to target. I think I was waiting for database lockout or for tracing to finally kick in so that investigation squad gets called to make use of compromised garrison access. Made me wish for Force(whatever) for terminals...

Okay, I am now convinced the numbers are too high and result in boredom. Or too much flexibility for someone who would not spend nearly all utility slots on hackware but put them to more optimal use elsewhere. On the other hand if progression will be slowed then the extra awesome rare hackware may get greater increase than normal.

Perhaps use this progression:
+8, +12, +16 ,+20, +25, +30
Makeshift could be +15. edit: or +10.

It looks nicer and does not make getting seveal Hacking Suite drops from material floors operator bots into as big impact as it is now.

[Kyzrati]

I did change it already, shortly after my last post, though somewhat more strict than you suggest. I'm starting with +10, +12, +14 ,+16, +20, +25. The latter two will remain a good bit better than the ones before if only because they're rare.

I put together a spreadsheet where I could see how different hackware totals affect all the robot hacking difficulties given different adjustments, and in the end this approach really makes a lot of sense because in Alpha 12 it becomes easier and easier to stack over time with the double benefit of both many more slots and better hack percentages, while with the new progression it's very much possible to stack and get good at hacking, but not quite so extreme.

...as you can see above, I originally left the lowest tier alone, deciding to keep the base the same so it has more long-term value (after considering starting with +8), but now I think I agree with you that it should come down. That would be especially meaningful since Operators don't carry anything better than that until -4. However, I'd be worried that combined with the other effects it could be a bit too much of a hacking nerf. Anyone else with opinions on that? +8% for Hacking Suites... (Certainly it would help give the Mak. version a more meaningful place in between at +10, rather than what I changed it to recently--an 11 stuck between 10 and 12...)

In any case, I'm sure there will still be more tweaking after Alpha 13.

[Kyzrati]

So the portion of these changes which were made for Alpha 13 have done pretty well so far, though one of the steps I'm considering taking over the next few days is to increase, perhaps double, the static chance for each programmer within range to remotely defend allies against hacking effects (from 25% to 50%).

I think this will help give combat hackers some more strategic considerations. Plus, you know, they can do an even better job living up to their name

Any opinions?

[zxc]

It would be good if there were some way to deal with programmers. Even as it is right now, two programmers (or heaven forbid, three+) will repel a great number of hacking attempts and there's just little you can do other than keep trying. Using other weaponry isn't really feasible due to the specialisation needed to make combat hacking work, and even the specialisation needed to make regular combat work.

In my current game, I fail half my hacking attempts against pairs of combat programmers. I win only by repeatedly hacking until RNG favours me. Sometimes I can split the pair, which results in a faster fight.

What if repelling a hack temporarily disabled that programmer? It doesn't have to be that, but you can perhaps see where I'm going with this. I just don't think it's fun when one type of bot completely counters your highly specialised build. A protector with an energy mantle would absorb damage directed at its allies, but you could target that protector directly in response. Two or more programmers will just be nearly impossible to hack, and you will just get nowhere. Or have programmer defensive repels not stack, and prevent programmers from protecting each other.

The other thing I would look at is how wide the radius is for programmer hacking attempt repelling (and its visibility to the player, which is currently nil). To be of greater tactical significance, it should be reduced and made visible somehow. If a programmer or two will repel all hacks in a 10-15 radius, it would reduce the decision-making to: 1. Run away, or 2. Kill everything with non-hacking methods.

If we wiped the current notion of combat hacking and came at it from scratch, I think I would want hacking to focus on indirect methods to gain control of a fight, rather than as a substitute for gun shooting to kill enemies (which Overload essentially is). The hack ideas proposed earlier would help here.

[Kyzrati]

Note that this new proposal wasn't really intended as a strong counter to combat hacking, I just happened to be working with some hacking features and came across this as an interesting idea. Because I disagree with this:

one type of bot completely counters your highly specialised build.

Even if you don't fight them, or avoid them with superior speed, as a hacker might you not have allies who can help with this? If you're that specialized, you just turn other combat bots and have them help / do the work for you, or use any of the many other tools at your disposal, like recalls, delaying their dispatches, etc.

There is also one crucial piece of information you're either overlooking, or maybe haven't yet realized: Programmers can only protect each other--or other robots--from hacks if they have line of sight to the defender. Can't you use that knowledge against them? (Note that I've had in my notes to add this to the lore in Alpha 14 if it isn't already there )

[zxc]

Yeah the LOS splitting is what I sometimes do to hack programmers more easily, especially when they are sent in exterm/intercept squads. But say, three programmers in a group are difficult to split up.

Regarding allies: my preference for a combat hacking playstyle is to not utilise a 'standing army' of allies but rather to create allies on the fly when needed. This involves less management and is more tactically interesting. It would be possible to make a small army of allies, park them, and if you come across a group of enemies accompanied by multiple programmers, retreat to your army. This process is convoluted and at that point I would rather avoid the fight entirely.

The only reason I take on groups of programmers as it is right now (at 25% repel chance) is because with the GRD and total map control I can take my time, kite to split up enemies, and overload them from around corners. The repel mechanic (as it exists currently, where your 95% chance hack fails 25%+ of the time) is easily the most annoying thing ever for this build. At a higher rate, I would let SW deal with all programmers (or if possible, get 100% EM resist myself and just slash programmers with melee).

From a different perspective: I won't be farming score in future Alphas like this, so my practical choice for a combat hacker every time will be to recall exterminations and assaults. Intercepts are trickier of course...

[Kyzrati]

Yes Alpha 14 will already be changing some things. "Total map control" will likely be a thing of the past, for example.

Regarding allies: my preference for a combat hacking playstyle is to not utilise a 'standing army' of allies but rather to create allies on the fly when needed. This involves less management and is more tactically interesting. It would be possible to make a small army of allies, park them, and if you come across a group of enemies accompanied by multiple programmers, retreat to your army. This process is convoluted and at that point I would rather avoid the fight entirely.

I certainly agree here.

In any case, I'll leave it as is and we'll see. Was just a thought for how to put a little more specific potentially counterable pressure on combat hacking.

[Sherlockkat]

the static chance for each programmer within range to remotely defend allies against hacking effects (from 25% to 50%).

50% is something we can handle, but makes it unfun. I already avoid them as it is. So, they function well as a deterrent. There aren't a lot of tools to deal with them tbh.

Re allies: I don't maintain a standing army either. Allies are just bullet sponges, I assimilate when needed but mostly operate alone. I have noticed that programmers trade a little too efficiently against the other complex robots which already makes them hard to handle in groups and you need to get lucky to break through their hacking defenses and get anything done. The flat hacking defense irrespective of what you have is already somewhat un-counterable.