Jump to content

Devnote Tuesdays: The 0.24 Experimentals Edition

SQUAD

By SQUAD
in KSP1 The Daily Kerbal

 Share

Recommended Posts

samstarman5

samstarman5

Posted
Posted

I will admit to feeling apprehension over this move to Curse. Curse has had a history of vulnerabilities and such. But that was actually a while ago, leaving hope that such issues were actually handled. It is a good thought that SpacePort media is upgrading, though.

It will be nice to see Spooty have an excuse to get on KSP more again. He does seem to like playing with the experimentals.

Link to comment
Share on other sites
Streetwind

Streetwind

Posted
Posted
Suggestion @Streetwind: Open a thread exactly like that and call it "0.25: Requested 20-minutes-to-fix Game/UI changers". Do politely ask a mod to sticky it. Close it when 0.25 enters testing, repeat as more game updates are developed :)

Of course a bug tracker can handle feature requests as well, but requests of this kind would just go under in a flood of real bug reports which are much more difficult to work on and require much more time to fix.

This is not really something for me to do. It should be something that Squad does when they have the time to actually work on the suggestions made. The list should reflect the state of the game at the time the committment to do such a project is made. If we created a list now, it might be outdated by the time Squad has an appropriate opening in their roadmap, and it will not be nearly as useful.

Link to comment
Share on other sites
HarvesteR

HarvesteR

Posted
Posted
Regardless of when there will be time for it, an update focused on community-sourced improvement suggestions is a great idea.

EVE Online had major success with this a few years ago when one of the dev teams started the "The Little Things That Kill" project. Following the idea that sometimes it can be really minor design oversights that crop up over and over in day-to-day gameplay, rather than high profile but rare bugs, that cause players to feel annoyed, they opened up a thread on the forums and just asked for the community to brainstorm. Everyone was asked to contribute anything they thought could be fixed in no more than 20 minutes of work by a single person. Of course, not everyone can judge these things correctly, but the team still received a gigantic amount of suggestions. Things as simple as "reorder the items in this right-click menu because the most used choice is in the least convenient place possible right now" and "please let me hit enter to confirm entering a name in this field, instead of having to use the mouse to click OK" and "take this feature you already have implemented in screen A and also make it available in screen B". Over the course of several patches and expansions, over 400 such "little things" got fixed.

That is actually a great idea, and taking care of those 'little things that kill' (great name for it) is something that we always try to do, whenever we get a chance. For the ARM update, in fact, I did devote an entire week to cleaning up loose ends, mainly concerning how maneuver nodes and map view features were handled...

But therein also lies the catch:

If you can sink an entire week in just that one area, take a step back to look at the entirety of the game. How much of the scope of the game would you say the map view and maneuver nodes represent? 10%, 15% maybe, I wouldn't dare call it any higher, what with the space center career features, craft construction, part logic, part physics (not the same), scenery, map scenery (also not the same as map view itself), persistence, and not least and probably forgetting a bunch of other bits, the UI on each scene also.... In fact, after listing thing... even 10% seems like a gross overestimation.

I don't mean to complain, just to give a sense of the enormity of the job that's ahead of us to tidy up these little things.

The good news is that as soon as we're done implementing the last stages of career mode, the plan is to devote more and more time to improving and tweaking everything that was left behind as we pushed forward. Things like what you suggested here will become increasingly more important.

If we were building a tunnel, you wouldn't expect the road to be fully paved up to rear end of the tunnel-boring machine. The whole tunnel would be closed to traffic in fact. It's pretty much the same principle here, with the advantage you get to visit the job site and drive in it already. (ok, that's quite enough stretch on that analogy, any more and it will collapse) :)

Cheers

Link to comment
Share on other sites
iDan122

iDan122

Posted
Posted
Harv, while you're here, a question I've always wondered: Why don't you use mod stuff (with permission of course), with code already written for you?

This was bothering me for months...

Seriously though what exactly makes that impossible? Plane parts were implemented fast when C7 joined.

I am starting to learn C only next year so an answer would be EXTREMELY helpful.

Link to comment
Share on other sites
HarvesteR

HarvesteR

Posted
Posted (edited)
Harv, while you're here, a question I've always wondered: Why don't you use mod stuff (with permission of course), with code already written for you?

This question has popped up in varying degrees of aggressiveness quite a few times... Thanks for asking it straight and simple. :)

'Merging' mods is one of those things that one the surface would appear simple, but it's actually quite a lot more complicated than it would seem.

Consider that even commercial assets from Unity's asset store, which are packages made specifically to be dropped in and used in existing projects, will, for the most part, require some drastic reworking to fit them into KSP. Granted, the mods are done already over our existing codebase, and that does make the initial integration easier, but there's more to it than that.

If we had a complete game, and someone came up with an awesome new mod that everybody wanted, and we had permission to fold it into the game (another issue in itself), that would probably be the end of the story... Assuming also that we wouldn't have to make any changes to the mod itself (another tall order, since mods are exactly meant to modify the game experience, by definition).

That's obviously not the case here. The game is still growing, and as it grows, it's very common for us to come across bits of old code that now need to be refactored to make it work again. And that's with our own code. Now, consider how frequently mods become incompatible when we release a new update. We are blessed with a modding community here that is so solid, you're likely going to see your broken mods fixed in a short amount of time. That's done by the mod authors themselves, because they care about their projects and they put in a lot of effort to keep it nicely maintained.

Now suppose we were to fold a mod into the game... That author support would now become our own burden, and given that we have our own systems to maintain as we develop already, imagine what it would be like if we started to suddenly plop down chunks containing thousands, or tens of thousands of new, unknown to us, lines of code. We'd end up with an unmaintainable mess of code.

In the end, we're happiest as we are right now. The gist of the problem is that neither the game nor the mods are carven-in-stone, unchanging pieces of code. Both are living, evolving projects, which evolve alongside each other, and it takes the combined efforts of everyone to keep this organism alive.

You can put it like this:

A bird needs a tree to nest in and survive... But try gluing the bird to the tree to see what happens. (actually, don't try that).

Cheers

Edited by HarvesteR
Link to comment
Share on other sites
Superfluous J

Superfluous J

Posted
Posted
'Merging' mods is one of those things that one the surface would appear simple, but it's actually quite a lot more complicated than it would seem.

I never thought of it this way before (but as a non-coder who spends his time around coders, I assumed it was harder than I thought it was).

Thank you for the explanation. It makes a lot of sense now.

Link to comment
Share on other sites
iDan122

iDan122

Posted
Posted

Thanks for the answer Harv, made things a lot more clearer. If someone dropped 100 lines of code into my program, i would be lost because I wasn't writing it. Implementing a mod is kind of like adopting a 17-year old.

Link to comment
Share on other sites
shadowsutekh

shadowsutekh

Posted
Posted (edited)
Please release the update for everyone at the same time!

"I also object to the fact that we pay to test this game, yet some people get the updates before others."

You don't pay to test, you paid for early access to a game in development. That is a very large difference from testing.

The media team doesn't get access to the finished version of an update before anyone else, hence their disclaimers that the content of their videos may or not change by release day. They just get to show off to the community in motion what highlights the updates contain. Frankly I like seeing updates in motion more than reading a little blurb of text and a screenshot or two.

You will get access to .24 when it is done, not before just like everyone else including me.

Edited by shadowsutekh
Link to comment
Share on other sites
Ted

Ted

Posted
Posted
how long time do usually experimentals take?

They usually last around two weeks, though given that it's a very intense part of development, that can quickly change!

Link to comment
Share on other sites
Albert VDS

Albert VDS

Posted
Posted
Please release the update for everyone at the same time!

Imagine how a experimental phase works. New fixes every hour, or at least every day.

Now each fix can potentially break your saved game or a mod. Now you need to start a new game or wait for the mod to be updated.

You wouldn't be able to keep a saved game for very long and modders might lag behind.

How would you manage the torrent of people reporting problems, bugs and other issues without delaying a release even more?

Link to comment
Share on other sites
Javster

Javster

Posted
Posted (edited)
Imagine how a experimental phase works. New fixes every hour, or at least every day.

Now each fix can potentially break your saved game or a mod. Now you need to start a new game or wait for the mod to be updated.

You wouldn't be able to keep a saved game for very long and modders might lag behind.

How would you manage the torrent of people reporting problems, bugs and other issues without delaying a release even more?

I suggest having a seperate website, eg. kerbal dev dot com where you can get a weekly update for testing.

Also, to quote the Steam Early access page, you buy the game and "Help test and report bugs"

http://store.steampowered.com/earlyaccessfaq/?snr=1_200_200_Early+Access

Edited by Javster
Link to comment
Share on other sites
Albert VDS

Albert VDS

Posted
Posted
I suggest having a seperate website, eg. kerbal dev dot com where you can get a weekly update for testing.

Also, to quote the Steam Early access page, you buy the game and "Help test and report bugs"

http://store.steampowered.com/earlyaccessfaq/?snr=1_200_200_Early+Access

Squad's early access definition doesn't have to be a carbon copy of Steam's.

Here's my question to you:

What would be more efficient in fixing bugs found in experimental?

Every player posting their own bug reports when they want to.

or

A dedicated testing team with a wide base of different setups.

Link to comment
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...