Developer Insights #18 - Graphics of Early Access KSP2

[Guest]

37 minutes ago, mattihase said:

I don't have the greatest degree of happiness about the state of unity.

I don't know ANYONE who has the greatest degree of happiness about the state of Unity! It's less a game engine than a collection of modules flying in loose formation (with some of them falling off mid-flight)

More seriously, I think there is a very real market opportunity there. Unreal is super expensive to develop on (at scale) because you pretty much need Perforce, the build system is super complex, and the minute you need to do something that can't be done with blueprints you need C++ coders who are expensive. Unity is just about the only other game in town if you want to do something that's at least AA ambition level. Unity has acquired or developed a quite a lot of really impressive tech but has done a terrible job of integrating it into a single product. It's a shame they killed their internal game project, if they had actually used it in-house to develop something reasonably big all the way to deployment and maintenance, there's a good chance they would have upped their game about that kind of thing.

I also really don't understand why they're so coy/expensive about source code access. That's just pointlessly annoying!

Edited March 12, 2023 by Guest

[Starhawk]

A few comments have been edited to remove open discussion of moderator action.

Open discussion of moderation is forbidden by the forum guidelines.  This also means that when a moderator removes content it is not okay to discuss the material or its removal or to refer to it.

Thank you for your understanding
Forum Moderation Team

[Talavar]

 I hate to be "that guy" but well.....I'm not sure why you stuck with unity on this one.  I experimented with unreal 5.03 creating planets and gravity wells using newtonian calculations, and it worked  well. (Granted my makeshift rocket was basically a pencil) Would probably work great in multiplayer if you enable world origin rebasing,. Anyway, my world looked fantastic (fully forested) from any distance, and I had minimal cycle hitches while dealing with gravity and (primitive) drag calculations. 70+ fps using nanite rendering on a gtx 1660 super. My lowest dip was 42 fps and it was while I was quickly swinging my camera over lots of terrain.  I imagine you'd need someone well versed in U5 to implement the map scene calculations though. Atleast - someone way more versed than me. However, I was able to put it all together in about 2 days including the earth and moon.  After that initial trial, I scrapped it and have started working on my own simulator.  It's just a suggestion. You guys already have your assets created. moving over could be advantageous. I'm just one guy, but you have an entire team. I'm sure you could pull it off fairly easily. Now that I've gotten over the learning curve, Unreal feels way less clunky to me than unity. (learning Unreal would be the biggest hurdle)
  You may all now verbally abuse me, and call me stupid for my input.  lol

[The Aziz]

HarvesteR was also a one guy who started his project.

Hey if you feel like it you can continue your work and enter the world of space sims. One that will be looking better than any other.

10 minutes ago, Talavar said:

moving over could be advantageous.

Changing engine after few years of development... I have a feeling that there are more cons than pros. Wonder why you don't hear about such thing when the project is nearing completion...

[JoeSchmuckatelli]

34 minutes ago, Talavar said:

Unreal feels way less clunky to me than unity. (learning Unreal would be the biggest hurdle)
  You may all now verbally abuse me,

These are not bad suggestions - but for the Studio to license and train would be expensive.  Thus, unlikely to happen.

[Talavar]

21 minutes ago, The Aziz said:

HarvesteR was also a one guy who started his project.

Hey if you feel like it you can continue your work and enter the world of space sims. One that will be looking better than any other.

Changing engine after few years of development... I have a feeling that there are more cons than pros. Wonder why you don't hear about such thing when the project is nearing completion...

 But it's not near completion. >.< there's a LONG way to go. and making assets is the one of the biggest part of the work. That's already finished, and can literally be dropped right in unreal with a simple converter..  Though, I'm not expecting them to actually do it. As I said "not sure why they stuck with unity"

Edited March 13, 2023 by Talavar

[Talavar]

39 minutes ago, The Aziz said:

HarvesteR was also a one guy who started his project.

Hey if you feel like it you can continue your work and enter the world of space sims. One that will be looking better than any other.

 That's the dream, isn't it. lol
It does look very good, though I do it mostly as a hobby. I don't know what to add to it though, really. lol.. I guess typical mining and planetary base building would be options, but other than that, I'm just not sure.. lol

[Talavar]

 Some people make some pretty beautiful scenes.

 

Edited March 13, 2023 by Talavar

[Jacke]

44 minutes ago, The Aziz said:

Changing engine after few years of development... I have a feeling that there are more cons than pros.

Changing a game's engine part-way through development is a good way to derail that development and cause other issues.  Noted examples that show this is bad are Daikatana and Star Citizen.  That and much of the rest of this comment are from reading commentary and talking with people I've come to trust and seeing the nature of the base issues.

Many space games have issues that isn't common in any other game type and thus no common game engine deals with well: having both a range of physics and a large range of scales.  It's more the large range of scales.  If you can pan smoothly from the ground to orbit or even beyond, or vice versa, then the game has been customised to handle the radical range of scales at least partly in this visual way.  Just because a game doesn't allow that doesn't mean the issue has been ignored.  Just because it does handle that visualisation doesn't mean the issue has been handled properly.  There are many many issues that come from this and spaces games with it need to address it early in development.  It's a realm where the Kraken lurks and is often encountered.

The key thing when picking any engine for a space game is often making sure the physics is right at all scales, with solutions being different at different scales.  This is the biggest problem with Unity that it does share with other engines.  Then dealing with physics and the large range of scales needs to be tackled at the start with 3rd-party and custom additions to the base engine.

Anyhoo, these issues make changing the engine of a space game even more fateful than other games, where it is bad enough.  If there are issues with the physics or large range of scales are still causing issues, it's usually better to fix those than change the game engine.  Fixing them will be hard enough.  Changing the game engine is almost guaranteed to make things much worse.

[Talavar]

1 hour ago, Jacke said:

Changing a game's engine part-way through development is a good way to derail that development and cause other issues.  Noted examples that show this is bad are Daikatana and Star Citizen.  That and much of the rest of this comment are from reading commentary and talking with people I've come to trust and seeing the nature of the base issues.

Many space games have issues that isn't common in any other game type and thus no common game engine deals with well: having both a range of physics and a large range of scales.  It's more the large range of scales.  If you can pan smoothly from the ground to orbit or even beyond, or vice versa, then the game has been customised to handle the radical range of scales at least partly in this visual way.  Just because a game doesn't allow that doesn't mean the issue has been ignored.  Just because it does handle that visualisation doesn't mean the issue has been handled properly.  There are many many issues that come from this and spaces games with it need to address it early in development.  It's a realm where the Kraken lurks and is often encountered.

The key thing when picking any engine for a space game is often making sure the physics is right at all scales, with solutions being different at different scales.  This is the biggest problem with Unity that it does share with other engines.  Then dealing with physics and the large range of scales needs to be tackled at the start with 3rd-party and custom additions to the base engine.

Anyhoo, these issues make changing the engine of a space game even more fateful than other games, where it is bad enough.  If there are issues with the physics or large range of scales are still causing issues, it's usually better to fix those than change the game engine.  Fixing them will be hard enough.  Changing the game engine is almost guaranteed to make things much worse.

This is exactly the problem I was pointing to with "world origin rebasing" Good catch there. It shows you understand the basic problem with vast scales. Once you hit the decimal cap, you get planets in large orbits ticking kilometers instead of centimeters. There are of course ways to correct this, it's just a matter of implementing them with close quarters smoothing.  basically when you get close it detects tick ratings and distance traveled, then creates sub-plots between them and moves them smoothly.  Ive found another way around this, simply by reducing all models' sizes by 1000 and dividing all distances by the same amount. This saves decimal space. basically you put the planets into decimals to take decimals away from the orbits while keeping the base relative scale intact.

Edited March 13, 2023 by Talavar

[radimov]

I've been working with Unity for years and I love it, it's comfortable to work with and you can get the result you want without much frustration.

The opposite happens to me with Unreal, it is orthopedic and uncomfortable to work with, there is also something that I find especially unattractive about Unreal, it has something in the shaders, lighting and materials that as soon as you see a game you know it is made with it, I do not like it, it is impossible to get rid of that smell of Unreal.

But it's just a personal opinion, I know many people who are happy with Unreal and have got used to work with it and like it, I didn't get it.

[linuxgurugamer]

On 3/10/2023 at 4:00 PM, Intercept Games said:

As a sidenote, despite how much we love you modders, this change will definitely break most visual mods (sorry modders, sometimes we must hurt the ones we love). 

Since there aren't ANY visual mods yet for KSP 2, this is the best time to do it

[zeekzeek22]

Hmm. This fits in pretty solidly with what I thought was up...using a revamped version of KSP1's shader during dev with the intention of adding a schmancy shader later in development, but getting a bit jumbled with an unexpected EA...since you don't need fancy terrain to make your interstellar physics sim. But I'm then confounded about the relationship with the artist team...if the terrain artist teams really needed to know/have the shader tools to do their work, that throws my whole idea out the window, and implies they should have moved on to CBT as soon as the artist started needing it to make assets. (laughing at how many people on this forum knows the "other" meaning of that acronym....as a psychology guy I remember naively going "why is everyone talking about Cognitive Behavioral Therapy?")

[RocketRockington]

On 3/12/2023 at 12:53 AM, Periple said:

Since you’re an experienced game developer who’s worked at lots of studios and are talking directly to the C-suite about your own concept, can you share some of your experiences looking at work in progress? In general, in your experience, when a game hits alpha, how does its performance compare to final targets? What type and kind of bugs do you expect to encounter? How does the visual fidelity compare to what you expect to see on release? How is the game balance?

So - it can vary quite a bit.  I realize that's not a satisfying answer so I'll give some examples.

For instance, some friends at Turtle Rock let me test the Alpha build for L4D way back when.  It was the best Alpha game I'd ever tried.  They only had the one level working and maybe one special zombie type, but it was amazingly fun, worked great in multiplayer - but it had limited content.  There's a reason Valve partnered with them soon after.   I genuinely wanted to stay and try it more afterwards.  (This is the sort of impression you'd have of KSP2 if you only listened to Nate talk about it) 

Almost all Alphas are not that - most projects I've worked on, needless to say, are in worse shape than that. 

First, there's a question of 'even though you're calling this alpha, is it really'.   I'd say most games, especially less well managed projects, tend to do some sort of sliding alpha where management is calling it alpha but actually you're still in production on some/many features.   Those projects tend to be the worst to deal with because often management is trying to pretend things are further along than they are, and the notion of having a feature-complete but content-incomplete game that you can start tuning, testing, and iterating as part of good game development practice has fallen by the wayside in favor of arbitrary management milestones (guess which style of Alpha KSP2 is in? )

Second - how buggy are you.  Most games in alpha are not constantly crashing bugfests  as you'd suspect, but there are areas of the game that may be 'here be pirates' - places that only the dev(s) involved are navigating successfully.  But still, the core of the game is stable, on a project that is doing ok.  Because what you want as a developer is stability to be able to work, rather than a bunch of side-issues hampering you.  Core stuff like, for instance, save-load is often made as bullet proof as possible so QA can hand you a save that points to an issue, for instance - games that are properly managed aim to be stable enough in the feature set that - especially for the content team who don't run the game from a local dev build, aren't losing time.   

Of course I've been on projects where the alpha IS a crashy bugfest, and those are painful to work on, and usually get delayed a lot, at best.  In a well managed process though, even if the bleeding edge of the build is unstable, the content team is still working with a stable version that may be days or sometimes even a week old.

Third -  on game balance - typically what is missing from alpha is the overall fun.   The content hasn't been tuned, designers haven't managed to iterate on things, features maybe work in silo'd isolation but need to be integrated.  Alpha is often when the design team gets to see just how well or badly their predictions on things coming together really works, you can't hand wave things anymore.   

But that said - there are typically pieces of the game that feel fun - if you're not seeing at least sections of it being fun, especially the 'core loop' you're probably in trouble 

That's another reason Alpha being feature complete is important.   And as Alpha progresses, if the design team knew what it was doing, the game as a whole gets more entertaining.  If you don't have the full feature set that you expected to have to support the gameplay pillars, though, designers can say 'oh, that parts missing, if we just had that it would be fun' and a project can limp through alpha still sucking.

Fourth - on visual fidelity - It varies.  Often you'll still see a bunch of missing assets. ut you'll also see parts of the game that are at full fidelity - especially if you did your proper due diligence through the stage gate process, at least one 'vertical slice' of your game has remained functional to show the game in a close-to-final state.   This can be difficult with games that are more sandbox than level based, but I'd say, for instance, in KSP2's case, one full-fidelity planet working at expected frame rate would have been a reasonable vertical slice for that.  Also the game is not fully optimized, but it's usually 'close enough' - within a factor of 2x (this is a rule of thumb of course, not a law).  If you're outside a factor of 2x of your target frame rate on target hardware, that means something needs more than just tweaking to reach it. v

Fifth - how does this compare to KSP2.  Well, KSP2 is in a weird state.  Pieces of it I'd call Beta - buggy but finished essentially.  The VAB, for instance.  The flight UI.  And some aspects of it - like the terrain rendering performance - should have been addressed earlier in the process, as they are fundamental to the game.   Pieces of it are missing completely from the release build.   In many ways what the release version of KSP2  is now is more like a vertical slice than an alpha product.  Depending on who you'd ask, I don't think it's even an 'MVP'.

KSP1 of course followed a similar course - it was developed in the meandering process of many indie games - a process that can yield good games, but more often than not its through Darwinian methods, rather than the less-failure prone structured processes that professionals typically try to use.  Professional studios cannot afford to have the failure rate that indie developers do, after all.

Hopefully this gives you some insight, let me know if not.  I'm never quite sure anymore how familiar people are with certain terms, but I'm trying not to use too much jargon.

[cocoscacao]

@RocketRockington And your thoughts on this PQS -> CBT transitions at this stage are? If you already wrote something about it, just point me to that post.

[RocketRockington]

1 minute ago, cocoscacao said:

@RocketRockington And your thoughts on this PQS -> CBT transitions at this stage are? If you already wrote something about it, just point me to that post

Some discussion has happened here.

 

[IronGremlin]

3 hours ago, RocketRockington said:

In many ways what the release version of KSP2  is now is more like a vertical slice than an alpha product.

Yeah I think this basically explains more or less everything about the current state of KSP 2.

It is a vertical slice demo that got hijacked into an MVP and then pushed to EA launch.

To be fair it's not a bad strategy for developing a piece of software - In a lot of domains that basic story is considered best practice.

And case in point KSP 2 got to "skip" a lot of the fine tuning and design iteration that made sense for KSP 1 - it seems self evidently true that it could've used some more polish prior to release, but it also seems pretty evident that most of that polish was already in flight prior to release.

AFAICT the 'culprit' here, such as there is one, appears to pretty clearly just be that schedules either slipped, or were victim of 'deadline acceleration' - I don't see a whole lot of evidence of mismanagement of the project as far as "where they're putting energy."

I anticipate you and I will disagree on this point, but I can understand why terrain performance is where it is - It's a massive problem to solve and they were way too late to hold release up on it. Reading between the lines it seems clear to me that they prioritized unblocking the art department over polishing performance - which is IMHO just a smarter business decision.

The choices were: "fire half the art staff and then maybe re-hire them later but probably not" vs. "hold up the release AGAIN in the middle of a pretty serious recession" vs. "release now and pray" -

Even considering foreknowledge of how bad this release was, if that was my set of choices, I would've picked the last one and ate the consequences.

 

[RocketRockington]

1 minute ago, IronGremlin said:

AFAICT the 'culprit' here, such as there is one, appears to pretty clearly just be that schedules either slipped, or were victim of 'deadline acceleration' - I don't see a whole lot of evidence of mismanagement of the project as far as "where they're putting energy."

Disagree here, as you suspected.  They put a lot of time into tutorials, UI, and random polish (eg: sparks when you attach parts in the VAB) than in core fundamentals, like save load. 

I'm not saying those aren't important - but because those things are leaf node features rather than things other parts of the game directly build on, they should have received less polish at this point - someplace much less than a finished product - than they clearly did.  

[whatsEJstandfor]

2 minutes ago, RocketRockington said:

Disagree here, as you suspected.  They put a lot of time into tutorials, UI, and random polish (eg: sparks when you attach parts in the VAB) than in core fundamentals, like save load. 

This implies that the UX designer or the artist who created the weld sparks effect were the same people responsible for making sure saves worked.

[RocketRockington]

7 minutes ago, whatsEJstandfor said:

This implies that the UX designer or the artist who created the weld sparks effect were the same people responsible for making sure saves worked.

I knew this argument would come. 

No.  This implies that the project management who staff the project focus on hiring people who can develop core features before hiring people that develop secondary features.   That's why good project management includes a staffing plan.

You don't get handed a random group of workers like some kind of MTG draft and get told to make what you can with them, you hire specifically for what's needed, when it's needed.

[Astro648]

The future looks bright for KSP2 despite the bad launch. I'm very excited, good luck with these new features!

@RocketRockingtonI get your point, but one thing that should be noted is that tutorials ARE a huge part of KSP2, they've said this many times

[RocketRockington]

27 minutes ago, Astro648 said:

The future looks bright for KSP2 despite the bad launch. I'm very excited, good luck with these new features!

@RocketRockingtonI get your point, but one thing that should be noted is that tutorials ARE a huge part of KSP2, they've said this many times

Whatever they've said, having a functional game is more important.  They shouldn't have put so much emphasis on the tutorials given that they've failed to deliver a game with reasonable performance and low bug count - better tutorials could have waited till the 1.0 release - which is really when they should have advertised to a broader audience, instead of doing a marketting push right at launch.   Anyone who wasn't already excited  by KSP2 and full of hope for the future certainly must have bounced off the terrible reviews, or refunded and left with a terrible impression.  This was not a release to expose 'new users' to.

Edited March 15, 2023 by RocketRockington

[The Aziz]

At least they can get feedback on them as well before "new players" arrive.,

[Superfluous J]

3 hours ago, RocketRockington said:

They shouldn't have put so much emphasis on the tutorials given that they've failed to deliver a game with reasonable performance and low bug count

Aren't the tutorials just videos? For all we knew they were done in 2019.

[aNERVASman]

2 hours ago, Superfluous J said:

Aren't the tutorials just videos? For all we knew they were done in 2019.

no there are playable tutorials too