So I've been working on the C++ port, and while progress is slow, it's definitely going somewhere. So far, I have the following elements completed.

  • Basic utilities, ranging from various types of collections to UTF-8 strings.

  • The parser for the command line and definition files, which comes as a kit: input components (lexer, binary reader), output components (text or binary form), a memory storage component, the preprocessor and the parser itself.

  • A virtual file system. The rationale is that I want to keep the possibility to have single-file mods (which Java made easy to do). The VFS can read from directories, from external data files, or from data stored inside the code. This can be extended by code and configured at runtime.

  • A logging system. It runs in a separate thread, can be extended and reconfigured.

In addition, I have written a few utilities for converting text data to binary data and vice-versa, to run preprocessor code, and to create code or data files for the VFS. I've also written quite a few automated tests - around 1000 so far.


Happy New Year!

It's been a really long while so I figured I should post something.

First of all, I've been sick and still am - long term stuff. So I haven't made as much progress as I would have liked as I find it hard to concentrate on, well, anything really.

In addition, while I had a mostly complete prototype for a first playable version, minus the A.I., I decided to port the whole thing from Java to C++.

Why? Well, I spent quite some time optimising the parts of the Java code that would have been kept in later versions. While the result was mostly satisfactory, it meant doing a few "dirty" things (e.g. pooling some objects; using /sun.misc.Unsafe/). These tricks tend to make the code harder to write and maintain, and they can also cause the problems you'd get in a lower-level language (memory leaks, for example).

So far, I've ported a lot of the "library" code, namely the VFS and data file parser, as well as most of the "preprocessor".

In the long term, this change means that the first release will be the command line UI, and that I'll have to work on an actual game UI right after that.


Because I don't have too much time to work on LegacyWorlds these days I'm not concentrating on anything specific; instead I'm doing a little bit of everything in parallel.

I've started generally fixing bugs and improving some of the non-placeholder code - mainly, the game loop and its UI/backend communication stuff are getting some clean-up and a few extra features, and I'm also trying to optimise the various parsers on two fronts (reducing object allocation and therefore garbage collection, and improving the parsing itself).

I've also been doing a bit of work on the Swing UI. For now:

  • games can be created, loaded and saved;

  • controls for how time passes (paused, normal speed or high speed) have been implemented;

  • the game window includes an events tab, a research tab and an incomplete map tab.

Last but not least, I have started adding content and trying to make the game more or less balanced.


I rewrote game loading and saving. Before now, I had a binary format that mirrored the game's state exactly. I am now using a more flexible format that can be translated directly into tokens which can be fed to the same parser that is used for, well, everything else. While the new format is definitely heavier (especially considering the parser has not been optimized at all at this stage), it has two major advantages over the previous one. First, it can be dumped to a human-readable format easily enough, which can help when debugging. Second, it allows some of the code (namely the definitions loader) to be re-used, as the definitions are saved along with the rest of the game data; until now, there were two separate loaders for the definitions: one for the human-readable version, another for the binary version.

I have implemented revolts. They will be triggered if a planet stays under 10% happiness for a few turns. Revolting citizens will attack ground forces (and, through them, fleets) as well as buildings. However, if enough ground forces are present on the planet, the revolt will be "contained" - it will only affect ground forces, and it will do so with much less strength.

I had initially planned for planets that revolt for long enough to become neutral, but chose not to do it at this point; it would require management AIs for neutral planets, and/or keeping track of relationships between empires, none of which I'm willing to work on when 99% of the game is placeholder-y.

The game's mechanics are now complete. I will be fixing a few bugs and optimizing a few things that I know are not placeholders for the next few weeks. Then I'll move on to adding actual content (resources, technologies, buildings and ships) to the game, although I don't want to add too much of it (again due to it being placeholder-y) so it will likely end up being rather similar to the online LWB5's tech graph.


As it turns out, I had much more free time while on vacation than what I expected, so I was able to make some progress on LW.

I finally finished the battle code; I didn't have the latest version of the code, so I did it from scratch, and that helped a lot (good to know for the next time I get stuck on something). This is placeholder code anyway, so I shouldn't have tried to get it to work "exactly as I wanted it" in the first place, but sometimes I just can't help myself.

In order for battles to work, I had to add some data about how damaged ships are in order for them not to get destroyed immediately in all cases. The more damaged a ship is, the less fleet power it provides. Damage is inflicted based on fleet power, so there's some feedback.

I'm also tracking damage information for buildings. During battles, attacking fleets will fire at defensive buildings, but sometimes they will miss and damage other buildings as well.

Planet capture works using ground forces, which are provided by specific types of ships, and by the planets themselves. Ground battles are computed right after space battles. Like fleet power, ground forces provided by ships is affected by damage to ships, and the computation is very similar. Of course, damage to ground forces results in the corresponding ships being damaged as well. At this point, ground combat does not affect buildings (but it will).

Because I did the battles this way, I was able to re-use the damage handling code for damage inflicted by insufficient upkeep. I'll also be able to re-use it when I write the code for revolts caused by low happiness, so there's that. However, I still have a few issues to work out (mostly related to fleets damaged while in Hyperspace, leading to fleets that should not be in Hyperspace being there, leading in turn to divisions by zero).

Finally, I also added two ways to force fleets belonging to an empire to attack a planet. There's an empire-wise enemy list, which works exactly like the one from the old online LegacyWorlds. I also added a way to force fleets to attack locally (this only works while the fleets are there; once they fly away, new fleets from the same empire will not be switched, unless forced again).


And again it has been way too long. Not much progress has been made, this post is mostly about replying to an email due to Hotmail not being too happy with my outgoing MX these days. So, yeah, I'll just do that while trying my best to remove personal details (sorry).

Hi, With the Legacy Worlds project being picked up again, I was wondering if you were looking for beta testers for it at all?

I'm quite (happily!) surprised anyone is still following what's happening with LW after all this time!

I'm currently busy with my (actual) job, so the project hasn't advanced all that much since the last update I posted (I'm more or less trying to get the battles to work, which is an annoyance at this point since most of this code is gonna go away later, but ah well - I'm fiddling with it).

Once I get enough time to work on it again and finish the current ToDo list, I'll release it. At that point, feedback will definitely be appreciated.

I had played legacy worlds both Beta 5 & 6, so am familiar with the basics of the game, however reading through your developer diary, quite a few of the mechanics have changed.

Well, it's going to be single-player, for starters, so that's a big change right there :p But yeah, a few things changed in that version (I'm mixing some B5 and B6M1 features, and adding a few new things that were planned for the actual B6, and adding or changing more things to bridge all of that together).

Please keep in mind that I'm only trying to get a "mostly playable" thing for now, not what I aim to do.

And I'm probably having WAY too much fun creating a random functional/symbolic programming language just for the game's configuration files :s

If beta testers are not required then that's ok, I'll check your diary every week or so for updates, and look forward to the public release.

Right now, please don't bother - I probably won't be touching it for all of Summer (my kids are on vacation, plus I currently have a freelance contract to complete, which doesn't leave me much time).

At any rate, when the first version gets released, I'll be happy to have your feedback.

Thank you for taking time to read this,

I'm very happy to hear from you, not to mention utterly surprised that anyone still knows about LW!


It had been way too long since I last worked on LW, but I'm back to it for now. I'll have other things going soon, but I'm going to try spending a little time on it every day anyway.

Because I only started working on it again a few days ago, this update is very short: the only thing I've done is getting started on the battle system. At this point, I'm detecting battle start/end conditions, gathering information about fleets that are present and I've also added damage-related data.


So it's been almost a month since my last update, mostly because there wasn't much progress recently, mostly due to external circumstances (various health-related issues, actual work, and other things too).

A lot of the game's internals (which had been scavenged from older code) have been updated or rewritten, because they were getting in the way or had pieces which were mostly unused.

The pre-processing language received a number of additions, including support for user-defined macros, new commands (including -parse, which simplifies tests by allowing output to be forced to the data parser immediately).

The event formatting code was completely rewritten. It used to have its own, limited formatting syntax, which was redundant with the preprocessing language; this extra formatting language has been removed entirely, and the preprocessor is used to transform events instead.

Various improvements to the CLI's views and command structure were completed, including fixing old bugs and inaccuracies. Handling of saved games has been improved, with various abilities such as copying or renaming games; thanks to these new abilities, options to create backup copies of a game automatically have been added.

Last but not least, I was getting tired of having to insert hooks in the main code for the module containing testing commands and debugging views, so I added a system that allows limited "mods" to be loaded. These mods can add new game commands and queries, support for new definitions, alternate event formatting instructions, or UI elements (these would be specific to the game UI currently in use).

I have been experimenting on and off with the battle computations, but so far I have not been able to get it right (by some definition of "right"). Since I am otherwise busy and still sick, this could take a while.


On the "game-y" side of things, I implemented planet ownership change, which made it possible to start working on various other parts.

  • The ability to abandon planets. It is quite simple; it has a delay which depends on how long the planet had been under your control when you abandon it (within limits of course), and it does affect happiness negatively.
  • The ability to destroy planets. It not only affects planet ownership (the planet has to become neutral before it is turned to dust), but many other parts of the game. Since planet destruction can destroy fleets around it, moving fleets have to be checked. In addition, any fleet that has a trajectory which takes it through the destroyed planet's area needs to have its travel time updated. Finally, there are many other details affected by it (such as the fleet detection system which needs to be reset, happiness which is affected on all planets in the owner's empire, all other planets in the same system, and possibly all planets on which self-destruct buildings are present).

I also added the necessary fields and computations to handle happiness effects from the size and age of a planet's controlling empire.

I am in the progress of modifying the event formatting code, as it used to have its specific mini-language; with the new "pre-processor", this has become redundant, but it requires a few other changes to be efficient.

On another front, I rewrote a lot of the existing tests for use with the test runner script, added new tests for old stuff, and started testing the new things as I added them. That takes a lot of time and it's a bit boring to do, but sometimes I discover a bug so I'm mostly fine with it.

I will not have much time to work on LegacyWorlds for the next two weeks, and so I intend to work mostly on both very small items (changes or fixes to the CLI views, that sort of things) or relatively big refactorings (but which don't require too much concentration and can be done in multiple stages) which I've had listed in my to-do list for quite a while. Oh, and quite possibly write more test scripts.


I implemented the tax system. It's pretty basic - you can set a tax rate for the whole empire, or use specific, per-planet tax rates. Of course, taxes influence happiness negatively after a certain threshold.

I have mostly rewritten the parser for the command language that is used for the game definitions as well as the command line interface. The idea is to be able to run automated test scripts. However, my initial plan (simply add a few things so it's easy to run a bunch of scripts with different parameters) didn't work out because I realised I'd have to eyeball the output for errors, and that gets rather hard once a dozen or more test scripts are being executed.

So I went for something a little deeper, and now I have a LISP-like language as the preprocessor. While it still has a few rather big warts (see this tweet for an example), it's mostly usable at this stage, so I don't intend to tweak it too much at the moment. I'll just add new built-ins when I need them and that's about it.

I've started working on the test runner, which is a script that loads all tests and executes them. It's a bit complicated because I still want to be able to run individual tests directly, so it has to process the test scripts into something more appropriate.

I intend to finish this next week, then get back to working on the game itself - my next "to-do list" item being the code for planet ownership changes, which is necessary for battles and to implement the ability to abandon planets or to blow them up.


LegacyWorlds is off-line... for now.

LegacyWorlds used to be an online, browser-based "strategy" (and by that, I mean "build as much weaponry as you can before hitting everyone else on the head with it") game. I lost all motivation to work on it, for many reasons.

The good news is... well, I'm doing something with some of the ideas that were meant for newer versions. So, LegacyWorlds will be back, albeit under a different form.

When? Hmm. I have no idea!

Meanwhile, the very old Beta 5 source code can be found on Github. I will publish the Beta 6 M1 source at some point, but that is definitely not a priority.

<- Older entries | Newer entries ->