I know Blender was planning to integrate multiplayer capabilities in the engine, but I am wasting some time (when I get a chance) messing with some multiplayer python code before I pick another game engine to export my Blender content to. I guess this could make Blender useful for some simple web games and 3d chat apps or prototypes. I’m just implementing python sockets and using an open source xml socket framework called swockets (www.swockets.org). Just working out some basic messaging as a test for starters: login, logout, message, broadcast, position, etc.
I’ll be happy to share an example when I’m finished if anyone is interested.
Blender went down just when the development was really rolling.
Blender 2.25 and holding
It will work in Creator or Publisher, but of course there will be slight code adjustments necessary for different versions of Blender. I’m using 2.25, but I can test the code in 2.23 when I’m done. I may try a few different frameworks as well after this. The chat is working fine from Blender now, but I need to finish the broadcast_my_position_to_everyone_else messaging - there are many ways to do this. I plan on putting up a working demo online as well. I’ll keep you informed.
I had a go at designing a ‘let_everyone_know_your_position’ script some time ago, using pythons support for UDP Datagrams. I got it kindof working but it just wasn’t fast enough to work in a proper multiplayer enviroment, no matter how much I tried to optimise the data content of the datagram.
So instead i tried a combination of position and velocity datagrams, ‘let_every1_know_your_velocity’ kind of thing. That gave the illusion of working well, but it still wasn’t fast enough and instead of slowing down the games actually got out of sync.
I don’t have 2 computers so I was testing it over the internet with a friends computer. Naturally that would make it much slower than just testing it on a fast network with little or no other traffic.
Another problem I encountered was that the Datagrams aren’t guarented to arrive in the same order that they were sent in. That ment that sometimes if u changed direction then changed back again although your computer would think you’re going in the original direction, the other computer might think you’re going in the other direction, because it miht have recieved the two velocity datagrams in reverse order.
Anyway I hope you have better luck, it would be nice to know how your attempts are coming on.
Yes, I’m using a separate server. Datagrams are faster, but the problem with their unguaranteed arrival will require a more complex solution. I was reading about a new method using UDP Datagrams that John Carmack was talking about, but I think he was only at the theory stage. I’m sticking with TCP for the first iteration anyways, then I may look into his idea with UDP some more. A rewrite in C++ might help some, but the general communication design is what is most important initially.
I could just send rotation and velocity information, and let the physics engine take care of the rest, but I have heard most online games attempt to compensate for lag by estimating where the person is based on velocity, etc. Without a high bandwidth connection things will get difficult.
TCP will at least guarantee ordered delivery and this will make it easier to design the rest of the code, then maybe I’ll come back and look at better frameworks, using UDP, etc. I think Q2 sent 20 TCP velocity/rotation/whatever statements per second, so I will just have to experiment with various settings for different connection speeds.
Maybe cable or dsl will be necessary for anything besides chat, but I don’t know yet, we’ll see (it’s fast on my home network :P).
On second thought I might just be wasting my time on abandoned/sold off technology that may not exist in the next version of Blender. (See News). I guess all 3 of us who bought Publisher to use for realtime projects are the only ones who care. I might finish something anyways since I started on it, but then it’s on to other game engines.
If your using TCP data streams you surely have to define start bytes and end bytes for the different sections of data (the virtual packets), and then you have to scan through the data as in comes in to seperate the packets. Sounds quite orkward.
