Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411279 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 05:36:13 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperPlaytestingLiberation Circuit: Rogue AI Simulator (version 1.0 now out!)
Pages: [1] 2
Print
Author Topic: Liberation Circuit: Rogue AI Simulator (version 1.0 now out!)  (Read 2103 times)
linley
Level 0
***



View Profile
« on: February 16, 2017, 07:24:08 PM »

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!

« Last Edit: March 10, 2017, 05:57:30 PM by linley » Logged

surt
Level 7
**


Meat by-product.


View Profile
« Reply #1 on: February 16, 2017, 11:05:51 PM »

Had a quick fiddle in linux.
Runs smoothly and looks great.
Found it somewhat awkward that the buttons in the top right of the screen preventing edge-scroll.
Logged

Real life would be so much better with permadeath.
PJ Gallery - OGA Gallery - CC0 Scraps
linley
Level 0
***



View Profile
« Reply #2 on: February 17, 2017, 05:31:32 AM »

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

zugz
Level 0
***


View Profile
« Reply #3 on: February 24, 2017, 10:49:29 PM »

Very nice!

To get it to compile on gentoo linux, I had to manually link with -lm and
-lallegro_foo for various values of foo.

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.

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

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

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

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

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.
Logged
linley
Level 0
***



View Profile
« Reply #4 on: February 25, 2017, 02:31:21 AM »

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.

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

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

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

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

Quote
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!

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

zugz
Level 0
***


View Profile
« Reply #5 on: February 25, 2017, 12:23:34 PM »

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

So you can. That does help! It's still a little painful to have to resize
every time I bring up a new tab - would be nice to have it remember the width
you've set for the nth panel.

The manual has details of all of the functions

Aha, I entirely missed the existence of the manual! It does the job well.

The current zoom levels are my attempt at a compromise.

I experimented with allowing view.zoom_level=1, but at least on my machine it
isn't actually usable - I get 2-4fps. So probably it's best to keep it as it
is.

I played around a bit more, and have a few more comments.

I tried to remap the control groups (I use a dvorak keyboard, for which the
defaults are horrible), but couldn't get it to work.

I'm finding it quite annoying that the map scrolls when I try to select the
buttons in the top-right for the tabs. I'm not sure what to do about it
though... maybe move the buttons to just above the minimap when the main view
is in focus, and hope it isn't too confusing that they pop up to the top-right
once selected? Assigning keys to them (e.g. F6-F10) could also help.

I believe %d is rather more common that %i as a printf escape for an integer.

I found that auto_move() doesn't handle unusual configurations of thrusters -
I tried having two pointing in opposite directions, and auto_move() just fired
them both at once, leading to plenty of spin but no travel...

I found the in-game text editor pretty painful to use, without features like
autoindent and keyboard-only navigation beyond arrow keys. But I don't suggest
you reimplement a proper programmer's editor, and I can see it does make sense
to have some kind of editor in there, if only to teach the player that there
is code for them to play with. So the only thing I'd suggest is a quick way to
fire up an external editor on a process source file (using $EDITOR on *nix).

Anyway, I'm generally pretty impressed with the project. It's a really unique
game, solidly implemented. Good luck with the final polishing!
Logged
linley
Level 0
***



View Profile
« Reply #6 on: February 25, 2017, 08:41:16 PM »

It's still a little painful to have to resize every time I bring up a new tab - would be nice to have it remember the width you've set for the nth panel.

It remembers the width for each specific panel, so if e.g. you resize the editor panel, the editor panel will stay the same width regardless of its position (although it doesn't save this to disk). This seemed like the best way to me.

Quote
Aha, I entirely missed the existence of the manual! It does the job well.

I've made it so when you start a game, the log (at the bottom of the display/editor panels) mentions the right-click help and the manual.

Quote
I experimented with allowing view.zoom_level=1, but at least on my machine it
isn't actually usable - I get 2-4fps. So probably it's best to keep it as it
is.

I've changed the zoom to be less dependent on resolution - now it tries to fit the same amount of vertical battlefield space on the screen, regardless of resolution. The way it worked before was a bit broken. It should be much more playable on a 1024x768 screen now.

Quote
I tried to remap the control groups (I use a dvorak keyboard, for which the
defaults are horrible), but couldn't get it to work.

Hm, unfortunately I don't have access to a dvorak keyboard, so I can't test this Sad

Quote
I'm finding it quite annoying that the map scrolls when I try to select the
buttons in the top-right for the tabs. I'm not sure what to do about it
though... maybe move the buttons to just above the minimap when the main view
is in focus, and hope it isn't too confusing that they pop up to the top-right
once selected? Assigning keys to them (e.g. F6-F10) could also help.

I think there needs to be a way of manually hiding the buttons when all panels are closed, so that they don't interfere with scrolling. I'm thinking of adding a new button which does this.

The function key idea is a good one, too. I haven't generally put as much thought into keyboard shortcuts as I should have.

Quote
I believe %d is rather more common that %i as a printf escape for an integer.

It is? I'll look into this and allow both if the code I need to change isn't too tangled (it's a while since I looked at that part of the compiler).

Quote
I found that auto_move() doesn't handle unusual configurations of thrusters -
I tried having two pointing in opposite directions, and auto_move() just fired
them both at once, leading to plenty of spin but no travel...

The move methods should deal with most configurations. But if there are only two thrusters, pointing in opposite directions, it may be that there's no simple way to use them to travel as they both probably produce too much spin.

Quote
I found the in-game text editor pretty painful to use, without features like
autoindent and keyboard-only navigation beyond arrow keys. But I don't suggest
you reimplement a proper programmer's editor, and I can see it does make sense
to have some kind of editor in there, if only to teach the player that there
is code for them to play with. So the only thing I'd suggest is a quick way to
fire up an external editor on a process source file (using $EDITOR on *nix).

Yeah, it's meant to be basically functional, but more complex IDE features are beyond it (and probably beyond my ability to implement!)

It would be good to have a way to open files in an external editor, but I think I would need someone else to code that as I don't have any way of testing those kinds of *nix things on Windows.

Quote
Anyway, I'm generally pretty impressed with the project. It's a really unique
game, solidly implemented. Good luck with the final polishing!

Thanks! I appreciate the detailed feedback!

Also, I've removed some unnecessary code from the custom game setup menu, so hopefully the slowdown bug you experienced is no longer there.
Logged

zugz
Level 0
***


View Profile
« Reply #7 on: February 26, 2017, 06:54:23 AM »

Thanks for the update. The changes all helped, including eliminating the
slowdown.

I think there needs to be a way of manually hiding the buttons when all panels
are closed, so that they don't interfere with scrolling. I'm thinking of
adding a new button which does this.
Actually what I think might be nicest is to have a simple toggle between
having just the main game screen visible and having other tabs open too. Then
you can place the toggle somewhere away from the scroll border, and it means
that the choice of which tabs to have open can be saved - so with one
click/keypress you can bring back whatever tabs you had open when you were
last working on something.

Quote
The function key idea is a good one, too. I haven't generally put as much
thought into keyboard shortcuts as I should have.

More would be better! I'd also like keyboard commands in the editor for
compiling and for loading and saving.

Quote
The move methods should deal with most configurations. But if there are only
two thrusters, pointing in opposite directions, it may be that there's no
simple way to use them to travel as they both probably produce too much spin.

Yeah, it seems auto_move prioritising turning to face the target over
accelerating towards it. That makes sense for many configurations, but not for
all. But maybe it's fine to let the player do the coding if they want
unconventional movement.

Quote
It would be good to have a way to open files in an external editor, but I
think I would need someone else to code that as I don't have any way of
testing those kinds of *nix things on Windows.

Actually, more important than opening an external editor is getting easy
access to what it saves. A "reload" command which doesn't make you locate the
source file every time would be great. So would be the ability to load files
for locked templates when the header hasn't changed.
Logged
linley
Level 0
***



View Profile
« Reply #8 on: February 27, 2017, 03:59:15 AM »

Quote
Actually what I think might be nicest is to have a simple toggle between
having just the main game screen visible and having other tabs open too. Then
you can place the toggle somewhere away from the scroll border, and it means
that the choice of which tabs to have open can be saved - so with one
click/keypress you can bring back whatever tabs you had open when you were
last working on something.

Ah, I understand. I'll see what I can do Smiley

Quote
But maybe it's fine to let the player do the coding if they want
unconventional movement.

Yeah, that's the plan. The autocoder and many of the higher-level methods (like .move_to()) are meant to be good enough for most situations, but they still leave plenty of scope for players to optimise process behaviour.

This is tied into what I've always meant to be the ultimate purpose of the game, which is the autonomous-mode programming-game multiplayer. Although I don't know if anyone will ever actually play it like this!

Quote
A "reload" command which doesn't make you locate the
source file every time would be great. So would be the ability to load files
for locked templates when the header hasn't changed.

I can see how these would be useful, and they shouldn't be hard to implement (the second would just require disabling the check that prevents it).
Logged

zugz
Level 0
***


View Profile
« Reply #9 on: February 28, 2017, 09:42:23 AM »

Cool, I look forward to the next update.

I can definitely imagine the autonomous mode getting some interest... maybe
(eventually) you could set up an automatic weekly tournament, where players
mail in the latest version of their template, they play each other, and the
results are announced. Could be fun!

A few more niggles and suggestions:

The in-game text editor regularly drops characters when I type, I guess
because I type faster than 1 key per frame. I don't know if allegro has an
event buffer like SDL does, but if so that would be more appropriate than just
checking for what key is being held down.

I guess this is again because I'm using a lower resolution than you test with,
but for me the minimap hides most of the component information dialogue. Maybe
the minimap could float over leftwards when it needs to?

I wonder whether it would make sense to support some C preprocessor statements
- maybe just #include, #define, and #ifdef. Of course players can run cpp
themselves to generate source files to be read by the game, but it'd be easier
if it was directly supported. This would make it much easier to develop and
maintain interdependent processes - which if you want autonomous mode to be a
big part of the game, seems important.

It could even makes sense to have a single editable master autocode file, with
the autocode function on the design screen just setting some #defines
according to the objects on the process and the chosen AI behaviour, made use
of by #ifdefs in the autocode file. That way autocode would stay useful even
when you find you want to customise the details.

One last thing: I experimented with messages, and found that check_messages()
seems to always returns a positive number even when no message had been
received, contrary to the docs.
Logged
zugz
Level 0
***


View Profile
« Reply #10 on: February 28, 2017, 12:55:48 PM »

Another little thing to add to the wishlist: a way to quit a game which doesn't exit the whole program.
Logged
michaelplzno
Level 10
*****



View Profile WWW
« Reply #11 on: February 28, 2017, 12:58:40 PM »

The trailer could use some work. Edit it down and focus a bit more on the editor and other RTS features IMO.

Also, the background, while cool, kind of distracts from the foreground because both the background and foreground use a sort of hexagon shape. If the BG were circles in a grid rather than hexes that would make the difference between FG and BG more pronounced and easier to parse visually.
Logged

linley
Level 0
***



View Profile
« Reply #12 on: March 01, 2017, 03:29:00 AM »

Another little thing to add to the wishlist: a way to quit a game which doesn't exit the whole program.

If you open the System panel (Sy) you get a quit button that exits the game without exiting the program.

I can definitely imagine the autonomous mode getting some interest... maybe
(eventually) you could set up an automatic weekly tournament, where players
mail in the latest version of their template, they play each other, and the
results are announced. Could be fun!

I'd love to do something like that! One day.

Quote
The in-game text editor regularly drops characters when I type, I guess
because I type faster than 1 key per frame. I don't know if allegro has an
event buffer like SDL does, but if so that would be more appropriate than just
checking for what key is being held down.

Allegro does have an event buffer, but I was using it in a really stupid way. Changing a while to an if fixed this problem (which I never really encountered because I don't type all that quickly).

Quote
I guess this is again because I'm using a lower resolution than you test with,
but for me the minimap hides most of the component information dialogue. Maybe
the minimap could float over leftwards when it needs to?

Moving the minimap might cause other problems, but it might make sense to move the component information. Since you can minimise it (the X button at the top of the component information box) I'm not too worried about it taking up screen space.

Quote
I wonder whether it would make sense to support some C preprocessor statements
- maybe just #include, #define, and #ifdef. Of course players can run cpp
themselves to generate source files to be read by the game, but it'd be easier
if it was directly supported. This would make it much easier to develop and
maintain interdependent processes - which if you want autonomous mode to be a
big part of the game, seems important.

Yeah, I'd like to add at least #define and #ifdef. #include is a bit trickier; I wrote a much more comprehensive compiler for the proto-version of this game (Invincible Countermeasure) and getting #include to work properly was quite difficult (unfortunately that compiler was an unmaintainable mess inside, so I scrapped it when I changed from IC to LC).

One possibility that would avoid needing to load #included files from disk each time the compiler is called may be to add a special header template, with #defines and enums and maybe subroutines, that the other source files can include at the start. I'll keep it in mind!

Quote
It could even makes sense to have a single editable master autocode file, with
the autocode function on the design screen just setting some #defines
according to the objects on the process and the chosen AI behaviour, made use
of by #ifdefs in the autocode file. That way autocode would stay useful even
when you find you want to customise the details.

Yes, a more advanced autocoder is on my to-do list.

Quote
One last thing: I experimented with messages, and found that check_messages()
seems to always returns a positive number even when no message had been
received, contrary to the docs.

You're right, it was broken. Fixed. Also, I'll update the manual to better explain how to read messages (including an example of the recommended way of using a while(next_message()) loop to read messages one by one).

Just updated the github repository with these fixes.
Logged

linley
Level 0
***



View Profile
« Reply #13 on: March 01, 2017, 04:28:20 AM »

The trailer could use some work. Edit it down and focus a bit more on the editor and other RTS features IMO.

The idea of that trailer is to give an impression of the game's theme and what the action looks like, while showing just enough of the RTS/editor stuff to convey what kind of game it is. I'm going to record a longer, more gameplay-focussed video at some point before the final release, though (after I've sorted out some final interface stuff).

Quote
Also, the background, while cool, kind of distracts from the foreground because both the background and foreground use a sort of hexagon shape. If the BG were circles in a grid rather than hexes that would make the difference between FG and BG more pronounced and easier to parse visually.

Hm... is it really that hard to tell the FG from the BG? I've been looking at the game so long that it's hard for me to know. If it is, one solution is to use the colour switching options in init.txt to change the process colours to something with more contrast. I'd prefer to avoid circles, as they require a larger vertex buffer and take longer to render.

Anyway, thanks for trying it!
Logged

zugz
Level 0
***


View Profile
« Reply #14 on: March 02, 2017, 09:55:09 AM »

Thanks, the update helped. The editor now processes my keystrokes fine.
I like the new position of the buttons on the main map screen, but there's
still a slight problem in the other direction: hitting the 'X' to get *back*
to the main screen leaves the mouse in position to scroll. This is quite
annoying and disorienting. I'm not sure what should be done about it - perhaps
just a special case for this situation that the pointer is in the scroll
border when the map is shown, making the map scroll only once the pointer
leaves the border then re-enters it.

The component box placement is fine, and thanks to the alpha blending doesn't
seriously get in the way. I think it would be worth allowing it to be closed
without closing the process box too, though.

As a datapoint: I had no problem differentiating foreground from background.
Logged
linley
Level 0
***



View Profile
« Reply #15 on: March 02, 2017, 07:27:39 PM »

Just updated the repository. Changes:

- closing all panels (or closing the last open panel) now blocks mouse scrolling until the mouse moves away, as zugz suggested. A temporary interface thing shows up when scrolling is blocked.

- there are now a few more keyboard shortcuts: ctrl-s to save, ctrl-a to save all, f8 to test compile, f9 to compile. These are indicated in the editor menus.

- I tried to implement ctrl-o to open a file, but ran into some problems with the way Allegro's keyboard routines work when opening a file dialogue box. There's a workaround in the latest unstable version of Allegro 5, but I'm using a stable version. I'll try to fix this sometime.

- there's a new "reload" function in the "File" editor menu. It reloads the current file from disk.

- it's now possible to load source code into a locked template.

... and a few minor issues fixed.
Logged

linley
Level 0
***



View Profile
« Reply #16 on: March 03, 2017, 08:43:21 PM »





A new video with plenty of RTS gameplay, playing a mission from the start: harvesting, expanding, defending, and designing new processes and sending them into battle.
Logged

zugz
Level 0
***


View Profile
« Reply #17 on: March 04, 2017, 02:24:16 AM »

- closing all panels (or closing the last open panel) now blocks mouse
  scrolling until the mouse moves away, as zugz suggested.

Great. One little problem though - when an editor tab is open, moving the
mouse to the very top-right corner leads to the main map scrolling.

Quote
- there's a new "reload" function in the "File" editor menu. It reloads the current file from disk.

Good stuff. How about a keyboard shortcut for it (^R?)?
Logged
linley
Level 0
***



View Profile
« Reply #18 on: March 04, 2017, 03:40:38 AM »

Great. One little problem though - when an editor tab is open, moving the
mouse to the very top-right corner leads to the main map scrolling.

I haven't been able to reproduce this, but I can see how it could happen if the Allegro mouse routines are reporting the mouse's position as equal to or greater than the maximum size of the display - this appears to be impossible on my system but may happen on yours. I've added a check for this which will hopefully fix the problem.

Quote
Good stuff. How about a keyboard shortcut for it (^R?)?

I considered this earlier but decided not to add it, to avoid having a single keyboard shortcut that could overwrite all changes to a source file. But it's simple to add so I've put it in as a compile-time option - if you define RELOAD_KEYBOARD_SHORTCUT (or uncomment the #define for it at about line 170 of e_editor.c) it will be available.

Just updated the repository. Hopefully the next update will be version 1.0!
« Last Edit: March 04, 2017, 04:20:45 AM by linley » Logged

zugz
Level 0
***


View Profile
« Reply #19 on: March 08, 2017, 09:32:25 AM »

Great. One little problem though - when an editor tab is open, moving the
mouse to the very top-right corner leads to the main map scrolling.

I've added a check for this which will hopefully fix the problem.

It did!

But the big commit on Wednesday (2348adf1), though it included some nice
things, seems to have broken things a bit for me. The game now runs really
slowly. The game rate seems to be scaling with fps, which it seemed not to be
before. I get about 12-15fps when not much is going on, which translates to a
painfully slow gamerate. If I turn off the background (thanks for that
option!) I get 30 fps and a decent gamerate.

Couple of other things I forgot to mention before (not affected by this
update):

When any of the 'skip' options are in effect, the game runs faster as you'd
expect, but scrolling the map is paradoxically much slower then normal.

I wonder if it would make sense to make the build queue a bit cleverer.
Currently it waits for the builder of the job at the front of the queue to
finish recycling, even if it would be possible to start a job further down in
the queue immediately. It took me a while even to realise that recycling was
per-builder rather than global, and realising it made my operations much more
efficient - but more fiddly.
Logged
Pages: [1] 2
Print
Jump to:  

Theme orange-lt created by panic