1.3 And More: Confirmed Features

[whitejj01]

9 hours ago, Streetwind said:

I've long kept my fingers crossed for such a "worldbuilding update",

I want so much to be able to land on duna in front of a giant mesa. make of actual rock. that I can't just walk through.

As a matter of fact, mesas at all would be fricking amazing.

[p1t1o]

10 minutes ago, whitejj01 said:

As a matter of fact, mesas at all would be fricking amazing.

Mesas? I'd just be happy with two textures per planet!

 

 

[whitejj01]

sorry, with my whole mission to duna thing, I'm just really aggravated about the lack of surface detail.

 

BTW, are there any mods that increase the terrain texture res? I'm Always landing and seeing individual pixels below me.

[whitejj01]

*Looks around forums*

GASP!

maybe they're working on some awesome new systems like RADIATION!!!

c'mon, how frickin' bad-ass would it be if there were radiation science experiments and late-tech-tree radiation shielding parts for traveling to Jool, WHICH WOULD EMIT RADIATION!?!?!?

[Darnok]

Probably Kerbal creator where you would be able to customize your own crew space suits, name etc etc...

[whitejj01]

also, how cool is it that TheEpicSquared took his coordinates, translated them into binary code, and put that as his location?

AWESOME!

[TheEpicSquared]

7 minutes ago, whitejj01 said:

also, how cool is it that TheEpicSquared took his coordinates, translated them into binary code, and put that as his location?

AWESOME!

Actually, it's not the coordinates of my location.  

Spoiler

It's the coordinates of Area 51.  

But thanks anyway.  

 

[whitejj01]

1 minute ago, TheEpicSquared said:

It's the coordinates of Area 51.  

But thanks anyway.  

#stupid

[eagle92lightning]

On 1/21/2017 at 2:16 PM, HoloYolo said:

One and two I agree with.

The problem with 3 is that they have to make a brand new solar system (new star and at least 2 planets to make it interesting) all over again. I imagine that they will be semi realistic with the distance, so time warping will take forever without mods/BetterTimeWarp added into the game. Also, we already have 3m parts, aka the NASA ones. For interstellar travel we either need faster timewarp, warp drives/better and longer lasting nukes, or maybe a combo of both.

I'd be ok with 4 as long as it is optional, but if I can't turn it off no thanks. I wonder, would the life support be like USI or TAC?

NASA is making bigger and I mean bigger rockets all the time

[nater662]

Do we know what will be in update 1.3? I have not heard anything and the dev blogs are void of information. The old planned features  http://wiki.kerbalspaceprogram.com/wiki/Planned_features page is dead.

Anyone heard anything or any timelines? 

[Foxster]

Nope. KSP has no roadmap for reasons only the development team know. i.e. we don't even know why we know nothing. 

[regex]

46 minutes ago, nater662 said:

Do we know what will be in update 1.3?

Localization, bugfixes, probably some performance improvements, IIRC. Beyond that, no one knows.

[Superfluous J]

The above plus an unnamed feature that all we know is that modders can and could have reason to want to hook into.

[ansaman]

The developers seem to want to "surprise" us with some new feature they keep hinting at.  I am waiting for screaming flaming Kerbals staggering from every wreck or body parts and internal organs splattering like in some first person shooters (Yes, I spelled that out.) MOAR EGGCITEMENTS!

[Foxster]

I'm going to go out on a limb and say the super-secret things is a dV and TWR display. 

[Whisky Tango Foxtrot]

Have they given any information on when 1.3 is expected to be released?

[ansaman]

10 minutes ago, Foxster said:

I'm going to go out on a limb and say the super-secret things is a dV and TWR display. 

Oh that would be very helpful to many newbies!

5 minutes ago, Whisky Tango Foxtrot said:

Have they given any information on when 1.3 is expected to be released?

Do not ask about release dates. It is heavily discouraged. Do not nag the developers

 

[Snark]

1 hour ago, Whisky Tango Foxtrot said:

Have they given any information on when 1.3 is expected to be released?

1 hour ago, ansaman said:

Do not ask about release dates. It is heavily discouraged.

It is not just just discouraged, it's also explicitly against the forum rules (see 2.3.e).

Note that Squad has always been reticent about release dates-- and quite properly so.  It can be quite hard to predict how long it will take for software to be "ready", until you get really close to the end.  Squad generally never announces release dates for any future version.

In the past, generally the way one knows that a release is imminent is when they announce that the new version has been released to "Experimentals".  Typically the full release comes within 2-3 weeks or so of going to experimentals.  But that's also not set in stone-- the experimentals could drag on a lot longer, if a lot of issues get turned up that need addressing.

(And speaking as a software engineer with a couple of decades of experience in the industry, I gotta say that I think they've made the right call, there.  It's impossible to predict when it'll be ready.  So if you're the company, and you make a prediction, you're going to be wrong, which means either you'll have to renege on it and say "Nope folks, we changed our minds"-- which will disappoint and outrage everyone-- or else you have to say "Well, it's not ready, but we'll just ship it anyway because we've hit the date"-- which will lead to a buggy and/or incomplete product, and lots of really unhappy users.  So as galling as the current state of ignorance may feel... it's actually better this way.  It's better not to know, than to think you know and find out that you're wrong.)

Generally the way you find out when Squad will be releasing an update is when they say "Hi everyone, we just released it!" 

Note that I'm not a Squad employee and therefore don't have any more visibility into what they're going to do than you do-- I'm just describing what they've always done in the past.  That's no guarantee that they'll do it this time around, just "this is what they've always done, so in the absence of evidence to the contrary, it's probably the most likely assumption this time too."

[TopHeavy11]

Personally, I think we might see another mod integration, like SP+ or Asteroid Day.

[Zhetaan]

@Snark:

Since you're a software engineer, I thought I'd ask a follow-up question regarding release dates:  as much as the alternative choices of pushing back release dates or shipping incomplete products would cause problems with the customer base, how much do release dates affect those responsible for production?  Obviously, within the company, there are those who know exactly how far along the product is and there are those who know how far along they'd like the product to be; one quite naturally cannot hide the progress from those who are making the progress.  Is the mismatch between these something that the professionals--managers and production people alike--have essentially learned to accept, or does it remain a major source of friction, anxiety, and other unpleasantness in the industry?  In other words, is knowing the intended release date (and how far away one is from meeting that date) something that the professional levels normally handle well, or is it in essence 'cursed knowledge' no matter who you are?

I can see professional developers running everywhere between the extremes on this one, from accepting that release dates are suggestions at best all the way to tearing their hair out over not completing the job 'on time', for whatever that means.

[Terwin]

1 hour ago, Zhetaan said:

I can see professional developers running everywhere between the extremes on this one, from accepting that release dates are suggestions at best all the way to tearing their hair out over not completing the job 'on time', for whatever that means.

That depends primarily on Management and how they handle it.

If Management includes a reasonable amount of development time and buffer to the schedule, and is understanding of reasonable delays, then missing a release date would be uncommon but something that is expected on occasion.(which could be met with either a delayed release or a reduction in planed features)

If Management likes to treat developers as an expendable resource with inadequate time to complete assigned tasks and harsh punishment for missing deadlines, you will have a much more anxious environment with high rates of burn-out and code defects.

 

It can be hard to get good estimates on how long a piece of code will take, as any time you have made that piece of code in the past, you do not need to re-make it, you just copy the old code, so all code that needs to be written is either new, or new-to-me type of work to a lesser or greater extent.  I have no doubt that the high level of uncertainty causes management types no end of headaches.

 

[TheKorbinjer]

Well, due to recent mass unplanned disassembly, they've decided to add

(stand up and look down onto your screen, or highlight everything)

 

MOAR BOOSTERS                                     ( ͡° ͜ʖ ͡°)

Honestly, I have no idea.  ¯\_(ツ)_/¯

 

[Snark]

2 hours ago, Zhetaan said:

Since you're a software engineer, I thought I'd ask a follow-up question regarding release dates

Sure thing! 

Just to be really explicit, though, in case anyone's reading this post and missed my disclaimer above:  Everything I say here, it's based on my general knowledge of the software industry, having worked as a professional software engineer in companies large and small for over 20 years.  I don't work for Squad, and I have zero visibility into their management practices, their decision making process, the relationship their management has with the developers who are working there, or anything else.  I'm a Squad outsider, same as you, and I don't have any more access to such information than you do.  So, please don't read too much into what I'm about to say:  it's not about Squad specifically, it's about the industry in general.

2 hours ago, Zhetaan said:

as much as the alternative choices of pushing back release dates or shipping incomplete products would cause problems with the customer base, how much do release dates affect those responsible for production?

An excellent question, with a simple answer:  It depends. 

...Okay, perhaps a bit more detail would be helpful there.

Software engineering, like all engineering, is subject to finite development resources, and one has to make a judgment call about which of the following to prioritize:

• What we produce
• When we produce it
• At what quality do we produce it

The old engineering joke goes:  "You can have it cheap, high-quality, and on time.  Pick any two."

Everything's a trade-off.  If you wanna ship more features, you either have to spend more time to get it out the door, or cut corners on quality.  If you want to hit a deadline, you either have to cut features, or be willing to ship crap.  If you want to ship a gold-star, armor-plated, high-quality product, you either have to cut features, or take a long time to produce.

(Or you can pump more money and people into production, in an attempt to boost all three.)

There's no single right decision.  It completely depends on the requirements of the situation.

My experience over the last couple of decades has been that for the most part (with some notable exceptions), this feature/time/quality triangle tends to get collapsed into a simple linear feature/time scale, with quality mostly out of the equation.  Why?  Details in spoiler section, because I can already tell this post is gonna be long. 

Spoiler

Because in most cases, the "quality" decision is the easiest one to make:

• You don't want to ship crap, because no matter how much you bat other stuff out of the park, a crap product will come back to bite you and you'll fail your business goals when the customers abandon you.
• On the other hand, you generally don't want to ship armor-plated, guaranteed-never-to-have-a-problem-even-once-in-a-century product, because getting something to that level of reliability is so ludicrously expensive and time-consuming that you'll totally fail on the other two axes and go out of business.  (Fault-finding and quality control are subject to diminishing returns; the fewer bugs are left, the more expensive and time consuming it is to find and fix them.  It's like cleaning a room:  easy and quick to clean it well, virtually impossible to clean it perfectly so there's literally not a single speck of dust anywhere.)

Certainly there are outliers.  If you're a company that's producing really critical software-- for example, to run the space shuttle, or hospital life-support equipment, or air traffic control, or nuclear power station control-- where people die, or you can literally cause billions-with-a-B dollars of damage, if something breaks-- then "extreme quality" is an option.  Those are the cases where the call has been made that "It's okay if it takes years and many millions of dollars to produce a simple piece of code, and each individual line of code literally costs more than a thousand dollars to produce."  In other words, it's a situation where time and features go out the window in order to sacrifice everything to the god of Quality.

However, those tend to be rare exceptions.  In the vast majority of cases, there's a fairly clear "sweet spot" of quality control investment, where you can get really-good-but-not-perfect for a reasonable cost.  You don't want to be crappier than that, because it doesn't save you much money and makes your product a lot worse and seriously annoys your customer base.  But you don't want to be a lot better than that, either, since you've hit the point of diminishing returns and it would involve spending tons of money and time for only a tiny incremental improvement in quality.

So the remainder of the discussion here will assume we're talking about software produced at this "sweet spot" level of quality, and just talk about the time-versus-features question.

So, assuming that as a company you've made the usually-what-everyone-does decision to ship "really good, but not perfect" software with a reasonable investment in QA, this means you're down to a question of what versus when.  It means that, broadly speaking, you have two ways to ship:

• Feature-driven:  "We know what features we want to ship.  We're going to work on it until those features are ready, and will take as much time as it takes in order to do so.  This means we can't predict exactly when we'll ship."
• Schedule-driven:  "We know when we want to ship; there's a date we need to meet, for some external or internal reasons.  We will do whatever we have to in order to meet that date.  This means we may have to cut features."

It's not strictly an either/or; there's a spectrum.  For example, you may be primarily schedule-driven, but you have some absolute-must-have features that you literally can't ship without, so you have to accept the risk that you may have to slip the schedule.  (You want to avoid that if possible, because it gives you a black eye and erodes your credibility if you do it a lot, but sometimes it's unavoidable.)

Generally, it's external factors that force a company's hand and determine whether a given release will be feature-driven or schedule-driven.

For example, suppose you're a game company working on a major new release, and a big gaming convention like E3 is coming up nine months from now, and your business model and marketing and such is critically dependent on having a big "wow" release at the convention, and if you miss it you'll go out of business because you don't have enough venture capital to last another year until the next one.  In that case... you gotta make that date.  So you'll do whatever it takes to hit that date, which may entail working some long hours... but it also may entail scaling back the planned feature list and cutting features until you've whittled it down to something that you can get done by the deadline, but still has enough stuff in it to be sellable.

On the other hand, you might have a case where you already have a product that's out there, working well, selling well.  You're working on a new version that you'll be releasing to address some issues.  On the one hand, there's no explicit deadline breathing down your neck-- it's not like "this has to be ready by 3:12PM on Thursday, six weeks from now, or we'll go out of business."  On the other hand, you have to address these issues, otherwise what's the point of releasing?  So in that case, you just work on those features until they're ready, then you ship, whenever that happens to be.

Both cases happen.  My experience is that the large majority of releases are schedule-driven, especially in larger companies where there are other big, heavy wheels with lots of inertia that also have to be set in motion for a release (e.g. marketing campaigns, scheduled analyst calls, tech support centers set up, supply-chain issues for hardware, documentation production, all kinds of other stuff).  But feature-driven releases happen, too.
 

 

2 hours ago, Zhetaan said:

Obviously, within the company, there are those who know exactly how far along the product is and there are those who know how far along they'd like the product to be; one quite naturally cannot hide the progress from those who are making the progress.  Is the mismatch between these something that the professionals--managers and production people alike--have essentially learned to accept, or does it remain a major source of friction, anxiety, and other unpleasantness in the industry?

Again, it depends on the company, its level of competence, and the business model it's chosen for itself.

Many words in spoiler section below.  I'll tell you three stories about three different hypothetical types of company, with three very different answers to the question you ask above.  I'll call them Type A, Type B, and Type C, just for convenience.

The executive summary:  Ideally, this supposed conflict isn't actually a conflict, because the management and developers work closely with each other in an environment of mutual respect and support, since they're all playing for the same team.  However, it's also possible to have a "use 'em up and spit 'em out" business model, where management treats developers as a consumable resource, and routinely just burns them out and then hires replacements.  That's repugnant to me, of course, since I'm a developer and am therefore biased in the matter, but depending on circumstances it can be a successful business model for the company.

Spoiler

A Type A company is one that's targeting success based on hiring skilled experts, giving them the resources they need to do their job well, and retaining them long-term so that you hold on to their hard-won expertise.  In this type of company... there's ideally no mismatch, because management and production are in close cahoots.  The managers and the developers work closely together, probably sit right next to each other, communicate frequently on a day-to-day basis.  The managers make sure that the developers know what the business goals are and what external requirements have to get nailed.  The developers make sure that management knows how the work is going, and give a prompt heads-up if any technical issues pop up that could impact schedule or quality.  Low-level management tends to have an engineering background.  If the company's big enough to have layers of upper-level management, then they respect what engineers tell them, and listen carefully to lower management.  So this conflict that you describe isn't a conflict and (mostly) doesn't happen because everyone's playing for the same team and working together to make the good stuff happen.

Examples of big type-A companies are the star players of the software world:  the Microsofts, the Googles, the Amazons, the Apples, the Facebooks-- those kinds of folks.  An example of a little type-A company would be some tiny but well-run indie startup where you've got five developers and one company founder (who may themselves be one of the developers), all working together in a garage somewhere.

Then you have the Type B company.  These tend to be run by business types who are focused on short-term gains.  They've made the business decision that developers are a consumable resource.  "Churn and burn" sums up this type of company.  Hire lots of young, clueless fresh college CS graduates, whom you can get for cheap.  Run them ragged with ridiculously long hours and unpleasant working conditions, squeezing every scrap of code out of them you can get, until they burn out and quit-- when you replace them by hiring the next young, clueless, cheap engineer.  Use 'em up and spit 'em out.  As long as the supply of fresh faces holds out, a company that does this well can keep going for years and make tons of money.

There are some notorious examples of Type B among big gaming companies.  I shall name no names; the ones that are sufficiently notorious have a widely known reputation.  There's plenty of info out there on the web, and you can google things just fine without help from me.     (Note that I'm not saying all gaming companies are bad-- there are some good ones out there-- simply that some of the biggest, best-known examples of the Type B are to be found in that industry.)

And then there's Type C, which is basically "incompetent Type B".  The screwups.  The companies that are hopelessly mismanaged and have an adversarial relationship between management and development, to the point that it harms output and eventually goes out of business.  However, even if the company crashes and burns, it's possible that the folks at the top of the pyramid may make out like bandits, and head for the door with enough cash to start up another enterprise and repeat the cycle.  These are the "strip miners" of the software world:  move in, extract cash while damaging everything and everybody around them, then flee to virgin territory.

Obviously, since I'm a developer myself and see everything through a developer's eyes, I'm biased here.    Given my biased perspective, I define "good company" as one that treats developers well.  So that's going to color the language that I use here.  I've been fortunate enough to work almost exclusively at Type A companies for my whole career, since those are absolutely the best place to work, if you're a developer.  (That's no accident:  if there's a prospective company that may be interested in hiring me, naturally I'm gonna ask enough questions to figure out "is this going to be a place I will enjoy working.")  However, I've worked closely with a lot of other people, including ones who came from the B's and C's of the world, so I've got a reasonable handle on what those are like.  It's worth noting that Type B, while unpleasant to work at as a developer, can be highly commercially successful for many years.

Also, for a big enough company, it's not necessarily an either-or thing.  You could have, for example, a company that might have some divisions that are run as Type A, but other divisions that are Type B.  It's a whole spectrum.

One thing to note-- if you're outside the company (e.g. as a customer, looking on)-- it can be difficult or impossible to tell which of the above-described models it is, unless the company is so large and well-known and has so many ex-employees that conditions in the company are an open secret.  But if the company is a small one, then it can be impossible for an outsider to tell.  "Don't know" means "don't know".

So, again, please take everything I say above as a general commentary on the state of the industry, and don't take anything I say as even the remotest speculation as to what category Squad might be in.

 

2 hours ago, Zhetaan said:

In other words, is knowing the intended release date (and how far away one is from meeting that date) something that the professional levels normally handle well, or is it in essence 'cursed knowledge' no matter who you are?

No, it's critically important information that everyone up and down the chain-- from uppermost management down to the rank-and-file engineers-- needs to have front-and-center in their minds at all times.  "What do I have to do, and how much time do I have to do it in."  It's really important, because if things start looking tight, then some difficult and irreversible decisions have to be made, such as finding features that can be cut.

But, again, the above applies to schedule-driven releases.  There are feature-driven releases where they slip the schedule to meet the needs of the features, rather than vice-versa.

 

My guess is that when Squad's working on KSP updates for the PC, they're primarily feature-driven rather than schedule-driven, thus all the player uncertainty and their reticence about announcing dates.  I would also guess that where the console releases are concerned, they would tend to be more schedule-driven, since that involves cumbersome supply-chain stuff that has to be coordinated, and approval process, and all that stuff.  I base these guesses on my general knowledge of how things work in the industry, and also on what I've observed from Squad's public announcements and actions.  I suspect they're reasonably good guesses, but that's all they are, just guesses, and I could be wrong, since (like you) I don't have any insider knowledge of how they make their shipping decisions.

[HebaruSan]

One more point to add to @Snark's in-depth disquisition is the role of publishers. They fund development of typical non-indie games (i.e., not SQUAD), so at the very least they need a way to make sure the studio isn't just taking the money and going to the beach, but they also care about getting the thing out the door in a timely fashion. They may have specific expectations about how many years a game will take or in which quarter it will be released. All of this means that the studio has to show regular progress and commit to dates to get continued funding. Publishers tend to push such games into the "schedule-driven" camp.

It's somewhat probable that the marketing-company higher-ups of SQUAD function like an internal publisher to the game-dev side of SQUAD; the dev team reports to them and probably provides high level overviews of the status of things. But I think we can all see that the relationship isn't exactly analogous, since the dev side seems to have significant freedom to define their own feature goals and release dates (presumably as long as they can make a convincing business case for those decisions).

I think this is the video where this former game industry guy talks about publishers. If not, check a few of his others, they're all pretty enlightening for those curious about the behind-the-scenes experience. Trigger warning, he does cover "gamer gate"-type topics from time to time.

 

[Zhetaan]

@Snark:

Just to clarify on my end, at no point do I assume that you speak for Squad; I'm simply interested in hearing what an expert has to say about the nature of the industry in general.  I find the development process fascinating, but that ought to come as no surprise:  I play KSP, so I have to have at least some interest in how complicated things are put together.

In truth, there are some interesting parallels between the software world and what I do.  I'm involved in water and wastewater treatment and infrastructure management, so the idea of refusing to fix all the little things because of the prohibitive expense resonates very strongly with me, as does the principle of quality being paramount (people really don't like poisoned water, it turns out).  For example, in water distribution, the goal is to keep the leaks down to under twenty percent.  That's quite a lot of wasted water but when you consider just how much it costs to dig a hole in the ground, both as a practical concern and in terms of the safety gear needed to keep people from dying in that hole (leaky pipes make mud:  one simply cannot get away with less-than-scrupulous care paid to safety matters), it begins to make sense.

In addition, there's a section of water pipe in my city that is made more of emergency patches than original pipe, but they don't dare dig it up and replace it because the emergency patches can be applied while the pipe is still under pressure.  To take the pipe out of service and replace it would mean draining and re-pressurising that section of the system--which could blow out every joint in every pipe and valve for the next four blocks.  It wouldn't be violent, of course; it would just cause twenty leaks where before there was one.  The upper management won't risk it until they can get a grant to fix the whole line.  Grants are not so forthcoming, so they instead buy patches and devote themselves to prayer.  In the meantime, people living on that street get angry that we're there every eight months or so, and they loudly complain that we don't just replace the pipe and have done with it, but there's always more to consider that most people just never bother to think about.

However,  I'd like to think that I am not most people.  Though the KSP devs choose, as is their right, not to explain their exact production process, having and idea about what goes on to make the stuff in the otherwise featureless grey box on my desk is helpful to me.  If I can't find out how the KSP devs do it, then I can ask a non-KSP dev how it works in general.  There's always a reason for people to do as they do, and that reason is rarely silly, pointless, or stupid:  it's usually good to find out what it is.  (Sometimes, though, someone tosses in a joker.  )