Thanks for your detailed comments!

On a 1024x768 sreen, the help text in the design tab flows off the screen, and
in-game text editor shows too few columns to be usable. I'd suggest having the
rightmost tab take up more of the width of the screen than it does.

You can resize the panels! (except the template panel)

Move the mouse over the edge and the cursor turns into a pair of arrows, which you can drag left and right.

If I select 'custom game' from the main menu, everything slows to a 0.2fps
crawl until I quit the game.

This shouldn't be happening! I'll see if I can work out what's going wrong here - most likely it's some kind of memory error that doesn't cause problems on my Windows setup but does on systems with less forgiving memory management.

It would be very nice to be able to rebind keys by name rather than keycode,
at least for alphanumerics.

I do see what you mean, but the key rebinding is mostly there for people who use non-QWERTY keyboards. Adding key names wouldn't work for them (because there are so many keyboard layouts out there that I couldn't match the names to the codes for all of them), and would probably cause more confusion.

As for the game itself: I've played only the first three levels and fiddled
about a bit with the designer. It all seems pretty smooth. The design
interface was slightly confusing at first, particularly with the role of
uplinks and downlinks, but became clear after a little experimentation.

I've been meaning to make the way uplinks/downlinks work a bit clearer. I should do that.

I haven't really experimented with the coding aspect. It looks feasible and
plausibly fun, but pretty daunting! I don't see any documentation of the 'auto
classes' or the basic functions like scan_for_threat() - is the idea that you
figure these out from the few samples provided, or are you meant to sourcedive
into the actual game source?

The manual has details of all of the functions, and right-clicking on a keyword in the editor gives a quick description of what it does, the parameters it takes and its return value.

I should add a hint about this somewhere, though, because you're right that it's not obvious.

In principle, designing and on-the-fly adapting an RTS AI does sound like a
lot of fun (though probably a pretty niche kind of fun!).

I hope so!

One thing - since you already seem to have set up the graphics structure to
allow arbitrary zoom, it would be very nice to be able to zoom out arbitrarily
far in the main game screen. I think it would make for a more intuitively
fluid way of navigating the map than using the minimap.

This is a perennial problem for designers of RTSs and similar games - most players prefer to play at a zoom level that lets them see as much of the battlefield as possible, but if it's too far out they don't see the graphics. The current zoom levels are my attempt at a compromise. However, at the moment they don't deal very well with lower resolutions like 1024x768, and I need to fix that.

Thanks for trying it! Good to know it works on Linux.

The button/scrolling thing is tricky to get right - the buttons needs to be easily available, and it's annoying for the map to scroll when you're just trying to open the editor, but the scrolling dead zone can be annoying too. Maybe I'll think of a solution eventually...

I've finally finished a beta release of Liberation Circuit, and I'd love some feedback on it!



Here's the Devlog: https://forums.tigsource.com/index.php?topic=48505.0

And the trailer:



It's an RTS about escaping from the hostile computer system. It has optional programming elements (you can design your own units and code their AI) but it can be played just as an RTS if you want.

Currently available for Windows at github:
https://github.com/linleyh/liberation-circuit/releases/tag/beta (download LibCirc_v0.99_beta.zip and run LibCirc.exe)

But it should build on any system supported by Allegro 5. The main github page is here: https://github.com/linleyh/liberation-circuit

All feedback appreciated!

I think it's finished!



But it probably needs a little bit of testing, so I've called this a beta release. Here's the Windows binary:

https://github.com/linleyh/liberation-circuit/releases/tag/beta

(to play, download LibCirc_v0.99_beta.zip and unzip, then run LibCirc.exe)

Here's the general github page for the game:

https://github.com/linleyh/liberation-circuit

And I've put a trailer up on Youtube:





I'd really appreciate any feedback on this version. Have fun!

Almost there! All I have left to do is finish writing the AI for the last few missions, and a bit of testing. Plus fixing any problems I find along the way, which is of course the part that takes the most time.

A couple of screenshots, which show the new, improved explosions, the more detailed backgrounds and a number of other changes. More to come!

Okay, I've *finally* put it up on github . The version there is very much a work-in-progress, but here it is:

https://github.com/linleyh/liberation-circuit

I've finally finished something I've been meaning to do for too long - adding drag-and-drop mouse controls to the process designer. I've also improved the selection indicator graphics, which were not very good; now they look like this:





You can drag an object (like the forward pulse object selected here) to move it to any other position on the process, and press shift to copy instead of moving. Objects and components are now rotated by dragging a rotation icon (the red thing with arrows) around instead of holding shift, which was kind of awkward in practice. Components can be moved around in a similar way, by clicking on the links connecting them together and dragging to another position (although copying components is not implemented at the moment). It's much better!

I'm working on the backgrounds, which have up until now just been tiled hexagons with slightly randomised sizes (although they can be altered to some extent by events in the game). Latest addition: a fairly subtle parallax scrolling effect:

Just added control groups - just like Starcraft 2, you can set a control group by pressing ctrl and a number (1-9) while some processes are selected, add to a control group by pressing shift and a number, and select a control group by pressing just the number (pressing it twice centres the display on the first member of the group).

This stuff is hard. I think the next game I write is going to have a very simple user interface...

Time for a new release version! Alpha 2 is up at sourceforce:

Windows executable
Source code
Version page

In this version:

• Many interface improvements
• A more comprehensive tutorial
• Some AI updates
• Some bug fixes (including an annoying memory leak)
• Lots of other things

This version opens to a fullscreen window by default, so if that will annoy you please edit init.txt before running it (see instructions in the text file).

This video shows the gameplay in more detail, including designing a new process and using the code editor (at the start I copy the code from the tri_base process into template 0, so that the more expensive tri_base process spawns at the beginning).

I like the leaf shapes on A1 and A3, but I also like the 3D effect that the shading gives A2 and B1. I think if you shaded A3 by darkening the lower/side leaves and slightly brightening the upper/front leaves (but not too uniformly) you would get the ultimate tree.

Some progress towards a beta release:

• A clearer and more useful tutorial
• Various improvements in the autocoded AI - in particular, it's less likely to collide with the enemy now
• Less bouncy collision physics
• A less cluttered interface - the process information box can be minimised now, and the console is smaller
• Fewer annoying method failure messages for things like trying to build with insufficient data
• The procedural music now starts off simple, then builds in complexity. It also has several more possible scales
• The build queue and font improvements mentioned above
• Better graphics for harvesting, transferring and repairing
• Support for non-QWERTY keyboards and key remapping
• Notifications when your units come under attack
• Follow mode, in which the display tracks the selected process
• Rebalancing and other minor changes - I think the stream method (the beam thing) is still a bit too good

I still need to do more testing, and update the manual with some of the API changes related to the build queue. I'm also thinking about adding a special chaos mission where the data well placement and the enemy's units are randomised to some extent, which could be interesting. Story mode will have to wait for something closer to the final release!

I had a problem with coordinating units building other units: if there were (say) 3 builders, with 2 of them trying to build multiple cheap units and 1 trying to build an expensive unit, the cheap units would use up all of the resources (data) as fast as they could be accumulated and the expensive unit would never get built.

This would be easy to fix if units had a single command program that could allocate building tasks in a unified way, but not so easy for LC's distributed unit AI. In the alpha release I dealt with it (for the enemy mission AI) by having the builder that was trying to make the expensive unit send out a broadcast asking other builders to stop building anything until the expensive unit was finished. But this was awkward and complicated.

Anyway, my solution was to add a unified build queue for each player, including computer-controlled players. Builder units can add build orders to it, and when one of a builder's orders is at the front of the queue it can execute it with a simple build_from_queue() call. Build commands given by the user through the mouse interface automatically go on the queue (and the user can also cancel orders on the queue or move them up and down). It seems to work!

Anyway, I'm not sure about the font I used for most of the in-game text; the individual letters look okay, but it's hard to read somehow (part of the problem is that it needs to be fixed-width for various reasons). I'm thinking of going back to an older font with more rounded letters:



(example text from the tutorial mission: the current font is on the top; the new, rounded font is on the bottom).

Yeah, I think the rounded one is the way to go.

If anyone is interested in building their own Linux version, bamccaig at the allegro.cc forum has written a bash script to download and build the game (requires Allegro 5, of course). Here it is.

As he points out, Sourceforge has been getting itself a not-great reputation in the last few years. Does anyone know of any good alternatives (for FOSS projects) that are suitable for distributing binaries as well as source? Github seems to be focussed on collaboration through git and isn't really what I need. Maybe Fosshub?

Sorry for the lack of updates, but it's difficult to make an interesting story out of things like "I fixed a bug in the expression parser" or "now the manual has a few pictures in it".

Anyway, time for a work-in-progress release! Version alpha 1 is now up at Sourceforge:

Windows binary (run LibCirc.exe to play; all data files and the manual are included in the zip)
Source code (requires the Allegro 5 library; should compile on any platform supported by Allegro)

Here's a few minutes of gameplay:



The game is set up to run in a window, in case trying to run in fullscreen is a problem for some people. I suggest editing init.txt to make it run in fullscreen windowed mode if possible.

In this version:

• the basic gameplay is all there
• the autocoder generates all the code you need to play it like an RTS without doing any programming (the blue processes in the video are all autocoded)
• there are 7 increasingly difficult missions to play, including a tutorial
• asynchronous multiplayer is in
• there's a (mostly complete) description of the API in the manual

Still to come:

• rebalancing
• new components and objects
• story mode
• compiler optimisations
• lots of other stuff

Have fun. All comments/critique appreciated!

So progress has been steady but slow...



These are autonomous (i.e. not user-controlled) processes - the large yellow one is a kind of leader which broadcasts a signal to other nearby processes, and the little yellow ones are followers that listen for the signal and, once they find it, swirl around the source. The blue process had some followers too, but they didn't make it

I've changed the fog of war effect again. I liked the look of the one I had before (the animated gif up the page) but the overall effect was kind of oppressive, as if there were always dark clouds rolling across the screen and closing over the player's vision. Also changed are the packet (bullet) and move object (engine) effects - now they look kind of like waves rippling along, instead of like more chunks of flat-shaded pixels.

And I just realised a few days ago that one of the fixed-point maths functions I was using (hypot) was secretly calling a floating-point function and converting the result back into fixed point. That's not good, because if I want the game to run consistently across as many different systems as possible I can't use any floating-point stuff in the gameplay code (there's plenty in the display code, though). Fortunately it turned out to be easier than expected to implement an integer-based sqrt, and not much slower.

Now I'm working on the manual. I know no-one reads manuals anymore, but this game really needs a readable specification for the programming API. It turns out that technical writing is not that easy!

Well, development has been ticking along slowly but kind of steadily. Here's an update:


This is a harvester process gathering data from a data well. You can see its movement objects at the back, its harvest object at the front, and one data storage object on each side. The yellow centre of the data well indicates how much data is presently available, and the orange things around it indicate its reserves (from which the available data will be replenished gradually).

Data is the basic currency of the game's economy; you need to gather it from data wells and bring it back to a process with an allocation object, which makes the data available to build new processes. Or you could use a builder process to build an allocator process near the data well (an allocator process is immobile).



A process with long-range attack objects engages an immobile defensive process. The attacker has front-facing move objects which allow it to move backwards to keep its distance, although if it loses sight of its target it will probably stop firing unless it has a spotter (all processes on the same side share vision, with some limitations) or is configured to keep firing blindly.




A couple of larger processes face off. Each is partly protected by an interface (aka a shield) which can absorb a large amount of damage, but once it goes down the process can be destroyed component by component.

I've tried to play the demo but can't get it to work - I can go through the menu and start a championship or practice game, and the track comes up on the screen and music starts playing, but cars never appear on the track. Things that look like shadows of cars appear, but they don't do anything.

The program doesn't seem to lock up, because I can pause/unpause and use the options menu.

(Tried on Windows 7 in both Firefox and IE)

Have I just missed some kind of "start game" button? Anything I can do to try and work out what's going wrong?

Okay, third try at the fog of war effect:



This one's my favourite so far.