- Single player
- Easy coffeebreak fun
- Use mouse wheel to zoom out to see the big picture, and zoom in for the kill.
- Easy at first, very hectic later on.

Windows 2000 or XP,
800MHz or higher CPU,
512MB RAM

Max OSX tiger works, earlier possibly works, G4 CPU, x86 may work under emulation.

Tapwave zodiac version works on both models.

This is a short clip by plank films mobile of the Tapwave Zodiac version of the game. The gameplay is pretty much the same for all versions, with the main difference being the zooming controls.

On mouse-driven platforms with mouse wheel, the wheel is the most convenient way. Right-dragging also works.

On Tapwave Zodiac, a couple of buttons are used for zooming and the analog joystick aims;

On mac, A and Z keys can also be used to control zooming (as macs mostly only have one mouse button, and no wheel).

• GameHippo review
• Suomipelit review (finnish)
• Orbital Eunuchs Sniper, i.e. linux port
• Post mortem report
• Home of the underdogs review - top dog

The standard 'gamasutra' formula for postmortems contains 5 things that have gone right and 5 things that have gone wrong, so here we go.

Additional, great games experiment -exclusive comments added in italics.

What went right

1. Simple idea
   
When deciding on the game idea I automatically discarded all the ideas that would be either content-bound or that would require lots of tweaking to make a sensible game. This meant dropping all 3d games, for example, because I didn't feel like doing collision detection, and I didn't know whether the 'ludiengine' would be enough. In any case, 2d art is easier to do than 3d.

I actually ran out of features to implement. Right now I have plenty of ideas how to turn orbital sniper into an actual full-blown game, but about 8 hours before the end of the contest, the game was essentially done.

In retrospect, there are plenty of things to implement, but for the time limitations of the competition, things like generated maps, scripted scenarios, and so on, were out of the question.

2. Enough sleep & food
   
I slept the 6 first hours of the competition, and 8 hours in the middle. This let me keep my head and spend most of the competition time doing more or less sane code.

While others seem to have written some game frameworks beforehand, I spent my time preparing food. I could have cooked even more food beforehand or gone microwave, but instead I spent a total of 4 hours just cooking during the contest. This gave me time to think things over and not do stupid things. Also, it enabled me to work without being hungry. =)

3. Deciding not to make OOP code
   
Because the game didn't explicitly require any OOP code, I decided to make everything global. The resulting code is rather ugly and while it caused some problems when doing the 'new game' feature, it enabled me to make fast and straight changes to the way the code works without having to refactor the codebase, and thus saved time.

In another ludum dare entry post mortem that I've written since I praise the choice of going OOP, so this isn't a very hard rule.. =)

4. SDL
   
In the end, SDL was everything I needed to make a game. Controls, framebuffer, audio and image loading. And it's very easy to use as well. If I had been doing a 3d game instead, I would probably have written it on dx7 instead.

Now that dx7 is "somewhat" old, I'd use OpenGL instead.

5. #ludumdare
   
The IRC channel, which I only used briefly in the beginning and a lot later on, was a great help; in the beginning someone told me how to implement the mouse wheel support in SDL (which is unobvious), and in the end people told me things that are irritating in the game, enabling me to fix some of those.

The game would have no sound or play again options if someone on the channel hadn't mentioned about doing them.

I think I made the right decision not to hang on IRC from the beginning, in order to get the work done.

What went wrong

1. Not enough playtesting
   
While the game was complete, I didn't do enough playtesting, and the game ramps from being boring (in the beginning, for experienced players) to being too hard (too early, for inexperienced players) pretty quickly. I did some gameplay tweaking in the last 8 hours and ended up uploading 4 different versions on the server; the last version is pretty decent.

Scheduling game testing in a 48 hour competition is rather difficult.

2. Too infrequent backups
   
At one point my machine crashed and I lost the 'main' cpp file. The last backup batch I had done was 6 hours old, so I lost all my audio code and some of the gameplay tweaks. Luckily I remembered most of those, and reimplementing sound only took about 30 minutes. Keeping time log also helped, as I could see what main features I had worked on after the backup had been made.

3. SDL debugging
   
I was inexperienced in debugging under SDL. I managed to spend a total of 2 hours finding one fatal bug in the code; 30 minutes of which was spent rewriting the audio code. If I had known about the SDL_INIT_NOPARACHUTE flag earlier, I might have caught the bug earlier.

4. Underestimating the power of modern PCs
   
Having concentrated on programming low-power handheld devices recently, I was surprised to find that most things that I did had no effect of any kind on the framerate. I originally planned on doing some 256 pedestrians, for the fear that their AI code would eat too much CPU power. As a joke, I threw 16384 of them in, and the game still ran at a decent speed. I dropped the count down to 1536 since that looked good. Another thing was that I ran the AI code 20 times per second originally; I upped that to 100hz and it had no noticeable effect on the framerate either.

I might have saved some time by not bothering to do all that fixed point math stuff in the beginning.

On the other hand, writing the processor-sensitive bits in fixed point enabled me to port the game to a mobile platform - namely the now-dead tapwave zodiac - without a major headache.

5. Work the next day
   
Going to work after crunching a game all weekend, and being awake at 4am on moday morning, was a bit of a killer.

Project stats

2502 lines of code, totaling 82704 bytes, of which 16516 bytes in comments (19.970%).

30e spent on groceries (most of which was not consumed during the contest, though)

Equipment used:
- Development machine 800MHz p3 with 768MB RAM and GeForce3
- Canon powershot S10 (for audio)
- Ancient, crappy & cheapo casio(?) microphone

The development of the game was performed within 48 hour time limit. This is the log of approximately what was going on in those hectic hours..

Saturday

4am
contest begins

10am
I manage to drag myself out of bed, with a great idea of a game if it has a 'gravity' theme, and find that it's 'guardian'. Ponder upon several ideas, take a walk.

11am
Start drawing a city map. Set up SDL. Find out that SDL doesn't have a stretch blit. Decide to write my own. First version done, I'm hungry.

12.30am
Start cooking pancakes.

12.40am
Get the great idea to keep a log

1:30pm
Damn, cooking these pancakes takes a long time.

2:00pm
Armed with a batch of pancakes, strawberry jam and prototype zoomer, I start working on mouse control.

2:10pm
Mental note: buy dronningholm jam next time.

3:34pm
Mouse control implemented + clippings & unreal dither implemented in zoomer

3:52pm
fixed some bugs in unreal dither reading outside image, added crosshairs & wobble

4:21pm
Working on writer, found that SDL's SDL_MUSTLOCK macro doesn't work.

4:39pm
Blitting from one 8bit surface, changing palette, blitting again doesn't work. Have to make
several copies of font..

5:15pm
Split source base into several source files.

6:13pm
Made prototype sprite stuff

6:32pm
drew AI waypoint map

7:00pm
did tracing code for AI waypoints

7:31pm
posted first screenshot in ludum dare

7:42pm
designed AI data structure; time to cook something.. omelet, ham, potatoes.

8:21pm
Done eating finally, going to mix some drink and then I'll work on AI behaviors.

9:53pm
Pedestrian AI is somewhat finished

10:02pm
Did a simple shooting animation

10:59pm
Drew logo screen

12:05am
Created the game end screen

Sunday

1:10am
Did preliminary VIP and bad guy spawns, fixed a bug in clipper with a kludge (too tired to think, really). Only real thing left before calling this a game are the VIP and bad guys' AI:s. I'm calling it a day.

9:29am
About 18 hours to go, I manage to drag my self up the bed again. I was wrong when I whined about the competition hours.. these are just about optimal for me.

10:52am
Made different zoom levels more sensible & made it so that camera wobble doesn't affect HUD stuff -> now there's a point in zooming extremely out (find VIPs and threats fast) and extremely in (actually hit someone)

10:59am
Added mouse wheel support (for zoom)

11:03am
Breakfast.

12:19pm
VIP and bad guys AIs done. Tweaked the target and spawn times a bit.

12:38pm
Added different game over reasons, fixed couple bugs. The game is now
playable, about 23 hours after the first lines of code. Time to start
cooking again..

2:23pm
Made enough pasta sauce for a family of 4. Oh dear. Dug up my old and
amazingly crappy microphone, downloaded goldwave and recorded some sounds.

3:46pm
Added sound. Next up is alpha blended, scaling sprite routines. Joy.

4:05pm
Avoiding the abovementioned task, added some stats to the game over screen.

4:12pm
Took a shower.

5:31pm
Sprites plugged in

5:52pm
Added screen border indicators. Time to try a release build for the first time.

6:10pm
Mixed some more drink, loaded the laundry machine and put it on, played
around a bit with the target display.

6:58pm
Added target information screens

7:39pm
Hunting a mystery bug.. only occurs in release mode.

7:50pm
Hm. Using release mode + fullscreen crashed the system so totally that I lost the contents of the main cpp file at least. I have no idea how
much had happened after my last backup. I at least lost sound and all the tweaking I did to the game settings. ARGH!

8:09pm
Since the game didn't crash anymore, I just have to hope that the crash
was caused by the audio system. Oh dear. Which I'll now start to recode.

8:35pm
Audio re-implemented

8:43pm
Managed to get it to crash in fullscreen again, but not in windowed mode, and SDL happily just kills off the application without letting me debug if we're in fullscreen. Joy.

9:08pm
Made the fullscren mode also a software surface, doesn't seem to crash
anymore. Probably a rare overflow somewhere. =(

9:14pm
Changed sprite drawing so that it'll draw slightly outside the screen -
clipping is performed per pixel but who cares, we have CPU power..
The clipping was done earlier, so that's not the cause of the bug.

9:21pm
ARGH! crashed again.

9:32pm
Managed to crash in windowed mode: AIs were trying to use wrong waypoints in some obscure case.

9:52pm
Ran physics loop at 10x speed for several minutes in fullscreen release mode and nothing crashed, so I'd guess the AI stuff is fixed now. I'm fairly confident (fingers crossed) that that was it. Next up: packaging & documentation.

10:15pm
Finished, now I'll just zip it up and toss it away..

--

After the above log was finished, I chatted on the ludum dare channel and ended up adding little things like the 'play again' feature (which was not fun due to the way the game was made), and way after the contest I ported it to tapwave zodiac and later on to mac os x. Separate people have made the linux version (orbital eunuchs sniper) which I haven't tried, but I've heard has some improvements such as different difficulty levels.

And yes, I have some long-term plans of making a "real" game out of this one day..