ShadowZone
-
Posts
683 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by ShadowZone
-
-
8 hours ago, J.Random said:
There is something that I don't actually understand from this video: salaries. It seems like @ShadowZone (or whoever he was speaking to) tries to argue - at the same time - that KSP2 developers were all juniors with no experience AND at the same time that they should have been paid above the market. idk, maybe Seattle is some sort of CA corner in WA, but 150k/yr sounds like A LOT for a junior coder, especially considering that it looks like it's after the tax (later on, there are estimations of 200k/employee).
Ah, maybe I didn't explain this correctly in the video:
The "only hired junior people" part was during the Star Theory days when they still tried to do it cheap and quick (10 million, two years). I don't know what the compensation cap was at that time.
The 150k was the maximum compensation for engineers at IG. They had trouble getting senior and lead people for that amount and more trouble keeping them. There was internal pushback against this cap, but corporate finance refused to budge. Again a decision that was made outside of the team directly and adversely affecting it.
The 200k/employee is "fully loaded" costs (I hope I'm using the correct term, we call it something else outside the English speaking world), not just salary. So per employee you also need equipment (PC hardware, office chairs, desks etc), rent (office space) and other overhead (HR department, legal etc). While some of the latter was offloaded to PD, there's still a more costs that pour into employing somebody. For instance in my country, an employee that gets 50k a year into their bank account (what actually lands in their pocket) overall costs a company double that amount.
The 200k/employee average was used as a rule of thumb number, but it was given to me by LGG as well as my sources independently from each other.
-
9 hours ago, TLTay said:
Did anyone spill the beans on the other project the majority of the team was working on since EA release?
Less than 10 people were working on the second game according to my information.
-
1 minute ago, Tony Tony Chopper said:
Thank you very much Shadowzone. No empty buzzwords, no hate, no half truths at all. But all the haters will feel confirmed by now. No statement after WARN, no statement after earnings call, not even a hint after you gave Nate a chance to talk over Zoom. Too bad. Yeah, I still wish it's best for it's completion. At this point I also hope there won't be any violence happening to them. That's quite possible for developers these days.
"You cannot NOT communicate."
The long silence was in itself a way to communicate corporate's disdain for our community. The silence also made people more willing to talk to me because they wanted the story to be heard. Had PD/T2 decided to be super open and transparent and honest, we would not be at this point.
-
4 minutes ago, ttikkoo said:
Amazing video, thank you. I always thought there was a huge imbalance between the KSP2's presentation and playability - the bit about the creative lead focusing on the art clears that up a lot. I really liked the "We need to talk about Nate" section - it was necessary given things that people have said here and on Reddit. Banning the developers from speaking to Squad still has me in disbelief.
I think LGG's stunned face when I told him says it all.
QuoteDid the the people involved in the KSP2 project provide any input on what they thought was the future of the game?
Nothing beyond speculation, just as we all do.
-
25 minutes ago, Vexillar said:
@ShadowZone - thanks. This seems to answer a lot of questions.
You're welcome!
If there are any questions I can answer, feel free to ask. I felt this needed to be made public after all the intransparency over the past 5 years.
-
13 hours ago, Flush Foot said:
Seems like Wednesdays are his "Studio-drama" upload schedule
Not really.
I wanted to get last week's video out as quickly as possible after I got wind of the news. This week I chose to publish it to release one week after the WARN notice became public. Kind of a "why are you still silent after one week of this" statement.
But I also have a "normal" video scheduled for this Friday, sort of a palate cleanser. And unless there is some major development, I want to return to my usual Friday 13:00 UTC schedule (looking at you, Take-Two earnings call on May 16...)
-
Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes
OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459As you can see in the video, I started on the night side of Pol. I placed a maneuver node on the day side and time warped to it. There was some changes in illumination, for instance indirect lighting on the vehicle (light reflecting from Pol towards the "belly" of the ship), but the sun itself was gone. Switching to map view revealed the sun there, but it stayed hidden in flight.
Logs, saves etc attached in the .zip file.
Included Attachments:
ForSci_Bug48__SundisappearsatPol_logs.zip
-
Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes
OS: Microsoft Windows 11 Pro 10.0.22621 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459I encountered this bug at Pol. My vehicle was in clear view of the sun, the panels pointed at it, but the game said "blocked by Pol". This was persisting through multiple attempts to repack and unfold the panels. It only went away when I undocked my lander and then switched back to the original vehicle.
Included Attachments:
-
7 hours ago, Ruedii said:
OK, let me put it simply, Agile purists are the absolute worst hypocrites in software.
Amen to that. Fundamentalists of any kind should be treated with caution. To stick with my earlier wording, these people are just selling you a different kind of snake oil
QuoteFollowing a specific manifesto and process as a means to complete software is a clear contradiction of Principal 2, and 12. Not adapting your development workflow and priorities and instead staying on a fixed set of priorities is against the very principals of Agile. So entering new methodologies, setting teams on other methodologies, is important.
I like to say that they're principles, not commandments. Or to quote Jack Sparrow (sorry, Captain Jack Sparrow), "they're more like ... guidelines". The whole idea behind the agile movement (or at least, the value that I personally took from it) is to make things more flexible and to be able to react to a constantly changing situation. If you try to force everyone to follow a rigid set of rules (and remember: rules != principles), then you are not agile, no matter mow many Scrum Alliance certifications you paste onto your LinkedIn page.
To me, it boils down to the axiom of "inspect and adapt", which coincidentally is also reflected in principle 12. So yeah, people that try to "make you agile" by prescribing certain processes or try to prevent you from coloring outside the lines are oftentimes making things worse.
When in doubt, refer to principle 1: is what you are doing helping you to deliver valuable software to your customer? The trick here is how to measure whether or not you're actually doing that.
QuoteFurthermore, Agile's 12 principals are seriously in contradiction to each other, because 6 assumes everyone works in the same way favoring face to face contact, but 5 says everyone should work in an environment best suited for them.
I for one do NOT communicate best in face to face contact. I find this sort of generalized broad brush fallacy a sham, which is exactly why you should never subscribe to a single management philosophy, lest you lose the ability to adapt to your fellow team members, and the needs of the project.I don't see the contradiction, because 5 and 6 are aimed at different aspects of a software development organization. Principle 5 is more aimed at upper management and how to treat your employees (especially the "trust them to get the job done" part. Oh boy, did I have heated discussions with managers about that one...). Principle 6 is more aimed toward the day to day operations. But you have to acknowledge the time the manifesto was created in, more than 23 years ago. Kent Beck's "Extreme Programming" was only released two years earlier, bringing the concept of "pair programming" to a wider audience (yeah, it had existed decades earlier, but Beck popuralized it).
For me, there's a two key things in principle 6:
-
efficient and effective method of conveying information
- to a development team
- within a development team
Me as a product owner, I'm responsible for the "to a team" part. In my experience, the most efficient way of explaining a feature, or a problem the customer has, is to sit down with the devs and have a conversation about it. The best outcome is when I get a gazillion questions and we can refine the item there on the spot with everyone walking away with the same understanding of what needs to be done. While principle 6 states "face to face", I have had good results with doing it via Teams/Zoom/etc and collecting everyone's input and thoughts on a digital white board (I'm a "drawer & pacer", I need to scribble on a whiteboard and walk around constantly when I'm thinking. I rarely have my camera on in remote meetings because I'm pacing up and down the office or my living room when I'm talking). Again, the manifesto was written almost a quarter of a century ago. They didn't have our means of communication. E-Mail was laggy, chat was minimalistic (yes, I remember and was part of various IRC servers in the Nineties), phone was cumbersome.
I know people who prefer writing meticulous JIRA tickets. I have had colleagues who recorded their "tickets" as a video and upload them as attachments to the relevant JIRA issue. It all boils down to this: "are you practicing an efficient and effective method of conveying information"? But it has to go both ways: just because that product owner likes to record videos does not mean the dev team is able to distill their tasks from it. Is has to work for both sides.
The signatories of the manifesto wanted to break the death spiral of "throw a spec over the fence, write dozens of e-mails back and forth until you really find out what needs to be done". To come back to the "inspect and adapt" part: if you and your co-workers are comfortable with the current way you communicate AND it enables you to be effective and efficient, then you do you. As before, the question is: how can you measure whether or not this is the case? A dev team might feel good about themselves, but they can still be inefficient and therefore not delivering valuable software early and continuously (principle 1).
QuoteI should say you should do an agile inspired methology with some things. You need to do much more rapid cycles and much more frequent changes to requirement in certain aspects of development. Fixing bugs and limitations are one of them. Honestly, the vast majority of Agile theory is extremely effective at triaging and addressing common bugs and limitations.
However, Agile is also very short-sighted and many functions require things it frowns on. For instance, forking a team and the codebase to add something that will take a lot of time. I find it one of those things managers come up with that don't really understand how programming and codebases work. Many major key items require a very large amount of base code and invisible background features. Agile is not very accommodating to the development of such code.I fail to see see how forking a team and code base has anything to do with the principles behind the agile manifesto. There's nothing in there that says "you need to do x" or "you have to use tool set y".
You mentioned things that "take a lot of time". If you have features that cannot be done within the confines of a single sprint, you have two options: preferably, put your heads together and try to split the item into more easily digestible chunks that chain together over the course of multiple sprints, or - less preferable - carry an issue over multiple sprints. Over the course of my career, I rarely had the latter situation. Yes, it can happen, but only after you made sure there's no other way.
Also, sprint cycles and release cycles do not necessarily have to be aligned. You can have two week sprints but release only every three months.
If I ever get into the unfortunate position of being a manager, I would be completely hands off about key development tasks like how to set up your code base or branching strategy or whatever. YOU as developers need to be able to work with the tools available, not me. If you have the plumber come over, do you lord over him and say: "No, don't use the wrench, use the screwdriver, I read that in a book ten years ago."? No, you don't. You trust the specialist that they know that the heck they are doing.
Coincidentally what you describe, managers interfering into direct dev work, is in contradiction to principle 5. They don't trust you to get the work done, so they mess with the environment because they (wrongly) believe they know better. Screw those people!
Management needs to get out of the way of day to day development (principle 5), the team needs to figure out how to best deliver themselves (follow principle 12 to be able to live up to principle 1). This is why the Scrum Master role is so important. They need to keep overbearing managers in check but also need to make the dev team really inspect how things are going and help them figure out what to adapt to constantly improve (which is in line with the Deming cycle and Kaizen both of which were inspirations for the agile manifesto).
QuoteWhen managing the roadmap you can take some inspiration from Agile. Determining what features should be delayed or canceled to get a new feature put in the roadmap is very consistent with agile.
Simply put, while it's a good theory to learn, it is rather short-sited, and broad brush to think it has to be applied to everything. Additionally, claiming it should be applied to everything is hypocritical in that it expressly says you need to adapt to the needs of your team and your clients. Sometimes what your team and clients need is not something Agile will provide, in which case you need to introduce other management and methodology theories.From what you write I get the feeling you have a more agile mindset than you give yourself credit, especially the way you recognize that organizations need to be flexible and structure themselves to be able to react to change and offer a good environment for developers. These are some of the most important aspects behind the agile manifesto.
But your final paragraph talks about methodology and application. As I said in my previous post, the principles are none of those, but just what they say the are: principles. They should be a guiding light to how you organize your work. Some of them might shine brighter for you than others. All of them need to be interpreted and adapted for your use case. I have heard of companies building ships that have adapted their work to incorporate the principles.
One big pitfall is what I repeatedly said about "how can you measure that". This is where most organizations start to flounder, because they often fall back into command & control rythms or try to create a tight noose around everyone with some KPI, OKR and whatever fancy management metric they come up with next. People like safety and large Excel files with a lot of numbers give the illusion of being able to control the chaos when in fact you can't often times. One of my other pet peeves I regularly have heated discussions about with our management staff.
Another pitfall is scaling. The manifesto is geared towards a single team working together but nowadays you often have large organizations with multiple teams. Along came LeSS, SAfE, CAS etc to muck things up even further, selling the illusion of a "one size fits all" framework you can put to your company. Snake oil, all of them.
History time: I was in a well functioning development organization that managed to implement a custom scaling strategy based on scrum and following the agile principles. It was not perfect, but it worked for us most of the time. Then we got new management and they immediately needed to mess things up by forcing SAfE onto us. We were forced into a box, nobody really liked or understood and the end result was less efficient development, lots of dissatisfaction which led to long time employees leaving but management still selling it as a success because THEIR plan was implemented. Textbook failure of principle 5 and also 12. We didn't inspect and adapt, we followed a fixed plan, to everyone's detriment.In closing, I just want to say I really appreciate this discussion, even if I disagree with you on some counts. This is how we can move the conversation forward how to best organize software development work. Maybe someone from the KSP2 dev team takes note and can pull something out of this for them to improve how they do things
-
efficient and effective method of conveying information
-
6 hours ago, Ruedii said:
Yes, the most common one is small bugs and high priority bugs are done AGILE, roadmap is planned Waterfall/Cascade, and implementation of major patches and roadmap steps is done SCRUM.
AGILE does not work well with roadmap as it results in a constant moving target, but it works well with smaller and high priority bugs. Leaning too much into AGILE planning methods will result in the project losing focus (e.g. KSP2 under the initial management team) but not embracing it enough will result in a lag between simple but game-breaking bugs from being fixed. It is a balance to do things right, and generally multi-methodolgy is the way to go.Very hard disagree on this.
Whoever taught you that Agile is something that you can do or that is a methodology or framework like some kind of cooking recipe, was selling you snake oil. The Agile Manifesto is over two decades old and people apparently still haven't understood it - or are deliberately misrepresenting it. It's far more fundamental: Either you (meaning your organization) are agile or you are not. If your work adheres to the twelve principles outlined in the manifesto (or at least most of them), then you are agile, no matter what framework you are using to structure your work. Scrum is just a methodology that developed from the agile way of thinking. But you can be agile doing Kanban or XP or yes, in parts even waterfall.
I have done long term projects in an agile environment with a team doing Scrum. Notice the difference: the environment (the organization, the system within which you act) IS agile (meaning it and the people within it follow the principles). The team is DOING Scrum. There are a gazillion teams out there doing Scrum but that are not agile. They go through the motions, they work in sprints, but it's all meaningless and in the end these teams end up going over budget, over time and not meeting their goals and everyone is wondering why.
So how did we do long term planning ("roadmaps" if you will) with Scrum? It all boils done to setting the correct goals, rigorous prioritization and constant application of the maxim "inspect and adapt". Instead of meticulously defining what the OUTPUT should be, the long term strategy must focus on OUTCOMES. Which is why the role of the Product Owner is so important when you are working within the Scrum framework. This role has to constantly prioritize the backlog according to the desired outcomes. The dev team is responsible to generate the output that iteratively gets the software towards the desired outcome.
In the end, the customer does not care about waterfall, scrum, kanban, whatever. They want to be able to reach their business goals and the software you produce needs to enable them to do so. Most customers engage in the fallacy of coming up with specific features and asking developers to implement those instead of saying "I have this problem that I need solved" and the specialists, the software developers, take care of the solution. I mean, nobody goes to the doctor and says "I need you to perform procedure xyz on me". No, you go to the doctor because you have some weird symptoms and want them to go away. The same thing needs to be applied to software development. Detailed upfront specifications are mostly done to reassure everyone that things can be planned in a world that is very unpredictable and ever changing. "No plan survives first contact with the enemy", as the old saying goes. As soon as the customer sees the first draft, they will want to change something. Having an Agile mindset enables your organization to adapt to this type of changes instead of slavishly following a rigid plan. In the end the goal must be to deliver the highest possible value within your software.
-
16 hours ago, Spicat said:
@ShadowZone, moved your bug report here, I think this is a more appropriate bug report for your report to be merged in.
Not sure the previous one it was merged with or this one apply. It happens really just right after loading up the game and then loading a save game with a craft that is prone to kill itself. You can see in the video that the game still slowly builds up the vehicle, making the parts appear over the first couple of seconds and then destroying itself. My assumption is that the game is still loading some physics stuff in background and once it is finished, it all applies at once to the vehicle, overloading it. Reloading the save always fixes it. Always. And it never happens afterwards, even with hours spent using that vehicle, hopping from it to others, docking vehicles to it. It only happens right after starting KSP2 and directly opening this save file.
-
I don't have any hard data to contribute but I can confirm that this has also happened to me.
-
Reported Version: v0.2.1 (latest) | Mods: Docking Alignment | Can replicate without mods? Yes
OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459I already reported a crash when docking something with 2 ports. After restarting the game it worked, but I tried to add another piece and then the crash happened again. So it is reproducible. Please merge with my previous report. Thank you!
Just logs this time, no additional video (but it does exist if needed).
Included Attachments:
ForSci_Bug45-DockingCrash2_logs.zip
-
Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes
OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459Load the save game from the bug package right after starting up the game. It will result in disintegration of the vehicle. Load the game again and suddenly everything is fine. See also video.
Included Attachments:
-
Reported Version: v0.2.1 (latest) | Mods: Docking Alignment | Can replicate without mods? Yes
OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459I am building a complex ring station. The final pieces need to dock two ports at the same time. The vehicles glitched into each other, the game claimed there was a successful dock (see "clonk" sound in video), then the game crashed (see log in bugpackage).
Included Attachments:
-
22 hours ago, ShadowZone said:
It hampers more complex trajectory planning, same as the choice to limit maneuver nodes to stop working when exceeding the calculated dV of the active vehicle (which can be demonstrably wrong often times).
I just want to add that with mods like Flight Plan you can still create maneuvers that exceed the displayed dV of your vehicle. So the functionality IS in fact still in the game, just blocked when manual user input is applied.
Again, please change this. It's fine to show "vessel will run out of fuel" or some other kind of warning, but straight up preventing people from doing something that in fact does not hurt their gameplay is just wrong. I know it was said this is because something with interstellar later down the line, but even then I cannot imagine what this might be.
-
26 minutes ago, KUAR said:
At risk of deviating from the topic, have you ever tried running scrum for a hybrid software/hardware product which is subject to waterfall procurement and agile development (internally)? Really struggling to mesh the competing frameworks!
Unfortunately, no. I have only worked in software projects over the course of my career, no hybrid or hardware. But I was involved in a big project where our team was working agile and the rest pretty much did waterfall. The biggest challenge was syncing up with the other teams that worked differently.
But here is where one of the creeds of the agile manifesto help: "people and interactions over processes and tools". We tried to get in touch with the right people and managed to work with them, no matter what framework they were using. It was still challenging, but defining the interfaces between teams and having constant communication helped.
-
43 minutes ago, Darta01 said:
Ah yes! The maneuver planning tool that does not allow you to plan maneuver!
This is a terrible design choice
I just have to add my voice to the people asking for #20 to switch from "works as intended" to "redesign going on based on player feedback".
It hampers more complex trajectory planning, same as the choice to limit maneuver nodes to stop working when exceeding the calculated dV of the active vehicle (which can be demonstrably wrong often times).
Please change this!
43 minutes ago, Sade said:What is sprint planning?
In modern software development and especially when using a framework called "Scrum", the development team works in short increments, usually 2 to 3 week cycles called "sprints". At the beginning the team pulls from a prioritized backlog what they believe they will be able to achieve during the coming 2 weeks. The backlog is usually prioritized by a product owner based on business value (based on answering the question: what will provide the most value to the customers/users of the software?).
This process of picking the body of work for the next sprint and committing to it is called sprint planning.
After a sprint, the development team presents their results and gathers feedback and after that usually sits down and discusses what went well and what could be improved in the upcoming sprints.
Switching to these shorter development cycles enables software companies to get feedback faster and improve on software faster than working months or years in the blind and then having to rework a metric ton of code at once if they realize they messed up a foundational feature.
At least that's the theory. Most software companies/teams use some variant of this process.
-
Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes
OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459I made a mistake during a complex build and pressed "CTRL+Z" to undo what I did. That worked fine but afterwards I was not able to place parts in any symmetry anymore. This only got better after relaunching the game.
Included Attachments:
-
Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes
OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459Load game, wonder why dV says 0 (instead of over 5000), go into map view to find a completely absurd trajectory that looks like a wreath made out of infinite short lines.
Can be remedied by loading other save games or the same multiple times. See video for details, logs attached.
Included Attachments:
-
Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes
OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459Situation: retrograde orbit around Laythe. I want to flip the trajectory, so there is a maneuver plan already set in the attached save game. When performing the burn, the game always refuses to do burn under timewarp in this situation.
Being around Jool generally seems to trigger this bug very reliably.
Included Attachments:
-
Reported Version: v0.2.1 (latest) | Mods: none | Can replicate without mods? Yes
OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459I have put a vehicle with multiple hydrogen tanks in an almost polar orbit around Jool. When returning from map view (but also on other occasions) the reflections on the tanks start to flicker like a strobe as if they were turned on and off.
Logs provided are from a playthrough with mods, but it also happens without mods.
Included Attachments:
-
Reported Version: v0.2.1 (latest) | Mods: BepInEx/SpaceWarp, UitkForKsp2, MicroEngineer, LazyOrbit, AlarmClockForKSP2, DockingAlignmentDisplay, node_manager, maneuver_node_controller, flight_plan, K2D2 | Can replicate without mods? Yes
OS: Microsoft Windows 11 Pro 10.0.22631 64-Bit | CPU: AMD Ryzen 9 3900X 12-Core Processor (24) | GPU: NVIDIA GeForce RTX 3090 (24340MB) | RAM: 65459Got my rocket on the pad. I hit "go" and one pair of rover wheels just falls off. Flight Report claims that they overheated. When I turn off part overheating, the message claims that they crashed. Logs, save file and workspace are all in the bug package I uploaded.
Included Attachments:
-
9 hours ago, Nate Simpson said:
Shadowzone is dunk-drunk, and now seeks out puddles across the Kerbolar System!
I feel exposed
Happy KSP-niversary to Nate, Dakota and the rest of the entire team! Looking forward to what you'll deliver this year!
Shadowzone's findings on KSP2 history
in KSP2 Discussion
Posted · Edited by ShadowZone
Yeah, the idea was to just take KSP1, freshen it up, stabilize the code base (no idea how they should have done that if nobody teaches you how it works) and add a bit more content. Think FIFA or Assassin's Creed franchise. The core mechanics remain the same, but some fluff around it changes.
Then they got enamored with the "interstellar, colonies and multiplayer" vision but somewhere along the line neither timeline nor budget were increased to accomodate such a re-imagining.
So, a bit more detail maybe:
When T2 gave them the hard deadline of February 2023, everything was still in the game in some form (colonies, interstellar, multiplayer) to varying degrees of completion. Around May '22 there was the notion "it won't be pretty, but we might be able to ship this". The decision to go EA and rip stuff out again was made around September. They did try to get at least colonies in there, but somebody pulled the plug because the deadline was already close and they wanted some other thing in there (don't know which one).
I am wondering about the time it takes them to release colonies as well. Apparently "For Science" took already multiple times longer than was expected. One of the issues I was told existed within Intercept Games was a lack of "okay, that's good enough" (and we'll make it prettier later) attitude. If it gets public, it needs to be as shiny and pretty as possible, was the mindset (at least this was how the story was told to me).
In software development you always need to do some kind of tradeoff. Let's take re-entry heating: the mechanics of "part gets hot, part goes boom" with a simple heat gauge or flashing parts or something could have probably been integrated a lot earlier than what we got with "For Science" with all the pretty plasma effects etc. Of course it looks cooler, but with the simple "show me just a gauge of what goes wrong" mechanic you could have tested the math behind it and verify if your assumptions about how which parts will behave under thermal load. The way they did it was that everything had to be "complete" before shipping it. Also kind of misunderstanding what Early Access should be. I don't know who made these calls for re-entry heating. But I believe we could have gotten a stripped down version much sooner, same for science and colonies.
Build the mechanics, test them, test them with the public, make them prettier on the go. That's how I would treat an Early Access development title.