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 say it's a RTS. I assume that means I can't pause the game to give orders? I don't like feeling so rushed when I play a game. I like the strategy aspect more than the real-time aspect. This reminds me of another game you made that was very similar, about 5 years ago or so? I don't remember what it was called, but I don't think there was any programming involved, only space battles. I liked that game but it was too hard for me.

If I have time, I'll try to give your game a whirl.

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?

Oh good! Thank god for pause.

I think that was the game, yes. Good game, but I wasn't very good at it.

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.

Thanks for the bash script. I have to admit that I am mostly ignorant of such things.

Sourceforce does have its problems (although I think it changed ownership a few months ago and the new owners have at least claimed that they'll try to clean it up) but I've had trouble finding a good alternative. Everyone seems to use Github these days, but it's not ideal for binary distribution; all I want is a place to upload zips with source code and Windows binaries and at least Sourceforge lets me do that without too much trouble.

Has anyone used FossHub? It looks like it might be okay as a substitute.

(I've set up an allegro.cc project, but they tend to take a while to start working)

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

The game is not quite what I expected. It's not bad, but there are some explanations of basic gameplay missing. For example, I'm not sure what the difference between an mbuild and a harvester is. What does a harvester do? How do I get more data? By using mbuilds? I'm just a little confused.

It would be nice if there were more movement options, like stationary rotation, strafing, and wheeling. It feels dumb that ships accelerate away from targets if they are facing away from them instead of just turning to face the attacker.

I never got into the programming aspect of it, as I was too busy trying to figure out basic gameplay.

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.

Wait, if you're not using Git, what are you using?

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

^
100% of the coders who lose everything in hard drive failure agree with this.

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

The beautiful part of version control is being able to review what you've changed and restore various states easily. Even if all you ever do is "add . && commit -m snapshot" you'll benefit from having various states. And they're stored more efficiently than the zip files.

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.

I'm not sure, but perhaps if you provide UI to customize the inputs by letting the user pick an "action", signal that they'll type an input, and then you reading the next input to fill in that slot would let such users customize the input to match their keyboard... I doubt that the layout matters. It probably has more to do with the actual "characters" not matching what you're expecting. I'm guessing. Providing a UI for the user to enter their own might suffice (this is assuming that the Allegro API will give you a means to visualize arbitrary keyboard inputs, but I suppose you could always display low-level codes at the worst...). /dunno

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?

For your purpose, I think you just need to accept both AltGr and Alt as modifiers for your ALT-something shortcuts.

For shortcuts based on physical locations, use the keycode (ex: W A S D will be the right keycodes on any keyboard for cursor-type movement, 1234567890 are the 10 top keys - even on AZERTY keyboards where, without SHIFT, they type &é"'(-è_çà

For shortcuts based on an actual letter (Ctrl-M -> Move), test for the keyboard.unicode value.

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.

I mistyped, it's the field keyboard.unichar from event ALLEGRO_EVENT_KEY_CHAR :
http://liballeg.org/a5docs/trunk/events.html#allegro_event_key_char
The event includes the modifier flags (+Ctrl, +Shift, etc.).

If DirectX works correctly with these keyboards, "character-emitting" keys will cause this event, with the right ünicode character.
Should be simple in your case : The unicode id of all a-z A-Z letters has the same value as the ASCII codes, so you can test if (event.keyboard.unichar == 'a')

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

Thanks - that looks like exactly what I need. I'll give it a try.

Edit: And it worked! Cheers for that.