• Developer Articles


    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.

    Maxmaps

    The 0.25 Plan

    By Maxmaps, in Developer Articles,

    Hey guys. It’s time we show you our grand plan for update 0.25.

    Now, we want to make something crystal clear before we carry on. This is a plan, and to borrow a quote from military history; No plan survives contact with the enemy. The enemy here aren't mongol hordes, chichimeca raiders or Ghandi’s nuclear missiles (Civ 5 bitterness aside). The enemy are bugs. The enemy are features ending up not as cool or fun as they were on paper. Or art assets more complex than drafted or code conflicts. Thus, we have to adapt. Maybe a feature is cut, or a new one pops up. Or the plan for something goes into a radically different direction.

    I’ll give you a small example. The game mechanics planned for the Admin Facility in were originally far simpler (somewhat similar to the Market from Age of Empires) and not very interesting overall. We redesigned them into a proper gameplay-enhancing set of mechanics that we are confident will be much more interesting than what we had before, which wasn’t much more than a UI to convert one currency into another. The bottom line is, things change, so please don’t take this list as is and understand that our ideas are likely to continue evolving. This list here has merely our current goals at the time of this post.

    So, without further ado, here’s the (current) plan:

    Administration Building
    A new facility at KSC which will allow you to choose from a set of Strategies to boost certain areas of your space program, usually at the expense of some other area. Start an Unpaid Internship Program to increase your Science gains at the cost of Reputation, or take up an Open Source Technologies Initiative to boost your Reputation gains at the cost of decreased Science rewards. All these combinations will be possible using Strategies, along with many more. Also, Strategies are fully mod-enabled and new ones can be added very easily. Just keep in mind, however, you can only take up a limited amount of strategies at a time, so choose wisely.

    New effects
    We’ve done a huge overhaul on particle and sound fx. We’ve got much better-looking and better-sounding explosions and rocket effects coming.

    Spaceplane Part Overhaul
    We are adding several new parts, along with the integration of fan-favorite mod Spaceplane Plus.

    Accessibility improvements
    More markers on your navball and a pointer to where your node is?A way to transfer Kerbals without them leaving their craft? A button to push your thrust all the way to 100%? We’re adding all that.

    Kerbal Experience
    Recovering Kerbals will now reward your reputation based on where they’ve been (and what they’ve done there), and their accomplishments will be stored in persistent ‘career’ logs for each crewmember.

    Difficulty panel
    We’re setting up a much needed Difficulty Options panel, to allow you to set up the game to your liking. Does reverting flights make everything too easy? Try disabling that to see what playing with no room for error feels like. Are you constantly broke without cash to continue? Give yourself some extra boost off the start by increasing your starting Funds. The list of tweakable options goes on, but you get the idea.

    Classified
    You’ll have to wait for this one a bit longer. If we had our way, we would tell no one about it and just let you guys discover it through gameplay with hilarious results.

    So there you have it. That’s our grand plan for 0.25. We are doing our best to bring all this to you, and hope you will be understanding if it changes a little on the way.



    HarvesteR
    After the last upgrade to our build pipes, I realized that this is a side of the project that very few people get to see, and that seemed a shame, since it's taken a considerable amount of work to develop and put together, and I thought it could be an interesting thing to showcase.

    I put together this chart which shows what happens when we generate a new build of the game. Each supported platform is color-coded, and the file formats are represented by different line styles.:




    This entire process is automated, driven by two 'Jenkins' continuous integration systems on the two build servers. These allow us to set off builds very easily. We push commits up to the git repository, and the build servers pull the latest state of the game (on any branch) and take it from there.

    The whole process takes about two hours to complete for a full release deployment that is meant to go public. For QA or experimental builds, we skip as many steps as possible, and that time is reduced to about 30 minutes.

    This system has been evolving and being improved continuously whenever we find ourselves having to do repetitive work to get builds out. It's been growing and being upgraded for almost two years now.

    The more keen-eyed readers will probably have noticed that the pipeline is incomplete. There are a few channels that don't cover every platform. For instance, the patcher doesn't yet support win64, and there is no installer for Linux. The pipeline is an evolving thing, and we continue to add things to it whenever we get a chance, or necessity dictates.

    The latest addition was related to the 'big download server'. Previously, the transferring of build files from the main server up to the download server was done manually. This process was automated now, and both 0.24.1 and 0.24.2 releases have been done without us having to do the FTP uploading ourselves.

    Anyhow, this is our build pipeline. Hopefully you'll find it interesting. It's quite a step up from the early days, back in versions 0.8 or thereabouts, when all of this was done manually.

    Cheers

    HarvesteR
    Hi again,

    I'm sure most of you have noticed a mildly infuriating bug related to right-clicking parts after yesterday's patch... So did we. It was fortunately a simple fix, and we've got a hotfix patch available now.

    Here's the changelog:



    ============================ First Contract (v0.24.2)

    HOTFIX:

    * Fixed a critical issue which prevented opening the right-click menus for several parts.




    As always, the latest version is available on the download page at the KSPStore, or an automatic update will be headed your way if you're on Steam.

    Happy Launchings,

    Cheers

    Maxmaps
    Hey guys! I am happy to share some exciting news - at least for me, anyway. I'm now producer for Kerbal Space Program . You’re probably wondering what a producer does in a video game studio and
    does a great job at explaining the general idea of the position. Think of me as a hub for the team, where information will flow in and out and my job is to is to maximize (get it?) efficiency and make sure everything is working according to plan. And when it’s not, I’ll be integral in helping assure we adjust and make sure the entire team is comfortable with the changes.

    Plus, being a producer for KSP presents several unique opportunities, since you guys get to play the game while we’re making it. My background in PR means we can (responsibly!) up the level of transparency, show you more stuff we’re working on without putting unnecessary stress on the developers, and my ties to the community mean I have a constant stream of feedback from fans and modders that will enhance KSP on the way to the mythical 1.0. So expect to hear a lot from me in the future!

    You probably have some questions, and since I want to answer as many as I can and as visibly as possible, feel free to join me this Monday, July 28th over at http://www.reddit.com/r/games for an AMA at 1:00 PM EST.