Developer Insights #7 - KSP 2 UX Architects

[Guest]

https://www.kerbalspaceprogram.com/dev-diaries/developer-insights-7-ksp-2-ux-architects/

I didn't see any post of it just yet

Edited November 28, 2020 by Guest

[pandaman]

[snip]

UX/UI is a very under appreciated aspect.   As a (sort of) engineer I appreciate function over form.   Important  as form/aesthetics  are, especially  for games, if it looks pretty, but doesn't function efficiently then it spoils the overall experience  and fun. 

Edited November 28, 2020 by Vanamonde

[klgraham1013]

Definitely something that needed improving from KSP1.  One of my big pet peeves.

I got bronze.

Edited November 28, 2020 by klgraham1013

[The Aziz]

I got green as a kid I was always saying that 4th place gets green medal

So anyway I hope they do it right. Especially after people being mad for no reason for navball not in the middle. I still stand by my words, from when we got to look at it for the first time, the UI looks good, it's ergonomic and everything useful is one place, maybe needs some slight tweaking, but digital font is terrible and confusing.

Edited November 28, 2020 by The Aziz

[K^2]

UI/UX is hard. Glad to see the Intercept has people who specialize in it working on making UI better. Best of luck to them.

[Bej Kerman]

Probably one of the biggest reasons players might feel dumb or slow is the UI. Having the altimeter, speedometer and various other important tools scattered around, like a spilled bag of peanuts on the floor of a cheap cinema in Britain, the country of the hillbillies who can't use bins for their lives, makes the player feel slow and leads to them having to dart their eyes around - Top center, bottom center, bottom right, top center, bottom center, bottom right, kaboom because you didn't stop to think about your trajectory and couldn't disable the retrograde SAS and switch to radial out in time leading to it flipping the craft. The KSP 2 UI clearly addresses this, having the UI compacted and in one place while the more useless things are placed further away, so that the player only has to dart around if they have no clue about the staging and never bothered to memorise it, or if they're too busy fixating on the Kerbals' expressions. 

[snip]

Edited November 29, 2020 by Vanamonde

[Alexoff]

It is not at all clear what this post is for. Is it about developers trying to make a good user interface? It is a pity that screenshots from ksp 1 are shown as an illustration

[Vanamonde]

Some comments removed. Keep it on-topic, please. 

[starcaptain]

One subtle thing I can think of when it comes to camera action in the UX: subtle but it bothers me.

Camera shake.

Camera shake as it existed in KSP1 only made sense when it came to explosions or perhaps some collisions. It had the effect of adding some animated noise to the position of the camera with reference to the player's movement handle. The shake made no sense at all when the vessel was experiencing high-G  load or high velocities in-atmosphere. In those conditions, the shake would make more sense as some kind of pull or lean in the direction of the forces. How to implement that, I'm not sure. But I always think of one scene in a movie that did that trick well: The Polar Express.

Notice how the camera gets pulled down. That's the visual feel I'd hope for.

 

[K^2]

3 hours ago, Alexoff said:

It is a pity that screenshots from ksp 1 are shown as an illustration

Such is the life of UI/UX designers. Almost all of their work is done in mockups, because there is nothing for the artists/engineers to implement until there is a mockup, and once it's implemented, there might be some tweaks here and there, but it's mostly a finished product. So we'll probably only see mockups in development updates, and then, somewhere down the line, the finished UI will be just there in a future screenshot on some entirely unrelated topic.

[Star-Eagle]

[snip]

On a more on topic note I'm glad to see some of the work their doing on the UX/UI, It's not something I think about very often though it has such a big impact on us as players.

Edited November 29, 2020 by Vanamonde

[Alexoff]

18 hours ago, K^2 said:

Such is the life of UI/UX designers. Almost all of their work is done in mockups, because there is nothing for the artists/engineers to implement until there is a mockup, and once it's implemented, there might be some tweaks here and there, but it's mostly a finished product. So we'll probably only see mockups in development updates, and then, somewhere down the line, the finished UI will be just there in a future screenshot on some entirely unrelated topic.

Apparently the core of the game is still far from completion and now something is being done more complicated than the new models of shadows and lighting

[K^2]

1 hour ago, Alexoff said:

Apparently the core of the game is still far from completion and now something is being done more complicated than the new models of shadows and lighting

Would you have preferred UX designers helped write the physics simulation? Or do you prefer not hiring any until the core is finished, and have development literally take decades?

[MechBFP]

I gotta say it is really nice to see these updates and insights. I really haven’t seen this level of non-indie dev involvement with the community since Morrowind. 

[Alexoff]

1 hour ago, K^2 said:

Would you have preferred UX designers helped write the physics simulation? Or do you prefer not hiring any until the core is finished, and have development literally take decades?

No, I would prefer to know something about the development of KSP 2, and not about the formulation of the problem and general words about their solution

[Meecrob]

40 minutes ago, MechBFP said:

I gotta say it is really nice to see these updates and insights. I really haven’t seen this level of non-indie dev involvement with the community since Morrowind. 

I agree. I know some of us want some sweet screenshots or notes on new features/parts, but I very much enjoy these "Here are the areas we know are crap in KSP1" type notes because those are the difficult things to fix and its great to see them getting attention.

[pandaman]

11 hours ago, Alexoff said:

No, I would prefer to know something about the development of KSP 2, and not about the formulation of the problem and general words about their solution

But, the article was entirely relevant to the development of KSP2.   And far better to have some info, to reassure us that development is still happening, than silence because there is nothing 'new and cool' ready to show yet.

It may not be 'juicy, exciting' stuff on gameplay, but it is vitally important to the overall player experience.  And, for me at least, it is encouraging to see they are putting effort into that aspect of it.

Edited November 30, 2020 by pandaman

[Bej Kerman]

46 minutes ago, pandaman said:

It nat not be 'juicy, exciting' stuff on gameplay, but it is vitally important to the overall player experience.  And, for me at least, it is encouraging to see they are putting effort into that aspect of it.

As I've said earlier, the worst part about the KSP 1 UI is the interface, as much as I'm going to get hate for this from people wearing rose-tinted shades. It's vital that the devs do the UI properly. The only thing that concerns me is that I don't think anyone has been talking about what will happen during major updates when the UI has to be expanded - I don't want them to fall into KSP 1's trap of stuffing everything into a corner where the UI element may be somewhat relevant (case in point, advanced orbital info / maneuver node interface). UI should be made to be expanded without things becoming lost in there.

[starcaptain]

I can imagine how daunting the UI/UX task must be for Kerbal Space Program 2. There is A LOT of information to convey even to do something pretty basic.

Simplification and streamlining such an interdisciplinary field as play-toy rocket science means there's so many things that must be explained easily through text, sight, sound or action, without sacrificing accuracy of the ideas they're related to.

Multiplying that requirement by the number of technologies that are counterintuitive to everyday life (MOST OF THEM) and then another heaping helpful that are speculative and based on future ideas that haven't even been built yet, sheesh.

[The Aziz]

5 hours ago, starcaptain said:

Multiplying that requirement by the number of technologies that are counterintuitive to everyday life

xkcd for the rescue once again

 

[Nate Simpson]

There is actually something quietly revolutionary being shown in that mockup: the addition of visible surface attach nodes (that little round bean on the right side of that fuel tank) makes vehicle construction significantly more user-friendly. I think I played KSP for a few years before I realized that there is in fact an invisible, but very real, third node on radially-attachable parts that exists alongside the visible stack attach nodes at each end. Being able to see that node, and representing it differently from stack nodes, helps the player understand why when they attach something radially it may suddenly rotate 180 degrees, or why it'll get a good connection when offset from its parent by 8 meters, but not by 9 meters. 

Little improvements like this do accumulate, and the devil is absolutely in the details. It's Levin's job to obsess over these incremental adjustments, but once you actually get your hands on the game you'll see how well it pays off.

As a side note -- especially with UX/UI design, we very often use screenshots from KSP1 as a baseline. As others have correctly speculated, using areas of the game that are under construction just adds new variables to track, and Levin doesn't want to have to spend additional time clarifying what's part of the official plan and what's just a bug. This is a much cleaner way of handling mockups.

[Bej Kerman]

1 minute ago, Nate Simpson said:

There is actually something quietly revolutionary being shown in that mockup: the addition of visible surface attach nodes (that little round bean on the right side of that fuel tank) makes vehicle construction significantly more user-friendly. I think I played KSP for a few years before I realized that there is in fact an invisible, but very real, third node on radially-attachable parts that exists alongside the visible stack attach nodes at each end. Being able to see that node, and representing it differently from stack nodes, helps the player understand why when they attach something radially it may suddenly rotate 180 degrees, or why it'll get a good connection when offset from its parent by 8 meters, but not by 9 meters. 

Little improvements like this do accumulate, and the devil is absolutely in the details. It's Levin's job to obsess over these incremental adjustments, but once you actually get your hands on the game you'll see how well it pays off.

As a side note -- especially with UX/UI design, we very often use screenshots from KSP1 as a baseline. As others have correctly speculated, using areas of the game that are under construction just adds new variables to track, and Levin doesn't want to have to spend additional time clarifying what's part of the official plan and what's just a bug. This is a much cleaner way of handling mockups.

What do you say about the expandability of the UI?

[Zimm]

Levin is a BADA55 and I'm glad he finally gets to share a tiny slice of the super difficult and iterative work he and his team have been doing.
He has helped me grasp aspects and details of the game I never even knew were there.

[Guest]

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.

[Soda Popinski]

On 11/30/2020 at 11:22 AM, 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.

True.  At least we're starting to see consistent locomotion, or at least the option for consistent movement control.  For those who don't VR, teleport is the most comfortable method, but in the early days, it might be done with pressing down on a joystick on the hand controller, or a button, on either the left or right hand.  The landing spot might be a straight line, or it might be a parabola like you're tossing a ball.  In the non-teleport at this point, it's typically left controller joystick control, but even that has some variety, including relative to your hand (what I prefer, pioneered in Onward), but there's also relative to where your head points.    There was also one where you swing your arms like your walking to move forward.  I think Creed had you roll your hands over each other like a cartoon boxer.

If I'm playing Population: One, I reload and charge my weapon with the grip button.  If I'm playing Pavlov, I do the same with the trigger button.

Imagine if FPSes didn't use the ASWD + mouse convention.

Edited December 2, 2020 by Soda Popinski