TablesRUs

Yes, I always found it very strange that a energy-centric approach wasn't taken from the very beginning; this seems like an obvious beginner's mistake made in the first game and Hamiltonian-esque mechanics really does seem like the natural formulation mechanics in this setting.

I don't understand the point that this comment is trying to make. Until Wube actually announced that they were going to release an expansion (something that happened only in 2021) they were under no obligation to produce anything at all; no one had given them a dime in exchange for progress (nor has anyone today). As of last year they would have been entirely within their rights to say "never mind, the expansion isn't in the cards afterall. Apologies to everyone for raising hopes." Moreover, they did an terrific job of setting expectations, making it exceedingly clear that they did not want to discuss progress until they felt comfortable with doing so, which they explicitly stated would take no less than a year. Around two and a half years after the initial announcement that there will be an expansion, Wube started to open up the faucet of information regarding what they have been working on. Since then there has been a new detailed blog post describing a different facet of the expansion every Friday. The information conveyed in even one of these posts is more than that of any given three month period of communication from IG over the course of KSP2's EA. Say what you will about the individual game design decisions made for the expansion but the scale of the work appears to be worth the wait: the (free) Factorio 2.0 update adds a number of interesting new mechanics, likely eliminates the need for over a dozen quality-of-life mods, and adds features that players have consistently wanted in 1.0. On top of the update, the (for-purchase) expansion likely doubles the quantity of gameplay, offers a noticeable improvement in art quality, and makes use of the new mechanics added by 2.0 in interesting ways. Wube's approach to communication (and development itself) should be a model for the industry. The fact that the expansion has yet to be released is, if anything, a welcome change in a field where shipping minimal (but buggy) viable products with sparse communication and spotty responsiveness to player feedback is all too common. You will likely be waiting until the heat death of the universe as Wube has a hard policy of not offering discounts. The price is the price. Personally, I can say that relative to the time spent using it, Factorio is one of the cheapest things I have ever purchased. If you have the slightest appreciation of automation, optimization, or problem solving I would encourage you to consider just dropping the $35. It is, IMHO, a gem both in its game design and its implementation.

There are signs of improvement here. However, legibility is still lacking and ultimately needs a lot more polish: The ubiquitous use of ALL CAPS text, the continued use of pixelated fonts (e.g. see the "Required delta-v" label in the Trip Planner window) makes it difficult to visually parse this text. It is well-known that spans of capitalized glyphs are less legible than text typeset with proper case (or even small-caps) The strangely inconsistent visual weight of various glyphs (see the delta glyph in Trip Planner) draw the eye to unimportant characters the aliasing-prone, low-resolution iconography (see the various toolbars along the bottom of the interface and unrecognizably-small icons in the Engineer's Report and window titlebars) are distracting yet unreadable and contribute to an unpolished feel More generally, I would reiterate the points made in my previous post on this topic with respect to the difficulty of achieving device independence with this pixelated style. The team is preparing an enormous time-sink for themselves by continuing to pursue this art style. I can only hope the remaining hints of pixelation in the example screenshots are merely awaiting their time for replacement; as others have said, it is time to kill this particular darling.

Personally, I still find the game to be too frustrating to warrant any significant time investment. I share Kerbart's concerns regarding technical debt. It's always hard to judge this sort of thing without seeing the codebase, but the number and, more importantly, kinds of bugs that we continue see in the game are rather concerning. The amount of "spooky action at a distance" observed in the game raises real concerns about the design and maintainability of the codebase. Moreover, while the game is undoubtedly in better shape that it was at release, it is concerning that many of the same classes of foundational bugs that we saw in the first release persist today (or are merely less visible now, in many some cases due to "fixes" that were admitted to be stop-gap). Writing a physics sandbox like KSP will inevitably be difficult; however, the sorts of UI inconsistencies, bizarre VAB behavior, and general bugginess that we see in the game are of a much different flavour than the numerical challenges that are central to this difficulty. This is quite worrying. For instance, the unreasonable effectiveness of "save and reload" as a workaround for the game's other issues suggests that the codebase does not have effective infrastructure for managing state and invalidating cached computation. While ad-hoc management of state seems all-too-common in game codebases, KSP has enough intrinsic complexity that the developers do not have the luxury of being sloppy in this area. A systematic, mechanically-enforced approach to maintaining (and asserting the consistency of) state is essential to ensure the correctness, maintainability, and later extensibility of the codebase. Moreover, addressing architectural deficiencies like this post facto can be extremely difficult. For this reason I am not optimistic that the developers' hopeful statements regarding the timing of the next update are realistic. Even worse, I worry that they will attempt to push to meet their optimistic timeline and in the process continue to build upon---and add additional debt to---an already-shaky foundation. They are no doubt in a hard situation as there are surely pressures coming from above to move the project forward. However, if they are serious about making a title that will remain viable for many years then they need to start making foundational repairs a priority, even if this requires refactoring and significant time. Even more, there have been claims that the game has little-if-any automated test infrastructure. This is very worrying as a project like KSP simply cannot be undertaken confidently without a testsuite. Moreover, testing is not something one can "just implement". Rather, the project must be deliberately structured to be testable. This is not easy and, among other things, requires minimization and careful tracking of state. Given the apparent condition of the game, I find it unlikely that they will be able to solidify the core of the game, put in place sufficient testing infrastructure, and implement the systems that they have promised in less than the 10 months that it took to deliver "For Science!" as claimed. However, continuing to put effort towards feature work while the core of the game is in its current state is only going to cost them more time in the long-run.

See the above post from The Aziz. He provides a good number of examples.

At the risk of venturing too far into the realm of "suggesting solutions", which we were asked not to do: I would hope that IG recognize that this isn't a prudent path forward. The current pixelated interface is very far from being acceptable and will take a considerable amount of work to make it functional across the wide array of devices that they need to support. This is because that by committing to a pixelated style they are giving up a plethora of anti-aliasing techniques which make it possible to produce interfaces that scale easily and clearly to a wide array of display geometries and densities; afterall, most anti-aliasing techniques involve some amount of interpolation, something which you intentionally need to avoid to maintain a crisp pixelated look. This leads to very painful design trade-offs as one must either: compromise the style by trying to remain device agnostic and accepting that users with low-to-moderate pixel densities will see a muddy mess as they lack the resolution to crisply realize the clean lines you intended design graphical elements to target the lowest-common-denominator of pixel density and accept that a (hopefully-small) amount of anti-aliasing will be necessary on some display geometries. However, such an approach significantly limits the amount of screen real-estate and detail that you have at your disposal. Given that users with very low pixel counts (e.g. TVs and low-end monitors) are too common to ignore, this isn't something that users with more modern display devices would appreciate. painstakingly design graphical elements for an array of pixel densities. Naturally, this leads to very difficult decisions (e.g. "should the dot in this icon be two pixel or three pixels at 100 dpi? what about 200 dpi? oh, but this other dot elsewhere needs to be three pixels in its context and yet should have the same weight as a dot which we can only afford to give two pixels..."). There is a good reason why interfaces are no longer designed this way. Some hybrid of the three; this appears to be where we are today, with some features being faithful to the style ("sharp") while others are muddy; some features are needlessly large, while others suffer from awful visual inconsistencies (e.g. some have significantly more visual weight than others which should look similar) Add to this difficulty the fact that it is extremely common to consume the game in compressed form (e.g. via Twitch, YouTube, or Remote Play). High frequency features like those found in the current style are anathema to the psychovisual models on which most video compression schemes are based. It is nigh inevitable that even a well-implemented pixelated style will look like mush via such a channel. Finally, there is the fact that all code has a cost. This is especially true for systems like user interfaces, which are notoriously hard to test and very platform dependent (and made even more so by the pixelated style). Keeping two interfaces in the tree would be incredibly expensive and would split attention in an area of the project which badly needs focus. Ultimately, I can't speak to why IG thought that the pixelated look would be worth the effort given that they had a perfectly reasonably-looking interface concept years ago. It should be clear to someone with a graphics background that the pixelated design was going to be challenging at best, with the result inevitably looking mediocre to at least some targeted players; the best you can reasonably hope for is that it would look "okay" for "most" players. I hope that IG sees the writing on the wall and writes off the current design as an interesting, but ultimately doomed, experiment. This would allow a change of course before more effort is put towards the Sisyphean task that otherwise lays ahead of them. Yes, perhaps this will mean discarding some sunk cost but reverting to a smooth style will almost certainly be easier than the alternative, and will certainly produce a better, more predictable, and easier-to-evolve result.

It doesn't seem reasonable to design UX around the assumption that the product will not behave as designed, especially when we are discussing something as foundational as delta-v calculation in a game about space travel. If this is how UX design was conducted then most UIs would look much different than they do, largely for the worse.

Could you clarify why you think KSP1's approach is preferable? If KSP2's delta-v calculations would be more reliable it seems like the new approach is strictly better. The one instance where I can imagine wanting a burn time instead is in the case of a very small burn, where you plan on using less than 100% throttle to extend the burn duration to improve your chances of precisely hitting the needed delta-v. If this is your motivation then perhaps a better approach would be to instead offer a way to specify the throttle scale which you intend to use for the burn (e.g. on a logarithmic scale: 1%, 10%, 100%). This setting could be equivalent to just temporarily setting the throttle limit of your staged engines for the duration of the burn. After you discard the maneuver plan the respective throttle limits would be returned to their previous values.

Here are a few thoughts from a recent session: In general I find the pixelated interface to be both significantly less legible than KSP1's interface and aesthetically unpleasing The dithered UI elements introduce a significant amount of high-frequency visual noise which make the interface look cluttered and busy The pixelated icons (e.g. in the "apps" toolbar of the VAB) are hard to recognize and suffer greatly from inconsistent visual weight due to apparent aliasing The hard edges of the pixelated style results in very nasty artifacts when video compression is involved. For instance, the following elements appear to be at best a wash of color when I play via Remote Play: the three-arrows icon in the "expand delta-v panel" button of the VAB the "-------" pattern in the title bar of windows (e.g. the part picker in the VAB) the dithering at the edges of the navball The whole effect is not helped by the fact that the style isn't even consistently implemented. For instance, many elements in the VAB use (IMHO far more legible) vector icons. I have large doubts that the pixelated style can be easily implemented across the entire interface in a way that will scale gracefully across pixel densities and screen sizes; for this reason I sincerely hope that the style is reconsidered. Relatedly, text is rather hard to read For instance, the dots in the middle of the "zero" character, coupled with the narrow character width and aliasing, make the character quite hard to discern and add a considerable amount of visual noise to numbers The formatting of numbers (and, in particular, times) is hard to parse, especially coupled with the general text legibility problem. For instance, consider the "time-to-point" indication of the maneuver plan interface. This particular case is especially bad as the interface insists on padding each number with leading zeros; one is therefore faced with walls of text like "T+000y, 000d, 00:04:22". The amount of visual noise makes this element nigh unreadable. The monospace font coupled with the pixelated style and aliasing render the "APPS", "ORBITAL INFO", "TIME WARP", "VESSEL RESOURCES", etc. window labels unreadable, especially when video compression is involved. Similarly, the system/planet/craft label in the top left corner is illegible due to its small size and typeface The VAB Strangely, disabling the fairing of an engine plate (e.g. MEM-125) in the parts manager also hides the "length" field, which controls the position of the interstage node. This seems like a bug; perhaps the interstage node should just cease to be if the fairing is disabled? The fairing editor is a regression in usability relative to KSP1 as each adjustment of the fairing's width or height requires a separate click-and-hold operation (after moving to the appropriate arrow widget, no less). This is particularly painful as I often find myself iterating several times on each dimension. While I haven't dared to build large enough craft to run into this yet, I fear that the stages in the stage panel are far too large; it's not uncommon to have often ten stages with several parts in each; this fits comfortably on the screen height in KSP 1. Currently I can fit at most a dozen parts/stages on the same screen in KSP 2. The part details given in the extended ("Shift") view of the part picker are not nearly as complete as they were in KSP 1. For instance, I know of no way to clearly determine whether an aerodynamic part will function as a control surface. It is currently possible to zoom "through" the vehicle you are constructing. This should not be possible. Zooming in should "center around" the vehicle that you are currently editing. It would be nice if there were a way to move up/down the craft using just the keyboard as middle-click-dragging with the mouse is rather RSI-inducing. The "delta" character in "delta v" label in the delta-v panel is strangely heavy compared to the "v" it sits next to The contrast of the text of the "part details" panels is both too high and too low. The light-grey-on-dark-grey text can be hard to read due to low contrast while the white-on-dark-blue text in the extended details panel (as seen after pressing Shift) is a bit too high-contrast. The heuristics for reconstructing staging after picking up and and re-placing a portion of a vessel seem far worse in KSP 2 than 1 (which was already pretty bad in this regard) Positive: The "ball" showing the location where the mouse has "grabbed" a part is a great improvement compared to KSP 1, making it much easier to tell where a part will be placed after you drop it. Positive: The "blueprint" view is a brilliant addition The flight view The text on the navball is quite blurry and is very hard to read. The positive/negative signs in from of the time-to-ap/pe are far too hard to see (c.f. notes above on text legibility). This had lead to more than one failed orbital entry. It is not possible to determine resources' rate of change in the "vessel resources" window. This makes it very hard to tell whether you can safely time-wrap. The parts manager While it can at times be a useful overview, but too often I find myself wanting to persistently focus on only a subset of the parts of the vehicle (either to actively manipulate or passively monitor). For this use-case the current design is a significant regression compared to KSP1. In general the information density of the parts manager is low. At most I can fit two parts' of information with my screen height; this is simply not enough. This is in part due to the very general vertical padding given to elements in the window. The map view The "splashes" on entering/leaving a sphere of influence are great. However, it can be very hard to remember which splash is entering and which is leaving. Reading the, e.g., time-to-periapsis label after "pinning" the periapsis is nigh impossible. The label will typically look something like "T-0yr:0d:01h:04m:18s". The jumble of letters, numbers, and symbols, coupled with above-noted visual noise and small size make it very hard to determine the time, much less to do so quickly. There needs to be some way to filter the vessels shown on the map view; even in KSP 1 it was very hard to clearly see and select the desired vessel in during a long playthrough. Maneuver plans: It's quite unclear why one cannot plan more than one maneuver plan at a time; presumably this is just a temporary limitation but it is certainly a serious regression that makes mission planning quite hard Manipulating maneuver plans is very hard; there needs to be a way to manipulate the maneuver gizmo without having the burn-point on screen. I often want to adjust a maneuver while focusing on the destination of my burn; this is simply too hard to do as-is. KSP1's use of a separate window for the maneuver gizmo wasn't great but at least made this possible. Currently it is very difficult to reliably make precise adjustments to a maneuver plan. While pulling on the arrows of the maneuver gizmo is a bit more predictable than the same operation in KSP1, the lack of the range slider means that you are limited in dynamic range. It is impossible to determine even qualitatively which directions a particular plan spans. For instance, if I accidentally "pull" on, e.g., the radial axis, I have no way to know this, much less accurately correct for the mistake (short of deleting the plan and starting over) There is no reason to disallow maneuver plans that exceed the craft's available fuel; this limitation is quite baffling to me The burn timer: The burn timer interface needs to mention how much delta-v is needed in the burn When one "over-burns" the "progress bar" should, e.g., change color; currently it is very hard to tell on which "side" of the end-of-burn on is currently on as one approaches the end Positive: The fact that burn calculations account for burn time start-of-burn indication is excellent.