Just looking, this reminds me of Battleships Forever (and Warning Forever, Captain Forever, etc).
Yep, I love the visual style of Warning Forever! The structure of a process in this game (a core with trees of linked components, each with weapons etc attached to points around the edge) is similar to the structure of a WF boss as well.
I've been meaning to try TIS-100 as well. Looks like it's on GOG, so I have no excuse...
TIS-100 is great fun! So much that I got the 100% achievement^^ Spacechem too. But those are more like puzzle games and not about scripting agents like Liberation Circuit seems to be.
Yes.
I always liked the idea of Core Wars, but its hardcore asm-like nature kept me away (although I had to learn some of the basic ideas behind asm to write a compiler for this game, so I should probably try it sometime). I did look at a few of the agent-combat-based games like PCRobots, Robocode etc as well, but while the concept was fascinating in theory, in practice I didn't find the focus on maximising the performance of a single robot or whatever against other identical robots all that interesting.
Since I started working on this game new kinds of programming games have come out, like Code Combat and Else Heart.Break(). But I don't think there's anything else quite like Liberation Circuit yet.
I like the new shot at the fog of war a lot better. I'm sure you could leave it that way but if I were asked to implement this (no time constraints and all) I'd probably experiment with animated voronoi.
I love the look of voronoi patterns (I didn't know what these were called before - thanks!) but I think even the optimised algorithms to generate them will be too complex and expensive to use them as animations. However, I'm experimenting with improvements that should allow non-rectangular bits of shadow without the smooth horizontal and vertical lines in the version I posted, and this might make voronoi-like patterns with fixed points/borders possible.
Processes can use printf() to send formatted text to a console on the display, and there'll be a verbose-error mode which will automatically inform the player of execution errors like out-of-bounds memory access (all memory access by in-game programs is rigorously bounds-checked, so these should always be caught), or specific errors in calls to built-in functions/methods. These error messages will probably mention which line of the source code the error occurred on.
Eventually there'll also be a way to generate a readable asm-like representation of the bytecode that the compiler produces, as well as an inline assembler and (maybe) dissassembler.
Other than that, I'm not sure - I'm not very familiar with other kinds of debugging tools, and writing decent user interfaces for things like that is really hard!
my own project used to be a code-game too, I just added simple text-output and basic shapes that overlay the view. now its a racing game, but I still have the editor stuff and plan to get back to it some time.
What kind of code did it use? I've been looking for a good programming game ever since I tried to work out PCRobots in DOS many years ago, but haven't had much luck (thus this project).
Okay, here's another shot at the fog of war effect. Instead of an alpha blend, the hidden part breaks up as a unit approaches and reforms as the unit leaves. The visible area is square, which reflects the way units see the world:
I'd consider to make the Fog-of-war by fading the background polys to black. That fuzzy black overlay looks off.
Yeah, I was thinking of something like that but the fuzzy overlay thing was easier to implement. I might try a few other approaches and see how they look.
Quote
Could you post a screenshot where the code is readable? Can you script only the behavior but also the form and capabilites of ships?
Here's a screenshot of the unit designer and the code editor, with a basic process loaded in:
Unit form and capability is coded in the header between the #process and #code lines, and you can design anything you like within the game's rules about cost, weight, maximum number of components etc. The header can be hand-edited, but it's much easier to use the designer and get it to automatically generate the header for you.
The rest of the code is most of the AI for a simple unit that wanders randomly around the map looking for something to attack.
(edit: I should mention that you can play without touching a line of code - the game can generate it for you based on the unit design)
The RTS part of the game (where the player designs and directly controls the units) will just be Player vs AI, at least at first.
The pure coding part of the game (where the player designs units and gives them AI, but doesn't control them directly after the game starts) will be both Player vs AI and Player vs Player - PvP will involve loading your units and someone else's units into a game and seeing who wins.
It should be possible to network the RTS part as well, but the last networked game I wrote used libnet to play over serial cable in DOS and I don't really have the skills to do the same kind of thing with modern technology...
I was originally going to let the player see the entire map and everything going on in the game, but now I'm thinking that some kind of fog of war might make the game more interesting - scouting and information-gathering will become important and you never know exactly what's going on.
The obvious way to implement it is to prepare a display-sized bitmap filled with solid black, then cut holes in it around each unit with some alpha blending around the edges, then blit it over the display like so:
The map down the bottom right works in a similar way.
I thought this would slow things down a lot, but even with lots of things on a zoomed-out screen it doesn't make a huge difference to the framerate. Nice!
The problem with doing fog of war like this is that it doesn't give a direct way to work out whether any particular enemy unit is visible, e.g. if you click on it. I'll probably deal with this by splitting the map into blocks then, each tick/frame, updating the blocks in a circle around each unit with a timestamp indicating that anything in the block is currently visible.
The graphics have been overhauled and everything looks much better now. The game is in an almost playable state (although far from finished), and fixing up the user interface is my next job. The unit AI generator is working properly now and produces AI capable of accepting various commands and doing a few things by itself, like acquiring targets for defensive weapons and aiming them, but things like selection and target indicator graphics need work. More soon!
UPDATE (15 April 2017) - version 1.3 adds an integrated debugger: here.
UPDATE (31 March 2017) - time for version 1.2! See here.
UPDATE (11 March 2017) - version 1.0 is up! See here.
UPDATE (3 March 2017) - A new beta release! See this post.
UPDATE (17 February 2017) - A beta release! And a trailer! The post.
UPDATE (4 August 2016) - I've uploaded a new release. Here's the post.
UPDATE (5 July 2016) - I've uploaded a work-in-progress release and a video. See this post.
...
Liberation Circuit is a real-time strategy game about processes battling for control of a computer system. At this stage of development it looks like this:
and this:
As well as being a unit in the RTS each process is also an actual program, written in a (very) simplified version of C and running as bytecode in a simple virtual machine. The game has a graphical process designer that lets you design processes by putting them together, piece by piece, and then automatically generates code to run the processes you design. But if you want to fine-tune your units you can use the game's built-in code editor and compiler to change the way they respond to your commands or give them completely autonomous AI.
So it's basically an RTS that you can also play as a programming game.
IC was a fascinating development project but unfortunately didn't really work as a game - the RTS part was too drifty and slow and the programming part was impossibly complicated. LC should fix both of those problems: the action will be much faster and more exciting (and at 60fps instead of 30) and the API is vastly simpler and easier to use (as well as being optional if you want to use the designer instead of hand-coding everything).
It will be released under the GPL and since it uses Allegro it will run on various platforms (at least Windows, Linux and Mac).
Progress: the basic game engine, bytecode interpreter, compiler, process designer, and code editor are working, although they'll all get some more polish. You can put together a process in the designer, auto-generate code to run it, compile the code, create the process in the game-world then tell it to move around and attack another process.
Still to do: - adding more "objects" (the bits attached to processes that let them do things, like move and attack) - visual effects like explosions (the effects in Invincible Countermeasure left plenty of scope for improvement) - sound effects and music. If I have time I'd like to write my own software synth - better backgrounds - some kind of multiplayer - many other things!
I don't usually like puzzle games, but something about the art style appealed to me and I downloaded this game. No problems getting it to work on Windows, except that the text files (README etc) lack .txt extensions, which makes them slightly difficult to open, and they don't have the kind of line breaks that Windows expects (opening in Notepad gives no line breaks at all; opening in Wordpad gives too many line breaks, in the wrong places).
I got up to tutorial 4 before I got stuck; the tutorials explain what the tools do but don't really explain how the spring physics work, and I think I needed to know more about that to get through tutorial 4 (I guessed I needed to press down both yellow springs at once so that the green spring would retract, but I spent a while trying to do this, and anything else I could think of, and nothing worked).
I like the way the art style looks in a screenshot, but the graphics are kind of dry in action. It really needs little things like transitional animations when a tool or a spring moves from one position or state to another, and more feedback when you try to do something that doesn't work. Basic sound effects would go a long way, too.
Also, the blocking force arrows are useful and should probably be on by default.
Windows binaries and source code are available. The game should also compile on Linux, Mac and other systems supported by Allegro 5 as well (if you compile it yourself, you'll need the data files from the Windows binaries to run it).
The new version has too many changes to list, but here are some of them: - much better tutorials - 6 new missions - improved graphics - legible fonts - better controls - all kinds of other improvements
The next version isn't quite ready yet, but it's coming along - I'll probably do another release with all (or almost all) game features implemented, then sit down and write a proper campaign mode with maybe even some kind of story for a version 1.0 release. I'm thinking about a new name as well.
Here's what it looks like now:
New stuff implemented so far:
Multisampled anti-aliasing! This was broken in the version of Allegro I was using before, but it's fixed in 5.0.10 and it makes the graphics look much, much better.
Waypoints, as Ziz suggested.
Easier-to-read fonts, also as Ziz suggested.
Numerous other interface improvements.
Various things to encourage the use of large multi-segmented super-processes like the one in the picture, such as shared irpt/data pools (connected processes no longer have to expressly shuffle resources between each other) and the new virtual interface method (a.k.a. shield)
Fullscreen mode (actually fullscreen window, which is slightly different, but true fullscreen seems to play badly with native file windows)
An optional special mouse cursor to fix the problems Vallar had with the mouse.
All kinds of other things.
I also need to work out how to write a makefile, which is something I should have done a long time ago...
Thanks for your comments! I'm going to address the interface issues and some of the AI issues in the next version, and work on the tutorial a bit as well.
11- The mouse still doesn't point in the correct location. It is 3-5 pixels off to the bottom (even after editing the file to the exact screen resolution I am using).
I honestly don't know about this one, though. It sounds like it might be a problem with Allegro, or at least with the way Allegro works on your particular system. I'm working on the way the game deals with display modes, though, so that might help.
I downloaded the game and tried to play it. Unfortunately the window starts in window mode and the location of the window is a bit off my desktop's screen to the top left. I can't make it full screen and I can't move the window either (the game window).
I think this happens when the resolution is set too high. Try editing init.txt and reducing the resolution to 1024x768, or something else that will fit on your monitor (1024x768 is the minimum, though).
The information in the green console window is probably more useful when the player is designing new processes than when they're just ordering processes around and don't care about things like the value of each of the process's 64 method registers. Most of the time I minimise it, but it can be useful to have around. The main reason it doesn't show real-time allocator efficiency is that calculating allocator efficiency for mobile processes is currently quite expensive.
I think adding another console should be okay, as long as it's small and very specific. I'll find a way!
-Moving my mouse outside the window into my browser window caused my game to scroll sideways endlessly. Maybe that's by design, but I'm not a fan. Ideally, I'd like to be able to turn off edge scrolling and control the camera with the arrow keys or by holding the middle mouse button and dragging. In any case, it should probably check if the window has focus and pause when it doesn't (at least as an option).
These are some of the things that I've noticed but never got around to fixing. Now that you've mentioned them, though, they are annoying. I'll spend some time with the Allegro manual and work out how to fix them.
Quote
-I found the interface confusing. The bottom console seemed like it was just for news, not actually entering commands. I thought that I'd be pressing the numbers from the list of processes instead, like pressing 3 for "new process". This was is probably simpler, but it's not obvious. The process/command list stands out far more, so that's what my eyes were drawn to. I think adding "here" to the "Click to build..." lines would be beneficial as well.
Yes, I'll try to make this more obvious.
Quote
-I think it might be a good idea to differentiate buildings from vehicles a bit more. I was surprised when it told me I could move my Builder process. I guess the buildings' differences could be made more obvious as well. I wasn't sure what the difference between the original factory and the differently-shaped one was.
There aren't really many differences between buildings and vehicles - a building is just a process with a method that makes it immobile (like the data allocation method). It would make sense to rename "builder" to something like "mobile builder", though.
Quote
-When a process stops moving, maybe it should rotate into alignment with the background again.
-Seeing the Builder fly around with its thrusters was pretty cool. It was a little wobbly, but for the most part it worked great. I would've liked to see it move a bit faster, though.
-Once I got into some combat, it seemed really strange that the ships would just plow into one another. I hope you plan on adding some obstacle avoidance and/or reverse thrusters at some point.
-One thing I think is a must for any RTS is having it be very easy for the player to group units. I couldn't use Shift or Control to add units to my selection, and dragging a box failed to select some units (usually on the left side) if the view scrolled while I was doing it.
Yeah, the pre-set processes and operator programs are all pretty stupid, and not well-designed in general. I'm working on them, as well as on adding a lot more missions.
Quote
-I feel like "Allocator Efficiency" should show up in the green console in real-time. I kept moving my builder around and trying to figure out where the efficiency reading was.
That wouldn't quite fit the way the consoles are supposed to work, but you're right that there needs to be a better way to give real-time information. Probably a smaller process data box that appears next to the selected process and only contains information particularly relevant to that kind of process.
Quote
-I didn't like that the X button on the window was disabled.
Yes, I'll make the game recognise the event that Allegro sets when the X is clicked, and give the user an immediate shutdown dialogue box.
And it also turns out that I needed to link the basic C libraries statically. I'm not sure why; I've never had this problem with MingW before. I've uploaded a new version and updated the link above.
It turns out that the game's preprocessor didn't work properly on *nix-based systems, because of confusion about line endings. I've uploaded a fixed version of the source code (thanks to Peter Hull for the fix) and updated the link in the first post. The Windows binaries shouldn't be affected.
Hello everyone! It's time for me to release the first public beta of my new game, Invincible Countermeasure.
It's an action/strategy/coding game about defending or invading a computer system inhabited by a variety of friendly and hostile processes that can move around, interact in various ways and reproduce themselves. It looks like this (youtube video):
Or this (screenshot):
On one level, you can play it as a real-time strategy game. You can use the predefined processes and give orders to them through the preset user interface. This beta version comes with three single-player missions that you can play like this.
To play on a deeper level, you can improve the processes and write your own. Each process is a small bytecode program running in a virtual machine emulating an imaginary 16-bit processor, and the game has a limited built-in C compiler (with inline assembler) that you can use to build processes to better carry out your commands.
At its heart, though, Invincible Countermeasure is a pure programming game. It supports asynchronous multiplayer in which 2-4 players pit autonomous processes against each other, and players can also rewrite the system program to create new game modes.
Here's the code editor:
This beta version is fully playable and has all of the basic features implemented, although there's plenty of work still to be done! (Among other things, the sound is very underdeveloped and there isn't any music yet.)
To build the game from source you'll need Allegro 5 installed. I've only tested the game on Windows, but it should compile on anything that Allegro supports. System requirements are very low.
It's a computer security/intrusion game which you can play as real-time strategy:
Or, since each unit is a small bytecode program running in the game's virtual machine, you can design your own units and write AI routines for them using the built-in C compiler:
Show Posts
and plan to get back to it some time.
