Jump to content

Maxsimal

Members
  • Posts

    285
  • Joined

  • Last visited

Reputation

1,125 Excellent

Profile Information

  • About me
    Former Lead Cat Wrangler

Recent Profile Visitors

9,204 profile views
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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?
  6. 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?
  7. 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.
  8. Thank you, I'm just glad I got to help move forward Kerbal for a while.
  9. That's amazing! And now we have some insight on what's in a Kerbal's head!
  10. It's not impossible, but it might be improbable.
  11. Thank you so much, it's been a pleasure working with you !
  12. 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
×
×
  • Create New...