Jump to content

  • Developer Articles

    KasperVld


     
    Good afternoon from Mexico!
    Last night at Unite Boston - for those of you who don’t know - the Unity Awards ceremony took place, and Kerbal Space Program was awarded not one, but two awards: Best Gameplay and Community Choice! It's an amazing honor and we’re very glad the KSP community supported us in such a major way. We want to thank you from the bottom of our hearts.
    Being part of such a strong lineup of games, and walking away with two awards is something we never saw coming, but there are also many games that were nominated, or won awards, that you really should check out:
    First and foremost: the winner of the Golden Cube, Cities Skylines. This game is a fantastic city builder with a great developer and publisher behind it. The first expansion pack, which is right around the corner, also looks very promising. Endless Legend walked away with the award for best 3D experience, and this 4X turn based fantasy game should definitely be on your list if you’re into the genre. Ori and the Blind Forest is a stunning looker. In this 2D platformer you explore a deeply emotional story about love and sacrifice. Did we say it’s a beautiful already? It took the award for best 2D experience! Probably the only riot training program we’ve ever seen: Anarcute won best student project! In this game your goal is to escape the police, gather a group of friends and destroy literally everything. It’s only a matter of time until Danny2462 gets his hands on this, we’re sure.
    Apart from making games, the Unity engine is often used to create a wide range of tools, art and virtual reality programs. In these categories the winners were Parachute Training Simulator (best visual simulation), UEFA Champions League Nissan Orchestra (best of non game), and Tilt Brush (best VR experience). Finally, Chronos - Time Control walked away with the best store asset award.
    Unfortunately the list would grow a bit long if we mentioned all the nominees, but rest assured they’re all amazing in their own way. A full list is available at the Unity website.
    Thank you to Unity and you all for the awards and a massive congratulations to all the winners on behalf of all of us here at Squad!
    KasperVld
    [TABLE=width: 965, align: center]
    [TR]
    [TD]In 2011, during the earliest days of Kerbal Space Program lead developer Felipe Falanghe stated that we'd bring the game to as many platforms as we could make it compatible with[1]. Today, we're holding true to that statement by announcing that Kerbal Space Program will be coming to the Wii U platform.
     
    Kerbal Space Program for Wii U will be ported by Flying Tiger Entertainment alongside the already announced ports to Playstation 4 and Xbox One. The Wii U is a unique platform that will allow us to include millions of Wii U owners worldwide in our passion for space and our game. We'd also like to thank Nintendo for giving us the chance to do so.
     


    [/TD]
    [/TR]
    [/TABLE]
     



    KasperVld
    [TABLE=width: 1000, align: center]
    [TR]
    [TD][/TD]
    [/TR]
    [/TABLE]
    [TABLE=width: 900, align: center]
    [TR]
    [TD]Hello everyone!
     
    While the news has been slow on our side for the past few weeks we’ve been discussing update 1.1 and we have some exciting news to share. Now that the Unity 5 update is nearly complete we put it through internal testing and found that we had made enough major changes that we wanted to share these with you a bit more quickly than we originally intended, so we’ve moved the 1.1 update forward.
     
    This means that the scope of the update will be reduced slightly in favor of speeding up the release schedule. The Unity 5 update in itself brings major changes to many game systems, and delivers a very solid performance boost, via the new version of PhysX being able to multithread across your processor cores. Perhaps more importantly the Unity 5 update has proven to make the game far more stable on 64 bit platforms, meaning a 64 bit client for Windows and possibly Mac OSX is something we’re looking into very seriously for this update. Also part of the engine update are the overhauls of the UI, wheels and various other systems that you’ve been reading about in the dev notes.
     
    Helping us accomplish this is modder extraordinaire NathanKell, who is new on the team and will be working closely with the existing developers to polish existing systems and implement new ones:

     

    Aside from a new developer, performance increases, reworked systems and new platform support we’ll be adding new content to the game as well. Porkjet, RoverDude, Arsonide and NathanKell have been working on a number of features.
     
    Highlights include:
    New Parts

    The Mk1 cockpit has been reworked, not redesigned from the ground up, keeping the original style that we all enjoy and incorporating in real-life counterpart cockpit designs. The Mk1 parts that received an overhaul a while back are also being slightly reworked to bring them closer in style to the rest of the beautiful spaceplane parts that Porkjet has modeled.
     
    It doesn’t stop there with the spaceplane parts though, Porkjet has also been working on 0.625m jets and associated parts, as well as spicing up the Basic Jet Engine and Turbo Jet Engine. You’ll all be seeing more of that at a later date, as well as a few parts that are currently still being designed and developed.
     
    Porkjet made an album with his work so far. Click this link!
      Antenna Diversity and Probes

    A feature we’re sure you’re all familiar with by now, if not you should read this article. RoverDude is still hard at work further refining this feature and incorporating the feedback we received from you, the community. Onwards to QA from there!
      Contextual Contracts

    Having Contracts that set full missions for you is great fun, but the real sense of achievement comes from watching something take shape and evolve over time. With Contextual Contracts, we’re hoping to provide the contracts KSP give you with a level of continuation from where you currently are in your space program. Therefore, instead of receiving endless contracts to build a base, you receive an initial contract and then additional ones to add a lab, for instance, or adjust a satellite to meet new requirements. We’re talking adding depth, not breadth to the contracts system, something we’re hoping improves the gameplay dynamic and furthers the potential that Career Mode allows players to have.
      Localisation

    Lastly, we’re planning on adding the framework for localisation into the next update, paving the way for implementing localised versions of KSP. But more on that later!


    Of course, a major engine update and these new features all require extensive QA testing. To bring this all together we will be focussing two or three weeks in QA purely on the engine update, after which the new features will also undergo testing and we’ll have a final part of testing focus on bugs in general to make sure we catch as many bugs as possible, both new and existing ones. All in all it will take us a while to finalize testing still, but we’re very happy to move forward and spend this time to provide a more stable and fluid experience for everyone.
     
    Keep an eye on our usual development news channels (Devnote Tuesdays and Squadcasts) in the near future. We’ll be keeping you up to date on any developments we can share![/TD]
    [/TR]
    [/TABLE]
    KasperVld
    [TABLE=width: 965, align: center]
    [TR]
    [TD]We’re very excited to announce that Kerbal Space Program is coming to Xbox One! The Xbox version of the game will be developed by the developers at Flying Tiger.
     
    Flying Tiger's development team has proven invaluable in the implementation of Unity 5, bringing a fresh viewpoint and years of experience that have deeply simplified the upgrade process for us. Furthermore, this cooperation has given us the opportunity to keep focussing on the PC version and the upcoming update, while reaching out to millions of console gamers at the same time.
     

     
    We'll be posting an update on the development of the KSP 1.1 patch on the forums tomorrow![/TD]
    [/TR]
    [/TABLE]

     



    Ted

    Development Relay

    By Ted, in Developer Articles,

    Up until now, and including 1.0, KSP development was for the most part horizontal, predominantly adding in features for sandbox and then post-0.18 adding in Career mode features. While there was vertical development in a number of major areas: the VAB/SPH editor, parts, contracts, etcetera, we are now at a point where that becomes the sole focus of KSP development. In other words, we're at a point in KSP's development where we're building upon already existing features to give them even more depth!

    This brings us to update 1.1. While there is still a fair chunk of 1.1 to design and plan, we do have a good idea of what we want it to include. While HarvesteR, Mu and Romfarer continue to work on the Unity 5 upgrade, RoverDude, Arsonide and Porkjet have already started planning, designing and developing a few of KSP 1.1's new features.
     
     



    RoverDude, specifically, has been working on two features that we've been quite eager to tell you all about. Note that these features are still in development and are pending QA playtesting, balancing and feedback as well as community feedback. Additionally, the more challenging aspects of these features will be off or reduced on the lower difficulties in KSP.

    The first feature is probe telemetry. With this, a probe must establish a connection back to Kerbin or another 'control point' via an antenna part in order to operate - be controlled by the player, or active in any way. These control points are the planet Kerbin, or a craft with an antenna, a pilot Kerbal, and optionally a large probe core.

    An example of using pilots as a control point would be a mission over Duna where a piloted command module serves as the remote control point for a landed, unmanned rover. If the player has a non-pilot Kerbal on board, they can still fly the ship, but they would lose access to the probe's piloting capabilities (i.e. a ship where a player uses a probe core for control, and crews it with a non-pilot).


    However, given the length of time a player would have to spend on simulating a relay network around Kerbin in order to ensure that the KSC is always reachable would be significant, we felt it would be better to have Kerbin simulating a Deep Space Network. It's a ground-based network of relay stations that attempt for complete coverage of Earth. In KSP this is translated to the Tracking Station. As a player upgrades their tracking station, the range of Kerbin's Deep Space Network will increase, eventually allowing it to receive signals all the way from Eeloo's closest approach to Kerbin - similar to New Horizon's range. In this design, the player then only has to send the signal to Kerbin, saving the triviality of waiting for the KSC to be on the facing side and breaking gameplay flow.

    At this point, you may be wondering what the second feature is, you may have forgotten about it or you may have figured it out. If it's the last one, well done! RoverDude's second feature for 1.1 is antenna relay networks. It extends to range, network pathfinding and soft occlusion of celestial bodies.

    In gameplay terms, this means that if you want to send data back to Kerbin, or control your probe while you're out of range from your control point, the probe will attempt to use relay satellites you've set up to communicate with a control point and the pathfinding model will simulate celestial bodies being in the way. Additionally, there's no direct pointing of antennas, meaning you won't need to have it pointing at the control point for a connection. The occlusion is slightly fuzzed or 'soft' to make it a bit more forgiving, for example Minmus won't stop you from being able to control your probe around Duna as it passes between you and Kerbin.

    To go along with this we've also modeled three new advanced antenna parts to serve as relay dishes. They're heavier than existing antennas, but offer the feature of automated network relaying.

    However, relays are not always required due to the nature of the Kerbin Deep Space Network we mentioned earlier. In the current design, it will be completely possible to shoot a signal directly from, say, Duna to Kerbin - with a sufficiently large antenna on your vessel. Though you will likely want to set up relays to deal with occlusion issues mentioned below. One possible use is that you may want to set up a relay network in a Duna polar orbit to allow continuous control to a landed rover.

    The relay/signal occlusion is present only for celestial bodies - not vessels or asteroids - and is implemented via analytic geometry. A probe in a low Munar orbit would be blocked while on the far side of the Mun, but a probe sending a signal from Jool would likely not be blocked by Minmus - the soft occlusion angle is fully configurable on an antenna by antenna basis for modders.
     


    We've focused on designing these features to be simple and approachable, using inspiration from some of the plugins that have implemented similar features. For example, we opted to have no flight computer, signal delay or antenna pointing. However, there is a clear distinction between the lightweight antennas used for direct communication, and the heavier, more complex antennas used for building up relay networks - the extra mass comes from the hardware required to store and forward data onto the relay network.Another area we've made more approachable is the default implementation of a built-in deep space network, where Kerbin has an ever-increasing inferred relay network, similar to what we have on Earth. The range of this network will be decreased if the player is on 'Hard' mode, effectively requiring the player to set up their own deep space network. On 'Easy' mode, relay, and antennas operate as they do today, with your only limitation being the power constraints and packet size of the antennas themselves. Furthermore, the settings will be exposed in the difficulty settings so they can be toggled in Custom Difficulty.

    Of course, science will also be subject to the antenna transmission and relay rules as well, using the same pathfinding rules and access to Kerbin's Deep Space Network as probes. With the exception that science must trace a control path all the way back to Kerbin.

    And there we have it! That's two of the principal features for 1.1 that will change the way you play KSP, but how much so is very dependent on how you play, what difficulty you play on and your game mode. We're pretty excited about these features and looking forward telling you more about 1.1 as development progresses; hopefully you are too!

    Please feel free to leave comments on any questions and the like that you may have.
     
    danRosas
    We are happy to announce that Valentina Kerman is now available at our Shapeways Store!



    As part of the announcement I’m going to explain to you how I prepare a Kerbal for 3D printing. First of all, I need to find the file with Valentina and the rig used in the game animations. Next step is to pose Val to match the rest of the crew available at Shapeways.



    Next up, the model needs to be adjusted for 3D printing. You can find the requirements and technical specifications at the Shapeways Materials page. So the easiest thing to do at this point is to separate the model into different parts (here I’m talking about internal parts, at the end one single mesh will be exported) and start closing holes.

    One of the requirements for 3D printing at Shapeways is that all meshes should be watertight. That means there shouldn’t be any “open facesâ€Â. So an optimized model for the game should not work for printing. Some parts of the model, like the body of our Kerbal, work with an empty space on the interior. It should be a walled structure, with an escape hole for the excess of material. That makes the model less expensive, because it will use less 3d printed material.



    Next step is to extrude the faces of the model of the sections that need support walls. For example, the head and the body. Those two have empty interiors. To extrude the faces I need to be working with mm inside of Maya for the sake of convenience. I only need to push the faces 2 units and most of the times this works just fine. Some parts, like the neck, need to be relaxed, so that faces won’t intersect with each other.




    Now that we have a watertight model, with support walls to have an empty interior, I need to combine all the shapes into one single mesh, and export the model. Valentina is ready to be uploaded to our Shapeways account, and see if the automated tests send any problems.
    As you can see, the tweaking process of a model is not extremely complicated, but it needs patience, to be careful about the small details and to always have an eye at the Maya units.

    Once everything is OK, we send the print to Shapeways!

    Our friends at Shapeways have sent us some pictures of the printing process of Valentina at the lab. You can find over here a detailed video of the process:


















    KasperVld
    Introducing Kerbal Space Program’s second official mod: Asteroid Day! We’ve partnered with the B612 Foundation to bring you this mod which will give you four new parts, a new experiment, and a unique contract.
     
    The Sentinel Infrared Telescope mimics the real world Sentinel mission being planned by the B612 Foundation, which plans to map 90% of the larger asteroids threatening Earth's orbit sometime between 2018 and 2024. Due to sun glare it is difficult for telescopes on Earth to observe objects passing on the planet's day side. Deploying a telescope into a solar orbit near Venus and facing it away from the Sun, back towards Earth's orbit, would cover that blind spot.
     
    Your mission will be to recreate this mission profile in Kerbal Space Program, deploying a telescope around Eve’s orbit. When deployed with an antenna and a power source between Eve and Kerbin, aligned to face away from the Sun, and activated, the telescope will begin to map the orbit of the outer planet in a 200° vision cone for passing asteroids.
     
    Other than the telescope itself, you will have three new parts to make your unmanned missions more enjoyable:

    The HECS-2 Probe Core comes with integrated batteries and SAS, to make building a compact Sentinel probe much easier. The OX-STAT-XL Photovoltaic Panels are a much larger version of the stock solar panels, for larger probes. The HG-55 High Gain Antenna can transmit larger amounts of data than any of the existing antennae in the game.

    This pack also includes a long-term contract to map asteroids around Kerbin as well as other planets that match various specifications. It differs from other contracts in that it encourages the use of existing infrastructure. It does not require a new vessel for each contract, and each scan is faster with more telescopes deployed.
     
    Get it now at Curse!

    HarvesteR
    Hi,

    KSP version 1.0.3 is now live! This revision brings several much-needed bugfixes and improvements, as well as a few new parts.

    Most importantly, this patch introduces a big revision to the thermal system for parts. The heat simulation has been greatly improved, heat from reentry is now handled in a totally new (and more accurate) way, and we've also added five new Radiator parts, so you can have much more control over how your ship deals with excess temperatures.

    We've also fixed a significant amount of bugs. Here's the complete changelog:



    =================================== v1.0.3 ============================================================

    New:

    Parts:
    * Added five new Radiator parts, three of which are deployable.

    Bug Fixes and Tweaks:

    Misc:
    * Fixed a bug where using the reset button with an Asteroid loaded would break the Mun tutorial.
    * Made part's internal highlighter much more efficient.
    * Disabled flashing highlighter in temperature gauges. (fixes memory leak with temperature overlay)
    * Fixed KSPUtil.PrintLatitude/Longitude giving wrong result for small negative values.
    * Fix for horizontalSrfSpd being incorrectly calculated.
    * Fixed unfortunate typo in the Docking Tutorial.
    * Fixed an issue where moving the camera using a 3D mouse would break drag-and-dropping of parts in the editors.

    Thermal:
    * 1.0.3 features a revised thermal mechanic to better balance heating/cooling between pods and spaceplanes.
    * Parts now have separate internal temperature and skin temperatures.
    * Skin temperature is the temperature used for radiation and convection, as well as engine exhaust damage.
    * Part internal temperature is increased by modules that generate heat and is used for part-part conduction.
    * Part internal and skin temperature also conduct between each other.
    * Solar panel efficiency is now calculated based on skin temperature.
    * When in an atmosphere, there is a divide between the exposed (to convection) and unexposed skin temperatures.
    * When not in an atmosphere, only one skin temperature is tracked; the two temperatures are unified on atmosphere exit.
    * Radiative outflux and influx is tracked separately for exposed and unexposed areas of skin (since the shock temperature is much higher than ambient temperature).

    Physics:
    * Added curve to control drag coefficient exponent to DCL and Physics.cs
    * With lowered drag for sharply-tapered cubes, wing lift and wing drag lowered to match.
    * Convection velocity exponent raised to 3.3 to increase reentry heat, as well as convection factor.
    * Convection min area typo corrected.
    * Newtonian convection kept pace with hypersonic convection.
    * Drag curves modified to lower transonic hump.
    * Wing curves modified to lower change in drag based on deflection.
    * Calculation of exposed area for convection fixed, spaceplanes no longer get as extreme heat.
    * Flight integrator: allow setting of newtonian density exponent (default 0.5) and use density or density^exponent whichever is greater.
    * Broke radiation into two parts, you get the regular background temp on your face not exposed to reentry flux, and the very high reentry one for the area that is.
    * Clamped convection correctly so you will never pass external temperature.
    * Added a factor to simulate the switch from laminar to turbulent flow (in layman's terms, if you're going too fast too low, you get a massive boost to heating). That corrects so steep reentries are in fact deadlier than shallow ones.
    * Added conduction-changer module to Mk1 and Mk1-2 pods (necessary to not kill chutes), buffed heat shields for new heat loads. Changed burn/rip numbers for drogue chutes.
    * Parachute module updated to use the new convection code.
    * Skin temperature variables are controllable on per-part basis.
    * Sped up Flight Integrator slightly by minimizing repeated loops through parts.
    * Better compute various vessel values This should lower phantom orbit changing and wobble!
    * Remove thermal mass as a factor in conduction rate: what matters is area.
    * Add conduction between parts' skins (as well as between the internals of parts, between a part's internals and its skin, and between the exposed and unexposed skin of a part, all of which were already in.)
    * Fix some small issues in conduction (better clamping), sped it up slightly.
    * Fixed issue with radiation (no longer have to use dirty hack to prevent parts blowing up).
    * Lowered skin thickness slightly globally, made magic number sane (part.skinMassPerArea is now in kg/m^2).
    * Added Hsp (resource thermal mass value) to Ore resource.

    Parts:
    * Updated Mk1 Inline Cockpit model.
    * Further decrease in LV-N heat production.
    * Rebalance of SRB for the new drag changes.
    * KR-2L description updated, mass to 9t, SL Isp to 255.
    * Jet thrusts rebalanced for new drag (thrusts lowered, BJE curves altered). Jet Isp halved due to increased fuel quantity and lower drag.
    * Lowered LV-N heat a bit, still a bit hot.
    * Edited KS-25x4 "Mammoth" engine description.
    * Update description of radial-mount engines to recommend use for extra attitude control.
    * Mk1 fuel tank: uses same dry mass fraction and resource filling compared to its LFO counterpart as Mk2 parts do.
    * Radial attachment point cost lowered.
    * Shielded docking port radial attach node fixed.
    * Aerospike mass lowered as a buff (it needed a buff to compete with late-tier engines) and tangents fixed.
    * Heat shield thermal mass modifier increased to 0.05 to deal with increased heating. Max temp lowered to 3000 to avoid totally overpowered radiation heatloss.
    * Mk3 cargo bays have override cubes (they got missed when cargo bays got custom cubes) - should now have expected drag.
    * New large landing gear have override cubes (cubes were reversed).
    * Mk3 parts have breaking forces/torques specified and should no longer break on landing.
    * Mk2 cockpits have same breaking force/torque as other Mk2 parts.
    * Ablator resource heat capacity increased.
    * Rebalanced LV-1 to have Sea Level ISP of 80.
    * Rebalanced Poodle to have Sea Level ISP of 90.
    * To fix spaceplane vs pod reentry and better allow hot reentries, temp is separated between part internal temperature and part skin temperature.
    * Fixed some occlusion issues. Occlusion is now over-generous rather than under-generous.
    * Buffed heat resistance of spaceplane parts.
    * Added in CoL and CoP offsets for wing parts, no longer at the attach node.
    * Fix for ablator and configs not taking skin temp into account.
    * Fixed Radian vs Lat/Lon bug in Overlay and made displays more consistent.
    * Fixed potential exploits with sci lab.
    * Removed transparency and added direct-attach node to heat shields.
    * Balanced heat shields for skin temps. A Mk1-2 straight-in reentry to Eve starting at 6.5km/sec surface (more orbital) is just barely survivable (ablator fully depletes), and regular Eve and Kerbin Munar reentries deplete about 1/6 to 1/4 the shield.
    * Added a tuning factor to conduction between parts with different shielded states, so a cargo/service bay won't conduct much to parts within it. Since radiation is disabled for parts within bays, they'd just increase in temperature with no way to cool during reentry, and parts in bays would be the first to blow up on reentry.
    * Upped non-drogue chute default full-deploy altitude since pods were crashing before the chute fully opened.
    * Upped non-drogue chutes' stress/thermal limits for deployment (safe speed is now around 290m/s at sea level rather than 250). Increased the time to fully deploy slightly so less of a G shock.
    * Increased max temp of linear RCS, slightly decreased max temp of RCS quad.
    * Tweaks to fairings to change the skin:internal thermal mass distribution, and better protect parts inside fairings and cargo bays.
    * Not-Rockomax Micronode side stack nodes corrected.
    * Parachutes now have deployment warnings in the Part Action menu, when it's safe to deploy etc.
    * Halved intakeAir requirements for jets. Slightly raises service ceiling, mainly helps mitigate flameouts due to resource transfer issues.
    * Balanced thermal mass of drogue chutes to correct max opening velocities.
    * Attach node refinements on Wing Connector Type A and Structural Wing Type A.
    * Removed drag from Intake context UI.

    Modding API:
    * flow multiplier curves can multiply thrust rather than flow.
    * Added method to convert string to ConfigNode.
    * Un-hardcoded altitude for navball velocity indicator to change modes.

    FX:
    * Heat animations for engine nacelles and 1.25m intakes.
    * SR-71 style exhaust flame for TurboRamjet.
    * Nose and tail cones heat animation.
    * Fixed incorrect transparency on the letter P on the UKSA flag.



    As always, the latest update is available at the KSPStore, Steam and GOG.

    Happy Launchings!

    Cheers
    HarvesteR
    Hi,

    Since we didn't have a full dev note this week in light of the PS4 announcement, I figured I'd write up some lines about what's currently going on on our end, which is for the most part related to the Unity 5 port at the moment.

    It's worth mentioning though, that our moving to U5, which I think is fair to say is something everyone has been asking for quite a while, has been largely sped up by our collab with FlyingTiger, who are developing the PS4 version. The first step for them was to move the game into U5, and because that was something that affected the entire project, we felt the best way to go about it was to work together on upgrading the project, so the PC version wouldn't be stuck on Unity4 as they moved on. So contrary to popular belief, the move into PS4 is actually giving PC development a boost, not hindering it.

    Anyhow, let's get into about what's going on development-wise.

    First off, the biggest hurdle/opportunity we came across was the game's UI. The current UI implementation (not design, mind) is, well, let's say it's not my favorite part of the project... The lack of a robust native UI toolset in U4 and earlier meant that over the course of development, we ended up with multiple different, sometimes conflicting UI systems working alongside one another. Unity's OnGUI code-driven UI, EzGUI, and the SSUI system I wrote back in v0.3 or so, all these systems were being used at the same time, each drawing their bit of UI, and trying not to step over the other's bits.

    Re-doing the UI was something we all wanted to do here, but the amount of work it would require was, to say the least, discouraging. That's all of the game's UI we're talking about. From part context menus to confirmation dialogs, to flight gauges to settings screens... all of it needs to be redone. Not a small task by any measure. So it's no wonder we weren't exactly in a hurry to deal with that before, even more so because before Unity's new UI system came along, the idea of consolidating UIs meant choosing one of those systems I mentioned earlier... so we wouldn't be upgrading to anything superior then.

    With the new UI system in U5 though, this became a much more interesting notion. Unity's new UI combines the best features of the many UI tools out there,into a flexible, sleek and very powerful all-around system. Good, but it still meant redoing the entirety of the game's UI.

    The final push came from the PS4 porting side. PS4 has its own set of tech requirements, and our 'eclectic' UI implementation was evidently not quite up to par with those reqs. For the past weeks then, we've been working on a total revision of the game's UI. Currently Jim (RomFarer), Mike (Mu) and DJ from FlyingTiger are assigned to that enormous undertaking.

    On my end, I'm tasked with the shaders and physics side of the U5 upgrade. Shader-wise, we had a few broken ones here and there because of upgrade issues, which were for the most part easy to fix (DJ helped me out there a lot too, he had been plugging away at it while we were still in exp for the 1.0 release). The ones that were most complicated were the terrain shaders. U5 compiles shaders differently, so that meant some of our terrain shaders were now above the SM3 limit for interpolators. A shader interpolator is the process by which the GPU figures out what a pixel that sits in the space inside a triangle ought to look like. It does that by (as the name implies), interpolating values from the surrounding vertices, which were calculated earlier, to compute the final colour of each pixel... Anyhow, the problem was that SM3 (DirectX9) imposes a limit of 10 interpolators, and with U5, we were now using 11. That wasn't all bad though, it meant we just had to reduce the shader by one interpolator, which I was able to do by moving some bits of the vertex code into the pixel program, and just pack the data that those bits needed to function into already existing interpolators which had one or two unused channels. It seems if you have a vector interpolator, it doesn't matter if it's a 3D or 4D vector, it will take up one interpolator. That means you can pack extra data into the 'w' axis of 3D vectors and cheat yourself some extra headroom that way.

    Shader issues dealt with then, I moved on to the physics. These were largely modified in U5, and at first sight, it appeared we were in for some real trouble, because all our joints were now less stable than before.

    Turns out, U5 opened up the range for some joint springs, so fortunately, all we needed to do there was up the stiffness of all joints again to have the same behaviour as before.

    Now, however, I ran into one real problem: The wheel colliders in the new PhysX are much less stable than their older selves in U4, and all our wheels were now effectively non-functional.

    Wheels are deceptively crucial things. You don't realize just how important they are, even to a game taking place mostly in space, until suddently they stop working. The broken wheels meant all spaceplanes would break up immediately on spawning, and of course, those that survived had very little chance of even getting up to speed on the runway, let alone making it off the ground.

    The wheels were not something we could apply a quick fix for. This needed a comprehensive new solution. Fortunately, this solution already existed, and just in time actually. A package called Vehicle Physics Pro (VPP in short), which is a more realism-focused vehicle simulation by Edy, who created Edy's Vehicle Physics, a widely used vehicle asset package, but more gameplay-focused than VPP, was just recently made available in 'early access' form. It's still not in the Unity Asset Store, as it's still being developed, but the bits we needed for KSP were all there already.

    So, I got in touch with Edy, and got us an Early Access license to VPP. Edy has been remarkably helpful also. He even wrote a wheel controller specifically for KSP in advance.

    VPP is primarily focused on cars and car-like vehicles, though, for normal-ish games where vehicles are a single rigidbody and gravity points 'down'. KSP is, well... not normal in that sense. There are no 'vehicles' as such, because every part has its own rigidbody, and gravity... well, let's just leave that by saying it doesn't point down, and not get into discussng what down even means in KSP.


    KSP's rather unique requirements meant that VPP also needed its set of modifications to work properly. For the most part, that was just a matter of replacing any bits of code that worked under the assumption that Vector3.up actually represents something meaningful in the game world by our FlightGlobals.upAxis and friends. Then, we also needed to contend with the vehicle setups themselves. In KSP, we can't rely on vehicles being set up as a single rigidbody. Each VPP 'vehicle' for us, just represents a single wheel or landing gear part, which is attached to others by joints.

    In practice, that means the simulation of suspensions and tire friction (which VPP does fantastically) can't rely on the vehicle's rigidbody mass to calculate the load a wheel is supporting (aka the 'sprung mass' of the wheel). Happily, there exists a law in physics called Hooke's Law, which states that the force exerted by a spring varies in direct proportion to its compression. That is to say, we can figure out how much weight a wheel (and its suspension spring) is supporting by looking at how compressed the spring is.

    Replacing the rigibody.mass bits in the VPP tire friction code with this 'trueWheelLoad' value made all the difference. The wheel tire friction and resulting traction are now correctly simulated as the weight shifts and changes in the vessel on top of them.

    Ok then, we now have a functional solution for wheel simulation, but that is still far from saying we have functioning wheels in KSP. The wheel part modules had all been written, long ago, to work with a simple Unity wheel collider component. That means all our wheel modules are now essentially obsolete, and have to be rewritten basically from scratch.

    Well, it seems 'rebuilt from scratch' is the phrase of the month here, so I decided to go ahead and do just that, which was something I had been wanting to do for quite some time.

    When we wrote the first landing gear components, IIRC, part modules didn't even exist. A part could be either an engine, or a fuel tank, or a langing gear, and if you needed something that combined any set of behaviours from those (like a wing that carries fuel), you had to write yet another subclass of Part to do that. Part Modules then came along and changed all that, but not before our existing landing legs and gear bays had already been written under the old paradigm. So when rovers came around, after modules and all that, they were given yet another set of code that basically did the same thing again.

    As a result, we ended up with part modules specific to rover wheels, other modules for landing gears (with retract/deploy animation control built-in), other modules for landing legs, none of which could be combined properly without creating a despair-inducing tangle that would drive a battle-hardened developer to drink in less time than it would take the resulting mess of physics objects to come to rest after jittering themselves to bits.

    Needless to say then, I've been wanting to write a new, modular, all-purpose wheel system for some time now, and the move to VPP wheels were the perfect opportunity.

    I'm currently working on this now. I've created a set of modules that work together to simulate different aspects of any wheel. One base module creates and manages the VPP wheel component, then other modules hook in and manage their specific parts. We have modules for Steering, Suspension, Brakes, Drive (motor), Damage and Deployment, each doing no more and no less than their jobs. Setting up every wheel type in the game then should become just a matter of plugging in the features that your wheel needs. Static landing gears? Just omit the deployment module. Want steering? pop it in. Rather steer it as a tank? set it up with a differential drive steering module instead. Also, don't forget the brakes if coming to a stop is part of your mission profile.

    There is still a lot to do there though. At the moment I'm working on the suspension module. This one is interesting, because suspensions are tricky things in KSP. You can't just set up the springs with fixed parameteres and leave it at that. Unless tuned to the mass they are meant to support, suspensions are pretty useless and can make a vehicle even less stable than if it had none. And in KSP, we can't ever assume we know anything about the vehicle sitting above the wheels.

    So, instead of defining suspension parameters by the usual spring and damper values, I set up a scheme where suspensions have in their cfg definitions a 'naturalFrequency' and 'dampingRatio' values, which are then used to calculate the spring and damper internally, thus properly supporting vehicles of any mass. This means suspensions should be nice and springy no matter what sort of monstrous contraption you put together in the editor. If they are meant to break under too much weight though, that's not the job of the suspension module, we have a separate damage module for that.


    Next up is steering. We did have steering already as a separate module, but it was incompatible with rover wheels (or was it rover-wheels only?)... anyhow, looking into it, I was suprised at just how much code there is at making a wheel turn either left or right. I reckon there must be an easier way to do steering... so that's up next on my to-do list. And while we are doing steering, we can set up the new steering system so all wheels on a vessel will behave properly and rotate to follow their own arcs (aka Ackermann steering), instead of just all just rotating to full deflection and leaving you to deal with drifting and doing donuts with an interplanetary rover.


    Anyhow, that pretty much accounts for everything that's been going on on the U5 development side of things. In the meantime, Ted, Mike and the QA and Experimentals teams have been also working on bugfixes for the next update. Whether or not that update will be built with U5 already is still being discussed, but chances are that it wont' be. U5 still has quite a ways to go, and we want to deliver bugfixes as soon as we can. Conversely, we don't want to spam everyone with tiny updates unless they are for fixing emergency issues, so right now we are getting together a set of fixes and improvements that will make for an update worth downloading (and doing the whole deployment process over).



    That's the story up to now. More news as they develop!

    Cheers
    Maxmaps
    Here's a short FAQ to help explain what the PS4 version means for the PC version.


    Why bring Kerbal Space Program to PS4?
    As the fanbase of our game has grown, we’ve received a constant influx of pokes and requests from people asking us to bring our game to PS4. With the power of current generation PS4 and the flexibility and ease of use of the Unity engine, bringing KSP over to the PS4 is simply a no brainer. Space is for everyone, regardless of how you prefer to play.

    How will the game work on PS4?
    That’s another thing we had asked ourselves for quite a while and simply had to make a goal: We could simply not compromise on players’ experience. Thankfully, the PS4 controller has systems that make building and flying rockets just as easy and intuitive as the PC version.

    How are you bringing Kerbal Space Program to PS4?
    We’ve teamed up with Flying Tiger Entertainment to bring the game to PS4. They have experience and have shown us time and time again that they were simply the right choice to make sure that the players receive a quality game on their PS4, and not a lazy port.

    Will this have a negative effect on the development of the PC version?
    Absolutely not. If anything, working in collaboration with Flying Tiger has helped us speed up processes like the Unity 5 upgrade, but in general the two will remain separate versions of the game, much like the educational version TeacherGaming works on!
×
×
  • Create New...