Where is Nate?

[jost]

I don't get it: Why is the (non-)use of an Autopilot relevant for the question whether Nate did a good job as a creative director? As far I know this role needs a certain skill set.  People can be good in a game and suck in a leadership role and vice versa.

But I also don't get why people would play KSP to engage in air combat ( there are way better options ) so  what do I know? 

Edited May 28 by jost

[Izny]

25 minutes ago, Meecrob said:

Lol I said I bet he did it manually a few times to do it, then used mechjeb. I bet he says the same as others in this thread, that it gets repetitive.

I doubt he did it manually, my whole point

[Meecrob]

45 minutes ago, jost said:

I don't get it: Why is the (non-)use of an Autopilot relevant for the question whether Nate did a good job as a creative director? As far I know this role needs a certain skill set.  People can be good in a good and suck in a leadership role and vice versa.

But I also don't get why people would play KSP to engage in air combat ( there are way better options ) so  what do I know? 

I cannot word my point properly, so I'm dropping it. I'm not trying to say you need to be some sort of crazy person who must hand fly everything to be a dev.

You can all relax.

 

40 minutes ago, Izny said:

I doubt he did it manually, my whole point

Lol, I didn't say he was successful

Edited May 28 by Meecrob

[Izny]

for the record: i'm a mechjeb pilot. in my defence: i'm not a ksp2 dev XD

[PDCWolf]

5 hours ago, Meecrob said:

I cannot word my point properly, so I'm dropping it. I'm not trying to say you need to be some sort of crazy person who must hand fly everything to be a dev.

You can all relax.

 

Lol, I didn't say he was successful

Don't worry, I kinda agree with the idea so I'll gladly say the controversial take myself, and then you can compare to your take:

If you don't know how to play the game, you have no hope of making it fun for the people who do.

Now, being bad is different and kinda excusable. Most devs @ KSPTV were horrid at playing the game, but this is not a game where you need to be skilled at to have fun. On the other hand they refused to use mods and I think IIRC they even prohibited using mods on official dev streams so that included mechjeb... up until about Skunky joined as CM.

 

[Meecrob]

22 minutes ago, PDCWolf said:

If you don't know how to play the game, you have no hope of making it fun for the people who do. 

Thank you! That is exactly what I am getting at.

 

25 minutes ago, PDCWolf said:

Now, being bad is different and kinda excusable. Most devs @ KSPTV were horrid at playing the game

Agreed. In fact, as someone said upthread, you want some fresh eyes on the project you are working on. Its way too easy to get tunnel vision.

I'll even go so far as to say that I support the devs using mechjeb if it is to ease their job. After all, that's why cheat codes were invented back in the day.

[Yaivenov]

17 hours ago, Meecrob said:

I cannot word my point properly, so I'm dropping it. I'm not trying to say you need to be some sort of crazy person who must hand fly everything to be a dev.

You can all relax.

 

Lol, I didn't say he was successful

Perhaps I can summarize in neutral language.

 

A chief director of game development should be intimately familiar with every facet of gameplay and game design and this should also be done without interposing any factors that could obfuscate the true state of these facets. 

Mr. Simpson's fidelity to this axiom appears to be in question.

Edited May 29 by Yaivenov
Their/the

[Skorj]

I think it would also be fine for a KSP2 creative director to say "I found docking so tedious in KSP1 that I used mechjeb, so we're going to add a part for that".  (Heck, I enjoy docking and I'd add a docking computer for people who don't.)  The point IMO is that someone in charge of a sequel to any game should have played the original to death, loved it overall, and have a very informed opinion on every detail, plus have solid data on what players statistically enjoy or bounce off of.

[Pthigrivi]

28 minutes ago, Skorj said:

I think it would also be fine for a KSP2 creative director to say "I found docking so tedious in KSP1 that I used mechjeb, so we're going to add a part for that".  (Heck, I enjoy docking and I'd add a docking computer for people who don't.)  The point IMO is that someone in charge of a sequel to any game should have played the original to death, loved it overall, and have a very informed opinion on every detail, plus have solid data on what players statistically enjoy or bounce off of.

Or certainly a detailed set of tutorials. I actually think ideally the devs would have a range of experience levels playing the game so expert player/devs could explain what the eventual goal was, newbies could could raise their hands when something wasn't being explained well, and average players could help make calls on what reasonable expectations should be. This even kind of goes to some issues with the way the mission tree played out. I understood the plan was to make KSP much more approachable but the linear nature of the missions rushed players pretty fast to execute a manual precision landing on the Mun, something I didn't learn until well after I'd landed any old place on the mun and minmus several times. 

Edited May 28 by Pthigrivi

[chefsbrian]

This back and forth discussion is actually exactly what the creative director is supposed to resolve - not just "do we need a part for this" or any of the other implications of docking vs automation, but the root of this comes to a very fundamental question I've seen constantly torpedo people talking about how to play KSP1. If you play KSP1 purely Vanilla, then the game is equal parts a simple rocket design game, with a flight simulator aspect and a mission planning aspect. These three elements mostly share equal weight in the balance of what a player is 'expected' to do. But once you start modding KSP1, its extremely easy to start shifting it so the game is primarily a rocket design and mission planning game, with a weak emphasis on the flight. Whether that's through abdicating flight responsibilities with tools like Mechjeb, or integrating them into mission planning and ship design with those programmable flight computer mods, or just making them less relevant with advanced parts and distant targets, like with the outer planets and Near Future propulsion - Your specific flight reactions become far less relevant than your careful trajectory planning and designing a rocket who's nuclear pulse drive doesn't melt during the prolonged burn. These are fundamentally very different ways to experience the game, where a player who prefers to engage with spaceflight as an equal partner to the systems will think everyone else is cheating themselves of half the fun, while the automation player who just wants to put together his mothership to go execute a meticulously planned and designed grand tour thinks the spaceflight player is just being stubborn and missing the 'good part' of the game. Neither play is wrong, of course, but its two very different design spaces.

In a simple polish up of KSP1 to make KSP2, the problem wouldn't exist, its the same equidistant approach. But colonies and interstellar change this gameplay design equation heavily. You are now putting far more emphasis into the things that aren't the ship flight. Do you continue to promote ship flight as much of a manual hands on process at all time as before, at the risk of preventing more players from engaging with the entirely new systems? Or do you take the same systematized approach that colonies and orbital assembly promotes, moving more weight off hands on flight and towards design and tooling?

I feel like Nate never showed a clear understanding of this design problem, or any potential solutions for it. And my simplest evidence for it would be his approval of Wobbly Rockets. Wobbly Rockets are 110% a space flight challenge and problem. There's no real engineering or mission design solution to them, nothing colonies or advanced parts or anything else would have done to help it out, just straight player piloting, literally. At the same time, we were being told of automated cargo routes for moving materials between sites once you've made the flight. One is an extremely hands on, experience every wild moment yourself design approach, the other is an extremely systematized, play it safe to maximize efficiency style approach. These don't mesh well, and the fact that Nate continued to actively defend it when people were disappointed shows that he was both aware of it, and seemingly completely ignorant to its wider design implications.

That's a 100% creative designer decision point right there, how and why you expect the player to engage most with the gameworld, with a known problem space stretching back into the original game and its community discussions, and Nate somehow just didn't seem to give it any thought at all. The docking autopilot argument is just a downstream thread of not knowing what systems are pillars and which systems are branches to the game.

[KerikBalm]

19 hours ago, Yaivenov said:

The simplest implementation would be a co-operative/limited multiplayer style with guest players tied to the host's instance, but able to look around and take control of specific kerbals or craft within the physics rendering area.  Time warp is controlled by host and use is deconflicted through player communication.

Yeah something like this could work, as well as each controlling a craft after a separation event (like air launch to orbit)

It would be like soliciting a guest pilot to help with a specific mission.

I don't see a MMO style multiplayer as viable 

[Skorj]

22 minutes ago, KerikBalm said:

Yeah something like this could work, as well as each controlling a craft after a separation event (like air launch to orbit)

It would be like soliciting a guest pilot to help with a specific mission.

I don't see a MMO style multiplayer as viable 

As long as you don't have multiple people hand-flying craft within the same physics bubble, it's actually straightforward.  That limitation could then be addressed as a game design issue: make sure there are ways to avoid that while accomplishing all the game's missions.

[Meecrob]

9 hours ago, Yaivenov said:

Perhaps I can summarize in neutral language.

 

A chief director of game development should be intimately familiar with every facet of gameplay and game design and this should also be done without interposing any factors that could obfuscate their true state of these facets. 

Mr. Simpson's fidelity to this axiom appears to be in question.

*Chef's kiss*

If I am ever at a loss for words in the future, I am messaging you, lol!