Once again, I have to start one of my blog entries with an apology for not updating this blog often enough - this time I actually have an excuse! I mostly post on here when two things happen together;

1. I have to have something interesting to post about, that's fairly rare as it is ;)


2. I have to have spare time, that's getting very rare recently as I've been working flat-out on Myriad.

Firstly, I'm going to talk a little about the progress I've made on Myriad, then I'll talk about this really-cool-idea(tm) I have.

So, what's been happening since that last post of mine? Well, I spent a while working on various bits of background code for Myriad, mostly the landscape level of detail and heightmap deformation synchronisation across multiple threads - it all sounds boring and to be honest it is. So I stopped doing that recently, and took a totally different tack and built a menu system, the menus are rather smooth, with everything transitioning on and off smoothly when you click a button. Next, started work on networking, using the excellent Lidgren networking library I very quickly got a network session up and running, combining that with the metaserver I built ages ago (running on google appengine) I had a server list. Finally, I built a proper network synchronisation system, the network architecture we're working with is peer-to-peer, so every peer needs an Agent (using the AgentB system I created for easy concurrency) which monitors changes to the local state and transmits these changes to all other peers who care (not just all other peers, that's too traffic heavy). I'm going to talk about the p2p networking system some other time, when I have more of it written and working! That's the stage I'm at now, all that is being synchronised at the moment is chat, but it's a good start! Next I plan to write a proper game lobby, which has a whole load of associated problems...

Anyway, moving rapidly on, a couple of paragraphs ago I mentioned a really-cool-idea(tm), I guess I'd better make good on that promise, first a little background.

A while ago I released the AgentB concurrency library, it implements the actor model of concurrency in C#, I'm using AgentB in Myriad and it's proving to be a very nice way to work, yay! Why does this matter? Well, one problem I'm facing in Myriad is how to distribute work across the p2p network, there are a few options:

1. Simulate all units on 1 computer
   This is the standard client/server model of networking games, and it's very easy to do however Myriad has large armies and simulating all those units on one PC would tax it, also the bandwidth required to transmit all that data to all the clients is huge (and lag becomes an issue)


2. Simulate all units on the computer of the player who owns them
   This is the technique Myriad is using, each player simulates his own units, there is a system for registering your interest in a world zone and if someone else's units wander into that zone that peer will start sending you updates. This distributes the simulation load and bandwidth requirements evenly across all computers. The disadvantage is that not all computers are made even, if someone owns most of the units (maybe towards the endgame because they're winning) this basically becomes the client/server model.


3. Simulate the unit on the computer of the player who is interacting with them the most

number 3 is the technique I want to talk about. Let me give you an illustrative example:

Player A
Owns 50 units on one side of the map (which he is actively doing stuff with)
Owns 10 units wandering around the other side of the map which he has forgotten about

Player B
Attacks those 10 units

In networking model 2, those 10 units are still simulated on the computer of player A and everything player B does to them has to be transmitted to player A and a confirmation sent back to player B - potentially a very slow operation.
However, in networking model 3, those 10 units are simulated on the computer of player A but they have a very low "attachment" because player A hasn't used them for a long time, once player B comes along and starts doing things with them the units migrate over to his computer and all subsequent actions player B takes on these units generate no network traffic.
What happens if player A comes along and start issuing commands to his 10 units? Well that's simple, the commands get transmitted to the units being simulated on player B's computer, if player A does enough with them or player B starts ignoring them the units will migrate back to being simulated on the computer of player A (once again to reduce network traffic).

Ok, so that's a really cool networking model, distribute all work evenly across all the clients in the game, dynamically moving units from computer to computer to reduce network traffic/latency (for example, in player A is in America, and player B is in Europe, that swapping of units could be very significant). However, as I'm sure you can imagine implementing that kind of system would be hell if you had to do it for every game, here comes part two of my really-cool-idea. The AgentB library uses actor based concurrency, which means that actors only interact through messages passed about, networks are really rather good at passing messages about from place to place - in fact if an agent was on the local computer or on a remote computer it shouldn't matter at all to an agent based system. AgentC is the next iteration of the Agent library, it doesn't aim to replace the AgentB library (which is great for local only concurrency and will continue to be supported, in fact I need to make a new release with a few minor bug fixes later today) it aims to bring something completely new to the table, if you write your agents to only interact with messages AgentC will automatically distribute your agents around a cluster of computers to optimise performance (either processing speed, network latency, or network traffic - you choose).

I guess I have my work cut out...