I have a build ready for some playing around. There is a lot that you will currently be unable to do as this is still just an alpha.
I have included the beginnings of a reference for some of the classes and a simple chat example.
This is not the source… yet.
I will be releasing the source once I get to a more stable version, but I thought that some people on this forum would be interested in playing around with this.
Please leave a comment whether bad or good; I am just interested in where we can go with this.
This version only has asynchronous based request handling for all data. I am sure once I get closer to a full source release many advancements could be made to the underlying thread handling.
As far as the pricing, I am unsure of what I would do ( still seeing the interest level ), but ultimately I am not doing this for monetary gain, but to allow people who need a custom or more advanced control of networking on an indie price range.
sending vector3 to all conected clients … maybe at every 1 second or more, synchronising doesnt matter, just to people move around…
is it hard to compile something like that?.. Iam very rich, I can buy you a beer, donat, icecream… just say what you want
seriously, Vector3 perhaps rotation, so many ppl can walk around. If you can compile that, I will be (and many others I think) very happy to play with.
thank you
Hey if you look at the example I gave it should give you a start… like I said earlier this is just a dll build. The full source will be out soon so you will have to be patient.
But you may be able to send a vector3.
Follow my sample of the chat and instead of doing
packet.data.Add(msg);
you can do packet.data.Add(transform.position);
then when you receive it just typecast the Vector3
Just remember as you build this, bitstreams are the bomb! The smaller you can get the packet data and push as much info as possible, the stronger your networking solution will be.
some workflow about mmo(simple color balls) will be:
client binary to server (currentPosition)
server calculate from allCurrentPositions[ ] which one is in range (we dont want to send to all, why should we if they are not visibile on screen or too far away)
I personally would not bog down the server with selective sending… rather I would have the client periodically receive a list of players within his “region” and then when he is close enough the player requests updating of that player.
Although this presents a security risk, which is less important for chat than game mechanics - the user could simply spam a list that says that everyone is in his region!
That is true, it all depends on the structure of your game of course. You could, in a mmo type setting, have a relay server handle all packet information and then pass the position info onto another thread or server to handle position stuff. This could take the stress off of the original server.
