pygame is
Simple DirectMedia Layer is
Site Swing

JPLLauncher - 1.0.4

David Khono Hackland (khono)



The player launches a probe into space, controlling only the initial velocity (direction and speed). Once launched the probe changes velocity based solely on gravity (and crashing into objects). Score is based on how close the probe gets to bodies (planets) for how long.

Readme contains instructions which aren't yet displayed in-game.

The game can get over 1000 FPS. There's a problem in that once the player turns the FPS up to around 1000, the game loses control over the framerate and the program goes at, what appears to be, maximum speed (over 3000 FPS at least). I'm a newbie programmer and I'm learning as I go. I wrote most of this (as of March 18, 2010) while I was in Laos stuck in the only air-conditioned room for two months. I had no internet (so my learning was limited) and my laptop keyboard had serious issues, so many of the comments contain "B"s instead of "D"s and semi-colons instead of commas. :-B

Far from a professional game, I was encouraged to publish it here by a fellow newbie python/pygame programmer.

BTW I probably should have started as version 0.0.4 but I already published it all as 1.0.4 so I'll leave it like that for now.

Page hits since March 18, 2010.
Free Hit Counter


Home Page:


click to view original size


JPLLauncher - 1.1.0 - Jun 23, 2010
JPLLauncher - 1.0.4 - Mar 18, 2010 account Comments

If you wish to leave a comment with your account, please sign in first.

June 29, 2010 12:36am - David Khono Hackland - nickname: (khono)
It's over nine thousaaaaaaaaand!!!

Yeah, raubana, it could be modified further to increase the latency (calculate less frequently) when the gravitational forces are tiny. Most of the processing takes place then during those slow times. I bet half the processing could be simplified out, too. But I still think that most of the time is taken while rendering to and updating the screen. Perhaps introducing hardware acceleration would speed things up by orders of magnitude. Hehe.
June 27, 2010 9:26pm - Dylan J. Raub - nickname: (dylanjraub)
The frame rate can be OVER 3000!
June 24, 2010 7:26am - David Khono Hackland - nickname: (khono)
I changed the screenshot. This screenshot is in the rewrite with only one body. It's easy to change how many bodies are generated by changing "self.numberofbodies = 5" in class Randombodiesmode(), the __init__ function.

There are many stable orbits possible with only one body and I've seen many interesting ones. This one's one of the best as it has a kind of flower design and a tunnel-like effect. I took this screenshot just after the probe started to run through the same cycle which resulted in a grid-like appearance. A screenshot I took later looks more like a kind of british fabric that I always thought ugly.

Oh, I just noticed. It also looks like a torus when I look at the bottom right. The red dot near the middle (not the big tan dot surrounded by black) is the probe.

I'm going to post some more screenshots at sourceforge. Feel free to send me any interesting ones you get.
June 23, 2010 3:56pm - David Khono Hackland - nickname: (khono)
Okay I've thrown up what I've gotten done so far in the rewrite. Hopefully I'll get to the stage I was at in 1.0.4 soon but... at this rate, it'll be a lonnng wait.

I've redone some of the systems, such as the colouring, the latency, and the scoring. I haven't yet put in the information which can be seen at the right side in the screenshot. Also, the score-screen currently does not function. It crashes the game.

Comments welcome.
May 14, 2010 9:30pm - David Khono Hackland - nickname: (khono)
I'm still working on the rewrite. At this point, I've almost gotten as far in the rewrite as I got in my very mixed code version :) Taken me ages but just wanted it to be known that I haven't given up. I've got lofty plans that, HOPEFULLYL, I'll be working on in the near future.

A general idea of my currently favourite plan is:

The basic story is that there's a fleet moving out in space (colonization, exploration, war, haven't decided which or if those'll be starting options). I got the idea from a recent Analog SF & Fact story. The player will be in charge of scouting with unmanned probes. The player starts with only limited options. Systems of stellar bodies will be generated, fairly randomly, and it will be the player's job to scout them with probes. The efficiency of the scanning will affect what's known about that system and of course, the cost in scouting it. The more known, the more chance valuable information is found, such as easily mineable materials or scientific data. The more materials, the better the fleet does and the more that is available for construction and whatnot. The more prestige the player gets (through results of probeing, primarily) the more control and resources the player may take. The player may start to choose specific development/research paths, specifically for probe and launcher technology (but other things as well, perhaps various kinds of telescopes in the fleet for better initial scans and finding of nearby systems). The player may also choose which probes are constructed, designing their own probes.

Some upgrades I've thought of:
Engines: Option to install various kinds, or none at all, with varying degrees of thrust and fuel included. These're able to modify the probe's trajectory after launch.
Various scanners: Simple light cameras which send information back; cameras designed for various ranges on the electro-magnetic spectrum, like radio, xray, etc; gravity meters with varying precision, allowing precise metrics of force in any given direction which may be analyzed for determining mass of the various bodies (one may solve for the exact gravity for every body because the average force is known for each location, but I don't yet know how to do this, but it'll be fun to figure out and model :).
AI to control the thrust to achieve specific results. This'll be difficult, I think, as the player must have the power to give commands to the AI and thus, I, or anyone helping me, must program it to be very sophisticated. Perhaps even set the probe in orbit around a specific body!
The ability to send multiple probes, even if the last probe(s) are still functional.

Many other ideas and they're still occuring to me. I think it could be a really fun game. A nice idea, I think. One of the few strategic games that doesn't involve combat :) Furthermore, it can be very educational with math, physics, and astronomy. Weee, exciting! I hope I get there.
March 26, 2010 3:30pm - David Khono Hackland - nickname: (khono)
@Gumm: Hah, I seem to have gotten around the problem. The code I wrote months ago to get around it wasn't complete... I didn't zero out the counter once the desired value was reached.

So, using:
counter2 += 1
if counter2 >= 10:
counter2 = 0

does the trick.

But yeah, Gumm, if I correctly understand what you're saying, that's pretty much what I'd figured as well.

Have any of you tried running the program with only 1 body? Change the numberofbodies variable in mainmenu() to 1. It makes some interesting designs and can show just how fast this game can go :)
March 25, 2010 1:08pm - Gummbum - nickname: (gummbum)
I've seen the FPS behavior you describe, David. FPS is not granular above 1000. I have seen 5000 and 10,000 and nothing in between. It is likely the product of the internal algorithm which calculates FPS as an average over the last few frames: i.e. at some point a nanosecond is no longer small enough to maintain accuracy. Whatever the reason, it seems you won't get accurate frame rates above 1000.
March 18, 2010 11:59pm - Ian Mallett - nickname: (geometrian)
A simple, yet still very fun game, if awkwardly coded. Some of my best runs:
March 18, 2010 12:56pm - David Khono Hackland - nickname: (khono)
I could get around it in other ways by drawing more than one pixel in the probe's path at a time, but that'd require rewriting a lot of code. I'm currently rewriting the entire program and will deal with this if it comes up in the rewrite.

I thought it an interesting bug, though. Are there many graphical games with framerates per second in excess of 1000?
March 18, 2010 12:52pm - David Khono Hackland - nickname: (khono)
@duckfin: I've done that: clock.tick(int(gameframerate))
I'm able to control the FPS effectively up until it gets around 1000 FPS. At that point, the program loses control and the FPS goes to max. I suspect it's an issue with limitation on accuracy in time measurement. I recall reading that setting something to fewer than 5 ms is likely to fail.

I tried working around this by making the game loop only call clock.tick() once every 10 or so frames. Assuming I did that correctly, that doesn't seem to resolve the problem or change the program's behaviour.
March 18, 2010 11:46am - Austin Morgan - nickname: (duckfin)
To throttle the FPS, make a clock object:

clock = pygame.time.Clock()

And include this in your main loop:


Where 30 is the MAXIMUM FPS you want the game to run at. It's not exact, but it's pretty close.

our projects welcomes all python game, art, music, sound, video and multimedia projects. If they use pygame or not.
recent releases
Feb 21, 2017

Jan 31, 2017

Jan 24, 2017

Jan 18, 2017

Jan 7, 2017

Dec 30, 2016

Dec 8, 2016

Nov 28, 2016

Nov 27, 2016

... more!
for pygame related questions, comments, and suggestions, please see help (lists, irc)