Should KSP have a Delta-V readout?

[dewin]

I'm in favor of a dV indicator being stock, and without any gating behind career upgrades.  (Even though it'd work very well with my ideas for a career tree mod with smaller, cheaper upgrades.)

[Kerbart]

21 minutes ago, Red Iron Crown said:

So....back to calculating by hand or using external tools then?

If you give the player accurate masses and accurate Isps then all you're doing by hiding the delta V counter or making it less accurate is pushing the player to manual/external calculation.

Option (b): pushing the player to upgrade their buildings.

"In the beginning, our rockets were inefficient. As we progressed, we managed to make better, leaner rockets"

I think it fits very well in a career narrative. Of course you can calculate things manually. Or use an external mod. Or just use sandbox if you don't like the career model of "earning" your way to bigger, better, faster. The whole point of career mode is progression, and personally I think something like this fits very well in it. We don't have maneuver nodes right from the beginning either, after all.

 

[regex]

 

6 minutes ago, Kerbart said:

"In the beginning, our rockets were inefficient. As we progressed, we managed to make better, leaner rockets"

So you want the player to upgrade or discover the isp of their rockets?  I can get behind that, it makes more sense for part testing contracts than #LOLTESTTHISSRBONAKERBINESCAPE.  Paywalling automated calculation is a simple irritant.

6 minutes ago, Kerbart said:

The whole point of career mode is progression

Progression that is logical is one thing, progression simply to make progression is lazy game design.

6 minutes ago, Kerbart said:

We don't have maneuver nodes right from the beginning either, after all.

Which makes sense in a way because you have to upgrade to better antennas and tracking.  Delta-V calculation for planning is just simple calculation; you have some rando to plug numbers into the slide rule and hand them to you.  Paywalling that is simply an irritant, poorly thought out game design.

[akron]

As much as I love science and how great it would be if I could calculate dV on my own with a calculator, I think the dV readout should be stock. The engineer report in the VAB/SPH is a good place to provide that information. dV and what it represents could also be KSPedia article as suggested. You can argue that it is not necessary to have a dV readout during flight, so you have a more traditional flight once you know the capabilities of your rocket, but it should be in the editors. I just think that along with orbital mechanics, dV should be one of those things that players naturally understand over time and not having that in stock limits that capability.

I have read far too many Reddit or imgur album comments about people who "can't even get to orbit" or "can't go to the moon" who might achieve those goals if the game helps them to learn about TWR, fuel, and the dV required to reach those goals. For example, upgrading your tracking station after achieving orbit could be set to unlock a dV chart so you can start to plan further voyages.

KSP is ultimately a game and should be accessible. It already does a good job of naturally teaching players basic space flight concepts over time. The inclusion of dV and TWR could expand that knowledge and help players be more successful, which in turn keeps them encouraged to play and explore.

Having the dV unlocked over time is not a good idea though. It should always be available on the editor. Maybe you can unlock a part with an in-flight readout or unlock it for your more advanced command modules later on, similar to how you can with Engineer or MechJeb.

Just some thoughts

Edited May 3, 2016 by akron

[monstah]

2 hours ago, Red Iron Crown said:

So....back to calculating by hand or using external tools then?

If you give the player accurate masses and accurate Isps then all you're doing by hiding the delta V counter or making it less accurate is pushing the player to manual/external calculation.

So, unlock the precision of the displayed part mass! /sarcasm

[Stoney3K]

On 02/05/2016 at 10:02 PM, Waxing_Kibbous said:

This is a fine idea and would give a good reason to try to shoehorn Ole Bill into the earlier missions.

That would make sense for a Delta-V readout in flight. I can imagine that that would be an unlockable gameplay element -- after all, you would need more instruments and computing capacity to figure out your dry/wet mass and engine Isp in real time.

Delta-V in the VAB should just be there since it is a derived number from information that is already displayed in the Engineer's report.

[Guest]

On ‎4‎/‎24‎/‎2014 at 10:10 AM, regex said:

I say no because I agree with the dev's position of trial and error gameplay. Graduating from the fumbling around at the beginning to realizing that was important information was a huge learning step for me.

On ‎5‎/‎3‎/‎2016 at 10:44 PM, regex said:

Okay, my argument is based on the grounds that, regardless of need, which is a very subjective topic in a video game, the information can easily be calculated by hand so there is no reason not to automate said calculation.

So early on, you say you support retaining trial and error gameplay and vote against a delta-v readout.

In your discussion with me, you say if the feature is to be included, it should be available from the very beginning, thus eliminating the 'trial and error' gameplay you originally advocated.

With my idea, you keep the trial and error gameplay until such time as the player might actually use the extra information constructively. Thus providing a learning curve, and gameplay progression.

You are trying to argue from the position of the tired old KSP player, working on his 50th career game, while I'm trying to address the problem from the position of the new player, starting a career for the first time.

You cannot design a game from both perspectives, you must choose one or the other. What you call lazy game design, I call providing a learning curve, and career progression for a player.

If you are actually working on your umpteenth career mode game, give yourself some Science and SpaceBucks at the start, and upgrade/research the first tiers of buildings/tech. No one is stopping you from reducing the amount of grind present in the game, and as an experienced player, you can do so easily with a few mouse clicks!

If you are a first-time player, using a trial and error period to learn basic game concepts, then being given the tools to improve your gameplay later on, is all logical game progression. Based on my reading of the thread, I see I am not alone in my opinion. You don't get the rocket launcher in level one, you start with the pistol, and work your way up. <- That is game design!

[Red Iron Crown]

@MailletC Note the dates on the two posts you quoted, opinions can change in two years.  

[regex]

24 minutes ago, MailletC said:

So early on, you say you support retaining trial and error gameplay and vote against a delta-v readout.

Oh wow, a two year old post.  I think back then I was even against using MechJeb because I felt like it was cheating.

Quote

In your discussion with me, you say if the feature is to be included, it should be available from the very beginning, thus eliminating the 'trial and error' gameplay you originally advocated.

No, I never said anything about eliminating trial-and-error gameplay, that's purely you projecting your own desired way of playing onto me.  After playing this game for so long I believe the trial-and-error should be moved elsewhere from constantly reverting launches and trips.

Quote

With my idea, you keep the trial and error gameplay

No, you keep your idea of what constitutes good trial-and-error gameplay and progression.

Quote

You are trying to argue from the position of the tired old KSP player, working on his 50th career game

I'm not trying, I am.

Quote

You cannot design a game from both perspectives, you must choose one or the other. What you call lazy game design, I call providing a learning curve, and career progression for a player.

If the information to calculate a desired and valuable piece of data is right in front of the player, and you refuse to calculate it for them until they jump through hoops I call it lazy game design.  Two years ago we didn't have a mass display in the VAB, we had to launch the craft and revert.  It was stupidly tedious to operate that way so you either installed KER/MechJeb or you simply built and launched, and tried in frustration until you finally made it to orbit.

Quote

If you are a first-time player, using a trial and error period to learn basic game concepts, then being given the tools to improve your gameplay later on, is all logical game progression. Based on my reading of the thread, I see I am not alone in my opinion. You don't get the rocket launcher in level one, you start with the pistol, and work your way up. <- That is game design!

A new player has zero idea how much delta-V they need to get to the Mun and back, much less reach orbit, so I'm not sure what you're removing from the trial-and-error period by providing the information to them.  If a player puzzles out that they need some 3.2km/s to get a rocket to orbit then they can more effectively and quickly build later lifters instead of wasting their time constantly reverting until they get it right (which is a stupidly tiring process).  If a new player goes to the forums and asks how much is needed and how to calculate it, and then finds out it is paywalled to create "progression", they will probably be rightfully peeved.

9 minutes ago, Red Iron Crown said:

@MailletC Note the dates on the two posts you quoted, opinions can change in two years.  

It doesn't matter, to them it's a silver bullet to put my argument in the grave.

E: Hell, I could have been trolling back then, or working on the assumption that everyone should suffer like I did, can't remember.

Edited May 4, 2016 by regex

[Guest]

11 minutes ago, Red Iron Crown said:

@MailletC Note the dates on the two posts you quoted, opinions can change in two years.  

I had not actually noticed that. The thread was at the top of the first page, thus I assumed it was a recent one. I guess I failed to note the thread date, and only noted the last reply date.

Since this thread is two years old, and SQUAD has made absolutely no announcements about including a Delta-V readout, this is a dead issue. So I'm not going to beat on a dead issue any longer.

Why this thread is still pinned to the front page is beyond me.

[regex]

Just now, MailletC said:

SQUAD has made absolutely no announcements about including a Delta-V readout

They have, actually.  Max previously announced that engineers may know something about "schmelta-V" (or something, although I trust nothing said by previous PMs) and @NathanKell has made overtures to programming it in the future (albeit with the requisite number of tears and groans that accompany such an endeavor).

I think, at the very least, we'll get much better mod support for delta-V calculators in the future.

Just now, MailletC said:

Why this thread is still pinned to the front page is beyond me.

@sal_vager thought it was a good thread for TOTM.  vOv

[r_rolo1]

20 minutes ago, MailletC said:

If you are a first-time player, using a trial and error period to learn basic game concepts, then being given the tools to improve your gameplay later on, is all logical game progression. Based on my reading of the thread, I see I am not alone in my opinion. You don't get the rocket launcher in level one, you start with the pistol, and work your way up. <- That is game design!

Ok, let me chime on this part of your argument and on the previous part you argued about creating a learning curve, since I see this one around a lot ...

For argument sake, I'll go to the same example you pick: that FPS games normally don't drop the best weapon on your hands at first, but first give you a pistol or a crowbar or any kind low level item. That might be true, but notice that they do that inside deliberately toned down levels, with low level enemy goons. The devs don't drop you with a pistol against the end boss on the first level, they drop you with a low level gun in a easy level that you can adequately mow down with some trial and error and maybe some tutorialish narrator/NPC text.

Now let's look at KSP, a game that is all about space exploration. You can't really make a space game exploration game with the easy stuff first, mainly because , by virtue of our old good friend Physics, the arguably hardest part of any space flight is to get to Low orbit first ( this until you can build and fuel your ships up there, but since KSP has no outbound ship build , that is not even a half-argument ). So you can't make a easy level first in KSP, period, and without that , the typical " let's give them the bad stuff first, and the good one later" game design strategy devolves in a inverted dificulty curve, with the hardest stuff being on the beginning and the game getting easier as you start getting the good stuff, that I assume is not the intended behaviour for most people  

In fact, if you peruse this same sub forum , you'll see a lot of complaints about people playing career ( or the new demo ) expressing their bafflement/anger about how hard the first steps of the game are or how utterly hard the new demo is compared with the previous ones ( or even stock ) because the SQUAD devs tried to create a learning curve by the method you're defending ( locking good parts, limting the size and weight of rockets, locking out action groups, mistaking a rover test facility with a landing strip for planes, making decouplers more expensive than ICBM capable rockets, locking out manouver nodes ) on top of a natural dificulty curve that is tilted in reverse of normal expectations , inadvertedly leading to making the game even more dificult at the beginning than it naturally was, and this without considering that you at first are suposedely less experienced than later ... 

My point, in resume, is that the method you're describing to create a learning curve is a bad fit for KSP as it is now, a sandbox space exploration game where the hardest step is naturally to get to orbit aka the first thing you need to do in game. If KSP was some kind of episodic maps with a lot of Space centers scattered around the planetary system and you started in Gilly and that you progressed around the centers by order of dificulty of launching from them, yeah, bad Space center facilities and a small assortement of not as good parts would probably fit well and trial and error would peobably not be frustrating. But on a open map and launching from the second hardest planetary surface to launch from in game at day 1 ... well, it is not  

 

 

Anyway, this is a wild tangent to the topic. In topic, I can't really see how the absence of a dV meter in VAB can be defended when all the intel needed to calculate it is literally displayed at the distance of a click ( unless you want to give a hand to players that have more math and physics backround  ). A dV meter on flight is another beast, though ...

[Majic]

19 minutes ago, MailletC said:

Why this thread is still pinned to the front page is beyond me.

Perhaps because it may not actually a dead issue. 

[HebaruSan]

12 minutes ago, r_rolo1 said:

That might be true, but notice that they do that inside deliberately toned down levels, with low level enemy goons. The devs don't drop you with a pistol against the end boss on the first level, they drop you with a low level gun in a easy level that you can adequately mow down with some trial and error and maybe some tutorialish narrator/NPC text.

Now let's look at KSP, a game that is all about space exploration. You can't really make a space game exploration game with the easy stuff first, mainly because , by virtue of our old good friend Physics, the arguably hardest part of any space flight is to get to Low orbit first ( this until you can build and fuel your ships up there, but since KSP has no outbound ship build , that is not even a half-argument ). So you can't make a easy level first in KSP, period

SQUAD has tried to create easier initial goals to keep new players busy during the early stages, with the "world first" milestones. An altitude record of 3.5 km, a speed record of 150 m/s, and a distance from KSC of 5 km (and so on) are all a lot easier than orbit. (The only list I could find is on @Heimdall's wiki profile.)

http://wiki.kerbalspaceprogram.com/wiki/User:Heimdall

12 minutes ago, r_rolo1 said:

A dV meter on flight is another beast, though ...

Why? You can still get the wet mass (map screen, 'i' for ship info), dry mass (LiquidFuel an Oxidizer are 5 kg per unit), and specific impulse (right click engines).

[r_rolo1]

1 minute ago, HebaruSan said:

SQUAD has tried to create easier initial goals to keep new players busy during the early stages, with the "world first" milestones. An altitude record of 3.5 km, a speed record of 150 m/s, and a distance from KSC of 5 km (and so on) are all a lot easier than orbit. (The only list I could find is on @Heimdall's wiki profile.)

http://wiki.kerbalspaceprogram.com/wiki/User:Heimdall

Well, I didn't said they didn't tried   But again my point was that KSP natural dificulty curve is heavily slanted towards the beginning of the game ( due to the inherent relative dificulty of launching to LKO compared with the interplanetary stuff, atleast until you're trying to return stuff to Kerbin  ) and that adding the typical "bad stuff for newbs, good stuff for pros" in top of that actually made the dificulty curve to be inverted :/  and those before LKO goals don't do much dent on that, unfortunately

2 minutes ago, HebaruSan said:

Why? You can still get the wet mass (map screen, 'i' for ship info), dry mass (LiquidFuel an Oxidizer are 5 kg per unit), and specific impulse (right click engines).

You awnsered your own question. You don't have acess to the dry mass in flight unless you have it on your own memory  ( and TBH up until 2 or 3 versions, LF, Ox and Mono were not of consistent weight across parts  ). You could argue it should be there, sure, but it isn't

[Guest]

1 minute ago, regex said:

They have, actually.  Max previously announced that engineers may know something about "schmelta-V" (or something, although I trust nothing said by previous PMs) and @NathanKell has made overtures to programming it in the future (albeit with the requisite number of tears and groans that accompany such an endeavor).

I think, at the very least, we'll get much better mod support for delta-V calculators in the future.

That's good to hear. I've been reading the devnote Tuesday posts for about two years now, and hadn't seen anything about that. I do hope something is implemented, regardless of how it's done. I've been in favor of a radar altimeter, docking port indicator while in docking mode, and a TWR and Delta-V report in the VAB for a long time.

14 minutes ago, r_rolo1 said:

For argument sake, I'll go to the same example you pick: that FPS games normally don't drop the best weapon on your hands at first, but first give you a pistol or a crowbar or any kind low level item. That might be true, but notice that they do that inside deliberately toned down levels, with low level enemy goons. The devs don't drop you with a pistol against the end boss on the first level, they drop you with a low level gun in a easy level that you can adequately mow down with some trial and error and maybe some tutorialish narrator/NPC text.

For sake of argument, I was treating the initial stages of flying around the Kerbin system as the 'Easy Levels' before you attempt to fly an interplanetary transfer. That being the beginning of the 'Challenging Levels'.

[r_rolo1]

20 minutes ago, MailletC said:

For sake of argument, I was treating the initial stages of flying around the Kerbin system as the 'Easy Levels' before you attempt to fly an interplanetary transfer. That being the beginning of the 'Challenging Levels'.

But arguing against that was my point  KSP natural dificulty curve is that the hardest step is going to LKO ( both by the dV requirements as per the contraints put down by the aerodynamics ) and that after you get to orbit, interplanetary stuff is comparatively easy ( also, note that going to Duna or Eve is easier than to go to the Mun, land and back  in dV count, ship complexity, and actual required piloting skills , so your Easy vs Challenging distinction between Kerbin mini-system and interplanetary is blurry , to say the least ) ... and if you add the typical restraints we see in other games like the ones you hinted out, you get a inverted dificulty curve, that is not intended behaviour , I assume ...

In other words, for a in game example, it is harder to get to the Mun on LV-30 and 45s on the intial VAB and launch pad contraints than to do a Moho or Eeloo and back with the fully unlocked Space center and science ... basically, we already have a inverted dificulty curve as it is. You don't need to coumpound that by adding yet another forced initial relative dificulty , like only having a dV meter after unlocking stuff

Edited May 4, 2016 by r_rolo1

[Guest]

1 minute ago, r_rolo1 said:

But arguing against that was my point  KSP natural dificulty curve is that the hardest step is going to LKO ( both by the dV requirements as per the contraints put down by the aerodynamics ) and that after you get to orbit, interplanetary stuff is comparatively easy ( also, note that going to Duna or Eve is easier than to go to the Mun, land and back  in dV count, ship complexity, and actual required piloting skills , so your Easy vs Challenging distinction between Kerbin mini-system and interplanetary is blurry , to say the least ) ... and if you add the typical restraints we see in other games like the ones you hinted out, you get a inverted dificulty curve, that is not intended behaviour , I assume ...

That's the problem, people look at an inverted difficulty curve and think it's not normal.

Yes, KSP has a steep initial learning curve. So what? Once you get past the learning curve, the game is trivially easy. KSP is a rocket flight SIM, with the same type of learning curve.

Sim games have a completely different learning curve than other types of games, because just getting started is the hardest part, and things get progressively easier as you learn how to play.

You modify the difficulty curve by not flooding the player with too much, too fast.

In the same way you learn how to take off and land in a Cessna 172 before you even think of flying a Boeing 747, you give the player just the basic tools, and let them learn how to do the basic things. That's why you don't burden the new player with a ton of information they can't use yet. In fact, the takeoff, and landing is the hardest part of the entire flight, in exactly the same way learning how to orbit Kerbin is the hardest part of playing KSP. Once you know how to get to orbit, you'll never think it's difficult ever again, except maybe when you're learning how to land.

I will readily admit, my own background as a pilot made this game much easier for me to learn than other people, but I also have experience with flight training. Learning how to fly a plane is an entirely different process than learning something else, like driving a car. When you learn to drive a car, you start out by going slowly, usually in an empty parking lot or some such place. You then progress to higher speeds, more winding roads, and eventually arrive at the interstate highway. You cannot apply the same type of learning curve to a flight sim, because the mechanics of the simulation are completely different.

 

My use of the Kerbin system as the 'Easy Mode' is entirely based on observed behavior, the typical player I've seen won't even think about traveling to another planet before they go to the "closest" places first because they see it as "easier". You know better, because you are already experienced, and are already familiar with things like Delta-V. You have to take off the 'experience goggles' when thinking about new game features, because these features will effect new players far more than experienced players.

[HebaruSan]

2 minutes ago, r_rolo1 said:

after you get to orbit, interplanetary stuff is comparatively easy ( also, note that going to Duna or Eve is easier than to go to the Mun, land and back  in dV count, ship complexity, and actual required piloting skills

I think you might be forgetting transfer windows. I can eyeball Mun burns every time, but I have to ask KAC or TWP or Alex Moon when to go interplanetary. A new player could easily spend upwards of 15 km/s and still not get where they're trying to go.

2 minutes ago, r_rolo1 said:

In other words, for a in game example, it is harder to get to the Mun on LV-30 and 45s on the intial VAB and launch pad contraints than to do a Moho or Eeloo and back with the fully unlocked Space center and science. You don't need to coumpound that by adding yet another forced initial relative dificulty , like only having a dV meter after unlocking stuff

Why would you attempt the Mun on T30s and T45s with the initial VAB and launch pad, except to challenge yourself? There are far easier activities available to unlock better tech and facilities. A Mun landing is not the equivalent of E1M1.

[r_rolo1]

@MailletC

You make 2 points. Let me adress them separately.

First, when I was talking about inverted dificulty not being intended behaviour, I was talking from the devs point of view, because games with high initial dificulty curves tend to sell less  . My point about the dificulty curve was not on the dificulty curve in itself, but that locking features out at the begining of the game added dificulty to a already dificult situation in this game particular design choice ( while it is a perfectly valid way of scaling dificulty in other games, though ). I do understand your point about piloting ( actually a good one ), but it is not really aplicable in here because KSP has nothing like a flight instructor  helping you along the way in those hard moments where you're learning to go to orbit ( I suggested that years ago. Devs aparently thought tutorials were enough for that ), a thing that in RL smooths the learning of piloting a plane a lot compared with dropping a completely untrained person in the pilot seat alone

Your other point is about perceived dificulty and information overload. I'll chime on the perceived dificulty  in the awnser below to other forumer , but on the information overload issue ... well, that is a UI design matter more than anything. It is perfectly aceptable in game design to toss stuff that you find that the player might need to but that is not immediatle needed or maybe intimidating in a second UI or under a advanced Tab. KSP already does that with a good bunch of the aero and thermal variables ( both via F11/12 or the Alf-F12 menus ...or even that tiny side menu on flight mode that gives you the wet mass among other things ), so I don't really see how a dV number can be any worse than the lift vector on one part or it's thermal emmisivity...

@HebaruSan

First , let me point out that launch windows are more sugestions that hard physical contraints. They are just the best times dV wise for a Hohmann transfer ( so they might not be even the best option dV wise in general ) and they actually might not the best times to launch if your mission profile includes a return from target ).

Second, note that going to the Mun also has launch windows and that you can also give 15 Km/s to a noob and he can also fail the Mun as well ;). In fact the more likely scenario for a noob player without any guidance from the forums is to miss the Mun even if with enough dV ...

Third, from the point of view of a noob the game gives you exactly as many clues about when to launch to the Mun as when to launch a interplanetary flight. You can eyeball it because you either made the math ( like I, Scott Manley and others did back in the days the Mun was added to the game ) or heard about the "Burn when the Mun rises above the horizon" rule of thumb either in the forums or on some RL Apollo missions related source. Note also that the stock game gives you enough intel to plan any transfer window you need interplanetary or not as long as you have acess to manouver nodes , as I describe here ( I agree it is cumbersome, unituitive and definitely not noob( or anyone )-friendly, but it was not me that designed the game  ).

That leaves point #4, the fact that interplanetary feels harder than Kerbin mini-system stuff, while actually it isn't like that necessarily in anything besides number of oportunities to get stuff right per hour of game ( something that also depends of the top warp speed , so again UI issues ). That is a typical example of a diference between perceived dificulty vs actual dificulty , something that happens when there is a mismatch between how the game looks hard against how hard it really is. That might be desirable at times, but in general when you have something like that happening it is because either the gameplay or UI are lacking and IMHO in this case it is mostly the case that the UI does nothing to dispel the outside of game based idea that just because a trip is longer , it must be harder ( not even in RL that is true, but oh well ) and in fact in some areas the game reinforces that view ( the contract reward structure, for a example ).This is yet other area where IMHO the game UI is lacking ...

 

 

On the point of Mun with LV-30 and 45 and low level KSC vs Eeloo or Moho with unlocked everything  ... my point was that a good rule of thumb regarding game design is that the highest perceivable short term goal dificulty should be somewhat constant during a game ( to avoid bottlenecks ) and that like the highest dificulty goal you can perceive in game in terms of doing a actual trip is going to Moho or Eeloo , the highest dificulty goal a noob player can see in it's short term list is going to the Mun ( the game literally opens with either kerbals in Kerbin orbit with the Mun rising in their backs or with a Kerbal in the ( fake  ) Mun with a crashed ship, your first launch with occur at Munrise as seen from KSC, the contract structure puts it as the obvious target after going to orbit ... any normal person would assume that going to the Mun is on the short term menu list  ). IMHO due to that those two goals should have similar dificulties to not create bottlenecks in perceived dificulty just because the game puts literally a shiny goal in front of your eyes that you will find yourself hard pressed to acheive with the starting tools.

More, doing stuff with only LV-30 and 45 with low level KSC buildings is literally the situation you are in the current game demo, so, unlike in the previous demos, it is quite hard to land on the Mun in them... So due to bad management of this issue in the full game, KSP is probably the only game I know it is harder in the the demo than in the full game , and I can't see how that is noob friendly

[Red Iron Crown]

2 hours ago, r_rolo1 said:

TBH up until 2 or 3 versions, LF, Ox and Mono were not of consistent weight across parts

News to me, LF and Ox have been 5 kg/unit and Monoprop has been 4 kg/unit since resources got split.

[Guest]

21 minutes ago, r_rolo1 said:

My point about the dificulty curve was not on the dificulty curve in itself, but that locking features out at the begining of the game added dificulty to a already dificult situation in this game particular design choice ( while it is a perfectly valid way of scaling dificulty in other games, though ). I do understand your point about piloting ( actually a good one ), but it is not really aplicable in here because KSP has nothing like a flight instructor  helping you along the way in those hard moments where you're learning to go to orbit ( I suggested that years ago. Devs aparently thought tutorials were enough for that ), a thing that in RL smooths the learning of piloting a plane a lot compared with dropping a completely untrained person in the pilot seat alone

Part of comment removed for nonsense, you do not speak for the devs, nor know their thought process. They have long since promoted their game as a learning process, and educational tool, now you propose to remove the "learning" part from the game. How silly. You are still treating KSP as if it's "just a game" when clearly, it isn't. It's a simulator. A very simple simulator, with a "little green men" comedic element, but still a simulator.

As for the rest of it, well it's a good thing we're playing a game and not launching actual rockets, yes? Real life doesn't have a reset button, but games certainly do! That's what makes them fun, instead of tragic.

Quote

Your other point is about perceived difficulty and information overload. I'll chime on the perceived difficulty  in the answer below to other former , but on the information overload issue ... well, that is a UI design matter more than anything. It is perfectly aceptable in game design to toss stuff that you find that the player might need to but that is not immediatle needed or maybe intimidating in a second UI or under a advanced Tab. KSP already does that with a good bunch of the aero and thermal variables ( both via F11/12 or the Alf-F12 menus ...or even that tiny side menu on flight mode that gives you the wet mass among other things ), so I don't really see how a dV number can be any worse than the lift vector on one part or it's thermal emissivity...

Throwing information at the player they cannot use only encourages them to ignore it.

Giving it to them after they realize how much they need it encourages them to use it.

See the difference?

Those function menus, except temperature gauges, are disabled by default, because the player doesn't need the information unless something goes wrong.

Your own example proves my point, you don't throw information at the player when they don't need it.

[r_rolo1]

Just now, Red Iron Crown said:

News to me, LF and Ox have been 5 kg/unit and Monoprop has been 4 kg/unit since resources got split.

IIRC there were some parts up to 0.25 ( that in my head is 3 versions away  ) that had not exactly 5kg per unit of LF due to most like some rounding errors of the devs. It was nothing very serious, though

[Pthigrivi]

I confess I have not followed this entire thread so apologies if this is a repeat:

An important point is that its not just about helping players plan better, which it does, but it also provides a real-time tool to understand rocket efficiency. Players can add and remove parts and watch their weight and dV change so that they can understand the trade-offs involved. This helps them not just to get to where they're going more reliably, but to learn how to build better rockets. In this way its not removing the trial and error spirit of the game, its just extending it into the VAB. This saves time for players because they're actually learning faster. They're also progressing faster and able to do more in less play-time, which makes it more rewarding. Not to mention generally helping players make more efficient rockets helps them keep their part-counts down and improves over-all average performance.

Edited May 5, 2016 by Pthigrivi

[r_rolo1]

Just now, MailletC said:

Part of comment removed for nonsense, you do not speak for the devs, nor know their thought process. They have long since promoted their game as a learning process, and educational tool, now you propose to remove the "learning" part from the game. How silly. You are still treating KSP as if it's "just a game" when clearly, it isn't. It's a simulator. A very simple simulator, with a "little green men" comedic element, but still a simulator.

As for the rest of it, well it's a good thing we're playing a game and not launching actual rockets, yes? Real life doesn't have a reset button, but games certainly do! That's what makes them fun, instead of tragic.

Well, I do not speak for the devs, surely ( neither of us, TBH ). I do know their thought process partly, though, because the devs fortunately can speak and type, and Harvester was always very, VERY adamant that he wanted to smooth out the game for newer players in his public interventions either here or in other media. OFC intentions do not always beat with final results and my point in this discussion was always that while the devs tried to make the entry of new players in the game easy, some of their actions worked in reverse.

About the game being a learning tool, yes, it is .I already used it to tutor high school kids about physics. But letting the players happily crash stuff until they got it right, while it is a learning experience, is probably not the optimal way of doing stuff, because while they can learn to do stuff right, they are not learning how to do it or why it worked this time and not the other.

For a quick example, I can say to a kid that the reason his rocket is not taking off is because the weight of the rocket ( pointing out ot the number in the flight engineer menu, maybe also taking the cue to explain the diference between mass and weight and how to get one from the other ) is bigger than the thrust of the engine ( pointing out to the parts menu number and maybe explaining other details depending of the age ) ... He could probably discover it by itself by taking out weight ( or adding boosters, most likely ), but I ,as a tutor, might point out exactly what he is doing right or wrong without much fuss because the numbers are there ,even if somewhat hidden ( more on that below ).

OTOH when a kid asks me what is that number that appears in manouver nodes, I can explain what it is and where it comes from ( it is actually a good starting point to introduce velocity as a vector ), but then the inevitable next question is "How do I know how much dV I have in my ship?", while I can talk a little about the general idea ( most of the times I can't really enter in much details because they don't know log tables  ), I can't really do like in the above example, because the number simply isn't there , in plain sight or not. I can't simply say: "Do you see? If you put this part here, your dV decreases because you're adding mass that is not fuel. Now if you take that part off and add a fuel tank, you're adding dV because your initial fuel load is bigger. So this ship might go where you wanted and the other one will not ...", while I can do this in the above mass of rocket vs thrust ASL example.

All of the above already happened to me, so I think I can talk about  it  

I'll not enter in the discussion of simulation vs game or about what is fun. Both are highly subjective and I assume our positions are quite divergent on both issues. And it would be even more off topic than most of this discussion...

1 minute ago, MailletC said:

Throwing information at the player they cannot use only encourages them to ignore it.

Giving it to them after they realize how much they need it encourages them to use it.

See the difference?

Those function menus, except temperature gauges, are disabled by default, because the player doesn't need the information unless something goes wrong.

Your own example proves my point, you don't throw information at the player when they don't need it.

Let me point out that a variable, besides being in plain sight or hidden, might be acessible. Or in other words, besides throwing him information or not, I have the option of saying to him "I leave this intel here. If you feel like it you want or need it, give it a look. But you don't actually need to see it at all times" .Every program that displays any kind of intel in it's UI has variables that are visible, others that are hidden and others that while not visible at the moment , can be acessed at the user will, normally under a submenu or another tab. 

Say, let's look at the flight scene on KSP by default and the intel it is there. You have exactly 3 numerical variables displayed: Mission time, Altimeter and Velocity relative to surface and a couple more non-numerical variables ( thurst percentage, g-meter, the thermal gauges, fuel in tanks, ... ). Those are visible without any more interaction with the UI and this is what a 1st time player sees and barring some random clicking or some self or assisted tutoring, this is all he will ever see on that screen.

Now note that the flight scene has far more intel more or less acessible , under sub menus of the already displayed intel ( say, you have speed relative to target and orbital velocity in the same UI part of the surface speed if you click it ), on click in some UI parts ( say fuel quantity in total and per state and rate of consumption/generation ) or via documented keyboard keys ( the drag/lift/thrust vector display ( F12 ) or the flight log (F3) are good examples ). This intel is avaliable to the player, but only on command by the player. That is, the player wants to see it and has to take a conscious step to see it and the game itself provides the way to get that intel. If you don't want a certain intel to be seen by most players, you can always let it only acessible via game console, like KSP does with a lot of variables. It is assumed most players will not go there without a good reason, right?

Then there are hidden variables that are never stated in the UI. Say, the game never states the densitity of Kerbin oceans or the air viscosity, but has surely variables inside that represent them and if you really, REALLY want to know them, you can only know them via trial and error in game or check the source files.

My point of view, that apparently I was not able to pass to you, is that the dV number should be acessible in game, like, for example, the wet mass of a in flight rocket or the lift vector on a part are. That is, the number is there and if I want to, I can go check it. I don't want or need the dV number in sight all the time or even most of the time, like the mission time is, but I would like that, when I want it , I could check it, like the ASL thrust of a engine in the VAB.

In resume, there is a middle ground in between thworing intel to the player and withholding that same intel in the depths of the source files. I think a ship dV fits there nicely.