Anyway, Liberation Circuit v1.0 is finally up! Here's the release page, with a Windows binary and source code that should be buildable on any system supported by Allegro 5. Build instructions are in readme.txt.

I'm beginning to wonder if accepting the pull request with the cmake scripts was a mistake, since they seem to be causing problems for a lot of people. Building the game should be as simple as compiling all the source files and linking them to Allegro...

(I know that including all of the header files as prerequisites for all of the .c files is not good, but at this stage I'd prefer not to go through every .c file to work out exactly which header files it needs)

When I run mingw32-make I get this:

fatal error: allegro5/allegro.h: No such file or directory

so apparently the -I flag is not working properly (allegro.h is in c:/CodeBlocks/allegro5/include/allegro5/).

Does anyone know how to fix this? Do I need to go through every source file and change:#include <allegro5/allegro.h>to#include <allegro.h>?Or would this cause other problems?

EDIT: I tried changing the #include as above and got the same error. Then I tried adding the directory with allegro.h in it to the path and still got the same error...

As far as Makefile dependencies my advice would be to not worry so much about it. It can greatly optimize build times after the first build so it's definitely useful, but as you realize it's a lot of work to maintain and keep up to date. It's really the job of an automated process, but that basically requires the Makefile to be generated instead of hand-written. For the purposes of just getting the game built you should suffice with a much more simple file. If it takes more than 5 seconds to build then you can try to optimize your process for you. For users that build once and play it though even 30 seconds or a minute is acceptable. Insert: Welp, I guess it is useful to define all headers as dependencies so objects are rebuilt when you change a header. So I guess you're right and I'm wrong. The poor man's solution could be to delete all objects before building them.

Allegro should be installed in the system include directories. When you specify -I/path/to/allegro you're defining that as a system directory. The #include "" syntax would search relative to the current file also, plus "quote directories". This is the first I recall reading about quote directories, but apparently you can add paths with --iquote (I've never seen that before either). Quoted paths are meant for headers in your program. Third party libraries, whether part of the OS, toolchain, or otherwise are all considered system headers.

Thanks for the makefile! It looks much better than mine. I've merged the pull request.

I think my computer's directory structure may be cursed in some way. I had a similar problem trying build Allegro 5 with cmake, which refused to find one of the files it needed no matter where I put it.

I'm not sure I understand - the repo does contain them, just in the /bin subdirectory.

One reason they're all in /bin is that the proc and story subdirectories contain .c files for the game to load itself, and putting these under /bin makes it less likely that people will think they're part of the game source and try to compile them.

This is the first time I've used git, though; is this an unusual way of putting the repo together?

One reason they're all in /bin is that the proc and story subdirectories contain .c files for the game to load itself, and putting these under /bin makes it less likely that people will think they're part of the game source and try to compile them.

This is the first time I've used git, though; is this an unusual way of putting the repo together?

I'm not sure. I think it's a little bit strange to put non-executable code into bin. Typically 'bin' means executable code that the operating system can run. In Linux, if you install a program there's a good chance this kind of stuff will end up in $PREFIX/lib/<program>/ where $PREFIX is /usr, /usr/local, or /usr/games. Within your own repository these kinds of files would probably be in their own subdirectories or else in a single one like 'data'.

I think something like data/story and data/proc would make sense to me. Ultimately, users should be relying on your build system, and where that doesn't support their platform they should be following your instructions and you should detail the process in your readme or in a BUILD or INSTALL file. You don't have to worry about users just trying to compile all .c files. That would be silly. Of course, an alternative solution would be to make up your own file extension for the game C files, like .lcc or .c.lc or anything else. But having them in special subdirectories should really be enough.

As a side note, you might be able to make the user's C preprocessor ignore the code in proc and story by default by wrapping the files in something like #ifdef LC_PROC or #ifdef LC_STORY and then when you process the files in-game you define that (or whatever is necessary for those instructions to match). These are just ideas. Ultimately, if you make something as cool as this you can do it any way you want.

I'm not sure. I think it's a little bit strange to put non-executable code into bin. Typically 'bin' means executable code that the operating system can run. In Linux, if you install a program there's a good chance this kind of stuff will end up in $PREFIX/lib/<program>/ where $PREFIX is /usr, /usr/local, or /usr/games. Within your own repository these kinds of files would probably be in their own subdirectories or else in a single one like 'data'.

Ah, I see. In hindsight I should have used a different arrangment, but changing it now would require changes to the various scripts and things that other people have contributed (and that I don't know how to update). I'll move on from my DOS-based understanding of directory structure one day...

Quote:

Of course, an alternative solution would be to make up your own file extension for the game C files, like .lcc or .c.lc or anything else.

I considered this, but decided on .c to make the files easier to edit in IDEs and things (e.g. this makes Code::Blocks treat them as C files and apply the correct syntax highlighting etc.).

I played until the green level and found that awfully difficult, I had several commander ships (the biggest you can make) and one of theirs would tear them all to pieces. I tried the ship design screen, but couldn't make heads or tails of it, it was a tad confusing. It would be nice to be able to pick a ship to upgrade, and perhaps click on part of it, and maybe an arrow to upgrade it a level for a cost, something like that maybe.

I've just realised that the description of the interface object that the game gives you in the design window is wrong... I must have forgotten to update it when I changed the way interfaces work. This is bad because interfaces are pretty essential to beating all but the earliest missions. I'll have to upload a new version soon...

(They work by generating a shield that protects every component except components with either move or interface objects. There are no interface_depth objects any more.)

I played until the green level and found that awfully difficult, I had several commander ships (the biggest you can make) and one of theirs would tear them all to pieces.

Yes, it's difficult to get past blue without redesigning at least some of the processes. I think by that time you should be able to give the commander a more powerful core and an interface, at least.

Quote:

I tried the ship design screen, but couldn't make heads or tails of it, it was a tad confusing. It would be nice to be able to pick a ship to upgrade, and perhaps click on part of it, and maybe an arrow to upgrade it a level for a cost, something like that maybe.

Yeah, it's a bit more complicated than that. There are no direct upgrades; pretty much everything is a trade-off in some way. The second video I linked above has some unit redesigning in it, which may be useful.