Jump to content

KSP2 should have no optional features


Guest
 Share

Recommended Posts

30 minutes ago, mcwaffles2003 said:

Also, whats to stop your strawman from getting frustrated when they started playing the game without turning off that feature in the first place... Many people who try this game don't get far due to the difficulty curve

I've already addressed this, several times in fact.

The difficulty curve in KSP, and specifically the bumps in it, have little to do with the systems that can be disabled. By the time you even have to deal with atmospheric heating, G-limits, or CommNet you're already reasonably proficient at the game. 

Once more: atmospheric heating, G-limits, or CommNet are not hard at all, compared to the difficulty of the very basics: (1) getting into orbit and (2) getting back without ending up as a hole in the ground.

If you're able to get to LKO and back and survive, you're easily able to deal with all of the optional systems.

 

30 minutes ago, mcwaffles2003 said:

And players have every right to play the game like that, just because it isn't your preference doesn't mean other people shouldn't be allowed to play that way

I really wish you lot would stop beating this strawman.

This has nothing to do with my preferences. In fact I fully expect that stock KSP2 won't exactly match my preferences, and look forward to the mods that allow me to tailor it more exactly to them. 

It's all about making a better game: stabler, more robust, with better integrated systems, with more synergies, with richer gameplay. As to "playing your way," KSP is already insanely moddable, and mods are a much better solution to that than toggles – and I've been continuously advocating for maximal moddability. Why should a game built from the ground up as a modding platform also have "built-in mods" that you can toggle on or off?

Edited by Guest
Link to comment
Share on other sites

23 minutes ago, Brikoleur said:

This has nothing to do with my preferences. In fact I fully expect that stock KSP2 won't exactly match my preferences, and look forward to the mods that allow me to tailor it more exactly to them. 

This entire thread is your preference

24 minutes ago, Brikoleur said:

It's all about making a better game: stabler, more robust

Prove to me that turning off features makes it more stable/robust please... I'm gunna pay the devs/programmer $60 for this game they better be able to just do that, options or not (I dont mind technical reads, in fact I quite enjoy them)

I hope when you make this claim it comes with programming experience specifically in making games since as someone with experience doing physics at a particle accelerator modeling magnetic fields in SRF cavities I wont go off and pretend like I know the nuances of how detectors in it should be built.

36 minutes ago, Brikoleur said:
  48 minutes ago, mcwaffles2003 said:

And players have every right to play the game like that, just because it isn't your preference doesn't mean other people shouldn't be allowed to play that way

I really wish you lot would stop beating this strawman.

Are you using that word just because I did or do you actually know what it means? Because I did not make a strawman argument, in fact several people, in this very thread, have said they prefer to play with some of the options being discussed off.

But please do explain how this is a strawman argument

28 minutes ago, Brikoleur said:

Why should a game built from the ground up as a modding platform also have "built-in mods" that you can toggle on or off?

I think we are looking at these options in different fashions. To me it sounds like you believe options are add-ons to a base game, to me it seems like the base game includes all the options and players are allowed to opt out. All the "better integrated systems, with more synergies" are built with all options applied, and turning them off just leaves less systems required to integrate/synergize.

Civ V for example... espionage is a core mechanic of the game and it is built with that in mind... Yet you can turn it off. Same with barbarians, turn limits, razing cities, etc... 

 

Link to comment
Share on other sites

2 minutes ago, mcwaffles2003 said:

This entire thread is your preference

My preference is for a stable, solid game with rich gameplay and systems that are integrated with each other, build on each other, and synergise with each other. Siloed-off optional systems run counter to this preference. I'm not against options because they're options, I'm against them because of their indirect effects.

3 minutes ago, mcwaffles2003 said:

Prove to me that turning off features makes it more stable/robust please... I'm gunna pay the devs/programmer $60 for this game they better be able to just do that, options or not (I dont mind technical reads, in fact I quite enjoy them)

I can't prove it. I can only argue a case about it, which I have attempted mostly in the OP. You're free to engage with my argument, or not, as you choose.

I know from experience that the more configurable a system is, the harder it is to test, debug, develop, and stabilise, because the configurable features always have unexpected interactions. I also know from experience that the practical outcome of a highly configurable system is almost always a flakier, buggier, harder to use, less reliable system.

I believe it's self-evident that if you want to make something that consists of systems that build upon other systems, the task will be easier if you can rely on the systems to be present and correct all the time, which frees you to focus on making the secondary systems better. 

Therefore, I believe optional systems are bad. That's really all there is to it.

As far as I can tell, logically, you can disagree with me in three ways:

  1. By not believing that making a system more configurable makes it harder to test, debug, develop, and stabilise, or alternatively that there are practical and affordable ways of accounting for the additional burden without compromising quality. (If you know what these ways are, I would be very interested to know, it would be immediately applicable in my day job.)
    • If this is your position, there's not much I can say to dissuade you, other than that my 30-ish years experience of making software says you're wrong. 
  2. By not accepting that it is easier to make secondary systems if you have a stable set of primary systems to work on, than if you have to account for some of the primary systems being present or not.
    • I can't say much to sway you about this either, because in my view this observation is self-evident.
  3. By accepting both of the above premises, but believing that having optional systems are worth the trade-off nevertheless: that you'd rather have a flakier, lower-quality game with fewer synergies and less rich gameplay but more options, than vice versa.
    • This is a value judgment – a matter of preference – and therefore not subject to argument either. However, if this is your position, I would respect it if you came out and said so directly: that way we can simply note that we disagree, and move in.

If there is some other way of logically disagreeing with my argument, I would be curious to hear it. 

Link to comment
Share on other sites

There's no evidence to suggest that Kerbals are an evolved life form.

I'll back that up.  They sprang into existence without females.  Remember that?  More like a meme, truth be told.

They live in a virtual world, too.  One that I suspect doesn't exist without our minds, but on the other hand, isn't constrained by our own physical requirements.

How do we know how they derive sustenance?  Truth be told, they have proven to be radiation- (and trauma-) hardened to an extent our species can never hope to match.

How do we know what waste products they produce and how those are to be disposed and/or recycled?

I hypothesize that Kerbals were created by an antecedent, sapient, highly-intelligent species that realized that, it, itself -- designed haphazardly by evolutionary processes -- could never make the voyage (permanently) into space -- and indeed never has.  Kerbals are more likely electronic/animatronic, in all likelihood.

How and why do we think their technology should be constrained by our own limited progress??!  Have Kerbals not already greatly surpassed our own space program and exceeded our present abilities in ways we can only dimly imagine?  What do we really know about the spiritual significance of the Kraken that inhabit the Kerballar verse.

                                                       

How dare we speculate about the parameters of the Kerbal Space Program and its entities!?  Let's keep "humankind" and what we pitifully call "real life" out of it and enjoy what has been given to us through the receiving end of a telescope with joy and gratitude.  The existence of many more mods than any human can count in a lifetime proves there is a benevolent Ultimate Force that wants us all to get along and not split hairs.

Is that so much to ask?

Edited by Hotel26
Link to comment
Share on other sites

Just now, Brikoleur said:

My preference is for a stable, solid game with rich gameplay and systems that are integrated with each other, build on each other, and synergise with each other. Siloed-off optional systems run counter to this preference. I'm not against options because they're options, I'm against them because of their indirect effects.

Just because a feature is optional doesn't mean it has to be "siloed-off". Just give everything dependencies and when one system is gone all other dependent features are as well.

I.e. commnet... If it is disabled just disable the function that checks if a probe is connected to KSC... Why is that so hard? Why does that make everything as unstable as you make it out to be?

8 minutes ago, Brikoleur said:

I know from experience

Is that experience in making games? If not, isn't just a little bit possible that you're speaking naively? Is it possible you don't understand the nuances of programming a video game? Or in your world is all programming the same?

Just because I've programmed stellar simulations doesn't give myself the impression that I know how to program in unity or the facets of it.

13 minutes ago, Brikoleur said:

Therefore, I believe optional systems are bad. That's really all there is to it.

May I direct you here?:

https://thebestschools.org/magazine/15-logical-fallacies-know/#falsedilemma

The world doesn't have to be so black and white. Just because were talking about boolean systems doesn't mean our reactions to them need to be as well.

You're argument boils down to something akin to "If it doesn't converge to 0 it must be divergent!"

Does making systems optional add any complexity to a game? Yes.. Does it add so much complexity that it will turn that game into a buggy, unstable, non-synergetic, disintegrated mess? No

My evidence to this assertion?

ALL THE STABLE GAMES WITHOUT A CRAP TON OF BUGS, of which there are many.

 

24 minutes ago, Brikoleur said:

By not believing that making a system more configurable makes it harder to test, debug, develop, and stabilise, or alternatively that there are practical and affordable ways of accounting for the additional burden without compromising quality. (If you know what these ways are, I would be very interested to know, it would be immediately applicable in my day job.)

  • If this is your position, there's not much I can say to dissuade you, other than that my 30-ish years experience of making software says you're wrong. 

To what extent? We're paying these people to do this. If it adds some work for them to do... then do it, it's their job.

 

27 minutes ago, Brikoleur said:

By not accepting that it is easier to make secondary systems if you have a stable set of primary systems to work on, than if you have to account for some of the primary systems being present or not.

  • I can't say much to sway you about this either, because in my view this observation is self-evident.

You are literally arguing against your own position here...

28 minutes ago, Brikoleur said:

Siloed-off optional systems run counter to this preference. I'm not against options because they're options, I'm against them because of their indirect effects.

 

19 minutes ago, Brikoleur said:

By accepting both of the above premises, but believing that having optional systems are worth the trade-off nevertheless: that you'd rather have a flakier, lower-quality game with fewer synergies and less rich gameplay but more options, than vice versa.

  • This is a value judgment – a matter of preference – and therefore not subject to argument either. However, if this is your position, I would respect it if you came out and said so directly: that way we can simply note that we disagree, and move in.

Going with this one. I am not a sith, so I don't deal in such absolutes, believing adding a couple options will wreck the game

Link to comment
Share on other sites

8 minutes ago, Hotel26 said:

There's no evidence to suggest that Kerbals are an evolved life form.

I'll back that up.  They sprang into existence without females.  Remember that?  More like a meme, truth be told.

They live in a virtual world, too.  One that I suspect doesn't exist without our minds, but on the other hand, isn't constrained by our own physical requirements.

How do we know how they derive sustenance?  Truth be told, they have proven to be radiation- (and trauma-) hardened to an extent our species can never hope to match.

How do we know what waste products they produce and how they are to be disposed and/or recycled?

How do we think their technology should be constrained by our own limited progress?  Have Kerbals not already greatly surpassed our own space program and exceeded our present abilities in ways we can only dimly imagine?  What do we really know about the spiritual significance of the Kraken that inhabit the Kerballar verse.

                                                       

How dare we speculate about the parameters of the Kerbal Space Program and its entities!?  Let's keep "humankind" and what we pitifully call "real life" out of it and enjoy what has been given to us through the receiving end of a telescope with joy and gratitude.  The existence of many more mods than any human can count in a lifetime proves there is a benevolent Ultimate Force that wants us all to get along and not split hairs.

Is that so much to ask?

is this sarcastic? :confused:

Spoiler

of course it is

 

Edited by Dirkidirk
Link to comment
Share on other sites

1 minute ago, mcwaffles2003 said:

Just because a feature is optional doesn't mean it has to be "siloed-off". Just give everything dependencies and when one system is gone all other dependent features are as well.

I.e. commnet... If it is disabled just disable the function that checks if a probe is connected to KSC... Why is that so hard? Why does that make everything as unstable as you make it out to be?

Dependency management is one of the hardest problems in software engineering. What you say in theory turns out to be a lot more difficult in practice. "Why is that so hard?" is like asking "What's so hard about making a rocket that goes to orbit? You just put enough fuel and oxidant in a tank, a nozzle at the bottom, light it on fire, and watch it go." 

4 minutes ago, mcwaffles2003 said:

Is that experience in making games? If not, isn't just a little bit possible that you're speaking naively? Is it possible you don't understand the nuances of programming a video game? Or in your world is all programming the same?

No, it's not from games. It's from making highly configurable systems for various business purposes. But I have been working with stuff where configurability is a specific design requirement as my day job for about 20 years now. The basic characteristics of a highly configurable system are the same whether it's a utility designed for inspectors of nuclear power plants or a rocket game.

6 minutes ago, mcwaffles2003 said:

To what extent? We're paying these people to do this. If it adds some work for them to do... then do it, it's their job.

You're paying people to do that stuff when you could instead be paying them to make the game better, stabler, richer, and more engaging. Moreover: in actual real-life practice, quite often the result won't be stable, robust, and good no matter how much you pay them. But if that's the trade-off you want to make, then fine – that's your preference, and I can't argue with preferences.

9 minutes ago, mcwaffles2003 said:

Going with this one. I am not a sith, so I don't deal in such absolutes, believing adding a couple options will wreck the game

Thanks, that's fair. In that case, I think we've reached the end of any productive discussion we can have on the topic, and will have to note our disagreement and move on.

Link to comment
Share on other sites

3 minutes ago, Brikoleur said:
The basic characteristics of a highly configurable system are the same whether it's a utility designed for inspectors of nuclear power plants or a rocket game.

Do you work with nuclear power plants? If so that's pretty cool

3 minutes ago, Brikoleur said:
Thanks, that's fair. In that case, I think we've reached the end of any productive discussion we can have on the topic, and will have to note our disagreement and move on.

Cool by me :)

Link to comment
Share on other sites

13 minutes ago, mcwaffles2003 said:

Do you work with nuclear power plants? If so that's pretty cool

I did a project for the national radiation safety centre once. It was INSANELY CONFIGURABLE :sob: 

Most of my work nowadays involves AI-augmented services for healthcare providers however. I think they're a lot cooler than the nuclear safety thing. But that would be a tangent and I don't think this is either the time or the place.

Link to comment
Share on other sites

I admit, while I read this thread I was confused by your position. At one point I considered deploying the "doing something for 30 years does not preclude doing something wrong for 30 years" line. I'm glad I didn't.

1 hour ago, Brikoleur said:

The basic characteristics of a highly configurable system are the same whether it's a utility designed for inspectors of nuclear power plants or a rocket game.

I believe I understand now. You work in a very conservative field—and it's right to be conservative! Failure is expensive. Lives are at stake. Of course stability is at a premium. Miscellaneous Boeing snafus aside, aerospace is the same way.

But—and I think this is a critical distinction—KSP (and KSP 2) are video games about aerospace. And video games demand a different design philosophy.

Every resource I've looked at in my three years or so (ha) since learning to program has described a concept known as "encapsulation." Encapsulation is used to ensure that you always know the ways in which the different parts of your project interact. In your words, it is a way to "silo away" parts of your project. And everywhere I've seen it, it has been described as a way to improve the ability of your program to be developed and maintained.

Encapsulation does this by allowing you to replace, say, Commnet checks to determine whether your vessel can be controlled with a function that just returns "true." This now lets you test other systems that may interact with Commnet without considering what Commnet would have to say about it. Your testing can now be more scientific because you can limit your independent variables to the absolute minimum and test each feature in relative isolation.

This also applies for development: You needn't wait for the implementation of plasma sheathing to develop relay functionality, because although these are both Commnet and should interact during real gameplay, each of them still means something in isolation.

This also has ripples for modding. If you wanted to write a mod to supplant Commnet, it could be very difficult to dig through a tightly-integrated system, commandeering every individual function—and what if you miss one? However, a properly-encapsulated Commnet would be but a step removed from a drop-in module. All functionality is located in one place, and can be replaced easily. It even makes API documentation more sensible.

So, in light of encapsulation being apparently accepted as best practice, and the benefits it brings, it's plausible that it is in use in the development of KSP 2. And, if replacement with stubs is present in the kind of testing suite encapsulation permits, it's plausible that it is in the testing suite applied to KSP 2. Given these, I conclude that it is plausible that adding an option to disable Commnet, or a feature like Commnet, is as easy as exposing the "stub out" functionality of the testing suite to an options menu—and doing so will not impact stability.

Link to comment
Share on other sites

35 minutes ago, 0111narwhalz said:

Every resource I've looked at in my three years or so (ha) since learning to program has described a concept known as "encapsulation." Encapsulation is used to ensure that you always know the ways in which the different parts of your project interact. In your words, it is a way to "silo away" parts of your project. And everywhere I've seen it, it has been described as a way to improve the ability of your program to be developed and maintained.

Encapsulation is totally critical, it's the only way to design software with any kind of complexity.

It's really easy too. You just have to know every current and future use case, then arrange that into suitable modules, and then design the simplest possible API for each of the module that accounts for all of the use cases, then never change them.

That was a joke.

In reality, you never know the use cases until you discover them as you're working on the system. You also never get the API right the first time. This means that you're continuously refactoring the system you're working on: moving bits and pieces from one module to another, adding an API feature here, removing a redundant API feature there, changing one characteristic in all APIs because that's the easiest way to address a new concern or use case that just came up, merging two overlapping modules, dividing a module that's grown too big into two, abstracting shared features of several modules into another module, and so on and so forth. The architecture of any reasonably complex piece of software isn't a static, dead skeleton fossilised in anthracite, it's a living thing that grows and changes with the software. The modules aren't static either: their features change, their interfaces change, they live, they die, and with them, the interactions they have with each other change.

This is where the problem of configurability really bites. If you have a really robust set of test cases -- as you should -- you can change things in the architecture surprisingly flexibly without breaking it. The problem is that configurability doesn't just add new test cases: it adds an entire new dimension to the test cases. The software can now break not just in one more way, it's more like it can break in (number of modules) * (number of configurable options) ways. It complicates things exponentially, not arithmetically. You're not dealing just with the change that's inherent in developing and maintaining a complex piece of software, with its relatively measured pace; you're dealing with dynamic changes that happen in the system at the flip of a switch.

---> and yeah: in practice it's never possible to completely do away with configurability, I know that better than most people I'd bet. I'm sure KSP2 will have configuration options, if not in a UI screen, then in a .properties file or somewhere. But the fewer configurable options there are, the easier it is to make a rich, exciting, complex (in a good way), fun, and stable game for players – and platform for modders.

My real objective for arguing this case isn't a hope that KSP2 will be entirely options-free: it's more to challenge the very common "But just make it optional!" suggestion that always comes up with controversial topics like LS. It's really not that simple: the more optional features there are in the game, the harder it will be to make a game that's worth playing, and modding, at all.

Edited by Guest
Link to comment
Share on other sites

21 minutes ago, Brikoleur said:

The problem is that configurability doesn't just add new test cases: it adds an entire new dimension to the test cases.

If it's done right, shouldn't it remove dimensions? By my intuition it should transform testing from O(k^n) to O(n), because rather than testing every combination of conditions between all of your modules, you test one condition for each module. (Integration testing is still important, of course, but that shouldn't buck O(n) into O(k^n), right?)

Basically I feel like turning modules off should happen in regular testing anyway, so that should not be disruptive in production.

Link to comment
Share on other sites

Just now, 0111narwhalz said:

If it's done right, shouldn't it remove dimensions? By my intuition it should transform testing from O(k^n) to O(n), because rather than testing every combination of conditions between all of your modules, you test one condition for each module. (Integration testing is still important, of course, but that shouldn't buck O(n) into O(k^n), right?)

Basically I feel like turning modules off should happen in regular testing anyway, so that should not be disruptive in production.

This risks turning into another tangent, but the short answer is "it depends."

There is software that is genuinely and by nature modular enough that stuff really can be siloed off and modules really can be switched on and off. For example I've been working on a microservice platform that provides a storage, search, and retrieval API for objects, connections, binaries, and counters. In this case it's not hard to know what will happen if I switch a module off: if the counter provider is offline, then counters won't work, but the other things won't be affected.

Even in this case, however, you'll run into problems if you have an application on top of the platform that makes use of these services. Has the application developer considered what will happen if one of the upstream services is offline? For example, is there a complex operation there that relies on objects, connections, and counters, and how have the different failure modes of the upstream service been taken into account? So it could very well be that if the counter module comes offline and the platform fails in a predictable way, the downstream service that relies on the platform will break in an unpredictable way.

Games are structured very much like this, in tiers: secondary systems build on primary systems, tertiary systems build on secondary ones, and so on; if everybody hasn't considered all the failure modes at every layer – and they never do, even grizzled veterans occasionally cut a corner, intentionally or through inadvertence – then the system will develop quirks whenever something out of the ordinary happens.

A game like KSP is inherently integrated. There are a ton of systems in there, and they all interact. I know just by looking at it that it's going to be a beast to test and maintain, even if Alan J. Perlis himself rose from the dead to be the architecture czar. The difficulty is that it has to be complex, otherwise it's not fun: the good kind of complexity creates the space for the emergent gameplay we all enjoy, whether your particular schtick is building robotic frogs or recreating real-life space missions in KSP-RO. Therefore it's doubly important to make the base game systems as robust and as stable as possible. Configurability in these systems is directly counter to this goal. 

And so we get back to my original thesis: Options are BAD.

Link to comment
Share on other sites

Wow, this circular argument is hurting my head. Here is a practical example for having options within KSP. 

I built a lander and want to test it before launching it. I have a couple choices here, I can cheat it into orbit of the planet I want it to land on, or I can change Kerbin's properties to match the planet I want to land on. 

It's more convenient to change the properties of Kerbin to match the planet I want to land on. Not because of the revert function, because that's what quick saves are for, because if I need to make a change to the lander; I can hop back into the VAB make my change and just launch to continue testing. No cheating into orbit again, no risking after several times cheating the orbit things just breaking, little temptation for the Kraken to come around. (Unless that's your goal.)

We wouldn't be able to do any of that without the options that are present in the game. The cheat orbit function wouldn't be in there. You wouldn't be able to change the planetary properties. Game play options are necessary in KSP if you don't want to go into a mission blind.

 

Link to comment
Share on other sites

Atmosphere heating, g forces, drag, relative gravity... These specific types of options are mentioned in the thread. They are "unnecessary" options to most players but are included in the game. You may call them  debugging options, but they are options none the less.

Now you need to define what options you are talking about. Are debugging options ok to have, but not options to turn off a feature? 

Link to comment
Share on other sites

14 minutes ago, shdwlrd said:

Atmosphere heating, g forces, drag, relative gravity... These specific types of options are mentioned in the thread. They are "unnecessary" options to most players but are included in the game. You may call them  debugging options, but they are options none the less.

Now you need to define what options you are talking about. Are debugging options ok to have, but not options to turn off a feature? 

I think lots of debugging options would be fine. The player can’t accidentally select them when starting a new game, or select them without understanding what they are when they first play the game. They have to go out of their way to not only learn that a debugging menu exists, but also use it  

If people want to use those options they can with the understanding that they may or may not work as advertised and any issues with them are not priority bug fixes and may never be fixed.

Edited by MechBFP
Link to comment
Share on other sites

The only real difference between a "debug" and "standard" option is whether or not the dev team decides it's part of normal gameplay, and consequently how much they attempt to fully test it. You cannot reasonably expect that a debug option won't break something weird, but there is at least some expectation that a standard option will behave better. How much players are willing to tolerate is part of the debate here, I suppose.

Personally, I'd rather have more options than less, even if it means that sometimes stuff might be quirky. That doesn't mean I'll put up with an indefinite number of bugs, but at the end of the day I think of KSP as a sandbox first and simulator second, rather than the reverse. Sandboxes are great for goofing around in, and shouldn't be taken so seriously.

Link to comment
Share on other sites

6 minutes ago, sturmhauke said:

The only real difference between a "debug" and "standard" option is whether or not the dev team decides it's part of normal gameplay, and consequently how much they attempt to fully test it.

Indeed. That of course can be a hard line to determine, but with focus testing and community feedback they can find that balance of options a lot of players will be asking for without overwhelming new players with ones that only 0.1% of the community wants.

Link to comment
Share on other sites

i think that having a lot of options let you be able to never play the same way adding variety without needing mods or personal rules and it lets the inexperienced learn this game should not be only for those that played ksp before. it should be a game for everybody no matter there skill level. you can NOT tell me that when you first played ksp you could have re-entered with 120% re-entry heating. you might say "ehh but the options will be default ehh". there is no way in kerbal hell that will go over easy, so no. 

 

There is no reason we should force all players to have the default difficulty when the experienced part of the community wants to challenge themselves and the inexperienced should have to play without some handicap.

Link to comment
Share on other sites

34 minutes ago, MechBFP said:

I think lots of debugging options would be fine. The player can’t accidentally select them when starting a new game, or select them without understanding what they are when they first play the game. They have to go out of their way to not only learn that a debugging menu exists, but also use it  

If people want to use those options they can with the understanding that they may or may not work as advertised and any issues with them are not priority bug fixes and may never be fixed.

Thanks for clearing that up. So what @Brikoleur is arguing against is unexplained options or features that may break or change how the base game is played. Either include them or forget about them.

I understand the programming and debugging time part of the argument. But at what point does an option/feature cross the line from optional to necessary? 

Link to comment
Share on other sites

5 hours ago, Brikoleur said:

Dependency management is one of the hardest problems in software engineering. What you say in theory turns out to be a lot more difficult in practice. "Why is that so hard?" is like asking "What's so hard about making a rocket that goes to orbit? You just put enough fuel and oxidant in a tank, a nozzle at the bottom, light it on fire, and watch it go."

Dependency management is a hard problem because it relates to handling dependencies on 3rd party libraries that will usually have their own dependencies, generally version specific dependencies that may conflict with the dependencies of other libraries you wish to use.

But I fail to see how making a feature optional has anything to do with needing additional 3rd party libraries which may have conflicting dependencies with libraries already in use.

 

Also, with encapsulation, you just make a best guess as to what you will need, and any time you need to add new stuff you increment the version of the api.  (removing stuff or changing stuff that may break existing code are generally higher-order version increments).

No need for perfect prediction, just a 'this is what we need now'.

You just use a factory class to load up the appropriate version based on what is wanted (Like calling DataLayerFacory to get either PostgresDataLayer or OracleDataLayer depending on which database you are using for this deployment)

 

 

Link to comment
Share on other sites

2 hours ago, Brikoleur said:

Games are structured very much like this, in tiers: secondary systems build on primary systems, tertiary systems build on secondary ones, and so on; if everybody hasn't considered all the failure modes at every layer – and they never do, even grizzled veterans occasionally cut a corner, intentionally or through inadvertence – then the system will develop quirks whenever something out of the ordinary happens.

A game like KSP is inherently integrated. There are a ton of systems in there, and they all interact. I know just by looking at it that it's going to be a beast to test and maintain, even if Alan J. Perlis himself rose from the dead to be the architecture czar. The difficulty is that it has to be complex, otherwise it's not fun: the good kind of complexity creates the space for the emergent gameplay we all enjoy, whether your particular schtick is building robotic frogs or recreating real-life space missions in KSP-RO. Therefore it's doubly important to make the base game systems as robust and as stable as possible. Configurability in these systems is directly counter to this goal. 

And so we get back to my original thesis: Options are BAD.

At what point did we slew to failure handling? Unexpected exceptions arising from a disabled feature are, I believe, a symptom of a kraken visitation. Turning something off should make it maximally predictable.

Encapsulation can and should make definitions of all interactions between systems accessible.

I'm curious as to which features you cannot stub out. You can replace Commnet connectivity checks with "yes it's connected." You can replace the thermodynamics with "yes everything is at 350K all the time." You can even replace aerodynamics with "no there's no aerodynamic force being applied." At what point does disabling these features cause unexpected results?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...