I believe the reason it happened, in short, is that Take2 (the publisher) were really obsessed with the release being a surprise, at the cost of far too much.
For one, this meant that basically every job listing for the game never described what the game you’d even work on was. Most of the devs they got were juniors who:
- were willing to sign more restrictive contracts without the confidence to push back
- did not necessarily know much about the game, or even the genre (supposedly, besides Nate, only 1 dev was an active KSP1 player and another was aware of the game but never really played)
- this game was their first sizeable project
For two, it meant that a lot of management roles were taken up by people from Take2 to enforce the secrecy (who also saw KSP as having franchise potential, but that’s a rant for another day). Few of them intimately understood what makes us dorky nerds enthusiastic about KSP.
This is also part of the reason they avoided talking to the KSP1 devs; they were afraid of some of them even hinting that a sequel was in the works. As to why they continued to not talk to them after announcing the game I’m not sure. Perhaps they were afraid they’d tell the uncomfortable truth that the game was making the same development mistakes as KSP1 and more.
themeatbridge@lemmy.world 3 days ago
You see this a lot in project management. People go to school to learn to manage projects, and they think that all projects are pretty much the same. You define the deliverables, set the schedule, track the progress, and everything should work out fine. When the project is a success, they pat themselves on the back for getting everyone to the finish line, and when the project fails they examine where in the process unexpected things happened.
Video games are an art form. Creativity can’t be iterated into existence, and the spark of fun is more than the component parts of a good time. Capitalists believe that they can invest in the creative process and buy the value of the talent of extraordinary people. They have commoditized creation, dissecting each step and then squeezing it into a format that fits into a procedure.
Here’s a Kanban board of game features, pick one and move it to the next phase. Develop, test, evaluate, repeat. What are your blockers? Is this in scope? Do we need to push the deadline?
That can help you make something, but it won’t be art.
SwampYankee@mander.xyz 3 days ago
As an art appreciator, and someone whose professional duties include project management, I love this comment, especially “[project management] can help you make something, but it won’t be art.”
philpo@feddit.org 3 days ago
As a project manager (well sort of, but did IT projects for a while, have multiple friends in the gaming manager): Yes and no.
From my point of view: The problem isn’t the fact that games are art. While games have their creative side they also require good “brick and mortar work” in the back - as many games as went horribly wrong due to a lack of space for creativity went wrong due to a lack of “less than glamorous” brick and mortar work and overcreativity. (Most drastic example would be the reddit dragon MMO story)
This is actually a reason why people who are very invested in the subject matter of the project they manage often are horrible project managers - and vice versa people who have no clue can’t be good PMs either.
Project management has one core component: Knowing when to ask whom. A good PM knows that the dev(or dev team lead) will always know better how long “feature X” will take. Of course I can try to learn how to do things… but that wouldn’t help much as the exact dev or team will still have their individual speeds. But a good PM also will know when to ask someone else who is nore knowledgeable for advice or to confirm things. (I literally had an Dev trying to tell me a small feature would take two weeks. Fair enough. But interestingly enough two other Devs were fairly sure it takes 30min including documentation. Which sounded way more reasonable. Turned out said Dev always tried to pull these stunts with new PMs and his lead being on vacation)
A good PM will also know when to give people space for creativity - and defend this room towards the budget.
Sadly - and this is a problem existing on all sides around PM- in the end it all boils down to a simple thing: Everyone thinks they know better. The PM thinks they know the job of being a Dev(or engineer,etc. etc.) better than the actual people doing the job. And vice versa the Devs think they could do without PMs (they can’t for larger projects it’s impossible, for mid size projects often really inefficient) or know their job better.
Such is life.
victorz@lemmy.world 3 days ago
Very insightful! Thank you!