Tuesday, 18 November 2014

Touch Prototype Orbital Mechanics

Over this past year, I created a little touch prototype game using the Kivy framework for python.
One of the major advantages for using python is that it's a great feasibility test for the motion integration algorithm.

If I can get realtime floating point calculations of the RK4 algorithm done in the notoriously slow python running on a mobile device, then there should be plenty cpu of headroom for the game with the switch to java.

As outlined in the previous post, I decided to go with a calculation buffer, with linear interpolation between the points of the buffer for display/playback for the orbital motion. Firing the engines causes a recalculation of the buffer as shown in the screenshots below.






Control of the ship is by pressing and dragging on the screen to create an acceleration vector which is used to orient the ship and determine the engine power.

The github repository for this prototype is here - https://github.com/kellpossible/KivyOrbiter

For a bit of fun, I also implemented a randomly generated star background. It might also be fun to use some perlin/simplex noise as a distribution function (or brightness function) to get some patterns/coherance with the stars.

I got the orbit calculations running in a separate thread, but python's threading sucks bad because of the GIL (Global Interpreter Lock). Would have been better off keeping it in the same thread and using my own scheduling/resuming. Anyway, after some profiling, got the performance to acceptable levels on the Samsung Galaxy SII

Takehome points:
I'm really not sure what combat would be like with this orbital physics, I'm thinking probably very confusing. We'll have to see I guess. It's certainly fun, and very intuitive for someone who's played kerbal space program or orbiter to manipulate the orbital trajectory using this control scheme. The point of being able to enable a mode to counter gravity (anti-gravity) at the expense of fuel should solve this problem, and allow a gradual progression. Also, slowing down game speed/decreasing the gravity, and allowing the user to control the speed using warp might also be a good option to give the player more time to think about combat or navigation before impeding collisions.
I might actually give this a go in the prototype. See what kind of a difference there is in fuel use.

Next up is the discussion about procedural content generation for the planet and star surfaces. I had a go at building a prototype for this in Java using LibGDX, which I've chosen as the platform for the actual game.

No comments:

Post a Comment