The Depot entry hasn't been approved yet, but I recently put a demo of my new game Angry Moth up on sourceforge.

Basically it's a 2D tribute to space battle games like Freespace 2 and Squadron.
Video here:

Files are here (Windows binary and source).

And a screenshot:
{"name":"AMdemo1.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/e\/7e2e6b4b0c884a9f13895398f37c7ae5.png","w":400,"h":300,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/e\/7e2e6b4b0c884a9f13895398f37c7ae5"}

It should be reasonably easy to work out what's going on, but here are a few hints:
- use slide a lot!
- support your fleet. You need each other
- generally, shields go down when their energy is reduced to zero and come back up when it's recharged to about 1/4 to 1/3
- the targetting display down the bottom left indicates which part of a warship has the shield generator
- don't forget to use the command button to tell your little squadron (of two) what to do. You can get them to attack your target, cover you (the default), form up or go back and defend the fleet
- hold the targetting key/button for a second to switch from manual targetting to automatic and back again

And some known issues:
- no music yet
- the sound in general is not so great
- the "mission data" menu option doesn't do anything
- sometimes fighters fly off into the distance if there's nothing for them to do (this is fixable but fixing it properly will require a bit of work)
- there is theoretical support for dual-stick analogue controllers (with the second stick controlling slide), but I understand that Allegro has some issues with the only one I've tested this on (an Xbox 360 controller). It does work as an ordinary single-stick controller, though. I suggest mapping slide to the bumpers, using the "set controls" thing in the game

Let me know what you think!

I gave it a brief try, and it was very hard. I used the 'formation' command, but the fleet didn't really seem to follow me.

I'll try it some more tomorrow.

I also tried, I'm not a big fan of this genre... But! I don't see anything wrong with this game in its current state. I didn't really screw around with your friendly AI system. So I don't have a comment on that. Just keep up the good work, with more content it will be very addictive.

I used the 'formation' command, but the fleet didn't really seem to follow me.

Sorry, I probably could have explained that better - the command function only affects the two fighters you have following you around. The fleet has its own ideas about where to go.

This is extremely cool. On my 4th game I managed to beat mission 1, (50% casualties), it's when I "got" how to use weapons: Against fighters: lasers and launch a targetting missile as soon as your target is going straight "up" or "down", don't necessarily insist against the same target. Against warships: keep your distance, one targetted missile, and hold fire3 to spam dumb rockets while it reloads.

I admire how you've managed to make a balance: fast ships don't fear so much a big ship as they can flee and regenerate, so the player's ship has a real advantage in chasing the small bombers before they damage the fleet.
I also discovered very fast that when your warships are close to the enemies, it's better to attack from a different side: either they shoot the fleet so you're safe, or they shoot at you and this draws A LOT of fire away from your group, and it's up to you to retreat when the shields are low.
The multiple "maps" / "sensors" are intuitive, they remove the need for a separate map screen.
The visuals are very nice, with an attention to details.
If I have a critic, it's about the number of controls (keys). I think I'm going to try a different setup: For the right hand only up down left right + targetting and command, for the left hand the strafe keys and fire keys.

Compiled from source on Linux + Allegro 4.2:

• the package contains ebullet.c which doesn't seem to be used

• it crashes on non-debug versions upon starting the main gameplay

Otherwise it works. No comments on the game itself, as I didn't actually play it.

Some further notes:
I forgot to mention that the "sidekicks", in cover mode, are very good. They don't stay long in harm's way and quickly catch up when you retreat, they seem to team together against the fighter that you're targetting, and I saw them do "hit-and-fade" attacks against the warship I was targetting.
About the "command" key: I guess it requires practice to memorize which key runs each command. Maybe it would be easier to learn if the command menu was a cross that appears while you hold the command key : you push a direction and release command key to select a command.

   attack my target
           |
cover -- cancel -- ?
           |
    go defend convoy

I'm eager to play more missions, even though the 2nd is still too hard for me
This really brings back memories of Wing Commander (I didn't play a lot, but I found it amazing) I hope you plan to make some missions where the player can pilot a bomber ship, too slow to chase fighters (so requires his escort) and fires super-slow missile that can wipe a small warship in one shot. The generic 3-weapons system has a lot of potential, from player-aimed projectiles to auto-targetting turret like the warships, "melee" phasers, temporary shields (extra bonus if it's large enough to protect a nearby friend), temporary boosts (speed, rate of fire), deployable stuff (prox mines, ship carrier )
So far the two missions are races against time (need to do enough damage before the fleets engage), with more types of game situations this can really shine.

Thanks for the comments so far!

Absolutely. Getting them to fire their small guns at you also draws energy from their main guns and shields (I probably should have written a readme with things like this in it).

You're right, ebullet is unnecessary. I knew I'd forget to take something out. It's probably just the old Hellspider file.

As for the crashing: damn. Unfortunately I don't have access to a Linux machine to try to track down the cause as it doesn't happen in Windows. Hopefully this issue will show up in my dev environment sometime so I can find it and eliminate it.

I considered that, but wanted to avoid using the directional controls so that you can keep moving while issuing a command. I agree that six movement keys, three fire keys and two others is too many, but I can't work out a way to reduce the number without dropping features or requiring awkward multi-key combination commands.

I'm still thinking about this - whether you'll fly the Angry Moth the whole game, or sometimes get to use something else. Hm.

Fail - All Warships Lost X 2. I think I'm getting better, but I'm not good enough yet.

Re - Linux
Maybe tomorrow I'll see if I can get AngryMoth compiled on OpenSUSE 11.3 and see if it crashes / debug it for you. Is Allegro 4 the only library you used for it?

Debugging help would be great, thanks!

Is Allegro 4 the only library you used for it?

Yep, just Allegro.

I'm only tossing ideas with enthusiasm It's the easy part, I know. Ariesnl had started a similar project, I was sad to see that it stalled.
I expect that missions take a lot of time to design (the briefings! the contextual radio messages and scripted events!), so it's really up to you to define how generic/ambitious you want the engine.
In any case, you're making it open-source, so everybody wins.

I really like your games. This one seems very complex yet it's relatively easy to play (I have yet to get used to the slide controls).

I'm thinking I got more than I bargained for.

First, there's no "pbullet.h" to include from the file "ebullet.c". I guessed and changed it to "ebullet.h" but then there were a ton of errors, so I skipped compilation of "ebullet.c".

Second, you used the 'itoa' function in input.c without including <stdlib.h>, so I included it, but guess what - my version of gcc must not have itoa anymore. It was deprecated anyway, so there's a looming 'implicit declaration of itoa' that is bound to crash if I finish compiling it. Nix that - I substituted sprintf for itoa and #included <stdio.h> in input.c. After that it finished compiling.

Third, there's a truckload of warnings left over that I'm not going to mess with. Some are about unused variables, but there are lots of warnings about possibly using uninitialized variables you might want to check out :

-------------- Clean: Release in AngryMoth ---------------

Cleaned "AngryMoth - Release"

-------------- Build: Release in AngryMoth ---------------

Compiling: briefing.c
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/briefing.c: In function ‘report_text’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/briefing.c:2585:6: warning: unused variable ‘dest_rank’
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/briefing.c:2583:6: warning: unused variable ‘elost’
Compiling: bullet.c
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/bullet.c: In function ‘bullet_explodes’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/bullet.c:1002:22: warning: unused variable ‘speed’
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/bullet.c:1003:6: warning: ‘target_x’ may be used uninitialized in this function
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/bullet.c:1003:16: warning: ‘target_y’ may be used uninitialized in this function
Compiling: cloud.c
Compiling: display.c
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/display.c: In function ‘draw_convoys’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/display.c:697:9: warning: unused variable ‘j’
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/display.c: In function ‘draw_final_details’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/display.c:1852:15: warning: unused variable ‘col’
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/display.c: In function ‘draw_HUD’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/display.c:2105:20: warning: ‘select_y’ may be used uninitialized in this function
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/display.c: In function ‘draw_pshield_circle’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/display.c:4918:14: warning: ‘d’ may be used uninitialized in this function
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/display.c: In function ‘draw_bullets’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/display.c:3368:49: warning: ‘x3’ may be used uninitialized in this function
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/display.c:3368:53: warning: ‘y3’ may be used uninitialized in this function
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/display.c: In function ‘draw_a_ship’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/display.c:803:8: warning: ‘angle_draw’ may be used uninitialized in this function
Compiling: display_init.c
Compiling: eclass.c
Compiling: game.c
Compiling: input.c
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/input.c: In function ‘get_input’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/input.c:79:7: warning: unused variable ‘istr’
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/input.c: In function ‘run_player_secondary’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/input.c:1408:9: warning: unused variable ‘i’
Compiling: level.c
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/level.c: In function ‘setup_player_wing’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/level.c:2664:6: warning: ‘angle’ may be used uninitialized in this function
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/level.c:2664:13: warning: ‘dist’ may be used uninitialized in this function
Compiling: main.c
Compiling: menu.c
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/menu.c: In function ‘menu_command’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/menu.c:620:7: warning: unused variable ‘p’
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/menu.c: In function ‘player_joystick_input’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/menu.c:702:6: warning: unused variable ‘j’
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/menu.c: In function ‘run_controls_setting’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/menu.c:1051:7: warning: unused variable ‘button’
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/menu.c:1050:8: warning: ‘inputted’ may be used uninitialized in this function
Compiling: message.c
Compiling: palette.c
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/palette.c: In function ‘blend_function’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/palette.c:460:9: warning: ‘output’ may be used uninitialized in this function
Compiling: ship.c
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/ship.c: In function ‘carrier_launches’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/ship.c:278:10: warning: unused variable ‘e3’
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/ship.c: In function ‘ship_explodes’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/ship.c:3965:6: warning: unused variable ‘y’
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/ship.c:3964:6: warning: unused variable ‘x’
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/ship.c: In function ‘wship_starts_breaking_up’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/ship.c:4070:6: warning: unused variable ‘y’
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/ship.c:4069:6: warning: unused variable ‘x’
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/ship.c:4068:6: warning: unused variable ‘c’
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/ship.c: In function ‘jump_clouds’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/ship.c:4415:9: warning: unused variable ‘i’
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/ship.c: In function ‘destroy_ship’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/ship.c:5008:13: warning: unused variable ‘tar’
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/ship.c: In function ‘turret_find_target’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/ship.c:2234:13: warning: ‘actual_dist_fighter’ may be used uninitialized in this function
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/ship.c:2234:34: warning: ‘actual_dist_wship’ may be used uninitialized in this function
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/ship.c: In function ‘wship_part_explodes’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/ship.c:4571:9: warning: ‘x’ may be used uninitialized in this function
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/ship.c:4571:12: warning: ‘y’ may be used uninitialized in this function
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/ship.c: In function ‘run_ships’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/ship.c:346:6: warning: ‘target_dist’ may be used uninitialized in this function
Compiling: sound.c
Compiling: stuff.c
Compiling: text.c
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/text.c: In function ‘generate_message’:
/home/edgar/ctwoplus/progcode/allegro/AM_demo_Source/text.c:46:6: warning: unused variable ‘i’
Linking console executable: AngryMoth
Output size is 681.49 KB
Process terminated with status 0 (0 minutes, 26 seconds)
0 errors, 35 warnings (0 minutes, 26 seconds)
 

Fourth, and I have no idea why this is happening - it compiled and ran - but when it finished loading, the up and right keys were stuck down and it kept scrolling through the menu changing settings. If I held down the down key it stopped moving up, but kept cycling through the option. If I held down the down and left keys then it stopped cycling and scrolling. It sucks, but the game is unplayable for me due to this bug. It's possible that it is because I am running OpenSUSE through a VirtualBox VM, but the up and right keys aren't stuck anywhere else in the OS, so I still have absolutely no idea why this is happening. It happens in both Debug and Release mode.

I set my controls for sliding left and right to A and S, cannons to L Shift, Fire 1 and 2 to Z and X, command to C, and target to space, along with Up, Down, Left, and Right to move. It feels pretty natural and you can use one finger on the left hand to slide and two others to fire.

And in other news, I finally finished Stage 1. Yay for me!

That's probably the problem. Allegro doesn't work well under a VM.

Should have read my post.

Yes, I forgot to mention that. Use snprintf when not on Windows, at least. (Windows uses _snprintf, so either way you'll probably need to use some #defines.)

I did read your post, but I thought I'd try to compile it anyway. You know, shits and giggles.

Why should I use snprintf when I know an integer can't possibly be longer than 10 characters and I use a buffer more than large enough to handle it with sprintf?

I have tried your game, it's pretty cool, I would prefer to see moving only the ship instead the whole world, though. But... To each his own

Thanks Edgar for the control setup suggestion. It definitely feels easier to control with both hands (although some shmup addicts might find the one-hand setup easier).

I finished mission 1 but lost some ships. I wonder if it's possible to beat it with no ships lost. Anyway, on to mission 2.

L O L what about 64bit?

Compiles OK on mingw-gcc 4.4.1 and the Allegro 4.2.3 package from a.cc, but only if I link statically (alleg_s).
For reasons that I don't understand, and apparently unrelated to the code, with alleg I had unsolvable errors.

Mission 2 complete I mostly hunted all fighters, attacking small warships only when the fleet was in contact with several of them and no fighter in sight. When the dust settled, I saw that group A had been wiped and group B was unharmed, the target base (which I hadn't even seen) destroyed.

About the code, -W and -Wall spit a lot of warnings. When it's about unused parameters or variables it's certainly harmless: only reminders of unfinished stuff. The "missing initializer"s have no consequences when the arrays are global, because the C standard guarantees initializations to zero on all platforms. But these two types cause a lot of "noise" that make it difficult to see important warnings.

By the way, you can avoid a lot of "extern" redundancies by using the following technique:

// in display_init.h
extern FONT* small_font;

// in display_init.c
#include "display_init.h" // This will make compiler catch mismatching definitions/declarations
FONT* small_font;

// in .C that need it
#include "display_init.h" 

edit:
I can't believe I hadn't seen the other weapons!! (menu "mission data" after briefing) Torpedo seems promising even if it's very hard to aim. Single rockets seems always slightly worse than the default anti-ship missile. Charged rockets are my kind of shotgun Heavy cannon seems useless for chasing fighters, so it has to compare with the missiles against warships. Tracking cannon didn't seem to track, but the scatter can be useful when chasing fighters.

The two demo mission require hunting fast ships, and I find the default weapons the most efficient. Even the anti-warship missiles do a lot of damage against fighters that run into them,

Thanks for testing this, and for the compiler output. I actually forgot about the uninitialised variable thing because my compiler (MingW) seems to automatically initialise them to zero unless certain optimisation options are turned on, and without those -Wall apparently doesn't give this warning. Next time I put the source up I'll get rid of all the warnings first.

My guess with the crash bug is that it's some kind of out-of-bounds array reference that in my dev environment ends up referring to something harmless. Stupid lazy Windows memory protection.

I've only ever tried to link it statically. There's a '#define ALLEGRO_STATICLINK' (or similar) at the start of config.h that I guess may cause problems with non-static linking.

Thanks, I will try that.

Okay, this is my fault for not explaining anything . Whenever you start pressing its fire button, the tracking cannon locks onto the closest enemy in front of you. You can tell which one because lines appear on either side of it. The cannon can only track things almost directly in front, though.

Thanks for the comments so far, everyone! (especially Audric and Edgar Reynaldo)

Compiling on Mac OS needed 2 fixes:
There's no itoa function so I needed to make my own.
In display.c line 2995, 'comstring' is not big enough to contain "Command: cover me" so it overwrites memory and aborts. I changed the definition of comstring to
char comstring[20];

Pete

And this is why you should simply be in the habit of using snprintf for all buffers, whether you technically need to (e.g., for integers) or not.

Further gameplay comments:
Torpedo angle is affected by the inertia of the player's ship when firing. This makes it very inaccurate because any strafing or sliding makes it drift to a side : In order to shoot straight, you must be totally stopped. It doesn't compare well with the anti-warship missiles that seem to do the same damage per second (50 vs 180, but they are like 3x faster) and allow you to dodge like crazy while requiring almost no aiming. Maybe it's because you mean the torpedo for bombing tactics (fly straight into target) but there's the delay before warhead arms, and I think I've also seen torpedoes shot down by enemy cannons.

Charged rockets look efficient against a single warship protected by fighters, because you stay on the move and you reload while turning around.

The random element in missions is great for creating new situations, but it makes the difficulty very random. In mission 2 I played a game where I obliterated all fighters and bomber, but the enemy reinforcements, a group of like 6 warships, tailed the assault group B : it followed it one screen away; I had 1 minute to attack it (alone) but couldn't do much damage, as soon as group B stopped in contact of the enemy base, this squad closed the distance and caught it in a perfect crossfire.
For scenarios that are complicated like 2, you may want to limit the placement randomness, or at least compute a starting position and speed that give a fixed "time of arrival" . Two groups that attack at 1 minute interval are a kind of threat, but if they attack at the same time it's 2x more dangerous.

A string buffer overflow? Seriously?? I am so embarrassed. Thanks for tracking it down, Peter. I need to learn how to use these mysterious "printf" functions.

Sort of - like most bullet types it takes on the player's velocity plus some forward velocity once launched, but once its engine has started it only accelerates straight ahead, in the direction the Moth was facing when it was fired. It just doesn't accelerate very fast.

That's right. The torpedo is supposed to be difficult and risky to use but very powerful, and the bombing tactics can be safer than hovering and firing AWS missiles if there are lots of fighters around. It may be that the torpedo is just not powerful enough to justify the difficulty and risk, though - this is all good feedback for balancing.

Sadly my collision detection routines aren't really up to handling something like this. Torpedos should only explode when they hit something or run out of fuel.

Hm, mission 2 is actually not supposed to have random enemy placement. There is code in level.c for random placement but it's not used in mission 2 - mission 2 is the one that's known internally as (arena.stage == 3), for various stupid reasons. That assault group should behave the same way every time. The only real potential for variation comes in either when Alpha group is destroyed (which causes the warships that were attacking it to move in to guard the base) or when all carriers are disabled (which causes Alpha group to move in to attack the base). Plus of course all of the chaos with fighters and bombers flying around.

(this is all very useful feedback, by the way - thanks!)

Torpedo: Yes, they never nullify the initial momentum, so any amount of strafing has huge consequence over distance. Really not designed for long-range aiming, which contradicts a little the speed of one shot every 2 seconds. (too short to run into ship, turn around, run into ship...)
I'd even prefer if the total shooting frequency was 2x slower, as it means I have to be very accurate 1 time every 4 seconds instead of 1 time every 2 seconds.

IMO, the 1-second buildup + 1-second cooldown mechanism would play better with an instant-hit weapon like the base's ray: you hit fire, and you know that in 1 second exactly, you must be facing a target; no matter your current momentum and distance.

As I mentioned (more or less clearly) the multi-rocket can already serve as a very nice series of bombs as you dive into a warship: it entices you to go straight ahead while they shoot one by one, but if a big blob of fire is fired agaisnt you , you can turn early and miss some shots, and while dodging and turning around you can can start reloading so it's not wasted time.

randomization: Ah my bad, I had read the source code for mission 1 and I had assumed the variations in mission 2 were due to the kind of random convoy placement or timing.

By the way I have never actually seen the "carriers". There's a lot of chaos for the player and it's very "busy", so I never could go sightseeing
It's extremely satisfying to get in the 6'o'clock of group of bombers as they line up toward a convoy, when you have fast projectiles like rockets.

Okay, I've just uploaded a revised version of the demo to sourceforce. Here's the link.

Changes:
- Optional fixed camera angle mode - go to "options" on the main menu.
- 2-stick controls can be turned off (also in the options menu).
- A string buffer overflow error that caused crashing on Linux has been fixed.
- Various rebalancings. Tracking cannon is better. Torpedo takes longer to recharge.
- Two little lines indicate the direction and distance of your current selected target.

Also, I've removed the ability to accelerate backwards. I just don't think it was working; it encouraged a particularly cautious and not that interesting attack style (in me, anyway). In the full game it will probably be available as an upgrade or something. Sideways slide is still there.

Reverse thrust is my favorite.

It's going to be a lot harder without reverse thrust. Now to avoid incoming fire, you are forced to strafe, and if you want to retreat you have to turn away and strafe or fully turn away. Bring reverse thrust back!

Yay! It's one of my favorites for taking out enemy fighters. That, and getting lucky with multi-rockets and fighters crossing in front of you.

One thing, it's fairly difficult to chase down fighters, they're much faster and more maneuverable than the Angry Moth.

Fixed camera is a nice experiment, but probably not worth keeping. It wastes a lot of screen space, I tried to uncomment the lines that adapt the ship position, and I even modified starfield to position accordingly, but it's still very confusing in middle of battle, too difficult to see our ship in battle.

I regret the suppression of ability to fly backward... When facing a warship, it's no longer possible to strafe in 4 directions in order to dodge, so if you're too close you have to turn away.

Here I attach a version where I have implemented a bomb weapon (replaces torpedo) It's a projectile that uses only the ship's momentum, has no collision while flying, and damages only at the end of its flight. You can press and hold fire to see a target reticle, and release to launch. It's rather accurate, just remember that the warships are in movement.
I tried to make an area-of-effect damage on explosion, but I failed (I don't understand the system of pixel collision) so I made it launch a small rings of 8 bombs instead. This is really an anti-warship weapon, because the precious projectiles won't be stopped by the fighters buzzing around.

I may try a "minefield" weapon, that leaves explosions behind to hit fighters that chase you.

I'm afraid that now I've taken reverse thrust out I prefer playing without it. It's more difficult but a bit more exciting. Sorry

I agree that it doesn't work very well, but it was the #1 most-requested feature after the first demo so I think I'll leave it in. Camera follow will always be the default and the mode around which the rest of the game is built. I tried a modified version of fixed camera that repositioned the Angry Moth around the screen depending on its angle, so that you could always see a fair way ahead, but I found it incomprehensible and it actually made me feel a bit seasick (gamesick?).

Hey, that actually works really well. I'll think about implementing something like it, although one change I'll make is to have the reticle always visible. Thanks! (and I'm impressed that you managed to untangle my terrible code well enough to add a feature like this.)

Yeah, the collision system for warships (which is based on special collision mask bitmaps) doesn't work very well for area-of-effect weapons. I'll see if I can think of a good work-around.

I had a second win of mission 2, using aw missile and charged rockets, and I noticed it's now much harder to fight a convoy of warships that is going forward : Impossible to stay before them.
By the way, did you entirely remove the ability to decelerate? I had the impression there was only one speed of "slowing down" - when going into stationary enemy ships, I felt I had to anticipate much earlier to decelerate.

I would have requested it too, but after testing ... yuck An earlier version of AriesNL's game had similar feature, where there also was a delay to smooth out the direction changes. (the change was kinda "elastic") It was very impressive to turn at high speed (180° with mouse control) and see the stars zoom by, but it was only viable because there was a much reduced 'population' on screen - and player ship was quite distinct.

Yes it's what I uncommented. I had adapted starfield position accordingly, but it wasn't sufficient: starfield doesn't move as fast as the player's ship so the "plane shift" isn't very clear (at first I thought I had made it negative), and all ships have same color scheme, so the player gets really lost.

The code: There are things I still can't determine without heavy debugging, like the color numbers in these bitmap masks, the "units" for all these integer variables (some are in pixels, some are in 2^9 or 2^10 pixels).
Also I don't understand the behavior of damage values; they don't seem linear...

On linux I had to comment out the part that used the 'itoa' function because its not in a standard library.

Anyway its a nice game but pretty hard. It would be cool if I could switch from playing as a little ship to managing the fleet like an RTS, or even to play as an arbitrary ship in the fleet. Currently management seems sort of useless because I'm usually too busy flying around trying not to die to send any meaningful commands.

All part of the plan. The Angry Moth shouldn't really be taking on whole convoys by itself.

Yes. The down key doesn't do anything at all right now.

The colour numbers (if you mean the ones in the collision masks) indicate what a bullet at a certain point in or around a ship's sprite (with the relative positions of the ship and bullet translated to coordinates on the bitmap) has hit: shield, a particular warship part, or nothing.

The units should pretty much all be in 2^10 pixels for the actual location of objects in the game, translated to pixel values in the display functions. I'm not sure what's 2^9; that's probably just an obfuscated way of dividing something by two while converting it to a pixel value.

Damage values are just as they're written, so a torpedo really does do about 60x as much damage as a cannon shot. The point is to establish a clear distinction between light anti-fighter weapons and heavy anti-warship weapons.

Letting the player manage the whole fleet would be fun, but the game's ship AI and level scripting systems aren't really set up for that. Maybe next game. As for issuing orders to your fighters, most of the time it's not really necessary. I just leave them set to "cover me" all the time, changing to "defend" occasionally if I want them to go away for a while (so they don't get shot down while I do something risky).