Kerbal Space Program

Kerbals have explored their neighboring planets but they want more. They want to colonize the rest of Kerbin. They want to colonize other habitable planets, like Laythe. They want… to reach beyond Kerbol, beyond the orbits of Eeloo and Jool. They know their sun may not survive forever, but Kerbals must.

We have seen evidence of other life out there. The mysterious monoliths, arches, and a crashed flying saucer in the arctic. These wonders have made Kerbals aware there is more, and they want to explore it.

They will develop cryogenic pods to survive the long journeys to other star systems (this will require giving Kerbals a life expectancy as described in Feedback #18833).

To simplify the game and avoid all the complicated management of new buildings, their operation, and such, a single dome covered plot for a colony can be treated like one building, with four short tunnels coming out to provide places to land and enter on foot (they would have doors).

Tourists and Colonists would be delivered to the colony if they land on one of the four landing pads outside. Players would be able to land their ships near by and use rovers to approach these marked areas if need be. Once “stable” on a colony landing pad, any contract requirements to deliver tourists to the colony will be checked off. To move the colonists in, you would use the transfer crew feature and the colony dome would be a viable structure to transfer to but only when you are on the landing pad. To be specific, no part of your vessel should be outside the vertical boarders of this landing pad, so if the ship is too large, then a rover will be required. It can be the size of the helicopter pads on the roof of the VAB. If a Kerbal is on foot (EVA) then he would have to approach one of the tunnel doors and it would behave like a hatch on a ship only instead of “(B)oard”, the command would be “Enter (B)iome” or “(G)o inside” (the first is to keep the same letter ‘B’ as the command key to press). “(E)nter” wouldn’t work because ‘E’ is used to turn the Kerbal on EVA.

When the active Kerbal enters the Biodome, then the game pauses, and control switches over to the Biodome screen much like it would when entering the VAB. The first screen would look like a 3D map of the buildings where you can click one to enter and work on its functions, much like when you get the over view of the KSC. At no point will you have to walk around inside the biodome and do anything. This will speed up production of this expansion considerably as you probably won’t even have to model a lot of detail and perhaps prevent the camera from changing angles, unless it becomes necessary to find and select a building. That’s a decision for the developers of course.

All biodomes will have upgrade levels, and the buildings available in them will be dependent on these upgrade levels. They will be manned by colonists when they are delivered to the colony. The buildings will have levels as well. Some ideas for colony buildings and their functions are as follows.

Mining Camp (Biodome level 1) – Manages production of wood, metals, water, and ore. Provides work for up to 6 colonists to be distributed as the player chooses. Level 1 can harvest Wood and Water. Level 2 can mine ore. Level 3 can mine raw metals.

Material Fabrication (Biodome Level 1) – Manages conversion of raw materials into building materials, such as lumber, plastics, glass, and hardware (screws, nails, door knobs, hinges, etc.). Only the material category need be of concern, not all the individual parts. These areas can be managed by any distribution of colonists but the building would have a maximum of 8 colonists working at a time. Level 1 will provide production of lumber and hardware. Level 2 will unlock glass, and level 3 plastics.

… and other such buildings working your way up to a VAB and SPH which will provide a launch pad and runway outside the dome. These will be Biodome level 3 facilities as they will be needed to build craft for exploring the new planet system. Of course, a simple colony dome without any functionality inside can be used as the basis of a combined VAB/SPH building menu if all that colonist management is outside the intended scope of the game.

One more thing about the new planetary systems. They will be procedurally generated once upon the start of any new game. This means every new game will have different biodome maps and this means data management will be crucial. With a one-time procedurally generated planet system for everything outside of the original Kerbol system of planets, planet systems can be created as they are reached. First, procedurally generated star map can be created, allowing the player to pick a star to navigate to in their new interstellar ships (more parts required, obviously). They won’t be able to zoom in on any star enough to see the planets until they arrive within 500,000,000,000 meters of the star, at which point the system will be procedurally generated as will each of the planets. It might be better to hold off on the planets until they get within orbit or set up a colony on one and advance it to level 3 where they will be able to observe the other planets through telescopes. The idle time spent accessing any of the features of the colony can be used to work on building the planet details, as can any use of the pause screen while in the system.

The game save data needs to be spread out into multiple files, all using a binary storage method to speed up loading and reduce redundancy. A database might be a logical model for managing the files saved for each planet, each vessel, Kerbal, contract and any kind of historical data. All of these files will be maintained in an open state during play (in other words, not being read out of the compressed single file save) and packed into a zip or other compressed single file format when saving. The persistent file will then become the database that manages the other files, including hash management to ensure they weren’t altered or replaced with older copies inconsistent with the rest of the game data. The single compressed file would be what players can upload to the bug tracker or make backups of. The daily access of the saved persistent will allow for each of the other related files to stay outside of the single file for reuse, but if a mismatch is detected between the hash stored in the persistent and any of the files, then it will have to load from a single file compressed copy of the persistent, created any time the player exits through the game menu only, and not every loading screen. If Alt-F4 is detected as the method of closing, then the zip can be created there too. This also means that data that is not needed during the flight of one ship, such as the part listing of all the other ships, don’t have to be stored in memory the whole time. You can update the in-flight ship configuration file once, record the new hash in the persistent database, and release those objects for garbage collection to load another ship from it’s saved data. The tracking of these vessels would not be a part of the in-flight ship configuration data because these need to be updated constantly as time progresses.

The hash seed should be generated once at the beginning of any new game so any attempt to discover the seed through brute force won’t be universally applicable to every game. This seed can be combined with the MD5 of each file to create a secure tamper resistant hash in the persistent database.

This is only an introduction to the idea. If plans are to move forward with it and my input is requested, I would be happy to work with your team on hashing out some more details.