Doing a Copy Paste from the Kerbal Space Program forums. This is in the early brainstorming stage, and I have no idea if things will take off, but I thought I would copy it over here to get additional feedback. If some wording sounds like this thread belongs to another forum entirely, that's because it does.

For anyone who doesn't know of the game: Kerbal Space Program is all about building rockets, and sending your three "Kerbal" Volunteers (aka, unwilling/unknowing test subjects) into space/giant fireball of death. Great fun, and you should check it out.



KSP is great and all, but lets face it: Carting your large desktop gaming rig around so you can launch rockets while on your way to work just gets you weird stares. Especially when you ask the bus driver if he has an outlet you can borrow for a few blocks.

So, this minor problem, coupled with me finally getting something that can be called a smart phone, has lead me to a project idea. I want to try my hand at a mobile development project, and I figured why not something that is like KSP in spirit, but simple enough to run on a cheap, bare bones phone.

My current idea is something that has more design and theory testing stages, coupled with an object based CAD system with kind of a late 80s style interface. (Anyone remember CADs that ran on DOS? I swear I'm not actually that old, I was just a geeky child.)

"Game" flow would be:
1. Component Design - A few basic 'object' types with rather primitive geometry options, which have different functions. Tanks, valves, pumps, (controls/computers?) etc. You then set up parameters, lengths, heights, widths, diameters, wall thicknesses, initial contents and initial states: Oxygen, Gas vs Liquid, etc.

2. Component Testing - Taking your custom pieces, and putting them in the wind tunnel! Run them through their paces, and see what happens. (Would also double as an advanced object properties calculation step, which would simplify runtime calculations during launch stage.)

3. Vehicle Assembly - Taking all your pretty little components, and slapping them together. (Similar to how KSP does it, but most likely simpler wireframe/2D CAD view)

4. Programming/Flight Plan - Setting up your burn stages etc ahead of time. How things are 'suppose' to go.

5. Launch/"practical Testing" - Fuel things up, and let it fly. Minimal "Data Only" style display, possibly basic simplified graphics, small labelled dots on lines. No detailed rendering of what is going on.


(Basically the whole project has to run nicely on my HTC Status/Chacha, with its pathetic little 480x320 landscape display. Because, as much as I like the community, I'll be programming for my device first and foremost.)


May also include designs for building up your facilities. Designing your launch systems, etc, and not killing off your work force. Not yet sure on what to do for a 'campaign' style game play. Possibly scenario based: X amount of money to do Y mission in Z time. Such as getting to the moon on a shoe string budget. May also include a missile game as well, and roll in a DEFCON style option. "In the Race for Space, Thermonuclear war can be 'Plan B'".

No idea about any kind of direct multiplayer option currently.

I'm kind of thinking that it would be interesting to be able to design the engines and combustion chambers themselves. Most likely I will just make up a simplified chemistry to go with it, just because having a totally accurate sim for it sounds a whole lot less fun to program.


Currently only possible tie in with the game that inspired it is being able to export your rocket/component blueprints. This feature would be used primarily for exchanging/storing designs within the app, but I would provide the specs for the format so someone else could write a converter program.


I'm playing a fun balancing act with this design between detail of the physics simulation (In atmosphere being the hardest part of it) and system resources. I really want to keep the processing being done to a minimum, even if the device has horsepower to spare. After all, more processing means less battery.


I'll work on some User Experience Docs and GUI Layouts at some point. Programming for something like a phone is going to be a really new experience for me. Most of my stuff is bound for cluster processing, so it should be interesting to go back to something as light as an 800mhz processor and less than 512MB memory.