KSP2, same old same old

[linuxgurugamer]

5 hours ago, whitespacekilla said:

, I don't think much will change game engine wise without a total re-write (which I also don't really want to see because so much that was found in KSP1 would be lost in a re-write). I'll buy KSP2 when the KSP1 community starts to fade.

Star Theory IS doing a total rewrite.  KSP is just too old with too many compromises.

However,  the good news is that the developers are all KSP players with a lot of passion for the game.  

They are definitely keeping the spirit of the game while making it better.  Among other things, think about much larger ships on mid level hardware. I'll be talking about it on my stream Sunday evening 

[whitespacekilla]

39 minutes ago, linuxgurugamer said:

Star Theory IS doing a total rewrite.  KSP is just too old with too many compromises.

However,  the good news is that the developers are all KSP players with a lot of passion for the game.  

They are definitely keeping the spirit of the game while making it better.  Among other things, think about much larger ships on mid level hardware. I'll be talking about it on my stream Sunday evening 

VERY interesting. Will you be able to describe the platform/engine, mod support mechanisms, etc.? I didn't think any of that would be interesting because I assumed pretty much the same codebase.

[linuxgurugamer]

3 minutes ago, whitespacekilla said:

VERY interesting. Will you be able to describe the platform/engine, mod support mechanisms, etc.? I didn't think any of that would be interesting because I assumed pretty much the same codebase.

It's still Unity, probably the current one.  Mod support is undefined,  but we let them know what we needed /wanted as modders.  Don't expect any mods to be ported, it's going to be a total rewrite.

[Superfluous J]

7 hours ago, Clockwork13 said:

I'd like to be wrong on that though

Prepare to like that part of it. You never ever optimize a program before you're done adding features (unless you need to release before all features are in, and in that case ew. That sucks), for much the same reason that you don't move your furniture into your house before you've finished building it.

Looking at that footage and saying "It looks choppy and slow" is like looking at the framework of a house and saying "That looks drafty."

2 hours ago, linuxgurugamer said:

After meeting the developers behind KSP2, asking questions, I am feeling a lot happier.

I'm  in Seattle for Pax West, and met with Private Division and Star Theory today.  Really hyped

Any chance we'll see some footage of your conversation?

Edited August 29, 2019 by 5thHorseman

[linuxgurugamer]

16 minutes ago, 5thHorseman said:

Any chance we'll see some footage of your conversation

Unfortunately, no.

I'll be talking about it on Sunday.

[Guest]

11 hours ago, whitespacekilla said:

So far as I understand it, this is a problem endemic to unity games. It's difficult (time consuming and not always doable) to use unity's engine and tools to create "perfect joints". Especially in dynamic contexts (like where joints are created dynamically between editable parts...).

No it's not. Joint rigidity is fully adjustable and it's also possible to weld parts into a single physics part. There are mods for KSP that let you do this already.

[Boris-Barboris]

15 hours ago, Delay said:

Optimization is one of the last steps. First you want to make sure that everything's running at all, then you can worry about framerates.

Optimization must be started on design stage, because:

1). "Running at all" is only one part of the goal, "running correctly and fast" is the goal. Games are not business software where you can just wait, performance is critical and is part of business requirements.
2). Performance requirements shape the set and scale of features that can be running. You DO design gameplay around performance, then you make gameplay correct, then you tune constants to converge to acceptable compromise.
3). Multiplayer MUST be completely shaped by performance requirements. There is a very small, strict subset of normal gameplay loop that can achieve good multiplayer performance in KSP-like game. Performance is the master here, not what the people want.

Low performance of demo is a red flag. You have no need of debug build or debuggers running in background to film a small gameplay teaser. In fact, you absolutely want to get as smooth a video as possible, and developers failing to do so is not a good sign. I mean, come on, at least lie and speed up the video to create an illusion of 60fps.

Rapid verbal evasion maneuvers on multiplayer and Linux questions are another red flags for me. There is no "later", such things shape the whole project from it's core. They must be certain at this point, and if they're not, they're gonna crash and backpedal on release. And if they are certain and design is shaped at this point, why withhold the information.

I'm afraid I'm even less than sceptic at this point, but I wish the new team best of luck, we're all counting on them.

[Delay]

1 hour ago, Boris-Barboris said:

Optimization must be started on design stage

If you do optimization first you have no idea what requirements you are optimizing for. And if there is too much going on, even after optimization, then you can still cut that content.

Like some games do, just before release.

[DStaal]

1 hour ago, Boris-Barboris said:

Optimization must be started on design stage, because:

1). "Running at all" is only one part of the goal, "running correctly and fast" is the goal. Games are not business software where you can just wait, performance is critical and is part of business requirements.
2). Performance requirements shape the set and scale of features that can be running. You DO design gameplay around performance, then you make gameplay correct, then you tune constants to converge to acceptable compromise.

I will admit good design is also necessary, but optimization is not the same as good design.  You're talking about good design, not optimization.

Optimization is taking the current design and looking for the chokepoints, then dealing with them.  Yes there are limits to what that can do without changing the design - but a 25% performance improvement overall wouldn't be out of line either.

If the performance stinks at launch, then there's a problem.  At this point it's still under active development.

[Boris-Barboris]

1 hour ago, Delay said:

If you do optimization first you have no idea what requirements you are optimizing for. And if there is too much going on, even after optimization, then you can still cut that content.

Like some games do, just before release.

"60 fps on this particular test PC in this 20 game situations" is a valid requirement. I refuse to accept this "optimize later" doctrine, it reeks of webdev oversupply-induced absolutism. There are methods to budget frame time to different subsystems. Prototypes gives reliable estimates on how much does a feature cost. Yes, it is work, but it must be done: fps is a requirement.
Not to mention the obvious downsides of late-stage content-cutting is inefficient (you've spent months on content that is not shipped) and sometimes unethical (false advertizement, trailers feature some other game, not the one you ship).

1 hour ago, DStaal said:

I will admit good design is also necessary, but optimization is not the same as good design.  You're talking about good design, not optimization.

Optimization is taking the current design and looking for the chokepoints, then dealing with them.  Yes there are limits to what that can do without changing the design - but a 25% performance improvement overall wouldn't be out of line either.

If the performance stinks at launch, then there's a problem.

That's why you optimize early, to optimize design. 10 fps + 25% is still 13 fps.

1 hour ago, DStaal said:

At this point it's still under active development.

I've never seen a trailer to the game lag and then the game shipping with no performance problems. Something's gotta be wrong. I seriously hope it's just too many trees with no LOD in the background.

Edited August 29, 2019 by Boris-Barboris
math, lmao

[Delay]

Just happened to click the notification icon (wanted to jump to a different thread) and saw this.

2 minutes ago, Boris-Barboris said:

I refuse to accept this "optimize later" doctrine, it reeks of webdev oversupply-induced absolutism.

The lag you see in this build of KSP is harmless compared to other WIP games before they hit the market. This really is a regular occurrence in games.

5 minutes ago, Boris-Barboris said:

Yes, it is work, but it must be done: fps is a requirement.

I'm not saying that optimization will not be done, I'm just saying that it is the last step when everything else is set in stone! Then, and only then, can you truly work on performance improvements because then you have everything you need to evaluate the game's performance in any situation - all in one go, as one step - rather than spread through development whenever a new mechanic is implemented.

And who cares about the performance of a early-in-development debug build that is never going to go public and has huge holes in gameplay and content?
Evaluating a finished, released product's performance based on an early pre-alpha build with lots of features missing is frankly ridiculous.

10 minutes ago, Boris-Barboris said:

Not to mention the obvious downsides of late-stage content-cutting because of performance is inefficient (you've spent months on content that is not shipped) and sometimes unethical (false advertizement, trailers feature some other game, not the one you ship).

Yes. I absolutely agree. Cutting content late-development sucks. But it happens, whether it was for performance or it failed some test or was not ready for release, etc.
For whatever reason it is, late-cut content appears time and again. There essentially is no game without it.

[Boris-Barboris]

1 minute ago, Delay said:

I'm not saying that optimization will not be done, I'm just saying that it is the last step when everything else is set in stone! Then, and only then, can you truly work on performance improvements because then you have everything you need to evaluate the game's performance in any situation - all in one go, as one step - rather than spread through development whenever a new mechanic is implemented.

And who cares about the performance of a early-in-development debug build that is never going to go public and has huge holes in gameplay and content?
Evaluating a finished, released product's performance based on an early pre-alpha build with lots of features missing is frankly ridiculous.

If opinions could be mapped to a sphere, ours would count as two poles.

1). Yes, performance must be worked on all the time, with constant vigilance, through the whole development cycle, to keep those features yes-men PMs promise at the bay called "Reality". I expect game developer to constantly think about performance while typing every line, every function, day and night. I expect planning and budgeting techniques to be applied to performance/time/memory aspect of the game. My expectations are not changed by the fact that modern gamedevs rightfully don't care about my ideas or wishes. Subjectivity is implied.
2). No, you don't need a finished game to start working on performance. You don't need all the game systems implemented to optimize one game system.
3). I must have missed the proof that it is a debug build. Pre-alfa != debug.
4). I don't evaluate, I speculate based on marketing material and domain knowledge. If the features are missing, I can rightfully expect the release to be even more laggy, so this particular argument is just as ridiculous.

[Delay]

14 minutes ago, Boris-Barboris said:

Pre-alfa != debug.

By "debug" I meant that the build is mainly used for testing the game/specific mechanics. Obviously developers don't compile and run their code for fun (just yet, at least). They play the game to test whether the mechanic they just worked on works as expected and is not throwing exceptions or other errors.

So I guess a more accurate word for what I mean would be "test build". It's a build specifically for testing.

20 minutes ago, Boris-Barboris said:

If the features are missing, I can rightfully expect the release to be even more laggy

That would be right if they'd leave performance as-is and never touch it again. And I can guarantee you they won't.

And yes: Performance is cared about throughout development and slight improvements are done all the time. But large performance improvements are very late in development - again - after everything that was to be implemented is implemented, there are no longer any features added, the game is in an otherwise completely finished state and there are no surprising bugs left.

[Tonas1997]

So while we're talking about KSP2 and its possible improvements over the first game - or lack thereof - I have a question:

I'm used to playing RSS/RO, meaning that while the "wobbly joints" and large part count ships are extremely relevant issues that should be addressed, I haven't felt their impact as much due to a multitude of factors (namely that I play a very slow career save with relatively small ships). The biggest hindrance to my enjoyment of the game, in its current state, are the loading times. I have a hefty modpack that results in +20 minute load times on a HDD - not sure on how much of an improvement getting a SSD would be - and, to be honest, I don't feel like sacrificing gameplay, part or visual mods so that I can get marginally better results when it comes to loading times. Doing so would completely transform my really enjoyable experience, one that mixes the realistic gameplay from RO with colonization, interstellar and orbital assembly possibilities from other mods. From what little I understand of this game, long load times are an Unity limitation that can't be improved upon that much.

However, I want to be hopeful that KSP2 can (and will) improve this particular... handicap, but some comments I read on the subreddit seem to indicate it can't be helped without the developers switching to another game engine. And that depresses me.

TL;DR: is it possible KSP2 will see a radical upgrade in loading speeds, or is it something we'll keep having to deal with? As a bonus, does anyone have any inspiring, infomercial-like SSD stories that could convince me to get one?

Edited August 29, 2019 by Tonas1997

[DStaal]

1 hour ago, Tonas1997 said:

TL;DR: is it possible KSP2 will see a radical upgrade in loading speeds, or is it something we'll keep having to deal with? As a bonus, does anyone have any inspiring, infomercial-like SSD stories that could convince me to get one?

It's been a while since I made the switch - but switching to SSD reduced my loading speed by something like 2/3rds.  It's obviously largely I/O limited.

[whitespacekilla]

On 8/29/2019 at 3:35 AM, Brikoleur said:

No it's not. Joint rigidity is fully adjustable and it's also possible to weld parts into a single physics part. There are mods for KSP that let you do this already.

Are you talking about KJR? It works by adding more connections. 

[Superfluous J]

13 minutes ago, whitespacekilla said:

Are you talking about KJR? It works by adding more connections. 

No there is (was? I never used it so don't know if it still exists or not or even its name) one that actually turned multiple parts into a single part. Pretty sure it had "welding" in the name.

[Cavscout74]

1 hour ago, 5thHorseman said:

No there is (was? I never used it so don't know if it still exists or not or even its name) one that actually turned multiple parts into a single part. Pretty sure it had "welding" in the name.

I never actually used it either - it was already broken when I first heard of it, and AFAIK it still is

Edited August 31, 2019 by Cavscout74

[whitespacekilla]

3 hours ago, 5thHorseman said:

No there is (was? I never used it so don't know if it still exists or not or even its name) one that actually turned multiple parts into a single part. Pretty sure it had "welding" in the name.

This is about when I figured out I was going to engage in an argument about joints in Unity with a bunch of people who have never developed in Unity and decided to just go on living my life.

[purpleivan]

On 8/29/2019 at 6:00 PM, Boris-Barboris said:

1). Yes, performance must be worked on all the time, with constant vigilance, through the whole development cycle, to keep those features yes-men PMs promise at the bay called "Reality". I expect game developer to constantly think about performance while typing every line, every function, day and night. I expect planning and budgeting techniques to be applied to performance/time/memory aspect of the game. My expectations are not changed by the fact that modern gamedevs rightfully don't care about my ideas or wishes. Subjectivity is implied.

I hope your joking, as this is nothing like normal games development. You can expect all you want, but the pursuit of performance above all else, at all times is simply not what happens in the development of any game. Yes work is done early on to help ensure a well performing game at the end of the process, but a lot of this structural rather than the code itself.

Pretty much all of the games I've worked (and it's a lot) have been a mess to some degree or another at Alpha, with features required by the publisher being jammed in, to meet their requirements for what the build contain at that stage.

Yes, yes... you're just stating you're expectations, but they don't match reality.

On 8/29/2019 at 6:00 PM, Boris-Barboris said:

2). No, you don't need a finished game to start working on performance. You don't need all the game systems implemented to optimize one game system.

No you don't need all the game's systems to be implemented in order to optimise one, but these things do not work in isolation. You may have one system that you believe to be optimal (or at least, good enough) until another gets implemented, or altered (in terms of performance or features) and then suddenly that optimal system written months ago, is looking anything but.

These thing don't just roll off a production line in their final perfect form, never to be touched again.

On 8/29/2019 at 6:00 PM, Boris-Barboris said:

4). I don't evaluate, I speculate based on marketing material and domain knowledge. If the features are missing, I can rightfully expect the release to be even more laggy, so this particular argument is just as ridiculous.

Again... not the reality of games development.

Even with additional features coming in during development, it's been my experience that performance generally goes up, rather than down, through the development cycle. This is partly due to optimisation work that's ongoing throughout development, but especially in the later stages of it. I've seen several games have significant improvements in performance in the last 2 or 3 months.

But also at any given stage, especially something like pre-Alpha, there's usually something (code or content) that in nothing like shipping condition, especially if a publisher pushes for the inclusion of features to show of some aspect of the game before their really ready. This kind of stuff can really hit performance.

 

KSP2 isn't due until sometime next year, that could be more than a year from now. Trying to assess the likely performance level of the final game, based on a single video, of the game in an unknown condition is simply pointless.