Developer Insights #7 - KSP 2 UX Architects

[Chilkoot]

On 11/30/2020 at 2:22 PM, Master39 said:

Playing in VR and seeing different game studios pioneering a completely new interaction systems between the game and the player has made me appreciate the work of UI designers a lot more, the devil is absolutely in the details.

And even 4 years after going fairly mainstream, many aspects of VR UI's are still not really settled, driving home how difficult it is to really get these things right and feeling natural.  We've kind of progressed from "no man's land" to "wild west", but even core mechanics like inventory management, object interaction and locomotion are still not nearly as settled as the analogous systems in established pancake genres like FPS or RTS.

Nate's been playing it coy on VR support in KSP 2, with - as far as I'm aware - the most recent response being "We'll see".  With so many different views and interfaces (VAB, EVA, In-Flight,  Map, Tech tree, KSC overview, etc), it's probably unrealistic to expect VR support in KSP 2 on day one, though it would also be pretty short-sighted to not keep it on the table for a future release.

Off-topic, an even bigger bugbear in VR game and media design is story telling.  There is no "Five C's of Cinematography" for VR, being an entirely new medium.  In 2015, at VR content developers' conferences, over 50% of the keynotes were related to storytelling challenges.  It was the same in 2020.  Directors are still trying to figure out how to tell a story in VR in a consistent and engaging way (though there has at least been some progress).  We have really strong and established methods to do this when a person is staring at a rectangle filled with images, none of which really carry over to a fully interactive environment where we don't control the camera.

[Dunbaratu]

For the sake of modders, one thing I hope KSP changes about the UI/UX is to have a much stronger wall of separation between what is UI code and what is API code.  So the UI's only job is to talk to the API that really enforces the rules, rather than the UI code itself doing it.  I've run across frustrations in the past modding for KSP 1 where I've had to re-implement KSP's main rules again in my own code (which is an awful and not future-proofed at all way to do it) because when you talk to the API directly and don't click on UI windows, you are skipping parts of the rules that are done by the UI.  Like fuel transfers.  Those little windows that pop up with the "in" and "out" buttons control rules about whether you can transfer fuel between tanks and how fast the transfer is allowed to flow.  So if I try to have a mod that triggers the fuel transfer a different way, not through the main UI, it lets players cheat and bypass the rules which isn't the intent.  Another example is that it refuses to update the KSPFields that describe Breaking Ground's robot part servo positions (i.e "this hinge is at 45 degrees") if the UI window that would display them to a user is not open.  If you're not a player trying to read that field but instead are a mod trying to read that field, there doesn't seem to be a way to tell the system to give you an updated calculation of that field other than forcing the window open for a moment to trigger the UI code that updates it.  These are a couple of example, but that's the general idea.  It's sometimes hard for a modder to sneak in under the UI code to accomplish the same thing the UI code does, when some of the main game's logic is inside the UI code itself.

Basically that wall I'm talking about is a design principle where you view the UI/UX code as "one of several mods".  They are *one way* to talk TO the game, rather than BEING the game.  Given that they say they plan to do multiplayer I have high opes that this might happen.  Multiplayer probably needs the same principle in place so that the server decides what is physically doable rather than the UI code in each client being in charge of that.

[OvinandRusk]

oh