vaquum : everything is better in space

[nihilocrat]

This is a devthread for the space shooty game I am working on as part of the "Finish your Dang Game" competition. I have had various incarnations of this game written in various languages as I have been growing up, as I've always wanted to make a top-down free-flying space shooter/trading/exploration game but haven't actually sat down and finished one.

The game is being coded in Python, using the pyglet library as well as Box2D (though I might replace this with a simpler homegrown physics lib later, as I'm not using many of its features) and a handful of other libraries.




It just so happens I'm making this post mere minutes within the 40th anniversary of the Apollo 11 Moon landing. Please take a moment to ponder what the human race has accomplished and how we don't have a damn moon base yet.

[Pepsi Ranger]

It just so happens I'm making this post mere minutes within the 40th anniversary of the Apollo 11 Moon landing. Please take a moment to ponder what the human race has accomplished and how we don't have a damn moon base yet.

Well, early science fiction history has taught us that we're not likely to have a moon base until at least 2010, which means WE STILL HAVE TIME. History has also taught us that people are born procrastinators, hence the need for this current contest.

On a more relevant note, this game looks fun. One of my favorite games to come out of the last five years is a PC title called Space Rangers 2 (and Space Rangers 1 for that matter) and it uses a similar system as what you're describing. I'm glad you chose to work on this one, as this would've also gotten my vote.

If you finish the bare minimum version and find yourself short on gameplay ideas for a fuller experience, feel free to ask.

[Momoka]

So is this like....a Star Control type of game, or on overhead R-type? Those two ships look unevenly matched.

[Mogri]

Oh man, if you make something like the "Tactical" mode on the original Star Control, I will love you from now until forever.

[nihilocrat]

Much more like Star Control, full 360 degrees of movement.

The tactical mode from SC1 is actually one of the ideas I was thinking about. I have a lot of ideas for a trading/exploration game with factions and other crap, but I don't know if that's going to be possible in the time limit. The tactical mode sounds more focused and thus easier to implement. In tactical mode the battles would most likely not be one-on-one fights, but skirmishes between fleets.

Just to be clear, you're talking about this, right?


I will try and tweak the game so that superior firepower does necessarily win the day, probably with a weighted "rock-paper-scissors" system. In a weighted system, you have the traditional RPS model, but the options have different costs and payouts. In this case, a rock (battleships) are weak against paper (frigates) and expensive, but have lots of firepower and hitpoints. They are a high-cost, high-payout option. Paper (frigates) are cheap and fast, but difficult to keep alive, being low-cost and low-payout. Cruisers (scissors) are in the middle. However, in general, Battleships beat Cruisers, Cruisers beat Frigates, Frigates beat Battleships.

In either case there would be plenty of input for player skill. Frigates reward players who keep moving and use hit-and-run tactics. Battleships reward players who can think long-term and multitask (greater variety of weapons and defensive abilities). Cruisers are in between, allowing flexibility but not being the best choice for either role. Turrets will probably have limited firing arcs that are decided at design-time, and not be able to fire in their entire rear arc (90 degrees) to keep players on their toes.

Progress is coming along nicely, I'll post screenshots when I accomplish something particularly exciting.

[nihilocrat]

Added teamcolors. Holy primary colors, batman!



There are also mouse-guided missiles. The particles are messed up right now, I can't get them to render the right texture, so they just use some random crap sitting on the texture atlas.

The missiles are intended to be a long-range weapon that require a good deal of player attention to aim. The missile shoots directly out the front of the ship and points towards the crosshairs and thrusts towards it, however its slow turning speed and the inertia it picks up make it difficult to maneuver. Right now it's a bit too hard, but I'm pleased with the amount of effort it takes to score a hit. If you don't line up the shot right you need to overcompensate to get the missile back on track. The attention required and the poor short-range abilities make dedicated missile craft vulnerable to direct attack.



Added the 'Praetor'-class cruiser and 'Fafnir'-class Battleship

[nihilocrat]

Designed more ships. Bad news: encountering various bugs that do not make any sense at all, and performance issues that I'm not sure how to get around.

[Mogri]

What bugs? What performance issues? Several of us are programmers, so there's a slight chance someone might be able to help.

I like the modular designs.

[nihilocrat]

Bug-wise, bullet and missiles have suddenly stopped ticking down properly and now disappear almost as soon as they exit the muzzle. Also, this is probably just some misuse of Box2D, but even though I put the bullets and shapes of a particular ship all in the same group (as a negative integer, as per the documentation) they still collide with each other. The particles, using Lepton, still don't use the correct texture even though I'm using the latest version with special Texturizer code.

Performance-wise, on a very modern PC (only about a year or two old) the CPU usage slowly creeps up until it almost entirely eats up a single core, with only two AI opponents and the series of ships, unpiloted, you see above. I will probably want to just optimize my code a little before making a final assessment of that, perhaps even going so far as trying to multithread. I know a lot of the code that's used to aim the turrets probably has some costly hacks in it, and this code has to be run for every single turret. Perhaps I should batch these calls so that turrets of the same type will all follow a 'master' turret. Unless I make some kind of breakthrough I might need to rewrite the core engine (stuff that happens every frame) in C++. I've gotten kind of fat on Python, it's much easier to do lots of things, so I am reluctant to go back to the bad old days.

I should really try to go all the way with psyco, though. I can't find binaries for Python 2.6, and when I try to install from source it doesn't seem to actually install it (in Windows), so I've given up for the time being.

On the plus side, I reworked a good deal of my engine code awhile back such that it's actually a lot easier to use it for future games.

[Bob the Hamster]

Has the cProfile module shown you anything? I tend to find it very helpful.

[nihilocrat]

Actually I have in fact been using it. It's a bit hard to read the output because there are lots of pyglet functions (stuff related to clock, idle, and events) that have lots of cumulative time because they are calling the heavy-lifting functions. However, I do see some important engine functions bubbling up to the top.

Code: Select all

Fri Jul 31 12:45:53 2009    sternflucht.prof

         25448006 function calls (25419768 primitive calls) in 142.916 CPU secon
ds

   Ordered by: cumulative time
   List reduced from 478 to 20 due to restriction <20>

   ncalls  tottime  percall  cumtime  percall filename&#58;lineno&#40;function&#41;
        1    0.000    0.000  142.916  142.916 <string>&#58;1&#40;<module>&#41;
        1    0.000    0.000  142.916  142.916 __init__.py&#58;256&#40;run&#41;
        1   53.191   53.191  142.916  142.916 win32.py&#58;46&#40;run&#41;
     6798    0.367    0.000   89.130    0.013 win32.py&#58;83&#40;_timer_func&#41;
     6798    0.206    0.000   88.755    0.013 __init__.py&#58;162&#40;idle&#41;
16023/16021    0.156    0.000   49.880    0.003 event.py&#58;318&#40;dispatch_event&#41;
     6798    0.018    0.000   43.322    0.006 clock.py&#58;624&#40;tick&#41;
     6798    0.313    0.000   43.304    0.006 clock.py&#58;240&#40;tick&#41;
10751/10750    0.046    0.000   42.715    0.004 __init__.py&#58;1214&#40;dispatch_event&#41;

     6801    0.797    0.000   42.476    0.006 sternflucht.py&#58;556&#40;on_draw&#41;
    20403    0.400    0.000   32.056    0.002 __init__.py&#58;525&#40;draw&#41;
    40804    0.174    0.000   25.788    0.001 __init__.py&#58;464&#40;<lambda>&#41;
    40804   12.612    0.000   25.614    0.001 vertexdomain.py&#58;246&#40;draw&#41;
     6462    1.420    0.000   21.871    0.003 sternflucht.py&#58;340&#40;update&#41;
   977366   15.934    0.000   15.934    0.000 lib.py&#58;85&#40;errcheck&#41;
     4351    0.060    0.000   12.519    0.003 sternflucht.py&#58;496&#40;update&#41;
    81923    1.602    0.000    9.724    0.000 Ship.py&#58;332&#40;update&#41;
     4351    0.150    0.000    9.194    0.002 system.py&#58;56&#40;update&#41;
   189562    9.025    0.000    9.025    0.000 &#123;method 'update' of 'group.ParticleGroup' objects&#125;
     6362    0.102    0.000    7.384    0.001 layout.py&#58;863&#40;_update&#41;

From this, it looks like rendering is taking the lion's share of processing. There is in fact one place where I do this, which I should be optimizing:

Code: Select all

        for d in self.model.dudes:
            for w in d.weapons:
                rabbyt.render_unsorted(w.bullet_sprites)
            for t in d.turrets:
                for w in t.weapons:
                    rabbyt.render_unsorted(w.bullet_sprites)

I am rewriting the code such that the View itself holds all of the bullet_sprites so it doesn't have to loop through weapons and turrets like this.

Ultimately I'm unsure if these piecemeal optimizations will pay off. However, in this case, it's much cleaner to let the View hold all the sprites anyways.


UPDATE: Holycrap! Rewriting the bullet-management code has fixed the issue with bullets disappearing when they are shot. Remaining issues: particles still use the wrong texture, bullets still manage to hit the very ship they are shot from.

[nihilocrat]

I haven't worked on this for about two weeks now, as I spend time with some other projects. Morale is kind of low because even with those, I'm not really getting on a path to completion.

The only really huge technical hurdle right now is getting py2exe to work (and later cx_Freeze or whatever is used now for Linux), pyBox2D does not appreciate being packaged that way it seems.

On the plus side, I now have a headless server version of the game, just need to write the code that sends updates to connected clients, and put in the interface sugar expected in any multiplayer game.

Hoping I can get this all done in time. I made a post in my blog about it a little while ago, probably going to go for a simple game where I basically just make what I already have be multiplayer, and perhaps add some capture points plus very simple resources to add some cost/risk to the use of different ships. It would be kind of like the Battlefield series, but, you know, not.

[nihilocrat]

Unfortunately I've managed to make a game that's the opposite of what was intended for the compo; one that's pretty complete but has some major stuff that needs to be finished up someday. I have lost all my freetime because I need to spend it preparing for a move to Canada.

Thus, the game is going to be in limbo for the foreseeable future, I hope other people have better luck!

[Bob the Hamster]

I hope you will post a copy of it anyway. Even if it doesn't pass the "complete" test, it still seems interesting and fun.