Code center > Darwinbots3
P2P Internet Mode
Cyberduke:
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.
Peter:
--- Quote ---Is this just for sharing bots in otherwise isolated simulations or are we talking multi-user simulation?
--- End quote ---
Isolated that are shared trough a central server. Altrough that is what Eric is talking about and has been inplementated in DB2.
The title states a P2P-network as you see.
--- Quote ---it would enforce the total separation of rendering frame rate to simulation frame rate
--- End quote ---
uhuh, seperation rendering/simulation, uhuh. If you mean about shutting the graphical interface down it is also in DB2. I am pretty sure there comes something like it in DB3.
Current way of IM. Simply, central server receivs bots, sends bots and updute IM-graphs. Does nothing else as far I know.
Cyberduke:
Ah ok I have misunderstood, after skimming though aload of posts about P2P networking I assumed the talk was of a system closer to the like of Terrarium.
Cyberduke:
And in fact after more reading (so far I have spent most of the day reading this forum) with ideas like complex dynamic cell shapes and joins that could well take a cell update into the realms of 128 bits or more which considering the number of cells and frequency of change would make viewing over the internet far too slow, it would still be fine locally, but then what’s the point!
Numsgil:
It's not like terrarium, where you have a server running things and you connect to view it (that's how it worked, right?) Rather, each user is running their own local copy, and bots are periodically teleported to a central depository, where they sit in raw binary form until another user downloads them in to their own sim. We don't have the money for a fancy central server, so the idea here is to leverage everyone's computing power to create a large universe for bots to roam around in.
BTW, if you're interested I could use a hand with DB3 (in C#), or Eric could use a hand with the current DB2 (in VB6).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version