Jump to content

  • Developer Articles

    HarvesteR
    Hi,

    It’s time we talk about THE FUTURE. I don’t mean hoverboards and self-tying sneakers (2015, we’re counting on you), I mean the future of Kerbal Space Program.

    The next update will mark a big milestone for us at Squad, as it is the last update focused on Career Mode. After the next release, Kerbal Space Program will reach an internal milestone we call “Scope Complete”.

    Let me back up a little here and explain what Scope Complete means, it means KSP now has all the features we considered vital to be in the game that we designed so many years ago. It doesn’t mean the game has everything we want it to have, it means everything we considered necessary for it to be Kerbal Space Program exists, even if only in a minimal form.

    Scope completion means that every big system that the game needed is there, some closer to completion than others, of course, but they’re all there. So, what’s next then? This is the good news: After Scope Completion, development focus shifts towards completing those unfinished features, balancing and adding some smaller stuff. No more groundwork, no more laying down infrastructure. We’ve finished building the kitchen, it’s time for us to start cooking.

    As soon as the next update is released, KSP will enter a new phase of development, which for want of a better term, we’re calling ‘Beta’. Beta development is going to be a new stage for the project, and that also means our development workflow will change, and by consequence, this will have an effect on the releases. There shouldn’t be any huge frameworks that we have to build for months on end and still have to release with barely more than enough content to showcase the system.

    Beta means we’ll be focusing on creating content, on using the tools we’ve built. It means a different approach to selecting which features go in, since we won’t be constrained by the development constraints of one feature requiring another. Priorities should level out, which means the things we consider important should also match what everyone considers important. Beta essentially means we’ll be working a lot more on stability, usability, performance, balance, aesthetics, all the while still throwing in little and some not-so-little things we hope you will enjoy.

    To make this clear to everyone (even those who don't read this post), we’ve decided to not call the next release version 0.26, as convention would have it. Instead once the update is out, we’ll be officially in Beta, so we’re calling the next release version 0.90.0 (zero-ninety-zero).

    There’s a ton of things we’re constantly discussing internally regarding what exactly we’ll add during Beta, but I figure we should at least tell you about the first two things we really want to add to the game before we can call it anything close to ready:

    Overhauled Aerodynamics - The current system has been fantastic at… existing, really. It can’t be beat at ‘being a system that exists and works within KSP’, but we can do better. We’ve been a long time planning a major overhaul to make it more realistic, reliable, predictable, and hopefully a lot less arcane.

    Deep Space Refueling - We’re aware there is one big end-game mechanic missing in the game: Being able to refuel a vessel once you’re out in Space. This is what we originally set out to achieve with the old Resource Mining plan and saw ourselves running into a very tedious dead-end. The Resources system was flawed because it overcomplicated accomplishing a basic need: To be able to find something out in space which can be used to fill up the tanks again. That’s the essence of it, and we don’t need 40+ single-purpose parts and 9 different resources to do it. In fact, all that complexity was going to be very effective at making sure most attempts to build a refueling outpost would fail. We are now planning a new, more elegant system, which hopefully will add a new, fun element of gameplay, as well as the massive boost to continuity this feature implies.


    Here is also a (not so) small FAQ with some answers we imagine you’ll probably be wanting to ask about:


    Q: You’re not pulling the plug on KSP, are you?
    A: Of course not! We still have a long way to go. We just want to let everyone know we’re going to reach a new stage of development soon.

    Q: I won’t consider KSP complete until Feature X is implemented!
    A: That’s not a question. However, if you asked everyone which features they would like to see in KSP, you’d get different answers from just about everybody. We all have our wishlist of ideas and features we’d like to see, us devs included. The fact is, we must be very level-headed here with what we want to do, and what we can in fact achieve in the time we have. That’s not to say of course, we aren’t planning to tackle the biggests requests from our community. Just remember that all features are judged in a big-picture perspective, and how it affects the game experience for everyone, and sometimes even what would seem like fun ideas are going to fall outside the scope of the game, or just be plain too much to take on. Time and Manpower are our main limiting resources now, and those must be spent wisely, pursuing the goals that will add the most enjoyment for everyone.

    Q: What about the features you “promised” on the Wiki’s Planned Feature List?
    A: That list is maintained by the community, and doesn’t imply any promise on our part. In fact, the best thing to do about that list is disregard it. We did implement a significant portion of it, in any case, but let me go ahead and quote the very first lines on that page:





    Q: Can you give us an official list of planned features for 1.0 then?
    A: Not without a time machine. Seriously though, any lists we publish can only result in leaving people disappointed. The problem here is that no amount of disclaimers and notices will keep everyone from taking every feature on a list as a commitment from us. We don’t want to commit to anything we’re not sure about ourselves, so if we do have to leave something out, we should be the only ones to be disappointed. It’s not great, we know, but it’s for the best.

    Q: Are you going to make KSP more realistic?
    A: That depends. Does that added realism make KSP more fun? The key point to keep in mind here is that KSP is a game first, a simulator second. We want to add realism in places where we feel those additions will make the game more enjoyable, but we aren’t just going to add realism features just for the sake of being realistic.

    Q: How long until 1.0 now, then?
    A: That’s a very good question, but I’m afraid it’s kind of the same as asking ‘when is the next release coming?’. We can’t give you a release date, because chances are high we’ll end up changing it afterwards. Knowing in advance will only lead to disappointment.

    Q: And after 1.0 comes out, is that the end?
    A: Nope. There’s still going to be a lot to be done even after that, but when we hit 1.0, KSP will be coming out of Early Access. Our main focus during the Beta phase will be to improve the overall playing experience of the game as much as possible. Once we’re outside the Early Access umbrella, KSP will have to stand on its own as-is, and not rely on upcoming features and perceived potential affecting players’ opinions. That’s not to say we rely on that now (or have ever), but that’s an unavoidable side-effect of being in Early Access. People will fill in the gaps with imagined features, and no real addition can hope to live up to everyone’s hopes and expectations. We can only try our best to have a solid game when release time comes.

    Q: What’s coming after 1.0 then?
    A: Now we’re getting way ahead of ourselves. Let’s wind this back to the near future.

    Q: What about Multiplayer?
    A: Multiplayer is something we’ve been working on for quite a while, but it still has a long way to go before it’s ready. MP is planned for after 1.0. So that’s still coming, but let’s take this one step at a time.

    Q: Does the term Beta really apply here?
    A: Not in the strictest sense, but then again, there isn’t a term that would better describe what we are planning. Beta is the period in software development when all planned capabilities are implemented, and dev focus is centered on polish and bugfixing. Yes, we do that already in experimentals, but we’re going to be doing it in a wider scope during Beta phase. For an update’s QA and Experimental periods, testing is focused mostly on the new features being added. Beta means taking a step back, and seeing all areas of the game under equal focus for testing and improvement. We know there are several bugs we haven’t fixed yet. This is the time to make those fixes and assure the game is working as well as possible. The term Beta is definitely fitting here.

    Q: Does that mean we’re going to have access to Experimental releases?
    A: No. We’re still going to go through the same branch-testing->QA->Experimentals system as we have always done. I’m just saying we’re going to work on the game under a wider perspective, more focused on the overall experience than on any single feature. This could translate to more ‘diversified’ changelogs on each release.

    Q: Are ‘Beta’ updates going to be released quicker?
    A: We hope so, but we can’t make any promises. We have tried shortening updates once before, and became aware of how the QA and experimental phases don’t really scale in proportion to the shorter update, so the result was that we spent more time testing, and less time developing, which needless to say, wasn’t very efficient. We’ll have to find our stride again for Beta, just as we did during Alpha.

    Q: Are updates going to be released in a regular interval?
    A: Most likely not. Imposing such a strict process on us would either cause features to be rushed to make a release, or some releases having very few features on them. Probably both. The plan is to play it by ear, and do a release when we feel we have something worth releasing.

    Q: I’m still concerned this means you’re going to abandon KSP.
    A: We know, and this is why we’re doing this announcement now. We want to give everyone as much early notice as possible about what’s coming up, so nobody runs into any surprises. We’re not even in Beta yet actually. There’s still the next update to go, and after that, a period of Beta updates until 1.0, and even after that, we still have more stuff planned. So worry not, we’re going to be at it for quite a while.

    Q: Are you going to add more whatever-it-is-you-want-added?
    A: We want to add as much content as we can during Beta, but time is the main limiting factor, and development manpower is finite. We’ll have to make choices through the Beta period about what we want to add, against how much time and effort that will take, compared to adding something else instead in the same span of time. As always, we’ll be weighing the gains of adding some piece of content versus another, and choosing the ones we feel will have the best effect in improving the game overall.

    Of course, some areas are obviously short on content at the moment (Contracts and Biomes come to mind). Those are going to be highest on our lists as they’re the least developed sets of content at the moment. The logic behind reaching for Feature-Completion and 1.0 is very similar to the logic we used to reach for Scope Completion. We focus on the area of least development. The good news now is that the area of least development is always going to be something we already have in the game, and the lack of content there is likely noticed by everyone already.

    Q: Are you going to integrate “Mod X” into the game? (a.k.a. Q:How can I get my mod integrated into stock?)
    A: This depends on several factors. First of all, we have to ask ourselves: Is this mod doing something we wanted to do ourselves already? Some mods, awesome though they are, aren’t part of what we have planned for KSP, and that’s fine. That’s why we support modding in the first place, but it also means a mod isn’t going to be auto-added just because it’s cool.
    Second of all, if we do find a mod that does exactly what we wanted to do ourselves, and it’s done well, follows the style of the game, all that stuff, then we get in touch with the author, and we get the conversation rolling from there. There isn’t a system for adding a mod into the game. That said, we very well might find mods that do stuff we wanted to do, and we wouldn’t want to reinvent the wheel if we can avoid it.

    A: Being in version 0.25 now, don’t you have 75 updates left to do before 1.0?
    Q: Eek, no! Thankfully, version numbers don’t work that way. The minor version (as the ‘n’ in v0.n.0 is called), isn’t a decimal fraction of the major version. There isn’t a pre-established convention in the software industry on how to increment version numbers, so each studio tends to do it in their own way. We’ve been relatively consistent with our versioning scheme, adding 1 to the minor version on each new update, and a 1 to the revision number when we release hotfixes and small patches. So the answer here is, there won’t be 75 updates between 0.25 and 1.0 in the same way we don’t have to release 10 revisions to go from 0.24.0 to 0.25.0.

    A: How is ‘release 26’ going to be identified as Beta then?
    Q: We’re going to call our first Beta version KSP v0.90.0 (zero-ninety-zero, or oh-ninety-oh if you live across the pond), to make it clear to everyone that KSP is nearing a state of completion. Of course, that doesn’t mean we plan to do exactly 10 Beta patches to reach 1.0. It could be more, it could be less, we can’t tell. If we run past 0.99. the next version could be 0.100.0, or we could change the system a bit, and increment the revision numbers instead, depending on how much we feel a release has added. In a way, Beta updates really are more like revision patches actually. We’ll keep announcing new releases as we have always done in any case, so just hang around the community and you’ll never miss a release.


    We want to thank you from the bottom of our heart for supporting our crazy project all the way from the earliest alphas builds up to Scope Completion, and we hope you’ll stick with us from here through Beta and up to the long-awaited 1.0


    Many Cheers,


    The KSP Development Team, and everyone at Squad.
    Maxmaps
    Hey guys! It’s that time again, here with the general plan for 0.90

    But before that, let's talk about the 0.25 plan. As I explained in the previous version, we were showing you what we were trying to get into the game, I am happy to say we succeeded in most of this except for these two things. Call this a mea culpa. Or the best laid plans of Max and men.


    Kerbal Experience - We got the coding done on this part, the system is functional, Kerbals can log where they go and all that… but we found the aspect of having to pay Kerbals per mission turned them from enthusiastic volunteers to mercenaries. Thus we decided to sit on the feature til we came up with a better approach. MK3 Overhaul - We got the models done! We got most of the code done… but the scale of the overhaul didn’t feel right. Going up a tier should feel like a sufficiently large upgrade, and as such it should have more options open up for you. Being as Porkjet was fantastic about adapting SP+, we figured we could go even further next time around.


    However - we have a general plan to stick to, features to deliver on and motivational whipping sessions to hand out, so let’s talk about what’s coming in update 0.90!

    Editor overhaul - Boy has this one been a long time coming. We’re improving part sorting, adding 3d widgets to make building way easier and overall make it a more pleasant, reliable experience. No more fiddling to get things to fit! Kerbal Experience - We’re using the created experience tracking system to give Kerbals traits. These traits will level up as they partake in missions and accomplish goals, increasing the unique passive bonuses each Kerbal will be generated with. Extra Contracts - We’re adding a couple new contract types. We’re also integrating the related mod ‘Fine Print’ to stock. S’really good. Biomes Everywhere - Revising all of the old ones and adding new ones to every single planet and moon. MK3 Overhaul - We’re going to be working with Porkjet to get as much of this as we can for 25. The general scope for this one dwarfs the content in SP+, so we hope you can understand this one will take time. Attempts to clone Porkjet have so far been unsuccessful. Upgradable buildings - The last big feature missing from career mode and the reason why our art team has been chained to their desks for months now. Every building is getting a tech progression path which will slowly unlock all of their current capacities and some new ones. Take your space center from an amateur project to a world class space center.

    Rowsdower
    Kerbal Space Program, the award-winning, indie space agency sim game from Squad, released its latest update, Economic Boom, and it is available to play today. Updates are free to existing players. KSP: Economic Boom offer new players the most fully-realized version of the game, which is still in active development for PC, Mac and Linux as an Early Access title on Steam and via the game’s website.

    Players will experience a new challenge as the Kerbal Space Center, where players build and launch their rocketships, is now fully destructible. Buildings can be decimated by poorly-steered rocketships and in the game’s Career Mode, require costly repairs for players trying to manage their space agency.

    Among these buildings is the new Administration Facility, in which players can select and activate Strategies. The Strategy system is a new gameplay mechanic, where each strategy, once accepted, applies effects over several game aspects, specifically Kerbal Space Program’s three in-game currencies, Funds, Reputation and Science. Some examples include:


    Aggressive Negotiations: Enables players to get a discount on the cost of parts but at a cost to Reputation on each ‘discount’ Open-Sourced Technologies: Divert Science earnings to make them public domain, increasing Reputation. Unpaid Intership Program: Boost your Science earnings without spending any Funds by hiring unpaid interns to do the data crunching. Working for the Space Program surely is its own reward, isn’t it? Well, as long as an agency’s Reputation lasts that is.


    “Career Mode is getting a significant addition with the Administration Building and all that comes with it,†Felipe Falanghe, Kerbal Space Program creator and lead developer said. “The Strategy system gives players great freedom to change the rules around, and ultimately it allows them to tune the game to fit their own ways of playing. Also, as it’s fully moddable and new strategies can easily be added, this new feature has a lot of potential for expansion.â€Â

    The team also worked with modder, Christopher “PorkJet†Thuersam, to incorporate his popular SpacePlane+ parts pack mod to the game. This was more than a simple addition however: Each part was updated for even better looks, and to offer players parts that are there not just specifically for spaceplanes, but that can be used in as many combinations as possible.

    The game is now available for 40% off on STEAM and from the KSP STORE.
    Rowsdower
    What is KSP: Economic Boom?
    This is a new update to Kerbal Space Program, also numbered 0.25, as each update to the game has a number attached to it. It is free for existing players and new players will install this version when they download the game. It focuses on expanding the reach of career mode, as well as enhancing existing features, like spaceplane parts, visual effects, plus the usual batch of bugfixes and improvements. Check out the full changelog which always accompanies the release for a complete list of changes.

    When is it coming out?
    Update 0.25 will be available the 7th of October, 2014

    This update came out really fast. It's not a dream, is it?
    We’ve taken on a new direction in the way our development schedule runs. It allows us to plan and implement a smaller set of features that we can deliver to you without some of the wider update gaps we’ve released things under in the past.

    What are the main new features in Update 0.25?
    New spaceplane parts, the administration building with the strategies contained within, and an in-depth difficulty settings panel that will let you customize your gameplay experience. There is also the matter of destructible buildings at the KSC, which is a smaller (though much more visible) feature in this update that lays the groundwork for something coming in 0.26.

    What are some of the smaller new features in Update 0.25?
    An enhanced navball, a key binding for maxing out your throttle immediately, a button to return you to the space center much like the Recover Vessel one, also on the altimeter, a function to turn off surface attaching on a part to help with the brand new cargo bays, vessel markers at KSC, destructible buildings, just to mention a few.

    Have any old features been tweaked?
    We’ve added in the ability to toggle surface attachment for parts by the way of pressing the modifier key (Alt for Windows). Construction also got a small tweak. Spaceplanes are way cooler now. The navball is highly functional. We even fixed a couple terrain textures. There’s a ton of small scale fixes.

    What bugs were fixed in Update 0.25?
    We’ve had a bunch of good ol’ bugfixes and tweaks for Economic Boom. Nothing too massive, other than the OSX mouse input issue, but definitely much needed ones. The changelog in the readme.txt should have all the juicy details.

    Will this update break my saves?
    On the tests conducted on the stock version of 0.25, saves were not broken. We do not intend to push an update that will break saves, but due to the sometimes unpredictable nature of an update push, combined with other factors, there’s always a small risk involved. If there are any problems, check out the support forums for help, or report them to the bug tracker right away and we will have a look at the issue. Please keep in mind that modded installs are much more likely to stop working. We recommend starting off with a clean install and add mods gradually so you can spot if one isn’t working.

    Is the 64 bit Windows build any more stable than from 0.24?
    Ted: The 64-bit Windows build suffered some significant stability issues with 0.25. However, after a lot of debugging, issue tracking and all around hard work by the developers and testers, we've implemented some hopeful fixes for the issues that were presenting themselves. Despite this though, it should be noted that the 0.25 64-bit Windows build is still inherently unstable and may be prone to crashing - even stock. These issues are unfortunately beyond our reach to fix, but please let us know if you find any useful test cases or workarounds, as those can possibly lead to fixes either from us or from Unity.

    Why are the parts on my craft misaligned? Why does my craft look screwed up? Is this fixable? Will I have to redo my craft?
    Because we’ve removed a bunch of the old Spaceplane parts and replaced them with shiny new Spaceplane+ parts, the game will be loading in the new Spaceplane+ parts in place of the older ones. The reason for these offsets is that the new parts aren’t the same dimensions as the old ones. But no fear! For vessels that you’ve still got in the SPH/VAB and aren’t rolled out yet, you can simply pick up the offset parts and place it back down to correct the misalignment. For existing vessels, that vessel will have the offset on the parts and you won’t be able to change that - outside of going into the persistence file and manually editing the connections. We recommend recovering all vessels that contain spaceplane parts before the update.

    What’s this about a shrunken SAS?
    Using the most advanced methods of editing part configs, we’ve changed the Inline Reaction Wheel to be a 0.625m size part. The SAS values have also been adjusted with this in mind, so it’s not as powerful as it once was. After all the revisions to the SAS system, the old Inline Reaction Wheel became redundant with the Advanced Reaction Wheel module, so we decided to repurpose it as a size 0 module, which didn’t exist.

    What happened to the MK3 parts that were mentioned a while back?
    After spending some time with them in QA, we decided that they weren’t ready for public consumption and didn’t reflect what we actually want the Mk3 parts to function as. Needless to say, they shall make a return and the old Mk3 parts still remain for the time being.

    For that matter, what happened to Kerbal experience?
    Kerbal experience is planned for 0.26. We decided to hold off on our original design, and we’re very glad we did. More on that later.

    Why is my game no longer set to 1080p? Why can't I switch back?
    If your resolution and textures got reset after applying the update and you cannot get them back to how they were, that means your settings.cfg file got reset. You will need to redo every setting you had before the update, including custom keybindings. While this does not appear to be a common issue, we will be looking into it further.

    Why the big fuss over destructible buildings?
    They fit the aesthetics and theme of KSP, were fun to make and in reality are just a bonus from a big feature coming in 0.26. Ted also has a shorter reason: Because they're Destructible. Freaking. Buildings.

    What’s this long term plan we’ve been hearing about and what does it have to do with the buildings?
    We’re not quite ready to unveil this one but pay attention to the devblog because once we are ready, we’ll unload all the gory details there.

    How’d the idea for destructible buildings come up and how long did it take to implement?
    Destructible buildings have been in the roadmap since just about the beginning. Changing our effects system and adding the new building-centric system just gave us the perfect opportunity to put them in. In the process of implementing them, we also created several very useful tools that will be very handy to add other features. For instance, the new KSC vessel markers share the same base implementation we wrote originally for the context menus to let you repair the destroyed facilities.

    What does having destructible buildings add to the gameplay?
    A harsh punishment for reckless flying near KSC. Breaking one of your buildings could possibly end your career right there. Also, fun to blow up in Sandbox.

    Why was destructible buildings implemented over new biomes, planets or other community requests?
    As explained before, adding them wasn’t precisely hard or time consuming once we got the new systems in. Their being there is really just the visible side of a much larger revision of the KSC and Kerbin setup, plus the addition of new sound and particle effects. Adding support for destructible facilities was the best way to implement all these new things, and didn’t require us to go silent for several months on a large part of development.

    How does the admin building work?
    You go in and enact strategies, which cost a certain amount of your currencies to be turned on. Provided, of course, you can afford them. Also, to get to the highest levels of commitment for a strategy, your reputation must be above a minimum level.

    What are strategies?
    In RPG-speak, they’re passive buffs and nerfs to different parts of your space program. They affect simple things, like contract payouts and currency interactions, or more complex ones like improving the recovery factor for vessels recovered away from KSC.

    I know that I can earn resources, but are there any costs involved? Any penalties?
    There’s a cost for setting up the strategy, a minimum reputation level for each level of commitment, and all strategies also have penalty factors. No freebies here.

    How tricky will it be to employ these strategies in order to get the resources I want?
    The stronger your commitment to the strategy, the higher the payoff, and usually the lower the penalties. However, setup costs increase very steeply, and you’ll need plenty of reputation to max out commitment levels. Careful planning is advised, welcomed and expected.

    How balanced are these strategies?
    Strategies are balanced against themselves. That is, in order to gain something you must lose something else, like increased Launch Costs for increased Recovery Gains, or a reputation hit for a discount in launch costs, but really, the purpose of Strategies is to make the overall balance of the game more flexible. You should be able to find a system which maximizes results for your style of playing, or set yourself up with huge challenges to break out of your comfort zone.

    How moddable are the strategies?
    Like almost all of KSP, the strategies are highly moddable. Have fun!

    What’s Spaceplane+?
    It’s a particularly excellent pack of parts that many players have put to good use to augment and enhance their plane-making experience. The modder, Porkjet, does remarkable work.

    Why has this mod been implemented into stock KSP?
    We thought Porkjet did a great job creating the parts so it made sense to ask him to work with us on implementing his parts into the game as a stock feature. He was great to work with and we think it will be pretty clear for those who haven’t used his mod, what a massive addition this is to our parts.

    Do you have the permission of the mod author to do this?
    Yes. We worked with Porkjet to make this happen. He’s been a great partner to Squad during this process and we’re really pleased we could work with him in this fashion.

    Was any work done to better implement Spaceplane+ into the game or did you just do a 1:1 mod port?
    Most of the parts in SP+ were improved from the original mod. Porkjet is really passionate about his work, and made a point of delivering top-quality assets for us. We were not disappinted. The new Mk2 fuselage sections are incredibly versatile, and well, the improved visuals speak for themselves.

    Are there any other new parts in the game?
    Other than the superbly styled and detailed SP+ parts from Porkjet, we’ve also revised the mk1 fuselages and cockpit to fit the KSP style and tweaked the balance on several parts for improved consistency.

    IVAs?
    The cockpits that belonged to the SP+ part pack have brought with them their own IVA views and they’re mighty fine looking. The Mk2 cockpits have a spectacular IVA space, which was adapted to not have any mod dependencies..

    What will happen to the old parts?
    Parts that have direct equivalents in Spaceplane+ have been removed with the ones from Spaceplane+ taking their place. The old Spaceplane parts that don’t have equivalent parts in Spaceplane+ remain. There's a possibility that we may one day collect all our old parts into a Legacy Pack and release it as a mod, but that isn’t certain at the moment and definitely shouldn’t be expected before we complete all the part revisions we have planned.

    Is there any indicator that marks the difference between new parts and legacy parts?
    No, but it should be easy to tell just by looking at them.

    Tell us all about the new navball markers.
    Additional to the vectors you could already see on the NavBall you will now see the radial and normal vectors as well, if you are familiar with maneuver nodes you already know them, if not, the normal and antinormal (the pink ones) are perpendicular to your orbital plane, in the positive and negative direction respectively. The radial ones (blue-ish) point directly towards and away from the current reference celestial body. For more information about the effects each has we recommend you redo the tutorials, as they’ve been updated to include this information.

    In addition to the radial and normal vectors, now there’s also an arrow indicating the general direction of the maneuver marker on the NavBall when you are using one, so no more looking around like crazy looking for it, now you will know exactly where to point.

    Why did you make new navball improvements instead of implementing enhanced navball, similar to what you did with Spaceplane+?
    The way we implemented the NavBall markers is not exactly the same as the Enhanced NavBall mod from a gameplay point of view. That’s not the case for Spaceplane+, which was exactly what we were looking for out of the box.

    How were the explosion FX redone?
    One of the best things about Unity is that there is no shortage of add-on packages to be found.
    Instead of reinventing the wheel, we searched for the best FX packages out there and put together a stunning collection of blasts, thumps, thuds, sparks, flares and fire, plus a vast collection of new sound effects. Then we set out to modify them to work in the absurd coordinate spaces of KSP (did you know the Space Center is sideways? Kerbin is aligned north-side up, and KSC is at the equator, so it’s rotated 90°).

    Were any other new or redone FX put in?
    Indeed. After we had these new explosions done, it would have been wasteful to only use them for destructible buildings. We replaced pretty much all of the old explosion effects from parts, for much more impressive, loud and violent displays of rocketry going wrong.

    Why just those instead of X feature?
    Couldn’t that be asked of anything? There are tons of ideas, but our development resources are very much finite. That means we always have to make choices when we set out the plan for a new update and these features not only fell nicely in line with our longer-term goals, they also provided nice achievable steps to implement larger subsystems that will support other features on the following updates. Sometimes the logic behind these choices may not be immediately apparent, especially when you consider that every player has their own unique wishlist of features, sometimes pulling in completely opposite directions. Not only that, but also consider that we strive to improve the game not just for veteran players, but also for players who will have their first encounter with KSP on this version.

    How many new difficulty options are there?
    There are four levels of difficulty - Easy, Normal, Moderate and Hard. We also have a Custom mode that lets you dig in deeper and modify each difficulty parameter on its own. Our goal is to offer as much freedom for players as possible, to make the game easier, or to set up nearly impossible challenges for themselves.

    Can I mix and match the new options?
    In Custom difficulty mode you absolutely can! Some of the variables can be toggled, such as permadeath for your Kerbal buddies. Others are percentages that you can use a slider to tweak, such as Reputation income.

    Can I have different options with each save?
    Yep! On creation, each save has the ability to be created with its own set of difficulty option values.

    Are there recommended easy or hard settings?
    We recommend you choose the difficulty level you like best. We do not recommend taking the advice of others about what the recommended difficulty to play at. If it’s fun, then it’s right.

    What are those markers all over the KSC?
    Once a vessel is safely landed (or splashed) reasonably close to KSC, A marker in the Space Center scene will appear at its position, this will give you information about the vessel and shortcuts to either resume flight or end it.

    Wait, what markers all over the KSC?
    Once you go on at least one successful mission and return home safely you will see what we’re talking about.

    How does an internal crew transfer work?
    Mouse over the crew hatch of a crewable part, once you see the Crew Hatch label left click to bring up the Crew Hatch Dialog, in there you will see the part’s crew, with options to EVA or transfer, once you are in transfer mode, click any other crewable part with at least one available seat et voila (or press Esc to cancel).

    Will I be able to transfer a Kerbal through anything? Squeeze it through a tiny grate?
    Yes, a Kerbal can go from crewable part A to crewable part B, no matter what comes in between. Just how the Kerbal managed to get to part B is open to interpretation.

    Any hints as to what might be in store for 0.26?
    Good question. There have been a few hints already if you’ve been reading carefully this far, but that’s all we have to share at the moment. Stay tuned for new announcements soon though.
    KasperVld
    Kerbal Space Program: Economic Boom Gameplay Videos are Here!

    Check out your favorite KSP Youtubers as they get their hands on the pre-release version of KSP version 0.25, also known as Economic Boom. Want to know what's new? Does the update contain enough excitement to fuel a hype train? Watch the videos and let them show you what the KSP: Economic Boom is all about.

    KSP-TV will be streaming 0.25!
    Looking for a more interactive experience? KSP-TV will be streaming version 0.25 from the moment this article is live until exhaustion gets the better of them. [thread=84562]Check out the schedule[/thread] to see when your favourite KSP streamer takes the wheel, or head to the KSP-TV channel directly!







    Rowsdower

    BOOM!

    By Rowsdower, in Developer Articles,

    Do you like explosions? Sure, we all do! You may enjoy THIS example of 0.25's new, glorious explosion fx. You may also enjoy the big secret that will be revealed on next week's EPISODE...


    Ted
    Making a video game can lead to a fair number of misconceptions and misunderstandings for those who aren’t working on the team, especially when it gets close to an update’s launch and it’s the Testing department's time to shine. So I wanted to have a go at letting everybody know exactly what our department does and what we're about!

    First things first, let’s take a look at what the QA team is:

    The QA team – Quality is none of our middle names, it would be a terrible middle name.
    Comprised of around a dozen seasoned players that know their way around KSP like the back of their hand, the QA team is arguably the most passionate of KSP’s community. Many of our team have worked professionally in software development, so they know the in’s and out’s of general development cycles and those that haven’t have picked it up very quickly! The QA team was created more than a year ago after 0.18 to accommodate the increased rate at which content was being developed and the scale of the game’s growth. Since then, it’s undergone minor personnel changes, but for the most part has had a core handful of members that have remained.


    Now, let’s go through what the QA team does:

    QA – Assuring Quality through Quality Assurance
    Those familiar with game development, or perhaps games in general, will know the essence of QA is bug hunting, documenting found bugs and assisting Developers in fixing them. It’s the most bare bone part of the entire process and is performed by a handful of us QA testers pretty much constantly, thanks to the Branch System.

    Given such a comparatively small, volunteer team, QA is very much about efficiency and focus, with mostly test cases being used instead of a general playtesting method. What this means is that instead of going through the motions of the game as a normal player would, we tend to identify areas of the new content that would usually be prone to issue and hunt for bugs there. This method cuts down the time taken to find issues by a significant margin and correspondingly means that the content is tested more evenly – playtesting can sometimes skip completely past some aspects of a feature.
    Furthermore, this method allows us to work closely with the developers and compare exactly what they intended to occur for specific cases, to what actually occurs – this is where QA becomes more about feedback.




    An example of a Feedback Report.
    Minor but specific feedback that is to only an exact area of a feature.


    When we talk about feedback, it’s actually quite a loose term to use. It can range from the type of feedback players, such as you reading this now, provide us with, such as comments on the forums about KSP to the developed suggestions we receive either via e-mail or on the many other KSP Communities out there. So, when it comes to QA, we use the term feedback in a very narrow scope. It means providing specific recommendations and improvements to certain areas of a feature. As we rarely do general feedback in the form of a forum thread for an update in QA, we use the Redmine Issue Tracking system to log all our feedback. In QA, there is little use in us telling the feature’s developer it could be a bit more ‘flashy’ or ‘eye-catching’, what we both require is an established dynamic of improvement via recommending a certain component be changed in size or color, and suggesting the size or color to change it to. With this explained, one can see QA is a lot more than just finding bugs. It’s about having the knowledge of the game (especially how it works under-the-hood), the comprehension of the ideas behind the features in the game, the understanding of what a Developer wants the feature to turn out like and how you can assist them in making it happen. Furthermore, it’s about condensing all of that into concise and objectively written issue reports.
    Though that doesn’t mean we don’t come across our fair share of game-breaking and eye-widening bugs. These buggers can be quite the kicker when you’re striding through an otherwise uneventful set of features. However, we’ve all encountered more than enough of these types of bugs to be able to jump right into the method of establishing the necessary information for an ideal bug report.
    Such a method involves doing many of the following:
    Making any relevant notes before doing anything else. Noting down what exactly has occurred prior to the issue becoming present is invaluable; it’s the sort of detail that is easy to forget when it comes to later steps.

    Quickly making a copy of the relevant logs (usually KSP.log and output_log/player.log). If relevant to persistence, or the likelihood of being in the same situation is rare in the near future, or the current situation is difficult to get into; making a copy of the persistence file, quicksave file and/or the craft file. Inspecting the relevant logs for any errors or warnings that were written to it. Narrowing down a potential cause using the above information. Determining reproduction steps. Finally, minimizing the mass of information collected about the issue into a neat and brief issue.

    While this seems like a lot to do, it quickly becomes a routine when encountering an issue and is very much second-nature. Of course, not all of the above is carried out for each issue encountered. It depends greatly on the severity and nature of the issue encountered.
    All of this keeps us working quickly through features, branches and issues, with builds often flying out of the build server many times a day. And at the end of QA, we have a build that can be played without encountering major issues, is feature-complete and ready to be given a thorough inspection and play test by the Experimental Team.

    So, all in all, that’s what the QA Team does during an average QA phase. Onward to the Experimental Team!


    Experimental Team – More than just a Team that Experiments.
    The Experimental Team is comprised of, on average, 50-60 active testers. All of these testers are volunteers who contribute their spare time to playtest KSP. Prior to version 0.15, the Experimental Team didn’t exist. However, with the increasing size of the KSP player base and the game itself, open testing was no longer a viable option for efficient and spot-on bug reporting and issue tracking. Thus the Experimental Team was created.
    The Experimental Testers are normal KSP players, sourced from the various KSP communities via a simple application process. Often and understandably, they don’t have as much spare time to devote to testing as the QA Testers and thus we have significantly more Experimental Testers ‘signed up’ than we need at any one time. This works in everyone’s favour as it keeps the activity level throughout an Experimental Phase and doesn’t put pressure on the testers while they also deal with their personal and professional lives.

    What is the Experimental Team responsible for, then?


    Experimental Testing – Are we Experimentally Testing or Testing Experimentals?
    At its core, Experimental Testing is much like using a focus group to ‘test the water’ on an update. Of course, there is far more depth to Experimental Testing than just using the Team as a focus group, but we’ll touch upon that later. For now, it’s best to discuss how significant and useful the Experimental Team is in this part of the testing process.
    After we have an update go through QA, as detailed above, it is hopefully free from major issues and each feature has had any needed major improvements and refinements carried out; we’re at a feature-complete state. However, many components of a feature may still be unpolished, such as part balancing, or the performance of newer UI on different platforms (eg high-resolution screens). Here is where Experimental Testing comes in and assists us in cleaning up the remaining minor feedback issues. In game development, it’s a mammoth task to try to account for all edge cases and different types of hardware, but with the Experimental Team as diverse as it is, it makes it a whole lot easier to approach this task and dissect it into manageable parts.




    A typical high priority issue that can be seen in Experimentals.
    Some may recognise this issue as being one of the examples in the KSP Tester applications.

    Moving on, while the Experimental Team is incredibly useful in providing minor and focused feedback, it really shines when we arrive at general feedback for an update. Essentially, each Experimental Tester provides their opinion in a feedback thread and they go into as much detail as they feel necessary. Here, the size of the Experimental Team becomes its strength, we can get a feel for how the Community may react to certain components of an update. We can also gauge what minor changes are needed to improve players’ perception of a feature in some areas. Furthermore, this area of feedback really illustrates whether some difficulty in use of features are more widespread than others and we see what misconceptions about gameplay mechanics exist.
    As I mentioned earlier, feature-lock is pretty much in place for Experimental Testing, so this feedback often works with that in mind, with a lot of the changes that come out of it being minor, with as big of an effect as is possible.

    An Experimental Testing phase typically lasts around a week, though it is highly dependent on the number of issues that arise and how much further development is required to reach a release state. At the end of the Experimental phase, there are still a fair amount of issues on the tracker that are still open, but it’s important to note that these issues are always minor ones, ones that aren’t in the scope of the update or simply issues that would take too much time and resources to resolve – the latter is more often than not for feedback issues, as opposed to bugs. The overall aim of the Experimental Testing period is to produce an update that is balanced, playable, can stand the test of time and performs well on a wide of a range of systems as possible.

    That about concludes this Dev Article, though I’ll be writing up more in the future that cover the other various aspects and components of testing. Feel free to ask any questions you have in the comments, I’ll be sure to read and reply to them.
×
×
  • Create New...