A while ago I released a beta version of a game called Invincible Countermeasure, a kind of hybrid RTS and programming game. A number of people were very helpful with comments and patches, but ultimately IC just didn't work very well as a game.

Even though it wasn't very fun, I think the basic idea of the game was sound. So I've taken the engine I wrote for Invincible Countermeasure and turned it into a new game with a focus on gameplay rather than conceptual purity. It's still the same kind of game, but with a vastly simpler API, a GUI-based process (unit) designer and an autocoder for player-designed units that lets it be played without any coding at all.

Here's a video of some gameplay.

Here's the version page on Sourceforge. I've uploaded a zip containing source code, another one containing data files (everything needed to run the game other than the executable and the Allegro dll) and one with Windows binaries (includes everything needed to run the game).

All comments welcome!

Edit: here's a screenshot, too:

{"name":"tCL4TgW.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/d\/5\/d5aceacfcddfe31b6e46bb4cac0c3cdd.png","w":762,"h":632,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/d\/5\/d5aceacfcddfe31b6e46bb4cac0c3cdd"}

You can pause the game (by pressing 'p') and give orders while it's paused. It's definitely not a game of twitch reflexes.

Is the other game you're thinking of Angry Moth?

Don't you know SourceForge is dead to the world?

Append:

Here's a simple bash script (use at own risk; SourceForge is linking to the downloads without TLS) to fetch and build for you in Linux (based on a Monolith shared object for Allegro 5).

If all goes well you'll end up with LibCirc/ and inside will be the binary, libcirc. Change to it and run it (I'm assuming the current working directory must be the root of LibCirc/).

src/c_compile.c: In function ‘add_print_string’:
src/c_compile.c:1173:2: warning: format not a string literal and no format arguments [-Wformat-security]
  snprintf(temp_string, string_length, source_string);
  ^
src/c_compile.c:1173:2: warning: format not a string literal and no format arguments [-Wformat-security]
src/d_draw.c: In function ‘draw_design_help_strings_for_help_button’:
src/d_draw.c:1065:3: warning: format not a string literal and no format arguments [-Wformat-security]
   al_draw_textf(font[FONT_BASIC].fnt, colours.base [COL_GREY] [SHADE_HIGH], base_x, line_y, ALLEGRO_ALIGN_LEFT, design_help_st
   ^
src/d_draw.c: In function ‘draw_design_help_strings_for_help_more_button’:
src/d_draw.c:1103:3: warning: format not a string literal and no format arguments [-Wformat-security]
   al_draw_textf(font[FONT_BASIC].fnt, colours.base [COL_GREY] [SHADE_HIGH], base_x, line_y, ALLEGRO_ALIGN_LEFT, design_help_st
   ^
src/t_draw.c: In function ‘draw_template_panel’:
src/t_draw.c:173:58: warning: format not a string literal and no format arguments [-Wformat-security]
    snprintf(file_path_string, TEMPLATE_FILE_PATH_LENGTH, draw_templ->source_edit->src_file_path);
                                                          ^
src/t_draw.c:173:58: warning: format not a string literal and no format arguments [-Wformat-security]

I couldn't remember Invincible Countermeasure, though I certainly remember playing it and liking it. It took a couple of seconds after starting the first mission to recognize it. I'm glad that the idea hasn't been abandoned. Looks good.

Github supports the zipped binary distribution https://help.github.com/articles/about-releases (But I have not used it).

gameovera: Thanks, I didn't know that. I'll have another look at Github, although I think to use it properly I would need to start using Git.

Edgar Reynaldo:
Thanks for trying it! To get more data you need to harvest it from a data well then process it at a unit which has an "allocate" object (which looks like a little windmill and can only be placed on an immobile unit).

The "base" unit has both a harvest object and an allocate object, so you can build a new base at a data well (using an mbuild) and harvest data directly. Or you can build a harvester to go and get data from another data well and bring it back to a base for allocation (it will automatically do this if you tell it to move near a data well). That's slower, but a harvester is cheaper than a base and can retreat if attacked.

You're right that this isn't very well explained. I'll add an extra step to the tutorial to better explain harvesters and data.

The way that units move is determined by the roughly Newtonian physics model. The little two-engine attacker units need to move forwards to turn around because the only way they can turn is by operating one engine more than the other, which generates torque. A unit with some forward-facing engines (like the "destroy" unit you can build) is able to turn more sharply.

The movement options are limited to avoid making the autocoder too complicated or the code it generates too long. Units can definitely be coded to move in other ways, though.

Windows Explorer's "Send to compressed folder" function is all the version control I need.

Nah, I have backups in various places. I just don't use a version control system.

I guess I just learned to code without it, so I have coping strategies.

Anyway, I got an email from someone saying that the game doesn't use the X11 keyboard layout (I'm guessing he uses a non-QWERTY European keyboard) so he can't use the editor. Does anyone know if there's an automatic way of dealing with non-QWERTY keyboards? Searching around suggests that earlier versions of Allegro dealt with this but I'm not sure Allegro 5 does.

Actually, after looking into European key layouts a bit more I suspect the problem is that my own input code is set up to interpret shifted keypresses on the assumption that the keyboard is a QWERTY one, and isn't treating the Alt Gr key correctly (before a minute ago I didn't even know what an Alt Gr key was).

Looks like I'll need to fix this myself, probably by adding an init file option allowing the user to set a non-QWERTY keyboard. I can't really expect the user to customise the input key-by-key as the IDE requires so many punctuation keys.

Does anyone know how to map the ALLEGRO_KEY_* codes to keys on a non-QWERTY keyboards? E.g. looking at the QWERTZ layout, I see there is a + key where the [ or ] key would be on a QWERTY keyboard. But there's no ALLEGRO_KEY_PLUS in the list of key codes.

Any ideas?

Hm, it turns out that he's using a "Neo" German keyboard, which looks like this. So the incompatibility goes a little deeper than a couple of letters and AltGr. Some google searching indicates that this is a bit of a recurring problem for Neo keyboards.

The only way I can think of to fix it would be to include new keyboard remapping code in my game, which would be simple if I knew which Allegro keycodes corresponded to which Neo keys but not so simple otherwise.

Is the keyboard.unicode value an Allegro thing? For this game, it's the actual letter being pressed (not the position on the keyboard) that matters.

It's under ALLEGRO_KEY_EQUALS, because that's the lower character on the plus key on a QWERTY keyboard.