Grid Sage Forums
Cogmind => Strategies => Topic started by: Bjartr on May 19, 2015, 04:21:46 PM
-
I haven't played more than an hour or so yet, but I'm wondering if there is there a way to determine how likely it is for enemies to notice me and start attacking. Similarly, is there a way to determine if having weapons unequipped vs equipped vs equipped & activated makes being noticed more likely?
-
They notice you as long as you are within their sight range (which is usually equal to your minimum/unmodified sight range), and if they take their turn while you are within that range.
So if you are moving very fast, their turn will come much later by comparison and you might be able to slip by/away if it's just a short distance. There is no specific indicator for this part--you'll have to get a feel for it (not knowing adds to the suspense!).
Know that when hostiles do spot you, their background glows for a bit to indicate that. I plan to add a tutorial message to the next version because the only place this very important mechanic/indicator is currently described is in the manual.
Similarly, is there a way to determine if having weapons unequipped vs equipped vs equipped & activated makes being noticed more likely?
Enemies don't care about what you have equipped or activated.
Stealthiness is best achieved by having the right utilities (which is even more important than being fast, but being fast helps). Things like various scanners and ECM. By the mid-game with the right build, if you're good you can avoid almost all confrontation. In the early game perfect stealth is more difficult to achieve, but it's less important because enemies are less dangerous.
-
I'm not sure if this is old news but.... Watchers don't send any distress signals (or react to you in any way) if you stand still and don't do anyhting. At least scouts on -10. Come to think of it, the tutorial's chatty little bot said something about pretending to be heap of junk in the corner or something similar, I seem to recall.
-
Watchers are just really weird in general. You are right in that on the lower levels, they are not very likely to 'sound the alarms', but standing still definitely isn't good enough on the higher floors. No idea what the trigger is.
-
Similarly, is there a way to determine if having weapons unequipped vs equipped vs equipped & activated makes being noticed more likely?
Stealthiness is best achieved by having the right utilities (which is even more important than being fast, but being fast helps). Things like various scanners and ECM. By the mid-game with the right build, if you're good you can avoid almost all confrontation. In the early game perfect stealth is more difficult to achieve, but it's less important because enemies are less dangerous.
Just a note from a new player: the description on ECM does not make it obvious that it makes you harder to be seen/shot at. In fact, the description made me think it applied to hacking.
-
Just a note from a new player: the description on ECM does not make it obvious that it makes you harder to be seen/shot at. In fact, the description made me think it applied to hacking.
Ooooo, I second this. I couldn't tell what ECM modules did and thus ignored them until I asked here what they did. and was informed what a crucial part of stealth builds they are. Their description definitely needs to be more clear as to their purpose.
-
In terms of general description cleanup, one other bit that bugged me (and only because I ran into the one part before the other) was the upgrade to the sensor array, which says it "needs a sensor array to function." Which is true enough. But I had to scratch my head for a second and go "ok, so...these other sensors I have...do they count?"
(Mid-post thought: rename "sensor array" to "scanner system"? ("scanner array"?) That's what it does, it scans robots.)
If we could get a UI tweak that would highlight the names of parts like the Terminals do for Queryable keywords and give a dropdown on what that thing is. E.g. I could mouse-over "[sensor array]" and get the description that would show up on the sensor array, similar to how we get a description of various stats, like heat, damage type, or load.
-
Just a note from a new player: the description on ECM does not make it obvious that it makes you harder to be seen/shot at. In fact, the description made me think it applied to hacking.
Good point--the description was written back before hacking even was planned to be included as a mechanic ;)
(Side note: Any utility that has anything to do with hacking is of the Hackware type.)
That said,
Their description definitely needs to be more clear as to their purpose.
I didn't want to reveal precisely how they work, at least not in the description itself, since that says a bit too much about the AI. I instead plan to provide that information via another themed help system to come. Then you'll have an even better idea of what it does in terms of affecting the AI.
I'll look at the current description and make sure there won't be any confusion with hacking.
In terms of general description cleanup, one other bit that bugged me (and only because I ran into the one part before the other) was the upgrade to the sensor array, which says it "needs a sensor array to function." Which is true enough. But I had to scratch my head for a second and go "ok, so...these other sensors I have...do they count?"
I think the quickest solution here is to capitalize the other two part names in the descriptions so that you know they are proper nouns which refer to something specific. (There are other reasons I'd prefer to not change the names of those parts themselves, and this could be a satisfactory workaround.)
(Mid-post thought: rename "sensor array" to "scanner system"? ("scanner array"?) That's what it does, it scans robots.)
There is also the Scan Processor, which gives more information about robots as well but operates alone by processing data from your default sensors.
If we could get a UI tweak that would highlight the names of parts like the Terminals do for Queryable keywords and give a dropdown on what that thing is. E.g. I could mouse-over "[sensor array]" and get the description that would show up on the sensor array, similar to how we get a description of various stats, like heat, damage type, or load.
Unfortunately such a system wouldn't have a broad enough application to make it feasible, as throughout the entire game there are only two item pairs that work like this Sensor Array-Signal Interpreter and Terrain Scanner-Terrain Scan Processor.
Also unfortunate for beginners is the fact that both pairs are available right from the start :/ (In general I've tried to design it so that special/additional mechanics don't appear until later in the game.)
-
Sensor Array/Signal Interpreter => Scanner Array/Scan Interpreter, perhaps?
Word associations can make a big difference, and 'scan' has connotations of 'what is that' rather than 'I see all'.
-
You're forgetting the Scan Processor, which serves even more of a "what is that" role.
Still, I do believe the wordage here is cause for some confusion.
-
My brain keeps wanting to read Signal Interpreter as Signal Interrupter. I think Signal Processor would be better, but it's maybe too similar to Scan Processor. You could even go for just "SPU". That's a little terse compared to the overall naming scheme, but you do already have the pattern of unpacking "Imp", "Hrd", and etc. in the item description.
-
True, though those are prefixes. Acronyms like ARC, ECM, and KE are not defined.
From watching several people play, I can say that different things are read quite differently by different players, for different reasons (usually quite inexplicably from a third-party point of view, though everyone has their own background). One element that's perfectly interpreted by one player is misread/misunderstood by another.
I'll look at these main culprits again, though I think the core issue is that they are the only parts which require other parts to fully function, adding a layer of difficulty to comprehension that isn't needed or practiced elsewhere.
-
Is it feasible to wrangle them into doing partial functionality without the extra bits, perhaps?
It might seem weird, but making sense of fuzzy data is better than no data at all, and the 'error' message could be a helpful hint as to the part needed to make it work properly...
As you say, they're a special case that is very rare. I guess my line of thinking is whether the special case is strictly needed at all. :)
-
The purpose of their unique separation was that they're simply too powerful to be provided in a single package. This was before the advent of multi-slot items, but I wouldn't want this particular package to be multi-slot, since it does come with increased versatility in that you can mix and match different kinds of sensors...
-
I'm suggesting that both parts function independently, even if you need to combine them to reach the current level of utility...
-
I know, and that's already the case. You can benefit from either of them individually.
-
... Signal Interpreters work by themselves? If I understand you correctly, then I stand corrected. :)
-
They have their own use now, yes, though not to detect robots. As of Alpha 3 they reveal where exits lead, so you're not 100% corrected, only 50% ;)
Either way, they're no longer completely useless on their own.
-
Either way, they're no longer completely useless on their own.
What DO they do, then?
-
As of Alpha 3 they reveal where exits lead
:)
-
This is very helpful for avoiding the early branches, where a lot of characters meet their deaths.
-
As of Alpha 3 they reveal where exits lead
:)
Doh, missed that. >..<