Code center > Darwinbots3
DB3 progress and networking
Numsgil:
--- Quote from: spike43884 on March 26, 2015, 12:02:48 PM ---Do you know any good tutorials etc. for C#
--- End quote ---
I picked it up pretty easily just by trying to make it do stuff I needed, but then I already knew C++ very well. If you don't really know a programming language yet it's going to be much harder. I learned to program on the ancient C For Dummies series of books, but that was way back in the 90s. I'm not sure what people use these days. But if there's one question I'm sure the internet can answer it's where to find resources for learning to program.
--- Quote ---I might ask, how can I edit things on that link
--- End quote ---
You don't; it's a read only look at the repository. If you want to make changes, you have to grab the repository and tools and make SVN patches (again, that DB3 link in the wiki is pretty explicit about how to set it all up).
--- Quote ---I'm thinking of first adding some notes in the networking module.
--- End quote ---
Any work around networking is going to be premature, as I don't have answers to even very basic questions like TCP or UDP. (UDP is traditionally what games use, but our multiplayer model in DB2 is very asynchronous and involves mostly sending largish bot files sporadically, so a simple TCP or web service interface might be better, but then maybe I want to do something more clever than what DB2 does). Or how I'm going to serialize anything.
As a beginner programmer the code base is going to be pretty frightening. You have to learn about things like unit testing and SVN patches, and most of the code is numerical algorithms for linear algebra, computational geometry, or DirectX shader code. That said, the Sunweaver module (the DNA basically) is self contained and pretty straightforward, so it might be a good place to poke around.
There's just not a lot of low hanging fruit left. If it was easy, I've already done it, or it's so far in the future that it doesn't matter yet. Not to be discouraging! I like when people help. Just don't expect to pick up the code and make meaningful contributions if you've never worked on a large (for some definition of large :)) code base before.
spike43884:
--- Quote from: Numsgil on March 26, 2015, 01:34:12 PM ---
--- Quote from: spike43884 on March 26, 2015, 12:02:48 PM ---Do you know any good tutorials etc. for C#
--- End quote ---
I picked it up pretty easily just by trying to make it do stuff I needed, but then I already knew C++ very well. If you don't really know a programming language yet it's going to be much harder. I learned to program on the ancient C For Dummies series of books, but that was way back in the 90s. I'm not sure what people use these days. But if there's one question I'm sure the internet can answer it's where to find resources for learning to program.
--- Quote ---I might ask, how can I edit things on that link
--- End quote ---
You don't; it's a read only look at the repository. If you want to make changes, you have to grab the repository and tools and make SVN patches (again, that DB3 link in the wiki is pretty explicit about how to set it all up).
--- Quote ---I'm thinking of first adding some notes in the networking module.
--- End quote ---
Any work around networking is going to be premature, as I don't have answers to even very basic questions like TCP or UDP. (UDP is traditionally what games use, but our multiplayer model in DB2 is very asynchronous and involves mostly sending largish bot files sporadically, so a simple TCP or web service interface might be better, but then maybe I want to do something more clever than what DB2 does). Or how I'm going to serialize anything.
As a beginner programmer the code base is going to be pretty frightening. You have to learn about things like unit testing and SVN patches, and most of the code is numerical algorithms for linear algebra, computational geometry, or DirectX shader code. That said, the Sunweaver module (the DNA basically) is self contained and pretty straightforward, so it might be a good place to poke around.
There's just not a lot of low hanging fruit left. If it was easy, I've already done it, or it's so far in the future that it doesn't matter yet. Not to be discouraging! I like when people help. Just don't expect to pick up the code and make meaningful contributions if you've never worked on a large (for some definition of large :)) code base before.
--- End quote ---
I haven't worked on very large codebases, hence why its good that its modular :) I'll have a look at the sunweaver module, but the networking I can devise a basic outlining system of how to run it through. The speradic messages are terrible unideal at the moment, so is the connection via 1 single port (to be honest, peterIM in general is shoddy). It should be preparing for bots nearby the teleportation 'zone' as such, so that if they do go through not all the data is sent in that speradic moment. Alternatively a short limbo time where over 5 seconds maybe? a bot is taken through.
Numsgil:
Well if you seriously want to play with networking, you're going to need some background reading so you know what you're talking about (Dunning-Kruger effect and all that). A good resource might be Gaffer on Games. There's a whole slew of articles that talk about networking in the context that most video games have to worry about it. Darwinbots is a little bit different than any of the networking archetypes typical for games, but it's a good place to start. (For the record, I doubt the core engine for Darwinbots will be deterministic just because I haven't put any effort towards that.)
If you can do the grunt work of reading and getting up to speed with the technology and infrastructure and tradeoffs available I'm liable to seriously consider any contributions you want to make. My knowledge of game networking is pretty superficial as it stands, and someone else with domain knowledge there would obviously be a great resource.
spike43884:
--- Quote from: Numsgil on March 27, 2015, 01:16:39 PM ---Well if you seriously want to play with networking, you're going to need some background reading so you know what you're talking about (Dunning-Kruger effect and all that). A good resource might be Gaffer on Games. There's a whole slew of articles that talk about networking in the context that most video games have to worry about it. Darwinbots is a little bit different than any of the networking archetypes typical for games, but it's a good place to start. (For the record, I doubt the core engine for Darwinbots will be deterministic just because I haven't put any effort towards that.)
If you can do the grunt work of reading and getting up to speed with the technology and infrastructure and tradeoffs available I'm liable to seriously consider any contributions you want to make. My knowledge of game networking is pretty superficial as it stands, and someone else with domain knowledge there would obviously be a great resource.
--- End quote ---
Checking that gaffer on games right now :) Thanks.
spike43884:
The peer-to-peer part gave me an idea, it mentions how its primarily now only used for RTS games (or turnbased games) Darwinbots, is a turnbased program. Each cycle representing one turn. The main problem they state is desyncronisation but thats mainly stated because they're sharing the same view, as in darwinbots we use different views, connected via a teleporter. Of course in darwinbots the cycles in the currrent IM rarely match, so we don't have to match speeds, we just need to hold whatever is being sent in limbo until it can be transported to the other end. The limbo also allows it to switch ports whichever its going through, though if it includes a limbo that'd start to transfer it more into a client-server topology (though it'd still function relatively close to peer-to-peer).
Preferred System:If we went for a direct client-server model a different approach could be taken, which is one I very much like. Each client can hook their 'area' to the server, with an outgoing only portal (because then we can let the weakest computers join in to!) then per client theres an ingoing portal on a 'server-held area'. This area is a larger, more powerful simulation. Then via a webpage or such what is happening can be displayed by a video feed. Because its a server it can handle many more bots, and can last for much longer because of the additional space and power. All the user-side area's have to comply to the rules set by whichever server they're connecting to (so when they send their bots in they won't just be huge big bertha's). This benefically means that completely slow computers, won't damage the sim in any way, as they're signal is sent out, then when its received its directly fired into the simulation, and both sims have no need to be in-sync as its one-way and they're different ''area's''
Hopefully that made as much sense as it did to me :P
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version