RTS4 Update 3

We’re 1 month in on the project reboot! I’ve fixed up the lobby UI and switched multiplayer to a relay server (having trouble with UDP Punchthrough on Azure).

In the game above, the two players desync after the Pegasus is trained. This has been fixed now, but it was caused by the “cheat” command (to instantly give a player resources) which I used for favor, did not serialize its data, so didn’t execute correctly on the other client.

The game has also been more heavily optimised so that it will run in WebGL, and I’ve been working on simplifying some of the internal simulation logic (ie. so that all things that deliver resources to players use a unified system).

RTS4 Update 2

Over the last week I’ve added LOS, D*Lite pathfinding, hitpoint bars, upgrades work (but only ones which affect prerequisites), and the UI has been updated with better placeholder graphics (the same used in the previous RTS4 attempt).

The random maps still generate incorrectly. Forests seem to fail randomly, but breakpointing in the code suddenly makes them work again.

NAT punchthrough looks a lot simpler than expected, so I’d like to try that next, along with some of the server-side player profile management and game listing.

RTS4 Attempt 3

I’ve restarted the RTS4 project and made a lot of progress very quickly thanks to pulling in existing code from the previous attempts. It’s not quite up to where I was in the previous attempt but getting close.

Currently the following is implemented:

  • Parsing the AOM format of proto.xml, terraintypes.xml, clifftypes.xml, forest.xml, waterbodies.xml (partial), techtree.xml
  • Parsing and executing random map .xs files
  • Primary unit actions (Move, Gather, GatherDrop, Attack, Build)
  • Building placement
  • Networking (only direct IP, no punch-through)

To speed up development, I’ve pulled in code for the following

  • Parser logic comes from ReGE (PhD project)
  • XScript runtime is (a modified version of) what was used in XNA RTS4
  • Math and Networking is based on that used in Unity RTS4
  • Simulation has been completely recoded and is implemented in Unity ECS

It’s not much to look at, but here is how it looks currently

There is currently no pathfinding and technologies cannot be activated, and there are several bugs. Food amount starts as -1. Ranged attacks work but are instant and do not use projectiles, and all attacks work off of the global clock instead of per-unit timers. Something is wrong with random map constraints and water decorations (purple boxes) are being spawned in base, and the starting forest rarely spawns correctly.

(Started 20 Feb 2020)

Back to RTS4

The previous tutorial series covers most of the basics for an RTS. I probably wont be doing any others for a while as I’d now like to concentrate on RTS4. There has been some quite significant progress made to the project; with the cleaner design from the UnityRTS tutorial series, and the separation of simulation from visuals, the project is much easier to work with now.

Separation of logic

In the UnityRTS projects, although updating happens at a fixed time interval, the coupling of the simulation and visuals makes it difficult to have simulations running in the background and ties the game more closely to the Unity engine (which with Unreal looking so nice, I want to avoid). These two functions are now separate, and each client now runs two simulations concurrently; one for the last known server state, and one for the clients visuals. Each network message is first run on the server, if it is prior to the clients visuals simulation time, the client sim is synced to the servers sim, and then rolled forward to the correct client time. This gives clients no lag while still minimising network bandwidth. As the visuals are separate to these simulations, they can smoothly interpolate whenever the client simulates incorrectly.


The decoupling of the simulation from the Unity visuals means that entities can no longer be described by components on a prefab. To replace and extend this system, each entity now has a prototype object, which calculates any stateless properties (its max health, build time, etc.). Getting a field is not as simple as looking it up by name; Prototypes have a list of technologies which can be enabled or disabled which augment fields, enable / disable components, and even enable / disable other technologies (both for just this entity, or for all entities owned by the player).

These toggleable technologies mean that entities can very simply support buffs and debuffs, by for example enabling a SlowPoison technology. The system also handles armoury upgrades by enabling the HardenedShields player-wide. And it can even be used to handle tech unlocks, for example by enabling age2 player-wide, which can in turn augment the villagers Builds list to include Barracks and Farms.

I dont fully understand the effects system in AoM, but this seems more extensible and quite happy at how many common RTS concepts it can support cleanly. None of my previous attempts included anything like this, so its great to finally understand it.

Unity RTS4 Prototypes example code for Villager


With the changes above, multiplayer is now functional. I’m using the RPC support in Unity to send messages (after serialising them to byte arrays) which conveniently handles lobbies and NAT punchthrough for me.


The current version can be played here (with multiplayer disabled at the moment). I also added in the older models instead of boxes.

RTS4 – Cliff models

Using a mesh for the cliff face turned out to be quite a bit more difficult than I originally thought. It’s finally working, though still incomplete. I’m not sure its worth the processing requirements and complexity it adds. I’ll probably disable it and decide later. Using a mesh means the cliff can have nice crevices that match the texture mapping, and have little ledges and rocks poking out. Otherwise without using a mesh, I’ll add some variation to make it look less rigid, but the texture wont match the mesh as nicely.

Other problems that this approach presents:

  • The cliff model would not be able to wrap around a raised plateau without a geometry seam (potentially showing through to the void below)
  • Matching the cliff model offset between terrain chunks is very complicated and unlikely to ever work completely (nasty geometry seams between each chunk)
  • Floating point errors cause holes in the geometry or can potentially crash the game
  • The cliffs are significantly higher poly
  • A mesh should be made for each cliff type, adding to the workload

This picture from Unity RTS shows a hand-modeled example of what I was going for.
Notice the darker sections of the cliff texture are inset.

RTS4 – Progress update

I’ve got back into the WebGL port of RTS4. I had previously done a lot of work for.. something.. I can’t quite remember, but I left it in a broken state. It’s now been fixed and had a little more progress made:

  • The UI is all data-bound through Knockout
  • Users can now box-select stuff
  • Units/buildings have a visual thing below them when selected
  • Constructing things now has a construction phase
  • The object bounds are used for building/attacking/gathering (instead of the unit walking to the object centre)
  • Scripts are combined into a single all.js file, reducing the load on my poor server
  • Models (including animations) are loaded in a much smaller binary format, meaning MUCH faster load times, and less content to download
  • Model transforming happens through an (as yet unseen) node.js server, which also opens a socket to the client; some basic multiplayer tests/features shouldnt be too far off.
  • Basics of an “EntityGroup” class, which manages a collection of entities that satisfy a list of requirements. (the “Villies” print out is using this system to count units)

I made a few models earlier, and since they look much better than the current build, ill post them here instead.

“Play” in browser (IE11 or Chrome)

Next step will probably be terrain and other visual improvements. The action system also needs to be revamped; the over-engineered “resources” system needs to be integrated into the entities themselves, rather than a separate component (health and population are considered resources in this system). The resources overhead is insignificant, and almost every entity that needs behaviours, needs resources. This may make it easier to integrate more concepts (like line of sight) to be resources (probably to be renamed to “properties”), which will make buffs much easier.

Note to self: I’d also like to have a concept of “abilities”, such as “move” and “face direction”, so that the correct action can gain access to the abilities they need (otherwise a unit ordered to move left but attack right wont know which order should control movement)

Unity RTS game

I’ve been getting a bit annoyed at the slow progress on the WebGL RTS4 project. I know what the problem is; I’m over-engineering it, trying to design it to be very general purpose and flexible, but as such it becomes very difficult to make progress.

I decided instead to see how far I could get building in a more purpose-built way. Over the last few weeks I’ve been putting together a model pack for Unity, to be released on the Asset Store along with a sample project to see the assets in action; this would be my sample project. The models were created in a hand-drawn cartoony style.


The current version was built over about a week:

  • Day 1: Pathfinding and unit movement
  • Day 2: Resource management, gathering, and melee combat
  • Day 3: Town Centre model, buildings as pathfinding obstructions
  • Day 4: Placement of buildings, terrain fog of war
  • Day 5: Hydra, Unit fog of war, FOW fading to grayscale over time

Some of the code is designed similarly to the WebGL RTS4 port, but with more stuff assumed (ie. only 1 action can be active at a time, terrain is a heightmap, buildings are rectangular).


Play in your browser (Unity)

ModHQ and UI Editing

I’ve integrated the UI viewer/editor into ModHQ and fixed up some performance problems. It now loads in about 2 seconds on my (fairly low specd) laptop. It also has a nice new loading screen.


The program is essentially read-only at this stage, any changes you make with the unit prototypes or UI wont be saved back to your data files. However, all changes made through the Data Files tab will.


In this screen, double click any item to convert it to XML and open it, you can then make edits in your xml editor, and save it back to have it compiled and inserted back to the data file. Textures can be viewed through this tab, but will not successfully save back to the data file.

As before, you can check and uncheck items in the UI Editor tab to see their contents


Download: ModHQ (.Net 4 + source)



RTS4 – WebGL

I’ve decided to move RTS4 to JavaScript and WebGL instead of some C# environment. Specifically, the game is being developed in TypeScript, a JavaScript-like language which adds common object oriented features to the language. The game is using the same “engine” as the WebPA demo, ported to TypeScript and improved with better separation between resources and WebGL interfaces, and added animation / DAE support. This move brings a heap of new abilities and challenges, summarised below:


  • Can access the game from anywhere by visiting the URL in a newer browser (can also run on mobiles)
  • Much less likely for WebGL to be discontinued
  • Built-in standard and high performance UI framework (HTML/CSS)


  • Very difficult to load external resources (require expensive upload or local storage options)
  • Mathematical inaccuracies make multiplayer and game replays much less stable, require error correction
  • Overall slower loading and rendering performance
  • Impossible to protect the game code from hackers, though security measures can be added to prevent cheating in multiplayer.

After designing enough of the game, I will likely build a native Windows version of the game as well. The current version is quite underwhelming, but can be played below.


Play in Chrome