I've finally finished a new beta version of Invincible Countermeasure! (here's the thread for the first beta).

It's a game about fighting for control of a computer system, which you can play either as an RTS or as a programming game (or both). And now it looks like this:

{"name":"spider_sm.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/6\/96332a9d9ca3f3f2ed56e2fd5b06c14e.png","w":800,"h":423,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/6\/96332a9d9ca3f3f2ed56e2fd5b06c14e"}

and this:

{"name":"panels_sm.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/9\/e9140beb6af30faa35f28ef71b500012.png","w":800,"h":423,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/9\/e9140beb6af30faa35f28ef71b500012"}

And here's a new gameplay video.

The new version has too many changes to list, but here are some of them:
- much better tutorials
- 6 new single-player missions
- improved graphics
- better controls
- all kinds of other improvements

You can get windows binaries (including everything you need to play) and source code (EDIT: which now includes all of the data files) here.
The Depot page is here.

All feedback welcome!

Keen to try it! Unfortunately remembered that I had forgotten that Allegro 5.0 doesn't work on OS X Yosemite. Will have to get the git version built and installed.
Pete

That window on the right of the second shot is the game and not your window manager? Either way, man, those are some good-looking graphics. I like your style.

Just a little note for the OP about distributing software. It's a good idea to always include a root-level directory in archives so that when extracted the files don't end up littering the destination directory. You seem to have done that, but "src - beta 2 release" is a terrible name. Also, discourage spaces in filenames. They're a pain to code with, and they add no actual value.

Instead, it would have been better to use filenames like this:

invincible-countermeasure-beta2-src.zip
`-* invincible-countermeasure-beta2/

My girlfriend and I are not feeling well so she's waiting for me to get back to the couch to watch more House, but I aim to try building and testing this out. Looks good.

Append:

= 11. Whisper♫bambams@sephiroth:~/src/invincible-countermeasure-beta2$ LD_LIBRARY_PATH=/usr/local/lib ./a.out 
Invincible Countermeasure
Copyright 2014-2015 Linley Henzell
Version: beta 2

This is free software and comes with no warranty (see licence.txt).
For instructions, read manual.htm.
To configure screen resolution etc, edit init.txt.

Have fun!


Failed to open init.txt. Starting with default settings.
Could not load sample file (data/sound/blip.wav). Sound disabled.
Error:failed to load font file (data/images/fwss_font.bmp)

Apparently the source distribution is lacking all of the resources? And the license? And configuration and everything? I would also include those files in the source unless there's some reason you can't (e.g., licensing). Generally, the source should contain everything needed to build and run it (except for third party files, particularly when their license is incompatible).

Append:

Looks like the game is GPL v3 so maybe later I'll create my own source distribution and upload it so it's easier for others.

We're up!
{"name":"609123","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/7\/47cac8452697c0380726a90a01aa477d.png","w":1061,"h":822,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/7\/47cac8452697c0380726a90a01aa477d"}

Gideon: Yes, the window on the right is part of the game - it's the built-in IDE. It is a programming game, after all.

Peter: Excellent! Good to see it compiles.

bamccaig: You're right, I didn't put that distribution together very well. I've renamed the source zip and updated it with the things you've suggested.

I have to say at first glance this looks amazing. I haven't actually been able to play it yet (I was trying to figure out how to package it up together, but perhaps you've already accomplished that), but it looks spectacular so far.

Append:

I assembled a slightly nicer package for *nix folk that seems to work at first glance, but I don't know exactly how the game works so I reserve the right for it to break depending on how it does work. There is a rudimentary Makefile in there that takes care of it on my system and a shell script launcher to take care of linking Allegro at run-time (albeit, I got lazy there and hard-coded /usr/local). There is also a Git repository that should contain all of my changes (though I created the repository in reverse so it may not be exactly accurate). It is an XZ tarball so uppercase J to decompress using a supporting tar(1).

Edit:

Edited: Copied the license to the root and added a URL file with a link back to the Depot.

Edit:

Edited: Copied manual to root (converted with html2text).

Edit:

Edited: Dynamically determine library path at build time and bake it into launcher script.

Edit:

GitHub repository for this UNIX distribution is created at https://github.com/bambams/invincible-countermeasure/. See below for updates.

It's come on a really long way since beta1, looking really good now!

I've made a OS X binary if you want it. Let me know. By the way it builds fine with Allegro 5.1.

Pete

[edit] ic-beta2-OSX.dmg

The visuals and GUI design are incredible, I really like the style. Everything is just nice to look at, especially those 'lightning' effects. I've only played through the first 2 tutorials and haven't seen how programming plays into it yet, but it sounds like a cool idea.

bamccaig:
Thanks for putting together that package. I had to add '-lm' to resolve an undefined reference to 'cos', but other than that it seems to run fine on my Archlinux system.

I went ahead and created a GitHub repository for the UNIX package at https://github.com/bambams/invincible-countermeasure/. It appears to be forked from Linley's repository. For completeness I'll include another revised version here.

Latest changes:

• I added libm to the Makefile LIBS per Erethar's report for Arch.

• I renamed license.txt to the more standard COPYING.

• I created a README* for the UNIX release branch explaining the project to the best of my ability.

* Linley, that included adding a copyright notice of "Copyright (C) 2014, 2015 Linley Henzell". Please let me know if there are any errors or changes you wish me to make and I'll fix it. Also feel free to incorporate my branch or use any of my work on this release into your own repository or code (or not, no worries).

It's quite pretty, with lots of little details and animations.
But as a game, I'm afraid it's a bit weak.
It uses the mechanisms of a classic RTS, but the ergonomy is not ideal for this :
1) Units are large and tend to drift away from each other, so a single group gets as large as the entire screen, it's difficult to rectangle-select them all. (note: playing in 1024x768, if it makes any difference)
2) Unless I missed something, the enemy units don't appear on the mini-map. So you have to drag-click on the minimap to look around, very often you catch a glimpse of a unit, but it's difficult to locate it precisely.
3) Another difficulty is with the lack of landmarks. The terrain being all the same everywhere, you don't really get an idea of which part of the larger map you're looking at.
Maybe instead of a classic RTS control, you could make units more autonomous, like Populous : The player would place and remove any number of "flags" instead, and units move around, trying to get an equal coverage of flags and factories.

Is the game drawn using vector graphics ? If it is, a smooth zoom feature would be excellent : Zoom out to view a larger area and get a "strategic" view , zoom in to see the firefight.

Peter: Thanks, I've uploaded the OSX binary to sourceforge.

bamccaig: Actually I opened that github repository before I realised that github was a bit more involved than what I needed. The repository you've set up looks good - I'll see if I can work out how to use some of your work for the next release (as you've probably worked out, I don't know very much about releasing software!).

Audric: Thanks for your comments.

1) I think I may have made a mistake by designing the game's graphics for my largish monitor, because it doesn't really work on smaller sizes like 1024x768. I'll look into how difficult it will be to implement a zoom feature (unfortunately, although the graphics are vector-based I wrote the display code with an Allegro 4 indexed colour mentality that doesn't accommodate scaling very well).

2) I'm not sure why the enemies don't appear on your mini-map, though. They should definitely be there; maybe the dots aren't bright enough to show on monitors with lower brightness settings. Does this happen on the tutorials as well as the missions, where the enemies use different colours?

3) The map doesn't start with landmarks, but does kind of get them as battles take place. But I do plan to make the background more varied at smoe point.

The RTS controls are pretty basic, but this is mostly because players can redefine them completely by rewriting the operator program (this is op_basic.c in the src or mission directory, which compiles in the game's own compiler). In fact the last couple of missions feature enemies that work on the flag-based principle you mentioned, although this may not be obvious to the player.

Minimap : I only tested tutorial, I'll check again and make a screen capture if I can.

bamccaig: what did you do about file locations for Linux? The beta2 has the exe, resources, settings file and mission progress file all under the same directory, which isn't conventional for OS X/Linux. I used al_get_standard_path() to put the init.txt and msn.dat into ALLEGRO_USER_SETTINGS_PATH.

Pete

Sorry about the minimap, there are dots indeed.

I didn't want to make any source changes since I didn't really know how the game works. The Git repository should document everything that I did, but I'm not certain. I began the work before I thought to track it with a Git repository.

Basically, I renamed the binaries directory to media since it seems to basically hold run-time files. The launcher script just changes into the media directory so that relative paths work as expected. At least, they seemed to for a basic test of starting a mission. I can't guarantee that there are no path-based bugs.

I moved source files into a new src/ directory and header files into a new include/ directory and created a Makefile and make/ directory with helpers. Predominantly, the changes I made just clean up the root directory so you can see an entire directory listing in a few lines, and added a Makefile that builds and generates a launcher script. The Makefile isn't intended to install the program anywhere because I wasn't sure how the game's compiler or interpreter works.

I avoided doing anything to the binaries directory because I couldn't be sure how it would break the game. Patches welcome if you can come up with a better way to organize it. I haven't really taken the time to play it yet, or to familiarize myself with the code. I'm really intrigued though that the game itself involves C code. I would like to come up with a way to install the game system-wide so that all users of the system could play without interfering with each other or duplicating more than is needed. I expected this would require source changes so I avoided it.

If we can figure out how to install it system-wide and shared by all users then we could even package it up for some popular distros. Either now or when a "stable" release is done. I bet that would help Linley with getting it used by more people.

Append:

I don't know if it's a bug in Allegro, the game, or LXDE, but with the game running in full-screen if I open the "Load File" dialog it doesn't appear. Nothing appears to have happened. I have to switch virtual consoles back and forth before I see it. If it affects all Linux users then it should certainly be fixed.

Shows up fine for me on fullscreen using Awesome window manager.

I did notice two other things while testing that:

1. If I press escape from the main menu, everything behind the "are you sure" popup begins flickering.

2. If I click the load button, it opens a native dialog. If I switch to another workspace and switch back, the dialog is still there but the display is black. If I 'x' out of the dialog, the dispay returns to normal.

I'm guessing it doesn't draw while the dialog is open, and somehow switching workspaces triggers the display to clear?
It's pretty minor, anyways.

Thanks for trying to fix up the directory structure! My approach to this is pretty much stuck in the DOS era, unfortunately.

If you're concerned about the compiler or interpreter generating temporary files or using other system resources, they don't do anything like that. The ways that the game loads and saves files are:
- loading the init.txt configuration file at startup
- loading the font and title bitmaps and the sound .wav files at startup
- loading and saving the msn.dat mission progress file at various points
- loading source code files from the missions directory when the player starts a mission (these source files are not meant to be changed either by the game or by the user)
- loading and saving other source code files, gamefiles, turnfiles and saved games at the user's direction

Out of those things, it's really only the init.txt and msn.dat files that might need to be kept separate for different users. Players choose where to store their own source files, saved games etc, and can put them in their own directory if they want.

That's not good. Unfortunately I suspect it's some kind of bug or incompatibility in Allegro, because the game uses Allegro's native file dialogue functions in a pretty straightforward way. I had a similar problem in Windows using true fullscreen which I fixed by using a fullscreen window instead.

If there isn't a fix for Allegro it may be that the only solution is to change the init.txt file to use a window with a resolution similar to your monitor's resolution.

That's strange. Does it happen if you press escape at any other time?

Yes, this is probably what's happening. The native dialogues block the game's execution so it can't refresh the display or anything else. I think there's a way to avoid this by opening the dialogues in a separate thread, but that would be quite complicated and probably error-prone.

I suggest using Allegro's _get_standard_path API then, i.e:

• loading the init.txt configuration file at startup -> ALLEGRO_USER_SETTINGS_PATH

• loading the font and title bitmaps and the sound .wav files at startup -> ALLEGRO_RESOURCES_PATH

• loading and saving the msn.dat mission progress file at various points -> ALLEGRO_USER_SETTINGS_PATH

• loading source code files from the missions directory when the player starts a mission (these source files are not meant to be changed either by the game or by the user) -> ALLEGRO_RESOURCES_PATH

• loading and saving other source code files, gamefiles, turnfiles and saved games at the user's direction -> ALLEGRO_USER_DOCUMENTS_PATH

I could implement this then put in a pull request to bam's repository?

On the error reports, I couldn't see any flickering when ESC was pressed, or any issues with the native dialogs.

I have one more observation: when playing windowed it still responds to mouse moves even when it's not the foreground app, which usually means the playfield will scroll over to one edge or another. Anyone else get this?

Cheers,
Pete

Any of the menu screens, but not in the actual game.

That sounds easy enough then. I had trouble grepping for file system paths. Perhaps Peter Hull will do better figuring it out. Otherwise, I might take another stab at it.

Good idea. Yes, that seems to work fine. I think it's more or less a "bug" or misfeature in Allegro.

OK, I have seen it on linux now if I attempt to close the window with the 'X' in the top right.
I'll see if I can figure it out!

[edit]: In close_window_box the program goes into a tight loop, drawing the dialog and calling al_flip_display When double buffering is used, the rest of the screen is not touched and therefore oscillates between the last two frames. Depending on how different they were you'll see more or less flicker. AFAICS it does happen during the game, too, if you try to exit while your processes are moving across the screen you'll see them wobble back a forth a tiny bit.

To solve this, is there a function that will redraw the rest of the screen appropriately (i.e. menus or gameplay)? If not, the backbuffer could be copied to a temp bitmap and used for the background for each frame. Or, is there a clever Allegro way to do that, which I'm not aware of!?

Linley, there is a Linux Mint user having trouble building using my Makefile. I suspect the problem is that I'm assuming Allegro 5.1 (which is just what I happened to install), but he is using Allegro 5.0.

https://github.com/bambams/invincible-countermeasure/issues/1

Which version of Allegro 5 are you using? Is it 5.0 or 5.1? Do you know of any problem using Allegro 5.0? In the meantime I'll try to see if I can coerce the Makefile to auto-detect this, assuming that either will suffice.

bamccaig: I'm using 5.0.10. I think his problem is that he's not using the correct linker options to link to the allegro library or the maths library. If the libraries weren't installed at all he wouldn't have been able to compile anything.

He posted a similar question at the other repository I set up for the game,
here, which suggests that he might not be using your makefile. Other than that, I'm not really sure what could be going wrong.

Peter: It would be great if you could implement the directory fix using _get_standard_path. I'm not sure how directories work in multi-user environments and I'd probably get it wrong.

I have the issue you describe with the game responding to mouse controls when the window isn't in the foreground, but it's never really bothered me so I haven't fixed it. I think it should be fixable by detecting the ALLEGRO_EVENT_DISPLAY_SWITCH_IN and ALLEGRO_EVENT_DISPLAY_SWITCH_OUT events; I'll look into this.

I haven't been able to reproduce the flickering problem with close_window_box(), or even the slight wobbling effect you describe. This is probably something to do with differences in the way different OSes or video card drivers treat double buffering.

One solution may be to uncomment the line:
al_set_target_bitmap(al_get_backbuffer(display));
at the end of the while loop in close_window_box(). I'm actually not sure why I commented that out.

If that doesn't work, I'll look into making it possible to call the standard display routines from close_window_box(), which isn't really possible now. You could try also uncommenting the line:
al_clear_to_color(colours.base [COL_BLUE] [SHADE_LOW]);
at the start of the loop, which at least should stop the flickering.

I'm assuming the problem is either linking to the wrong Allegro version (well, no, that wouldn't make sense, but I digress) or perhaps the libraries being listed in the middle of the command instead of the end (some inferior platforms require the libraries to be at the end, I think).

https://github.com/bambams/invincible-countermeasure/compare/bambams:3b83fcba28a61c286581650abc921d8ededca1e1...084c5d53211ae86168cd95548377c06639e2231b

I've asked him to try that and see if it helps. Otherwise, I may require some assistance from Allegro developers or Linux Mint users to diagnose this...

Append:

He replied back. Now he's getting this as output:

Package allegro-5 was not found in the pkg-config search path.
Perhaps you should add the directory containing `allegro-5.pc'
to the PKG_CONFIG_PATH environment variable
No package 'allegro-5' found
Makefile:18: *** commands commence before first target.  Stop.

That doesn't make sense to me. The original Makefile had allegro-5 hard-coded... That error should have occurred sooner. I can't help wondering if he's just trolling. Failing that, I can't imagine how to debug this without installing an amd64 build of Linux Mint and trying for myself...

Linley: - will do.

Regarding the Linux makefile, I had some problems with Xubuntu (both it and Mint are based on Ubuntu I believe). The libraries had to come after the .o files on the command line, and also they were registered with pkg-config as allegro-5.0 etc. instead of just allegro-5

Thanks, Peter. Those are the exact problems that I aimed to address with the last set of patches and that pleases me because it means that I was on the right track. Upon further investigation it appears that my fixes had some bugs.

It turns out that Makefiles are sensitive to tab characters even outside of rules. The art of Makefile authoring is still coming to me, obviously. In particular, don't use tabs for indentation outside of rules. Or at least, so I gather. This can be somewhat accidental since it basically requires mixed indentation in Makefiles (or else no indentation outside of rules).

The second bug that I had was in my script to detect Allegro versions. For one thing, it didn't silence stderr while it queried pkg-config for different Allegro versions, which would result in ugly error output that was meant to be ignored. For another, it was attempting to capture stdout and check for content whereas it appears that the exit status is a sufficient condition.

These bugs have been fixed:

https://github.com/bambams/invincible-countermeasure/compare/bambams:084c5d53211ae86168cd95548377c06639e2231b...8020d416b21bf7b20dead4fc4cb4ae377ca85052

The whole set of fixes then becomes:

https://github.com/bambams/invincible-countermeasure/compare/bambams:3b83fcba28a61c286581650abc921d8ededca1e1...8020d416b21bf7b20dead4fc4cb4ae377ca85052

I'll update the issue and see if that helps its OP.

On the subject of Makefiles, the link action should use `$^` (all prerequisites) rather than `$?` (all prerequisites newer than the target).

http://www.gnu.org/software/make/manual/make.html#Automatic-Variables

Pete

Good catch, Pete. Thanks.

Append:

That user's issue has been resolved and closed.

I've put in a pull request, never done this before so hopefully it'll be right.
Pete
https://github.com/bambams/invincible-countermeasure/pull/2

"Right" is subjective. Everybody wants it done a different way (to get it "correct" in a busy environment you basically have to ask, or just try and fix it after). Ultimately, you accomplished the core mechanic that is a pull request (publish the branch somewhere, send correspondence asking upstream to merge it in). There are some changes that I'd like to make before I merge (I try to be a perfectionist), but they're mostly subjective. And with the work that you've done I might be able to figure out an install target. I'll try to work on it this weekend. Thanks!

Yay!

On the code, my aim was to have a solution applicable to Windows, Mac and Linux, and to change Linley's code as little as possible.

I've run into a little snag though - when Xcode is building in development mode it puts the resources in a dir with a very long name, e.g. /Users/peterhull/Library/Developer/Xcode/DerivedData/Countermeasure-edbvuuhnycilvsaagjhpogqmjkcn/Build/Products/Debug/Countermeasure.app/Contents/Resources/data/images/fwss_font.bmp but the IC code has a hard limit of 100 chars for a path.
One option would be to go back to doing a chdir to the resource directory as you did with your launcher, but I've had problems in the past where File Open dialogs change the CWD which would mess that up. What's your opinion?

Pete

You should be able to get away with just changing FILE_PATH_LENGTH (in g_header.h) from 100 to whatever you need it to be.