-
Posts
287 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by Maxsimal
-
Glad Dean is spilling the beans on this.
-
I think it'll be faster than 5 years
-
When I worked on KSP1, every design was vetted by the leads group as feasible, and I had a strong understanding of what was reasonable even before I began, both from discussion with engineering leads and having been a former systems engineer and being a lead & systems designer on multiple previous projects. Beyond that, I also considered the needs of a variety of different player types, trying to envision features that would please them best without breaking the bank on dev costs. When the design was written, it included various amounts of scoping at the level of the entire design - what features could be cut if we didn't hit them - and within each documented feature - stretch goals that I'd hope we meet that even if they were not met, would not invalidate the entire feature. I tried to include features where if the engineers were behind, the artists could just work on something that did not need engineering time to inject into the game, and vice versa if the art team was behind, to introduce a level of elasticity to the scheduling. Of course, this was coupled by great effort from the dev team, and them working with me to understand the scope & effort behind each feature involved. This is a good general principle for any level of work on building a game - not putting the cart before the horse, validating assumptions on what you can and can't do, and building off of work you've decided is a key early priority for technical and/or gameplay reasons and then moving on from there. This is something I learned to do from working in the industry for a couple of decades and seeing the good, the bad and the ugly on development processes at a range of studios. You can introduce huge inefficiencies to the overall development process when you deviate from good game design & development practices. You can have developers complete work that needs to be thrown away or heavily modified later because you put the cart before the horse, or bet on something being finished and had your art team work on it while the engineering team didn't get to it. You can create designs that please a small portion of your target audience, or just yourself, that don't work for a broader audience and can't be tested until the last minute when its too late to adjust them. Beyond that - you can burn out your staff by whipsawing them between different targets or making off-the-cuff adjustments due to poor design & planning. You can drive engineers up the wall because while as a designer you work in a realm of possibilities and and aesthetic ideas, engineers have to work in a realm where no amount of grand viisionary work changes 30FPS into 60FPS. You can lower the morale of your art team by having to throw away assets they spent man months making because they end up not making it into the build. When you do introduce those morale problems - then you can either address by adopting better practices and fixing root cause. Or you can try to address them by shoving aside 'trouble makers' who raise the why are we doing this concerns in favor of staff with a more positive attitude - even if they're not as talented - often because they're less experienced and don't know where the source of the problem comes from. People to whom you can just say 'Hey, do what I want because I'm the leader here, I have way more experience than you.' As KSP's lead designer - I felt responsible for helping the team hit sprint milestones on time, even if I was not the person writing the code or creating the assets, and I was proud that by and large, we constantly hit those targets update after update - a 3 week slip was afaicr the largest slip we'd done - about 10% of our average version update time. Even if I wanted bigger and better things - the list of what I would have added just to the breaking ground DLC if I could have done anything I wanted by itself would have consumed years of additional dev time - knowing what was good enough and could be done efficiently was a key part of my job. This is in general what the person at the top of the design hierarchy should be doing - and if they're not doing that, the production staff and technical leadership should be empowered to push back and set those goals right. Further - it's about hiring & mentoring competent staff to work under and with you - people who push back against you when you get something wrong so you can correct it at the easy 'I fixed this in a document' stage vs at the very expensive 'it's been built and QA is telling me it sucks' stage. It's not about having your personal vision of each feature making it into the game - it's about getting the best possible game into the hands of the fans. Of course, I am not commenting WHATSOEVER on what happened on KSP2. I'm talking about my experience on KSP1 and on other work at other studios. I'm just saying that the job of design leadership isn't just bluesky visionary work, and building my own personal vision of a project - though having a good vision is important. It's about making sure that the game as envisioned matches the resources available, and that those resources are best utilized efficiently, both to make sure the eventual product is as good as possible for the broadest range of fans, and that the project makes its development costs back and then some, and so the whole team can be proud of the work they've accomplished without feeling burned out by the experience. I feel proud of the work I did on KSP1 even if I didn't get every I idea I had into it - and I hope my former coworkers do as well. This is true for every level of designer as well - one of the most negative things I've seen in the industry is when the top of the design hierarchy - whether they're titled as design director, creative director - heck, sometimes the exectuve producer arrogates this priviledge to themselves - when they decide they're just the blue sky person, the idea person, the person who drops a little nugget of creativity onto the team and expects them to execute around it, and where they don't want their creativity bounded by the earthly concerns of lesser mortals. Again, not saying this happened on KSP2, just saying that someone at the top like that doesn't get to not have responsibility for a project just because they're 'the idea guy' and its other people's job to build their vision or not.
- 255 replies
-
- 19
-
Unless T2 lets go of it, I don't think that's the case for the KSP franchise. For other projects that - yes. And I was not referring to other projects when it comes to letting go of the KSP franchise - I do think there are interesting things on the horizon for a KSP successor.
-
As much as I loved the Kerbal franchise - and wish it had succeeded and live on, I feel like the best thing is to put it all behind me at this point.
-
Man it's unfortunate it went down this way - but I gotta agree with SZ, a lot of this was very predictable from an early stage. The conflation of issues that generated problems on KSP2 was the reason I bowed out at the end of KSP1.
-
I have control points on everything - the plane has a cockpit, the sounding rocket has a probe core. Jumping back to the sounding rocket works fine if I do it while the plane is still in flight, its only after recovery that there's no way back - is FMRS supposed to have a toolbar icon while in the KSC view?
-
Hey been playing with this recently in the context of an RO/RP-1 game. Been having a few issues with something I was trying to do. Wondering if someone knows what might be up? I have a plane with a sounding rocket attached. The sounding rocket is meant to complete some contracts, the plane just return to base and land. Case 1: - Plane cockpit is the root part. I detach the sounding rocket and it flies off fine. I land and recover the plane, I cannot jump back to the sounding rocket at that point, I'm back to the KSC view. Is this is expected behavior? Case 2: - Plane cockpit is the root part. I detach the sounding rocket and switch to it after I level off the plane. I complete the contracts. I switch back to the plane. FMRS shows some 'fmrs completed contracts' in the message window. I land and recover the plane, but those contracts are not recorded as completed once I've recovered the plane, and the game state doesn't recall that I've passed the Karman line. Case 3: - Sounding rocket core is the root part I detach the sounding rocket. Upon detach, the plane rips itself to shreds, seems many B9 wings are insta-destroyed, maybe an issue with FAR at that point? Not sure. This is true when I jump back to the plane, not just from the sounding rocket's perspective .This is a show stopper so I don't really follow up on this case. I'll try it again with stronger wings soon. I'll play with this a bit more but I'd like to know if there's anything I've done that's obviously wrong, particularly with Case 2 since that seems to be the closest to successful, I'm not sure why FMRS is forgetting the contracts that were completed. Would a log at any point be helpful?
-
Nice work guys, you fixed a lot!
- 166 replies
-
- 12
-
Thank you! I'm very proud of the updates we did, but it was a team effort, both from the people who worked on these versions, and from the people who built Kerbal up into the awesome game we could add on top of.
-
Thank you, I'm just glad I got to help move forward Kerbal for a while.
-
That's amazing! And now we have some insight on what's in a Kerbal's head!
-
It's not impossible, but it might be improbable.
- 111 replies
-
- 3
-
- pc
- kerbal space program
-
(and 3 more)
Tagged with:
-
Thank you so much, it's been a pleasure working with you !
-
Welcome to another KSP devblog! This time we’re going to talk about wheels. In KSP 1.12 Final Approach, we’ve made some improvements to our wheels to address many pesky bugs. Another issue we’ve looked at is making it easier to drive your rovers without flipping them. To that end, we’ve added a new control to wheels: Steering Adjust, which can either be in Auto or in Override. When set to Auto, Steering Adjust will reduce the maximum angle your wheels can turn as your vehicle goes faster. Because most players use keyboard controls, it’s been too easy to overcrank your wheels by holding a key down too long and flipping your vehicle over - keeping Steering Adjust in Auto will help you deal with that. Setting Steering Adjust to Override will preserve the old steering behavior - but also expose some new controls to help you manually tune your wheel controls. Steering Angle will let you manually reduce the maximum deflection your wheels can go through. Steering Response will change how quickly the wheels respond to inputs - how quickly they’ll turn. Those of you who use an analogue controller will likely want to set your steering adjust to override if you like using your analogue controls to control the full range of motion of the wheel, though you can still turn down the Steering Angle to have better fine control. Bug Fixes We’ve also addressed some of the bugs that have been plaguing wheels for a while. Check the build notes for the exact list, but notable improvements include: Wheels and landing legs bouncing less when docking/undocking. Wheels and landing legs bouncing less on load. Landing legs being more stable generally and especially when deployed at wide angles. Wheels and landing legs suspension now handles different gravity changes much better than before. Fixed the wheel speed on the M1 and M1-F wheels. Wheel load balancing now across all grounded wheels on a vessel. Wheel Tuning Tips Finally, I’d like to share some simple tips to make a more drivable rover. Wheel Tuning Tips Finally, I’d like to share some simple tips to make a more drivable rover. Rolling over during a turn too often? If you’re still rolling your rover often over too often, here’s a few things to try: Lower your center of mass or widen your wheel track - the horizontal distance between your wheels. That’s always going to make your vehicle more stable. Use the Steering Adjust in Override mode, and manually lower the amount your wheels will turn. Set Friction Control to manual and lower the friction on all your wheels - this will make your vehicle tend to skid, rather than flip. Of course, you can get crazy with reaction wheels and RCS to keep your rover pinned to the ground - it’s the Kerbal way, after all. Flipping over when you brake or accelerate, particularly on low gravity worlds? If your rover flips forward or backward while braking or accelerating, try these tips: Make sure you have any reaction wheels turned off! Those can easily torque your vehicle over. Adjust your Brakes% to increase it on the back wheels, reducing it on the front wheels, and your motor power to the front wheels. . Set Friction Control to Override and lower your friction - low gravity worlds can be hard to drive on and it’s tempting to set this higher, but the low weight holding your vehicle down has to be accounted for. Oversteering? Oversteering is when your vehicle tends to turn too much, and possibly go into a spin, rather than following the direction it’s driving in. You can address this in a few ways. Set your back wheels to not steer - all-wheel-steering can be great for maneuverability, but it seems you’ve got too much of that! Either adjust the center of mass of your vehicle to put more mass on those back tires, or you can adjust friction to increase the friction of your back wheels and/or decrease the friction on your front wheels. Setting your Friction Control to give 50% more grip in the back - while not overdoing to cause problems with flipping - can help a lot. Understeering? Understeering is the opposite of the above problem, where your vehicle just doesn’t want to turn. And it can be solved by doing the opposite steps - moving mass forward, increasing the grip of the front wheels, etc. Do note that just turning the wheels more won’t typically help - understeer occurs because the steering tires are not exerting enough torque to turn your vehicle, turning them more will just cause them to slip more. A Fond Farewell I’ve been working on KSP since version 1.6, and it’s been an absolute pleasure to work on a game with so much love and creative investment from its fans. However, shipping 1.12 will mark the end of my time designing for Kerbal. It’s not a decision I came to lightly, I’ll definitely miss my teammates and the project. I know they’ll keep doing fantastic work expanding the franchise, but I’m off to do other things. I wanted to take a moment to say what an honor it has been working on something that is so much more than a game for many people, that inspires people about space exploration and educates them about the challenges and wonderful discoveries we have in reaching out into the Solar System. I will continue to be a fan of the franchise and you’ll likely see me kicking around in a more civilian role, feel free to say hi. Thank you for being amazing fans, I’m back to being one of you. Paul Boyle, KSP lead designer for versions 1.6 to 1.12, and the Breaking Ground DLC
- 26 comments
-
- 51
-
See you on stream in a few hours!
-
The adjustment is applied automatically to all modded parts, based on their crew capacity and whether or not they're a command part, and the modder has the option to turn it off if they don't want it, so unmaintained modded parts should generally be just fine.
-
Or maybe I was hungry while I wrote this post
-
It was an oversight in the change log. As JPLRepo says above, it doesn't apply to landing legs/wheels/landing gear. I believe it doesn't touch Kerbals either, at least not in the case we know about them sliding in, that's a separate issue. Not sure we've got anything for an issue with jittery landing legs, but there may be knock on effects from the ground anchor there anyway that we'll have to look at.
- 381 replies
-
- 2
-
- thread
- discussion
-
(and 3 more)
Tagged with:
-
The ground anchoring system is under the hood. The game now anchors parts better to the ground to deal with some sliding issues that would happen, especially when you had light parts contacting the surface w/heavier parts attached to them, and was kind of an artifact of how things worked in PhysX.
- 381 replies
-
- 7
-
- thread
- discussion
-
(and 3 more)
Tagged with:
-
Yes, everything is reflected in the dV readout in the VAB - loading/unloading Kerbals, changing their inventory, changing the craft's inventory, etc.
-
There’s a lot of cool stuff in 1.11 Some Reassembly Required, and the Squad team hopes you’re enjoying it all! I’m here to share a few thoughts on some tuning changes we’ve made to the game. Kerbals on the Scale Kerbals have always had a mass in the game when they’re EVA - 93.875kg. That included themselves, their suit, their EVA jetpack, and their parachute, plus any Snacks they managed to hide on themselves. Now with jetpacks and parachutes being something Kerbals can choose to go without - for better or worse we’re taking the time to update and rectify some things around this. On the Scales: First, Kerbals got a little fatter - now tip the scales at a full 94kg, fully loaded. A little weight gain is expected after almost 10 years on a job this stressful. Here’s how that breaks down: IVA Kerbals have mass now: Second, we’ve gone ahead and made Kerbals have a mass IVA. Previously, whenever a Kerbal got into a craft, their mass would be nulled out. Now, the weight of the Kerbal itself - 45kg with their suit on, plus anything their carrying - gets added to any part they’re riding in. Note: The command seat was a special case as that’s still an EVA Kerbal, and the Kerbal’s mass always counted. To keep everything roughly as it was before, all command pods are now automatically 94kg lighter per seat - that’s the weight of one Kerbal plus an EVA jetpack and a parachute. All other parts that could contain a Kerbal - crew cabins and the MPL - are 45kg lighter per seat, as you hopefully won’t be kicking your untrained passenger This automatic readjustment can be disabled on a per-part basis for modders who might want to do so. EVA fuel has a density now: Kerbal EVA fuel was always a bit abstract. With the addition of separated jetpacks and the EVA Fuel cylinders, we’ve adjusted that. Now EVA fuel is 5kg/unit, and the Kerbal respond as you’d expect as it's burned up - jumping a little higher, being able to accelerate faster with the Jetpack. Crewed part tuning adjustments: Since we’re already messing with pod masses a bit, we went ahead and made a few changes to the tuning of certain pods. First, all of them have inventory capacity, to store some baggage if you’d like. The amount of space involved depends on the part. Second, we’ve adjusted a few to align them more with other parts. PPD-10 Hitchhiker Storage Container: Its mass was adjusted from 2.5 tons to 2.07 tons, and it now has some significant cargo storage capacity. This makes it closer to the average .5 tons/passenger that other passenger containers had, accounting for the extra benefit of that large storage. Mk3 Passenger Module: Its mass goes from 6.5 to 7.18 tons: This part was judged to be too mass efficient vs other passenger storage modules, so it got bumped up. PPD-12 Cupola Module: Its mass was cut from 1.8 tons to .886 tons: Despite giving some glorious views of the cosmos, it's always been much too heavy, given how few Kerbals could get a view from inside it. Perhaps its now being built with transparent aluminum? Its cost was also cut in half, from 3200 to 1600. Mk2 Crew Cabin: Its mass goes from 2 to 1.85 tons - which is slightly less than the tuning adjustments for the passenger mass might otherwise have lowered it to,, since its built in lifting surface is now accounted for. There’s a lot more that’s gone into 1.11, and I hope you check all the changes out at the 1.11 intro and change log. Feel free to add a comment here if you’d like more info on some of the details behind the game design of this update!
- 44 comments
-
- 48
-
Basically this yes. I don't know why, when the Mk2 parts were added to the game, a nosecone wasn't added. Before my time. There might have been a good reason, it might have been an oversight. We do as many parts as we can manage, for each version, given our capacity and other goals we have for that version. In a world without those restrictions, I'm sure we'd have one. All I can recommend is doing your best to enjoy games as they stand. Continue to make recommendations, try to get people's buy in, but making a case that says anything like 'we need X, X is a huge problem' etc, when clearly that's a bit of an exaggeration, is unlikely to get you much good will from any dev team. Not only can it be a bit personally off putting, but it can get actually do the opposite of what you want, as noone wants to signal to a fan base that the best way to get something added to a game is to make posts like that. The best way to get changes is to make reasoned posts, with a moderate tone, and to get the community to agree with you.
-
Kerbal Space Program 1.10: "Shared Horizons” Grand Discussion Thread
Maxsimal replied to UomoCapra's topic in KSP1 Discussion
That was mean to read 'now'- 202 replies
-
- 1.10
- grand discussion thread
-
(and 3 more)
Tagged with:
-
Now I don't feel so bad I can't go out to the cinemas, something to look forward to! Can't wait!