-
Posts
1,735 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Everything posted by PDCWolf
-
I can imagine some accountant or analyst looking at how KSP2 got 7 years of time in the oven. Had to fund an entirely new studio over what possibly was licensing issues (or wanting to keep more money inside by making it a subsidiary). There was literally no game as the date approached, they only had a tech demo that barely worked and required top hardware to be playable. A massive media event where they flew in youtubers to play. A full year+ of development. Another media event for the first "mainline feature update". Literal hours of high production video footage as interviews, feature episodes and what not. A very aggressive marketing campaign. Having had to kill that marketing campaign because it was more harmful than good for the product. AFTER ALL OF THAT, the game only got ~10% the sales of the original, and a dubious rating, which is now even lower. That analyst or accountant, even in their very first job or with 20 years of experience, would've looked at that and gone "who thought this was a good idea?" before crossing it out of the list. KSP2 has such a horrible performance compared to its budget that really, I doubt we'll ever see anything about the IP, not just anymore KSP2 but the whole thing will probably never be touched again.
-
The CMs are "extremely silent" because they're out of a job. If I tell you your job is going away next month, the last thing I would do is let you keep access to social media channels in any official capacity. That's just asking to get sabotaged by someone who might not care so much about NDAs and stuff and happens to be a bit over the edge on losing their job. It's a huge liability with literally no upside. The same goes for devs really. Anyone who got fired will not keep working until June, they get that paid time as yet another reduction of liability, because you don't want people who might be on the edge over losing their jobs to have any chance to sabotage the product or the studio's internal infrastructure. The moment the WARN went out, anyone not absorbed into PD went home.
-
Just for context, T2 also laid off every employee of "2K Marin". But never closed the studio. The studio has been open for 11 years making no games and employing 0 people.
- 81 replies
-
- 13
-
-
Ask them where Argentina is on a map, ask them what 7723/22.7 is, ask them what's the length of the pushrods on a Mercedes OM611 engine is. You'll quickly realize that decimal maths, geography and car mechanics are "niches" by the bogus, nitpicky measure you use and consistently keep changing. Gee, and why would a game lose FPS as you add more saves when you only ever use one? oh yeah, because it's built like garbage. But hey, it's early access so it gets a free pass because maybe, someday, some magical group of developers will pick up this cancelled garbage and fix it. And why does nobody want to mod it? Surely not because it's a good platform with established modding standards and an official API. Every game should just never hit 1.0 by the sort of "arguments" I'm reading, that way you can do no wrong even if you ship a unity asset flip prototype because there's the hope for it to be magically fixed before the heat death of the universe. [snip]
-
If you think 1 and 2 are bad in KSP1, then let me remind you they're objectively, proven, tested to be much worse in KSP2. As for 3... you can run Parallax, Scatterer and EVE and still have a game about as playable as KSP2. Where you'd get this is wrong I'm not sure. 4... hard to test given not even modders wanted to do much for KSP2. I'm running about 54 mods right now in KSP1 and it's just fine, no impact save for initial load and occupied RAM, but the game still runs without an impact to FPS.
-
No it's not. That's exactly the problem. Can you build 1000+ parts vessels without the game falling apart? Can you have a save with hundreds of active flights without grinding the FPS to a halt? Can you add graphical mods without the performance dropping further? Can you have dozens of mods loaded without the game exploding? Can you even have multiple saves without breaking the game? Can you dock 2 docking ports at the same time? Because maybe they didn't even fix that in 14 months. In KSP1, you can do all of that. No one is being a doomer, that's what people here fail to understand and why ultimately they decided to shut the doors and only listen to the discord. The game is literal technical garbage. You're free to like it, but liking it doesn't change that it's technically inferior, feature inferior and performance inferior to its prequel, and it has badly designed systems that are unfixable without being completely rewritten from scratch. You don't want to take that from me because I'm "a doomer"? Fine, go around and look at users with even more technical knowledge than me. Go listen to industry specialists posting on these same forums. The argument doesn't change because it's not an argument, it's a basic truth and the only hope for it is "maybe they would have fixed that in the future".
-
[snip] It seems the problem with the argument is KSP2 gets credited some utopian future where the absolute garbage they build has been reworked into being actually good, whilst ignoring what KSP2 is right now. That's not even going into how most saves in KSP2 are just mucking around with small stuff or it grinds to a halt. This is why I'm pretty sure neither of you two is arguing based on reality, but rose tinted glasses. That KSP2 was not going to be able to support half of the stuff you can do on 1 is, based on what's there, an undeniable fact. If you wanna keep ignoring bug reports to have some sort of argument go ahead, but don't quote me anymore on it.
-
Vitriol doesn't make this argument any more sound, not that it had any substance to it to begin with. We can talk about which game you like all day, but if you wanna talk objective stuff like the technical side, there's no place for opinions there. KSP2 is a broken, unplayable, badly designed mess, left incomplete and wincing painfully on the ground after being unable to gather interest, sales, or any sort of trust in whatever might come out of it long term. This is not to say that KSP1 is perfect, far from it, but hey, one is still being played by thousands, with a myriad more playing hyper modded saves, making vessels in the thousands of parts, adding planets to it, clouds, obscene levels of detail, gigabytes worth of parts, mission packs, entire mechanics, and it refuses to break under all of that except for some very specific cases.
-
What is? believing such fundamental flaws [1][2][3][4] could be fixed by the same amateurs that thought loading every part infobox in a single window when they can have the same names was a good idea? Yeah, that's definitely rose tinted glasses. KSP1 was iconic. It's so iconic it's the reason a multi-billion-dollar company, the literally biggest publisher in gaming, was interested in acquiring the IP and murdering 2 studios trying to get a sequel out. Your personal vendetta with KSP1 or whatever they did with it that you didn't like, can't change the facts.
-
That stuff made the news too! Not just in gaming but mainstream media too. https://www.space.com/boeing-starliner-oft2-kerbal-jeb-zerog-indicator https://www.pcgamer.com/they-flew-a-freaking-kerbal-to-the-international-space-station/ https://www.gamereactor.eu/a-kerbonaut-has-made-it-to-the-international-space-station-in-real-life-1086663/ https://www.engadget.com/boeing-starliner-kerbal-space-program-jeb-212326380.html That's not to mention that they were approached to make an official education version, the game got taken to classrooms, expositions, the news, science talks and so much more. It's a shame the sequel fell into hands that somehow were more clueless and amateur than what for the most part was either a single guy from Brazil or a ragtag group of indie developers. But hey, don't get too caught up, some people are just too salty to see it.
-
HavesteR shares his thoughts on recent KSP2 news
PDCWolf replied to moeggz's topic in KSP2 Discussion
I think it wasn't lack of vision, but fear of having to carry the backpack. When freed, he instantly went to create another incredibly niche product: a VR lego-like RC sim. Rc people who own vr headsets and would put up with a lego-like building system is a subset of a subset of a subset of a subset of people. That's just not something he'd be able to freely do with a team of people hungry for the next big "Kerbal" game. Heck, it's not something that fits the Kerbal world, which is why when asked about it he went for "kerbal aircraft prequel". He probably felt having the Kerbal name on his shoulders when he wanted to do things that wouldn't necessarily fit said name, or that wouldn't be as successful and widely accepted as KSP1, was limiting him and keeping him away from what he wanted to do. Plus he could fund all of those fun projects just with selling the brand alone. -
HavesteR shares his thoughts on recent KSP2 news
PDCWolf replied to moeggz's topic in KSP2 Discussion
Nevermind then. Just sad they used that tech to go for this look. Yeah. I do agree with him that obviously doing "the same game" does set the bar higher, which is what these guys crashed against. -
HavesteR shares his thoughts on recent KSP2 news
PDCWolf replied to moeggz's topic in KSP2 Discussion
Visuals are... subjective at best: the overblown toy-cartoon style was one of the things I was hoping to mod out right away. Colonies could have an as amazing framework as they wanted, wouldn't really be useful when built on top of the bad multithreading and save/off-loaded-simulation system. Of course, MT was one of the things promised to get better someday(tm), along with HDRP, the PQS and so on, but we gotta judge what we have, because judging what they promised or showed on trailers... that hasn't gone so well. -
HavesteR shares his thoughts on recent KSP2 news
PDCWolf replied to moeggz's topic in KSP2 Discussion
Whilst I'd like the planes-only prequel, there is value in recreating KSP1 but bigger and better. In fact, I'd say a lot of folks that are still here or that bought the game at any point wanted exactly that: better KSP1. Then you realize they went with Unity again, same middleware, same mistakes, absolutely failed to expand on anything or iterate on any system, actually gimped other systems, set themselves for failure by making other systems horribly bad. In short, instead of revisiting the base game with more modern and better systems, they made a game that suffers the same foundational issues and doesn't really bring anything new to the table to justify them. Of course, this doesn't contradict that there's lots of space for Kerbal-based spinoffs that aren't lego rocket + spaceflight sim. -
HavesteR shares his thoughts on recent KSP2 news
PDCWolf replied to moeggz's topic in KSP2 Discussion
Love how humble he's remained. It was also very interested to hear that whilst "T2 kept SQUAD hired to develop updates for KSP1"... that "SQUAD" was literally nobody from the original team. Edit 1: "Before kerbals went to space they had to learn to fly" -Planes before rockets confirmed canon.- 49 replies
-
- 10
-
-
Can we please get an update as to what’s going on?
PDCWolf replied to HammerTyme's topic in KSP2 Discussion
At this point I'm starting to really look down on the people that would follow development further after being treated like this. "Oh yeah, we might or might have not killed your favorite franchise, hang in there like what you are until we decide it's profitable to speak to you again". -
One thing that comes to mind is saving fuel as a single pool, drain from that if the vessel is thrusting off-loaded, and then redistributing it back to tanks on vessel load. It'd probably not look that good unless you use some fancy math to regulate that distribution instead of making it equitative for example, but it's better than calculating fuel flow and drain from N tanks. You could also just force the player to pre-calc a burn for burn-during-warp, and not let them touch the vessel until that is done, thus you already have done the math whilst the vessel was loaded, and you just need to move it on rails when the user looks at it or sets it as active. There's probably many solutions and shortcuts I'm overlooking though, this is just back of the napkin stuff.
-
Funnily enough, the news article about it is still up. To me the wording sounds pretty committing, but hey, I'm not about to have another discussion centered on whether they literally said or implied "we promise". It's not about the hardware. There's a lot of games more complex than KSP/2 out there, even without being spaceflight simulators (please don't believe that's the hard part, it's not). This is just them choosing, probably by virtue of needing to GET GAME OUT FAST, the worst possible way to do things, in an engine known for not being good at using multiple cores of modern CPUs. Regarding multiplayer itself, it's achievable with some caveats like the delegation of collision calculations. Say we're playing on a server and I launch a missile at you: for most of the interaction, your craft would probably be just a single rigid body to my machine, and me and the missile would be the same to you. At the moment of computing the impact, I need to stream the craft data to the server (or to you, depending on architecture), for proper physics calculation of the impact. This is how you avoid all clients having to do all the calculation work. There's a myriad of engineering/crafting games that work just fine regarding this, even to really big scales. As for coordinate accuracy, it's irrelevant. In the same way my PC calculates my own physics and not yours, your craft would be a protovessel on my side, condemned to a single point in the scaled-space planetarium (remember that for a single player, the universe revolves around them). Right now the only problem is coordinate resets at like 2500 meters which is the point where unity begins to drop precision, and so the scene is moved to recenter the rover in it, causing it to jolt a bit or even just to get flung away. Again, in multiplayer it'd still be me doing my own calculations so you'd see my rover bugging out but they wouldn't affect your rover. Rask & Rusk... yeah, no idea how they were gonna do that without either a half-baked SoI abuse implementation, or actually making the jump to proper numeric integration. Orbits inside a binary system can get pretty complex and there's a ton of cases a simple SoI spaghetti wouldn't solve. I'm really pretty sure this is why we never heard of those two past promotional material. Do we need to compute every part of every vessel at every point? Probably not. KSP1 worked believably enough except for solar panels not getting updated as the sun left them. Trust under warp could probably use some logic shortcuts if we can put up with fuel drain being not perfectly realistic for example. At the end of the day we can speculate endlessly but if nobody is actually sitting down to solve those problems, there's no point collectively bashing our heads to think of solutions that won't be implemented anywhere.
-
As far as physics simulation, there's a couple problems to solve: Scene size, where you just can't simulate the full solar system 1:1 on any engine so tricks like the player-centric planetarium are used. The joining of parts. What do you do with ships the player isn't playing with. Unity, Unreal or whatever off the shelf engine would face the same scene size limit at some point, meaning the whole planetary system needs to go through a scaled player-centered planetarium mode like it does in KSP1. I really don't think there's another solution for that. I don't know how for example Orbiter handles it to say if it's different, and I know other games like Space Engineer just use a static, heavily scaled down system and displace the active scene resetting coordinates (like KSP1/2 does with rovers on the ground). As for the joining of parts, the particular problem with Unity, or rather how the devs used Unity in KSP1 and 2, is that they resorted to Unity's default joint system. That means when you put 2 parts together, they're not parent and child, but rather 2 nodes united by a joint. The flexibility this joint allows is what permits things like wobble and all other spaghetti effects... and creates phantom forces as well in some cases. Those joints are their own physical entity and can transfer forces along the connected rigid bodies. A secondary problem this causes is with collision detection, because if you allow elasticity on the joint, the 2 connected parts can collide and that's when a tank in the middle of your rocket explodes for no apparent reason, and thus the solution is to disable same-vessel collision. Every joint is an extra "part" that has to be serialized for saving, which is why autostrut is so toxic to performance. Now, all of this carries over to the third aspect: What do you do with non active vessels. "Serializing and saving" isn't just for when you stop playing, but also quicksaves, swapping active vessels, docking and so on. In KSP1 (and if I remember correctly), the ISRU and heating systems work for unloaded vessels by saving the current rates of change in resources (as in, say, fuel is increasing X units per second, ore decreases by Y amount per second) and when you switch back to a vessel, those rates are calculated against the time since you last played with that ship and are credited or debited to all containers equally and almost instantly. They also had some shortcuts over EC rates not being updated so a solar panel always generates max energy for an offloaded vessel even at night. In comes KSP2, and they promise trust on warp, real simulations for ISRU/Colonies and what not, except the way they do it is to serialize and dump even more data onto the save, and without any shortcut or optimization. Every aspect of a part in KSP2 is serialized and saved individually, and then recomputed pretty much live as you play with another ship someplace else. This means every solar panel, radiator, resource container, resource generator, resource debit, engine, SAS, and so on is continuously working and being recalculated even for vessels you aren't playing with. You might be launching a 20 part rocket, but that 100 part colony still will hit you like if you were launching it all in one piece right next to your new rocket. And the way this side of the system is built, really has nothing to do with engine choice. Engine choice just adds onto this mess by virtue of how the Unity default joints work and how bad Unity is natively at multithreading. Sure, some engines might have better native multithreading not requiring the mess you have to do in Unity to get that working, but still, it's a very flimsy system that resolves into an O(n) algorithm where more parts cause a linear decay in performance.
-
Well... sadly there's history of that, SQUAD promised multiplayer for KSP1 before selling the franchise out. Also, to clear it up: I do believe they were gonna do multiplayer, I do not believe for a second multiplayer was the real or only excuse to drop this or that feature, and I definitely don't believe the source of that screenshot has anything to do with the build of the game we were playing (tinfoil on: the blurred names were Star Theory devs and that's their build) . Multiplayer is probably the most complex thing they could've done for the game, so I don't see why they'd back away from whatever else. They already overpromised a lot.
-
I feel there was a balance they failed to hit (talking about direction as in the general sense of the finalized vision for the game). The heavy work on tutorials already tells you they were going for "we take this niche game and make it accessible to even more people, it'll definitely sell more." FS! followed on that by simplifying and linearizing the tech tree and having science be a single magic button, where you can absolutely skip even the timers so long as you hit it every time it flashes. Lastly, they also wanted to tell a semi-linear storyline through missions, discoverables and their lore. That part was really good, the new user onboarding was a magnitude better than KSP1. On the other hand, the game really required a strong technical foundation because by the time the difficulty curve of rocket launches and SSTOs is over, almost every player just goes big. Here is where to me they completely failed, by making a game that doesn't support this second bit. Of course now it'll all be woulds and coulds, but it's not hard to see that even without colonies we were already still finding the limits very easily (another example, another one, another). 8000 parts might sound like a lot on that bug report, but that's about a constellation of satellites, a couple rover missions, and a Jool 5 vessel. Meanwhile the game was supposed to allow you to do that on multiple star systems, whilst supporting trust under timewarp... and just no, the game could never be able to do that with the foundation it has. Also, as a last nail in the coffin, they forever handwaved the explanation of how Rask & Rusk (the binary system) were going to work. So yeah, we have a game built on flimsy foundations that they just outright refuse to talk about (remember the promises of HDRP and the system that'd replace PQS? I do), we have only the most basic stuff (yes, science and a tech tree is very basic, deal with it) implemented and none of the complex problems, and not just that but whatever little we have is already making those foundations quake... That's why you can google me saying "technologically bankrupt" multiple times. The balance they failed to implement in game by only including stuff for new people and nothing for veterans, was the same thing behind the scenes: they were doing only the easy stuff whilst completely neglecting the complex stuff and much less having the stones to talk about it. At this point I doubt they even had a plan past "cut everything down as manageable as possible", which is what net us all in one parts, gimped heating, the horrible coordinate reset on ground vehicles, and so on. I doubt they dropped anything in favor of a feature that probably never existed (yes, I saw the screenshot). I'm closer to believing they used multiplayer as an excuse to drop anything too complex/deep that might've further gimped the game's performance.
-
Yes, Nate also said that this parallel workflow was speeding up subsequent releases versus the cadence of bugfixes... and that didn't happen, with 2 proposed bugfix releases before colonies having failed to even show up let alone have a date for the first one 4 months down the road. That's what I mean with "don't exist": They weren't there, even if under "muh parallel development" they were supposed to start working on stuff as soon as FS! left the dock. Once again, all they could show from colonies was static assets on editor scenes., same kind of hot air they were showing before release saying they had a full game. Allegedly, and that being considered only as a way to have some compassion to their work. Even if this is something they've actively denied and the people working on whatever was scrapped was... themselves still under the same leadership. Sure you could talk licenses, but it's useless if we don't know how much really was lost, that's a magnitude order more conjecture than whether KSP2 is currently dead. This + things like using the same middleware, and hitting the same walls as the prequel with the fuel flow calculations were heavily worrying.
-
This has always been the nasty part for me: As prettier, funnier and maybe more modern than KSP1 as some might be convinced it was... The foundations KSP2 was built on are objectively worse, and the devs never bothered to communicate any sort of long or short term solution for a system that's designed from the ground up to crumble under very light pressures. Heating had to be gimped to reduce the performance hit of off-loaded vessel simulation. Parts had to be coalesced into all in 1 solutions to cut on part counts, even something as basic as science. And they tried to sell this as a revolutionary "you've gotta built around the a payload now". Logistics was to be a magic number crediting and debiting system because you've gotta keep vessels out of the simulation as much as possible. After all this, they somehow wanted to add physics to colonies... they failed to answer basic questions like "why?" and "how does this not kill performance further for very little benefit?" Add to that not having seen a single hint of colonies except the map interface and whatever loose change happens to be in the files already... I don't think colonies ever existed. The game PLAIN AND SIMPLY was not gonna work with even a couple 100 part colonies scattered around, let alone be able to keep track of Kerbals and logistics without exploding. And I say this with utmost security: that system had no fix other than a major rework of how KSP2 saves and loads data. Not only was it broken, it was not fixable.
