Devnote Tuesday: Experimenting and Researching

[A-Stax32]

That's because getting to Duna is HARD when you break it down. It's easy for US because we've done it. For a new player it's daunting.

One thought: Could you break it down into multiple tutorials?

1. You're in LKO, get a Duna encounter.
   
2. You're halfway to Duna, use a mid-course correction to tighten your approach.
   
3. You're in Duna's SOI and Ike's in the way. Oops. Fix that.
   
4. Aerobrake into a stable orbit.
   

Each starts in a situation that you COULD have gotten to from the previous tutorial, but it's set in stone so you as the tutor have control of the variables.

Totally agree with you on this one. This would be a great way to prevent the player from totally messing up everything without holing their hand the whole way.

[r_rolo1]

Really, Kasper? How can you uninstall all the programs on windows by accident? I can only imagine 2 or 3 ways of doing so ( say, going to a restore point that you made at 1st boot ), but doing that by accident actually requires some skill

@HarvesteR

Good to know the tech tree will be fully and easily moddable. It should always been that way from day 0

TBH I'm not that sold to the whole "let's throw the techs into a blender, feed it to QA and let's see what will come of it ... but only inside our parameters" . It is easy to fall in either extreme: the system will be gamed for all the juice it is worth by the QA and you will get just a list of best techs in the top spots, or your guidance is so railroading that you will end getting what you ( by you I mean the dev team ) wanted in the first place, making the whole exercise moot.

Let's just pick a clear example: manned vs unmanned flight. If all the techs were available from day 0 and all costs were equal, one of the first techs that would be picked surely would be the tech that gives the lightest probe core that can SAS and has some reaction wheels ( the OCTO, IIRC ), because obviously you want to reduce your payload mass to the minimum due to the rocket equation tyranny. But you ( dev team again ) have been adamant since first time we had science that you want manned flight first for #reasons ( never understood that TBH. It is not that you can nowadays EVA out besides in the Kerbal surface until you drop the bling ( so no opportunities for beauty EVA shots at first flights ) and if you are adamant on having a kerbal face in the lower right corner in first flights, you could always do a CAPCOM IVA and put Jeb on a joystick remote controlling it ). So, if we go the way you describe, QA will surely give you a list where probe techs would be high in the list of the first techs to be achieved, but you ( dev team ) would not want that ...

Edited March 18, 2015 by r_rolo1

[tater]

I’ve created a new version of the tech tree which features absolutely no dependencies between nodes. This means all notes are researchable from the start. Also, all nodes have the exact same cost.

So this means that we can research nuclear propulsion for 10 science at the beginning?

No, he's doing this for the QA team, and they will try and pick a progression of stuff. It's like crowd-sourcing different peoples' ideas about how they should be ordered.

The reality of course is that most all KSP tech is actually simultaneous. If you set the 1st tier at 1960, there would be almost nothing left in the tree past that.

[Tw1]

Up until now, the tech tree was hardcoded into the research and development UI prefab. This was changed now, and tech tree is now completely loaded from a cfg file.

Now, please make Kerbal gender and roles work the same way. Or, have them load from the persistent file. Something to make it less non-customisable.

Also, don't forget no amount of rearranging the tech tree will provide any benefit to post-tech tree, or post unlocking all the buildings game play, which, as well as detailed ground exploration, is still a hole in the game.

[basic.syntax]

Organizing related quotes together, I arrive at this:

This tech tree will be included on the QA builds, and during testing, we will ask the testers to note down the order in which they went on unlocking the nodes. From that data, we should be able to run some statistical analysis to help us determine which parts are needed first...

...this is highly dependent on what the contracts system will ask of you, and because that is changing in this update as well...

...we're not doing this in an open environment, but in the controlled group that is the QA team. We can instruct the testers to select nodes in a well-paced progression, selecting not the best and shiniest parts first, but what seems fit to be the next logical step.

What I gather from this is: QA will be running through the new contracts, and as a by-product of that testing, note down which parts they needed at a bare minimum, to complete the contract. Not the most expensive "best" part, but the least.

For example, putting an unmanned probe into Kerbin orbit - "that has a power (source) and antenna" - does not require the best probe core, solar panel or battery or "Mainsail" powered rocket, to get the job done.

One problem this testing WILL catch, is the awkward problem in .90 of aerial surveys: landing gear was too high-up in the tech tree. I imagine most QA testers will feel that wheels are necessary on the most minimal version of an airplane

[DrD]

Thanks this all sounds great.

This really is a polite forum, the majority of respondents were nice enough to include some thanks or compliments prior to launching into questions and/or comments.

Nice to see basic courtesy still lives on the internet.

[Commander Zoom]

Now, please make Kerbal gender and roles work the same way. Or, have them load from the persistent file. Something to make it less non-customisable.

Thiiiiiiis.

[Superfluous J]

Thanks for you input, maybe making several tutorials is not necessary, but you break down of the mission is definitely helpful.

You are welcome The worst part is I've done it so many times that I just pounded that out off the top of my head

- - - Updated - - -

So this means that we can research nuclear propulsion for 10 science at the beginning?

No, it means the tight-knit QA group can do it, for testing purposes.

- - - Updated - - -

Now, please make Kerbal gender and roles work the same way. Or, have them load from the persistent file. Something to make it less non-customisable.

YES!!

[dryer_lint]

One problem this testing WILL catch, is the awkward problem in .90 of aerial surveys: landing gear was too high-up in the tech tree. I imagine most QA testers will feel that wheels are necessary on the most minimal version of an airplane

This.

I remember trying to build a plane without landing gear. It was a great plane, a great kamikaze plane.

[r_rolo1]

Organizing related quotes together, I arrive at this: What I gather from this is: QA will be running through the new contracts, and as a by-product of that testing, note down which parts they needed at a bare minimum, to complete the contract. Not the most expensive "best" part, but the least.

For example, putting an unmanned probe into Kerbin orbit - "that has a power (source) and antenna" - does not require the best probe core, solar panel or battery or "Mainsail" powered rocket, to get the job done.

Hum, that might be the idea, but it is still a problem, because contract rewards ( that are the ultimate deciding factor on how effective a certain rocket is in doing that contract ) are ultimately decided by the the price structure of parts and, let's be honest, the price structure that the game has is almost as wonky as the science tree. And you need to add the fact that a good bunch of parts are not directly touched by the contracts ( fuel tanks, powered wheels, structural parts in general, capsules, batteries ... actually it would be faster to say what parts are touched by contracts directly ), so the bare minimum would either be the bare minimum ( say for your example would be a 200 l tank, a 48-7S, a OCTO2, a solar panel and the smallest antenna ) or a myriad of interchangeable configurations if you give it any kind of lenience ...

One problem this testing WILL catch, is the awkward problem in .90 of aerial surveys: landing gear was too high-up in the tech tree. I imagine most QA testers will feel that wheels are necessary on the most minimal version of an airplane

Only if you want to land them in a whole piece

Other issue that they will get is the lack of early engines for planes ( that are not rockets, that is ). My personal opinion is that, given that there are only 3 non-rocket non-ion engines ( and one of them is firmly stuck in the end of the tech tree due to it's Scifiey nature in RL ), it is hard to make a decent progression in the flight department in terms of engines. If there was a non jet engine for planes that was available with first tech, it would make flight progression easier to be made sane ...

Edited March 18, 2015 by r_rolo1

[TheMoonRover]

This is all sounding great!

For the Tech Tree you may find [THREAD=99521]this modded tech tree[/THREAD] to be a good source of inspiration.

Semi-serious suggestion: If there is going to be a GAME OVER scenario, shouldn't there also be some kind of WIN scenario. At the moment completing the tech tree and fully upgrading the buildings are the only things which constitute an ending. I liked NovaSilsko's idea of the easter egg storyline and hidden planet, but that would be a lot of work on top of an already huge workload (by the sounds of it). But how about if the Explore Body contracts lead up to a big final Grand Tour contract to land on all the planets in a single mission? Actually, thinking about it, there is a contract type called GrandTour shown in the debug menu, but it doesn't appear to do anything. That suggests the basic framework for it is already there but was dropped for some reason. Time and/or bugginess, perhaps? (Something tells me I've posted that before in a different thread. Ah well, no harm in posting it again here.)

[John FX]

I personally am still in favour of multiple choices for tech trees for stock play.

One is manned, one unmanned, one spaceplane and one historical. Each releases parts in set orders so the desired gameplay works best for that tree.

just reading the names you know which parts go in which order for each of them. Obviously the octo is very late for all of them, in fact the later tree would be very similar for all of them.

[monstah]

All very good. Thanks for all the effort.

[Superfluous J]

I remember trying to build a plane without landing gear. It was a great plane, a great kamikaze plane.

I actually had a great amount of fun making a plane for aerial surveys (and part testing) without landing gear. It was a fun design challenge. That said, it was not something the game should have forced on me by default.

[Lord Aurelius]

The highlights for me from this devnote are the moddable tech tree and the dds asset loader. Really glad to see that we're getting a proper interplanetary transfer tutorial, that's something I've still never really mastered (MechJeb is my friend and is the main reason I still play this game), I'll have to give it a try after 1.0 comes out and hopefully be able to finally master it.

That's an interesting methodology for getting data to check the node placement, not necessarily what I would do but hopefully it works out. My approach would be to draw out a rough draft (possibly based on what you have now) and playtest it repeatedly, identify problem points where players run into progression problems (i.e. a part/node needs to be moved earlier) or parts that are completely unused (move parts later to encourage players to use alternatives, or move the unused parts earlier before the alternative is unlocked). I would assume this is also the approach used by the various mod developers working with the tech tree.

I also agree that at some point the whole progression mechanic needs to be completely rethought, it doesn't really make any sense that random science data from other planets would be used to unlock new parts. It would make more sense for a mission plan to be identified (i.e. a contract) and then you identify the parts needed and do the research with funds (and possibly with contracts to unlock some parts as mentioned in another post, contracts to do something similar to the orion capsule test flight would be cool) and then to change the science to be the currency for some kind of end-game goal instead of being the primary means of progression. Another possibility would be that specific experiments give specific bonuses to certain parts, i.e. pressure experiments in Kerbin's atmosphere could improve the ISP of some of the engines, temperature/pressure/radiation experiments are required on a given body before EVA is allowed (as a side note: we have temperature and pressure experiments, but no radiation or magnetic fields?) so we would have a reason to send a small probe to scout ahead of time to upgrade get the data needed for a manned mission.

Thanks again Squad for providing weekly devnotes for us and for interacting with the community, I know we can be vocal and complain at times but it's because we all care about this game and want to see it succeed as much as you do.

Edited March 18, 2015 by Lord Aurelius

[NoMrBond]

Will the follow-up to the addition of DDS loading be that the stock textures are migrated to .DDS(DXT1/5) to take advantage of the increased loading speed?

If so this presents an opportunity to rationalise the textures (ensure appropriate sizes, PoT sizing etc) and to disable CPU R/W flags for suitable textures so that DX9 doesn't feel the need to keep mirrored system memory copies around after they've been pushed out the GPU.

I'm assuming modders will also be able to start packaging their textures as .DDS?

[gkorgood]

I guess that little mishap helps someone out then, haha. I 'refreshed' my computer http://windows.microsoft.com/en-us/windows-8/restore-refresh-reset-pc

Thanks, Kasper

[SaturnV]

Worrying about the new tech tree layout a bit. Looks like SQUAD is making a useful-one-first tech tree which IMO is not good enough.

Ideal tech tree should be intuitive and challenging, players & kerbals study with “bad“ parts to improve their design and unlock new better ones.

[Aragosnat]

Keep up the good work and remember to sleep.

[Scoundrel]

Felipe (HarvesteR): I’ve created a new version of the tech tree which features absolutely no dependencies between nodes. This means all notes are researchable from the start. Also, all nodes have the exact same cost. This tech tree will be included on the QA builds, and during testing, we will ask the testers to note down the order in which they went on unlocking the nodes. From that data, we should be able to run some statistical analysis to help us determine which parts are needed first, and how we should better organize the tech tree.

Um, not to sound obvious, but why continue with a tech tree when you have just presented a brilliant solution to the tech tree issue to begin with? Wouldn't the solution be to have a contract unlock the tech node, so every game has a different tech progression that doesn't require a tree, but can utilize a matrix so we have much higher replay value? You can even set the tech up in layers to match the contracts and use the difficulty setting to determine how many layers are revealed for early purchase (for those that don't like the idea of a procedural tech tree).

It just seems to me that going with the option that generates the most replay value and requires the least amount of work from you guys is win-win.

[Lord Aurelius]

Um, not to sound obvious, but why continue with a tech tree when you have just presented a brilliant solution to the tech tree issue to begin with? Wouldn't the solution be to have a contract unlock the tech node, so every game has a different tech progression that doesn't require a tree, but can utilize a matrix so we have much higher replay value? You can even set the tech up in layers to match the contracts and use the difficulty setting to determine how many layers are revealed for early purchase (for those that don't like the idea of a procedural tech tree).

It just seems to me that going with the option that generates the most replay value and requires the least amount of work from you guys is win-win.

That sounds like another great suggestion, as others have mentioned in this thread basically all the parts in the game are essentially parallel in terms of technology and gameplay rather than sequential, and trying to shoehorn them into a sequential tree basically means that inevitably some important parts will get shoved farther up the tree so you have to grind for a part that really should have been unlocked earlier. As an addition to your proposal, maybe later nodes could also unlock upgrades to earlier parts (so the tech tree doesn't get cluttered up with obsolete parts) such as better thrust/isp for engines, lighter parts, more power efficient parts, etc.

[federicoaa]

@Marco: Making a Duna transfer from LKO is hard because you need to take into account planetary alignment, ejection vector, and so on.

I remember the first time I went to Duna I just left Kerbin SOI and then tweaked a node to have an encounter with Duna. Off course this way requires more fuel, but it's easy for the firsts times.

What I suggest is this:

Have a first Duna tutorial use this method to plan the encounter, make it simple for the sake of quickly arriving. Focus the tutorial in how to plan the encounter, correct alignment and check you are arriving in the intended orbit.

Then have second (advanced) tutorial where you teach how to arrive to other planets from LKO. At this point, users have already been to Duna in the previous tutorial, so they will be more patient and probably eager to learn the complex stuff

[peachoftree]

For the duna tutorial, what if you taught it similar to rendezvous?

step 1: escape kerbin SOI

step 2: make a maneuver node that boosts Ap up to Duna's orbit

step 3: move node around your orbit until you get an intercept

step 4: adjust node / midcourse corrections

step 5: aerobrake / insertion burn

step 6: land

step 7: profit!

[Superfluous J]

For the duna tutorial, what if you taught it similar to rendezvous?

step 1: escape kerbin SOI

step 2: make a maneuver node that boosts Ap up to Duna's orbit

step 3: move node around your orbit until you get an intercept

step 4: adjust node / midcourse corrections

step 5: aerobrake / insertion burn

step 6: land

step 7: profit!

That is an extremely inefficient way to encounter Duna, and the tutorial should at least show a technique that is easily adapted to the most efficient way.

[Seyvern]

Yes, that would be the case if you were intent on gaming the system. However, we're not doing this in an open environment, but in the controlled group that is the QA team. We can instruct the testers to select nodes in a well-paced progression, selecting not the best and shiniest parts first, but what seems fit to be the next logical step.

With the assurance everyone is collecting their data with the intention of creating a logical, incremental progression, we should get some useful information. This can only happen with a very small, communicative test group, but we just happen to have such a group... (Who by the way, are outdoing themselves again this time around. Major props to them, they've done an immense amount of work these last few weeks!)

Cheers

Fair enough I suggested an open poll, you are doing a closed one, but you'll get the same results.

Thx for the clarification