Networking Idea

Hey all.

Now, I'm no expert at network coding, however, I've had an idea.

An idea that, by myself, i can get *working*- but it wont be as efficient and bugfree as it could be:

The idea:

Automatic networking of entities after the calling of a "networkentity" command. Tokamak physics could be included.

Its built around BPLite though i may change that.

Whatsit do?

well, Each frame, each entity is checked, and if *this* computer has updated it, send a message to the server- stating its position, rotation and any forces. Obviously, this isnt required every single frame since toka would take care of alot of it after setting forces.

It works by giving every entity a network ID. each level has the same, static amount of items (to begin with) which end up with the same ID on each computer.

This *should* mean that if client four moves object 4, it should be seen on each computer.

Now, i can se thus far quite clearly... however, I feel I'm missing something.


So, what i could do with to help here is:

1) Do you think it's a good idea to do this? (I *WILL* be releasing source since as i already said, I can't take the idea to its full potential)

2) Am I missing anything i should be thinking about? i can see one flaw of the idea, that each player entity would be trying to move every other player entity, because on every computer, Player1's mesh has the same ID. Moving player1 on machine 1 will move player2's machine :(. That should be easy to get around, but, Is there anythnig else I should think about?

I apreciate any thoughts- This will be a good coding/training excersize for me :)

It wouldn't work for me and the way I code multiplayer, and indeed i'm not much of a physics library person anyway, but at the end of the day if you make something that you yourself find useful then i'm sure it will help somebody else too.

I agree there would be specific uses.

I am trying to code it so toka is plugin-able :)
Thanks for your post.

I'm struggling to think past where I have got, and I cant see any flaws that might be obvious :)

Isn't this how networking already works?

Not necessarily Wallows, there's a number of ways to tackle multiplayer depending upon application. One useful bandwidth saver is to send packets when something changes direction rather than when something moves (works best with TCP/IP), or to send packets on a timed interval with momentum information (works best with UDP). Plus there's visual portalisation (not sending stuff out of sight of the client camera view).

As with all things programming the command set is there, but there's a million and one ways to use it.

Go write a network game, then come back and ask again. lol.

Without a library at all, you as the programmer have to deal with all the in/out communication part by part.


with BlitzPlay, its easier, you just organise meshes and send/receive what you need.


With the above idea, somethnig similar to Torque (i think), where you just simply tell it what entities need to be networked :)


"Thiscomputer=login()"


"Network this entity"

and

"updatenetwork"

:)

There are a few other issues you may need to resolve or data you may need to send. While sending physical state (position/velocity/forces/rotations) this won't necessarily take care of changes in the entities' animation states or alpha values. Another issue is taking care of entities which are created due to a user action - such as a bullet firing out of a weapon.

Hi Matty.

Thanks, yes, good thinking. Alpha information and scale i had not taken into consideration. Since blitz doesnt store scale information, Scale isn't a possibility without forcing the user to store the values manually.


I had indeed thought about the user created objects, since the demo code i was using to add it to shoots bullets.

The first build, I was not going to implement it.

The first build is now functional by the way.


(Ignore te FPS, its running twice on one machine)


The second build, I will be thinking of ways, like a single message containing info about the object created.

The second build is when i take acceleration into account in order to optimise network performance. (Only when tokamak is in use) so that only when the object gets moved initially, are the forces sent via network.

Thanks for pointing that out. I always miss simple stuff which could cause big problems later if not fixed :)

When i've been doing that I found that adding a "wait 5" command to the mainloop, or a similar value, really helped. It forces one app to wait for the other rather than having the highlighted window going fast and the other crawling along.

If you get the value right you can get both apps to have a similar fps and I found that makes testing network code much easier because there where less drop outs.

I hope that helps.

hehe, Becky, Oops.. I usually do that. in the screenies, my frameskipping code is hyperacting.. the games running full speed, but its skipping too much. (it was a hack job)

When remove skipping, both run fine :)

Thanks for the heads up though, I't should stop the occasionnal freeze.

By the way, I included a system where each computer can gain control of any toka object properly, whereas before, every computer would update an object if it had moved. Each object gets an ignore flag set for one or two frames so that network feedback doesnt occur.

it worked really well :)

Hey now thats a cool idea, good thinking Cyg!