keymap & UI/UX: Science!

[heaventwig]

Science has most of its interface commands available as keybindings. I've found one extant interface element so far that isn't listed in the snis_keyboard.c file, and a pair that are listed but which don't seem to do anything:

• align to ship (not available as a key binding)
• zoom/unzoom (doesn't do anything; expected behavior is to adjust the zoom of SRS or LRS, whichever is on screen at the time of the input).

The other UI modifications that occur to me for the science station are slightly more in the UX world. Scan direction, scan contact selection cycling, scan depth/layers/detail refinement, and moving the LRS display ball.

I didn't figure out until just now that there's an adjustment available for the direction of the scan, which is super cool. Not sure how else to indicate that for newbies, besides help (where you have it already) and on the screen (already indicated with the white interface element, now quite obvious to my eye). I do wish I could push one button to make the scanner focus on my selected scanner contact (which presupposes the ability to click/select scan contacts that I haven't yet scanned, also a thing I've wished for often; see my further notes below for more on this concept).

For scan-contact selection, I find myself wishing for the ability to cycle through scanning targets, like I do in other spaceship bridge simulators -- for example, if keys y, u, and i defaulted to selecting my closest possible scannable contact, my next further such contact, and my previous closer scanner target, cycling around from nearest to furthest and vice versa, that would make it possible (if time-consuming) to eventually cycle through all the scanner contacts in the system. I could also imagine saving a specific contact to a specific key, so that if I hit (say) ctrl-1 while I have a specific target selected, I can hit 1 later to select it again.

Once a contact is selected, as currently implemented, the science station seems to fairly immediately have phenomenal volumes of (phenomenally detailed and accurate) information about the object I'm scanning. Seems to me like it could be fun for that to be different, and changing it would make the whole "select whatever you like" thing work a bit better (that is, not just immediately win the science game). Here are a few ideas about ways to approach this:

• obfuscate the position of an object by adding randomness to (or just eliminating) low-order bits in position, bearing, mark, and velocity data (and thus also closing rate, eta, and "warp factor" data, which ought to be client-side calculations), as well as, possibly, shield information. One method that occurs to me as fun: use the target's velocity and its distance from the scanner, together with the scanner's notional scan saturation on the target, to generate a space in which to randomize the position of the target for presentation to science scanners; that perceived position (supplied by the server in response to scanner pings from the ship, maybe even with some indication of how much uncertainty there is) can then be used to decide where to show a dot in the sciball, or the dot could be distributed as a haze in that space of uncertainty (and if you click in a place with a haze from multiple possible contacts, you get one of them but it's random, hopefully based on relative probabilities and density, as to which one you get; a bunch of ships near a planet will just vanish into its mass until you build up scan saturation on that spot and increase your resolution). The detail screen could show a ± XYZ beside the current standard data, to inform the science officer just how uncertain they are about the contact's position and/or velocity.
• also suggests a thought: we should never have full information about both position and velocity! Insert Feynman's story here, about getting out of a ticket by giving a cop a physics lesson.
• if each ship tells the server what direction they're scanning all the time, with what power and what scanning width, and the server tells the ship what they see, the server can track how many scan particles have hit each scan contact (ship emits a number of scan particles based on power level, divided among the degrees width of scan, reduced as the cube of the distance from the source, and contacts return additional data or improved data according to the number of scan particles they've received; cloaking, if we ever go there, can then be implemented as some combination of scan-particle-evasion and scan-particle-dumping).
• reduce the availability of certain information until after you've been scanning a thing for a while; eg you have to focus scan on something, and also have located it accurately, to see its current shield frequencies.
• As I keep thinking about all this, it seems to me like there's two or three kinds of information about a scan target - there's persistent information like registry and/or transponder numbers, name, faction, type, mass, lifeforms, and armaments; there's information that's highly variable for most objects (less so for starbases, even less or not at all for planets), like position and velocity, along with related bearing, mark, closing, eta, and warp factor; and there's stuff that might or might not be adjusted by another ship during an engagement or between encounters, like shield frequencies. (And even the contents of a ship might change over time, so maybe lifeforms and armaments go in that third category?) Clients should be able to (and probably should) retain whatever persistent info they can acquire from the server about each contact they scan, and should (maybe must) discard scan info about position and velocity from past system-state updates supplied by the server (with a possible exception for stationary objects once they've been identified as such, though really the question of "do I know it's stationary" should be tracked server-side).
• In order to allow for the possibility of future third-party client development, I'd also suggest, as a way of integrating this set of fuzzy data suggestions with the prior easy-and-precise-selection suggestions, leaving the decision as to which thing you selected up to the server. Client can show things as a point or as a haze (should be a haze, but whatever), and the user can click where they want (or say "next contact" or "previous contact" or "contact closest to camera focus"); the client will tell the server "click on this spot" or "closest thing to here" or whatever, and server will say "you selected this."

I've also wished I could move the focus of the sciball - not just zoom in/out and adjust pitch, yaw, and roll, but drag my camera through the sky. I'd add a second position triad on the screen, just below the existing one, labeled camera, and a return-to-ship button. I would expect the scanning to continue to be centered on the ship, operating as normal, but I could then zoom in on the action near a specific starbase, say, or drop a waypoint somewhere (based on somethin I heard from comms) and zoom in there. Select something (or keep my selection on that starbase, waypoint, or whatever), and hit the "focus scan" button to aim my scanning dish at that area. Again, this needn't give me immediate information on all the things I've zoomed in on; the positional fuzz described for successive depth of scan might apply in this distant region of space as well, making it harder to see what the heck is on the screen even. But that's fine, just hold us steady here a moment cap'n, helm, and I'll tell you if I can find that pirate you're lookin for. (And if we have the triad of nearest-next-prev keys as described above for contact-selection, maybe that's actually based on camera position, so that if I move the camera and hit the "nearest" button my system asks the server for whatever is closest to that spot and - if we have the fuzzy-scan concept in play - the server returns something at random from amidst the local fuzz wherever I've put my camera. More likely a planet or starbase than an escape pod or an asteroid.)

[smcameron]

Well, you're not shy about asking for stuff, heh.

Bear in mind, when you put a lot of stuff in one issue like this, it's easy for pieces to fall off the table and get ignored/forgotten. But it's fine.

obfuscate the position of an object

To some extent, this is done already, (that's what the fuzzy balls of static you see are before you focus your beam on objects are doing.) You also have to ask about features like this, does it make the game more fun? Or is it just frustrating? I'm trying to remember but I think we experimented with this a bit 10 years ago and found that it was just frustrating. Maybe it's time to experiment in this area some more, but I'd be inclined to make it user-tunable if I added something like this.

never have full information about both position and velocity!

How does not having this info make the game more fun? How does having it make it less fun? How do you even know that what is presented onscreen today is accurate? (It is, but if it weren't, you wouldn't have known that.) So, if I made this information less accurate (i.e. mostly accurate, but off a bit), nobody would even notice, so why do that work? If I did make it so inaccurate as to be noticeable, this information would be rendered useless. It's almost useless anyway even though it's accurate. The main use of this information is to enable role-playing, so the science officer can say, "Captain, the vessel is fleeing at such and such velocity." and the like. As for the physics, we don't know those values to such a precision that Heisenberg's uncertainty principle would come into play.

I'm not going to address all your other suggestions in this issue individually right now, but I'll come back and consider them later.

possibility of future third-party client development

Ha, sure, that'll happen. You're very optimistic.

[heaventwig]

I'm not going to address all your other suggestions in this issue individually right now, but I'll come back and consider them later.

Would it help for me to factor them out into separate logical chunks?

The answer to this seems like pretty obviously yes; I guess my question is more "would it get in the way of your fun here, or make anything harder for you, to have these as separate submissions? Am I right in thinking it would more likely help?"

But I wanted to check before flooding the issue submission queue and calling this one a duplicate.

[heaventwig]

... fuzzy balls of static ...
You also have to ask about features like this, does it make the game more fun? Or is it just frustrating?

My writeup here was an attempt to address a thing that I've found frustrating with the snis science station, and seen others find frustrating as well: the fuzzy balls of static, and the inability to select anything within them. I figured there was important design intent behind them (my assumption is that it's about modeling the lack of local information about distant objects, plus the vibes of it all), so I was looking for a way to add some functionality to the science station (allow science to select things to scan within the distant undifferentiated clouds) while retaining that. I added some ideas about how the underlying code might work because I tend to think in those terms (how would I do this) before suggesting a thing.

But maybe it's worth checking my assumption: is it important to you that science not be able to differentiate distant stuff that's either outside scanner range or not been scanned recently?