How to Play (Quickie Version)

Your ship is at the bottom of the screen, riding the large waves. The waves will lift you helpessly up and down, which means there's a vertical factor to worry about. But they can also shield you from bullets. Move left and right, fire your SAM (Surface to Air Missile), dodge things.

Idling waves of Copters and Fighters at the top of the screen will decide to make attack runs. Fighters will loop around and occasionally drop a bomb - they will crash into the waves as well. This does not get rid of them, a new one will replace it from the top! You must shoot them to keep them dead. Copters are much nastier. They'll come down, look around, and fire a stream of bullets at you. Then maybe do it again.

Enemies are worth more at higher difficulty levels, and Copters and Fighters are worth more when they're trying to attack you then when they're just idling back and forth.

On certain levels there are other enemies: Cruise Missiles, Bombers, and Mines. Mines just slowly float at the bottom of the waves. Cruise Missiles shoot across the top of the screen, then the tops of the waves. All you have to do with these is not hit them. Bombers will fly across the screen and drop a huge number of bombs - but in theory there's enough room between them for you to live!

The game never really ends, but when your rank ceases to go up you've effectively beaten that difficulty level. The game will let you know when this happens, though you can keep playing and the toughness of the enemies will keep increasing. Try a higher difficulty level! You'll get more points, and I think you'll find level 3 extremely challenging. If you beat that, I guess I'll have to add difficulty level 4.

Thoughts on the Process

As I was programming this, I often compared it to what the process would be like on an Apple ][ or C64. In 6502 assembly language with about 40K of memory to play with - I've been there!

In favor of the old way, there's something to be said for the purity and economy of the assembly language. If you need to hold x/y positions for 30 planes, you just reserve that much space in the header and bang on them directly using the X register as an array index with the plane ID. Compare this to the way I do it here - A Plane class (which is a Sprite subclass ) has further Subclasses: Fighter and Copter. These objects are created as needed, positions and speeds are tuples and bounding rectangle positions, and of course all all movement is done somewhat indirectly.

Graphics were not so much an issue - when they're so crude almost anything is good enough for a small sprite; though doing larger graphics for backgrounds or title screens was still beyond me. Having more resolution and colors (and full multichannel wave sound cards) to work with for the new game is rather a bad situation for someone who's bad at making the art like I am. This definitely ate up a lot more of my time than I'd budgeted.

You didn't have to worry about writing an installer, cross-platform compatability, or much in the way of system configuration. And most humbling of all, the entire original Wavy Navy executable is smaller than one of my sound effects files!

Ooooon the other hand, I wrote this game entirely from scratch (except for the Pygame/SDL libraries ) in three weeks of spare time work, including creating all the art and finding and converting sounds, writing the docs, etc. Python's a dream language for doing quick revisions, adding functionality by slowly fleshing out the framework towards your overarching design, so you always have working code of some sort. What they're calling Agile Programming now. And not having a noticable compile step is wonderful - just edit and go. I can't imagine getting this done anywhere near that fast in the old days - even Nasir didn't turn out games quite that quickly.

Furthermore, the flexibility and ease of refactoring are incredible. In the old way, if you wanted to change how the plane x/y positions were handled (as described above), you'd be in biiiig trouble. Say you decided you needed another byte per coordinate to handle subpixel positions. You now have to rewrite every section of code that looks at the x/y positions. In Python, though this isn't Python specific of course, all that was just internal to the Plane class anyhow, and is handled by switching the positions from an int to a float. And that's all done implicitly since variable types are dynamic.

Performance was a worry - Python is interpreted bytecode and I really don't worry too much about speed when coding in Python other than not doing dumb algorithmic things. That wave sprite is huge (and there's three of them), and there are quite a few planes and bombs on screen at once.

I shouldn't have worried - it runs smooth on my 3Ghz P4 XP machine, as expected. But it also runs smooth on my cruddy ancient 250 MHz Pentium 2 Slackware box. In fact at 4-6x the resolution and 16 times as many bits per pixel (32 vs 2) to move around, the frame rate is better than it is on the original game - if you play it you'll notice he used some tricks like only updating a plane every so often if it was idling. I'm not doing anything myself to optimize it, though Pygame and SDL have a few built in boosts like using update bounding rectangles. I'm not disparaging the original game doing what it had to do to make things work at 1Mhz, just noting that if the Pygame version runs that well on a 250 MHz P2 and old graphics card that performance is not nearly the issue I had worried about.

This was the real corker. I developed the game entirely on Windows since it's what I have for a game/dev machine at home. I gave no consideration at all to porting other than using os.path functions to split/join path names instead of hardcoding 'foo\bar'. When v0.90 was done I copied it over to my slackware machine, installed SDL and Pygame on it, and ran the game.

It ran perfectly. And it looked and behaved exactly as it did on Windows with no changes. I didn't have to go back and add 'if unix: blah elif windows: blah' anywhere in the code. I just had to add a small package maker script. Real write once, run anywhere. Now that chokes me up. And now Python and PyGame run great on OS X.

The hardest part of writing this game was adjusting the difficulty levels. The low frame rate of the original game was an integral part of the difficulty! With a constant 30 fps, which is what I limited it to under Pygame, the Copters were no longer the awesome threat they once were.

My original version was incredibly hard starting at level 4 - the game would just switch into turbo and massacre you. So I backed it off and then it was too easy, even on difficulty 3. I knew this would be the nastiest thing to tune, so I left it till all the other issues were mostly taken care of.

Finally, I decided to leave difficulty 1 as it is (for the casual gamer) and worked on stepping up the difficulty for difficulty 3 to something that would hopefully be enjoyable even for the hardcore gamer. I increased the speed of the choppers so they were evil again, and made the probability of Copters/Fighters proportional to the square of the difficulty. And now difficulty 3 is fun for me to play, but I still have nagging doubts - real play balancing takes months, but I don't really have a cadre of testers. Oh well, as long as I sitll enjoy it!

For me, writing games in Python/Pygame is the way to go. I've looked at other 2D frameworks like PKT and Torque Builder, but having to revert back to some half-assed scripting language or C++ is just too painful to contemplate, even with all they do for you. This is for fun! I only ran into two real issues.

First, the lack of midi support is a bit disappointing. It'll work under *nix if you install timidity and have a Gravis Ultrasound, but that's not really acceptable. So I can't use .mids for music, which would hide my lack of skill at this and also make the music files 1/100th of the size. Perhaps I need to use the sndarray stuff to fake my own FM synth.

Finally, I am of course concerned that it takes more effort to install and run than a Flash game would (and won't just run in your browser). But again, I'm doing this for fun and ActionScript gives me hives.

I am currently contemplating writing my next game... Finally motivated again!