Hi everyone, I just came across darwinbots.
I was originally just looking to see what was already about in the area of robot programming games (ala C-robots) with a view to creating my own in C#.
But having found Darwinbots have decided not to bother.
Anyway...
I have been reading allot about version 3 design decisions, in regards to networking what is the objective? Is this just for sharing bots in otherwise isolated simulations or are we talking multi-user simulation?
A multi-user simulation might be possible over a classic client-server sockets architecture, which would be the simplest way for networking this kind of game (relatively speaking).
The simulation would be run in a service to which one or more clients could connect and view the current simulation state.
It would better support:-
1) Evolution Sims, You would be able to run your sim for months in the background as service and just load-up a client viewer every so-often to see what was going on. The service implementation could just save the sim when the service stopped and load it again when the service started.
2) Different client views on the same data, you could have a basic win forms statistics overview client, a primitive 2D client and a swanky 3D client. These could be developed interpedently from the server and even independently from the server’s platform
3) Independent simulation speed, it would enforce the total separation of rendering frame rate to simulation frame rate. The client can render as fast as it can, the simulation can simulate as fast as it can and the network can send and receive data as fast as it can, all Independently of each other.
4) League and shared games, all participants could connect and view the simulation in real-time to check on the progress their entry was making. Users could just set up their own server (simulated environment) and other users can join and introduce their bots and see them interact with other user’s bots.
5) Performance, it’s going to be the fastest and simplest way of any kind of multi-user simulation. Since this isn’t Counter strike there is no twitch user input or correlating feedback, you only really need to worry about raw bandwidth for sending updates. And in that regard you can just cap and rotate the number of bot updates you send in one tick, you would only need to send a reference ID and accumulated velocity delta’s as regular updates say about 32 bits per bot update, you should be able to manage an update rate of about 32 per tick (in a single UDP packet) with a tick rate of 5 per second, which would give you about 6.7kb/s (160 updates per second) per connection. Obviously for local connections you can achieve a display which approximates the status of the simulation much more tightly by using tick rates closer to that of the simulation frame rates or by updating a larger proportion of the bots in each tick.