Liberation Circuit - version 1.0!
Linley Henzell

Making a new thread because the other one is locked...

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.

The trailer.

Another video with more gameplay.

Eric Johnson

Congratulations on reaching version 1.0! I played it for a bit and wow, the sheer amount of polish is insane; everything is so sleek and smooth! I especially enjoy how smooth the interface is.

I'll have to play it some more later, but I like what I've seen so far. Well done! :D

P.S. The Windows binary worked flawlessly in Ubuntu using Wine.

Mark Oates

This is awesome Linley! Congratulations! I sent you a PM :)

bamccaig
Boooo said:

CMake 3.4 or higher is required. You are running version 3.0.2

git clone https://gitlab.kitware.com/cmake/cmake
cd cmake
prefix="/usr/local";
./bootstrap --prefix="$prefix" && make && make install

Now I need to figure out why cmake cannot find Allegro. :-/

Linley Henzell

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...

bamccaig

Maybe I'll hack up a Makefile and contribute that instead. Should be much simpler than that "redo" business or cmake...

Linley Henzell

I decided to try learning how to write my own makefile. I found some instructions here but I'm having trouble getting it to work. Here's what I have so far:

#SelectExpand
1objects = c_compile.o c_fix.o c_generate.o c_init.o c_keywords.o c_lexer.o c_prepr.o \ 2 d_code.o d_code_header.o d_design.o d_draw.o d_geo.o \ 3 e_clip.o e_complete.o e_editor.c e_files.o e_help.o e_inter.o e_log.o e_slider.o e_tools.o \ 4 f_game.o f_load.o f_save.o f_turn.o g_cloud.o g_command.o g_game.o g_group.o \ 5 g_method.o g_method_clob.o g_method_core.o g_method_misc.o g_method_pr.o g_method_std.o \ 6 g_method_sy.o g_method_uni.o g_misc.o g_motion.o g_packet.o g_proc.o g_proc_new.o g_proc_run.o \ 7 g_shapes.o g_world.o g_world_back.o g_world_map.o g_world_map_2.o \ 8 h_interface.o h_mission.o h_story.o \ 9 i_background.o i_buttons.o i_console.o i_disp_in.o i_display.o i_error.o i_input.o \ 10 i_sysmenu.o i_view.o \ 11 m_input.o m_main.o m_maths.o \ 12 p_draw.o p_init.o p_panels.o \ 13 s_menu.o s_mission.o s_turn.o \ 14 t_draw.o t_files.o t_init.o t_template.o \ 15 v_interp.o \ 16 x_init.o x_music.o x_sound.o x_synth.o \ 17 z_poly.o 18 19headers = c_compile.h c_fix.h c_generate.h c_header.h c_init.h c_keywords.h c_lexer.h c_prepr.h \ 20 d_code.h d_code_header.h d_design.h d_draw.h d_geo.h \ 21 e_clip.h e_complete.h e_editor.h e_files.h e_header.h e_help.h e_inter.h e_log.h e_slider.h e_tools.h \ 22 f_game.h f_load.h f_save.h f_turn.h \ 23 g_cloud.h g_command.h g_game.h g_group.h g_header.h g_method.h g_method_clob.h g_method_core.h \ 24 g_method_misc.h g_method_pr.h g_method_std.h g_method_sy.h g_method_uni.h g_misc.h g_motion.h g_packet.h g_proc.h \ 25 g_proc_new.h g_shapes.h g_world.h g_world_back.h g_world_map.h g_world_map_2.h \ 26 h_interface.h h_mission.h h_story.h \ 27 i_background.h i_buttons.h i_console.h i_disp_in.h i_display.h i_error.h i_header.h i_input.h \ 28 i_sysmenu.h i_view.h \ 29 m_config.h m_globvars.h m_input.h m_maths.h \ 30 p_draw.h p_init.h p_panels.h \ 31 s_menu.h s_mission.h s_turn.h \ 32 t_draw.h t_files.h t_template.h \ 33 v_interp.h \ 34 x_init.h x_music.h x_sound.h x_synth.h \ 35 z_poly.h 36 37CC=gcc 38 39libcirc : $(objects) 40 cc -I/CodeBlocks/allegro5/include/ -o libcirc $(objects) -lallegro -lm -lallegro_audio -lallegro_acodec - 41 42lallegro_font -lallegro_image -lallegro_primitives -lallegro_dialog -lallegro_main 43 44$(objects) : $(headers) 45 46.PHONY : clean 47clean : 48 rm edit $(objects)

(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...

Edgar Reynaldo

You need to change #include <allegro5/allegro.h> to #include "allegro5/allegro.h" so that it searches the proper directories. Otherwise it is searching system include directories.

Linley Henzell

Unfortunately that didn't work either.

Edgar Reynaldo

Your path is /CodeBlocks, not /c/CodeBlocks.

Linley Henzell

I've tried:
-I/CodeBlocks/allegro5/include/
-ICodeBlocks/allegro5/include/
-I/c/CodeBlocks/allegro5/include/
-Ic:/CodeBlocks/allegro5/include/
-I/c:/CodeBlocks/allegro5/include/

... still no luck.

Edgar Reynaldo

If you're using MinGW by itself, you should use -I C:/... and mingw32-make. If you're using MSYS, you should use -I c... and make.

I don't see what else might be wrong.

bamccaig

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.

Append:

First verify where Allegro really is. /c/CodeBlocks/allegro5 seems odd to me. Maybe /c/CodeBlocks/include/allegro5 makes sense. Windows' cmd or Unix's ls and find are your friends.

Append:

Here's one that appears to work in Debian, but I haven't tried actually running the game yet.

Makefile#SelectExpand
1ALLEGRO_MODULES = allegro-5 allegro_audio-5 allegro_acodec-5 allegro_dialog-5 allegro_font-5 allegro_image-5 allegro_primitives-5 2CFLAGS = $$(pkg-config --cflags $(ALLEGRO_MODULES)) -Wall 3LIBS = -lm $$(pkg-config --libs $(ALLEGRO_MODULES)) 4HEADERS = $(shell find src/ -name '*.h') 5OBJECTS = $(shell find src/ -name '*.c' | sed -e 's/\.c$$/.o/g') 6 7.PHONY: all clean 8 9all: lc 10 11clean: 12 rm -f lc src/*.o 13 14lc: $(OBJECTS) 15 gcc $(CFLAGS) -o $@ $? $(LIBS) 16 17%.o: %.c $(HEADERS) 18 gcc $(CFLAGS) -c -o $@ $<

Linley Henzell

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.

bamccaig

Is there a reason that the GitHub repo doesn't contain the following:

  • bin/Manual.html

  • bin/data/

  • bin/init.txt

  • bin/license.txt (duplicate of LICENSE.md basically)

  • bin/readme.txt

  • bin/proc/

  • bin/story/

I am inclined to add these to the root of the repo (instead of inside of 'bin'), but I don't want to if it violates your copyright/intentions.

Linley Henzell

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?

Neil Roy

Wow! :o Great game! This is exactly my style of game and the polish... I need shades it's so polished! 8-) Very nicely done!

I tried out your windows executable on Windows 7-64b and it works perfectly.

I done up a quick 1920x1080 screenshot, I felt it needed one in here.

{"name":"610824","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/d\/5\/d51ac8c744090a09c05a2b3a71112761.png","w":1920,"h":1080,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/d\/5\/d51ac8c744090a09c05a2b3a71112761"}610824

bamccaig

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

Oh, so they are!

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. :D

Linley Henzell
Quote:

Wow! :o Great game! This is exactly my style of game and the polish... I need shades it's so polished! 8-) Very nicely done!

Thanks. I appreciate it :)

bamccaig said:

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.).

-koro-
Mark Oates

Linley, did you get my PM?

Linley Henzell

Yes, and I thought I had sent a reply but it looks like I didn't press send. I'll try again.

EDIT: koro - thank you for the Mac binary! Do you mind if I put it up on the main project release page and itch.io?

Neil Roy

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.

Otherwise a really fun game.

Linley Henzell

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.)

Neil Roy said:

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.

-koro-

EDIT: koro - thank you for the Mac binary! Do you mind if I put it up on the main project release page and itch.io?

Of course not, go ahead. If anyone has an issue with it let me know (I only tested on OS X 10.9 which is a outdated).

Linley Henzell

Thanks! I've uploaded it to itch, and linked to your release on github.

Thread #616791. Printed from Allegro.cc