Creating only network objects within a certain distance
  • Hello,

    I'm currently using uLink for a networked multiplayer game where i have a very large terrain.

    I'm not even close to finishing the game and i already have 127 networked objects with lots more to go (maybe ending up with over 500)

    The frame rate yesterday is now crazy low, only 0.7 frames per second (yes 0.7 fps)

    I think it must be because so many networked objects.

    Most of the network objects are far away from the player so most of the time he cant see them and they cant affect him.

    Is there a way unLink can automatically instantiate only objects within a certain range of each networked player? If objects go out of range automatically delete them, so that it doesnt spend time and bandwidth updating objects that the player cant see or interact with anyway?

    Can uLink do that automatically? if so how do i set that up?

    If it cant, is there an asset that works with uLink that i can buy to do it for me, or do i have to write all that code myself, and how to do it?

    Thanks
    Desperate!!!
  • 8 Comments sorted by
  • Vote Up0Vote Down YukichuYukichu
    Member
    1220 Points
    http://developer.muchdifferent.com/unitypark/uLink/MinimizingBandwidth

    It has some stuff on scoping and whatnot, but I believe most of it you have to write on your own.
  • So why dont they add that to uLink as a feature since they are already keeping track of all the networked objects, instead of forcing everyone to keep track of them again, wasting double CPU time and memory.

    All they have to do is to calculate the distance from each player to the networked objects, if distance is greater than a certain value, delete those networked objects so that they dont have to get any networked data and CPU time. If they are within range, then instantiate them and send them data, automatically.
  • At 127 networked objects, i have a frame rate of 0.7 frames per second, so its basically unusable, i cant even switch to another windows at that frame rate, its basically frozen.

    whats the maximum amount of networked objects you guys have in your program, and what frame rate are you guys getting?
  • Vote Up0Vote Down YukichuYukichu
    Member
    1220 Points
    So RPCs use the name as part of the data, so keep them small, which makes naming them ridiculous. public void X() public void Y()

    Check how often you're updating your objects.

    Beyond that, if you're trying to update their position and this is the issue... try the scoping mentioned above. As to why it's only partially implemented... err... got me.

    Sorry I can't help ya more. I ended up using a different product for my networked objects, something that'd keep data in sync with less overhead and had better results. I use uLink only for P2P / scene management.
  • Yukichu,

    Thanks so much for your answers, can you tell me which product you are using for your networked objects?

    Thanks
  • @Yukichu
    I also want to know about what product you are using. If it's not suitable to post in the forum then please message me.
  • Vote Up0Vote Down YukichuYukichu
    Member
    1220 Points
    At one point someone asked me what I use in a PM a year or so back, and I responded, and apparently the site admins were watching it for, I don't know, talking about other products? I have no idea, and deleted my PMs, so I don't really care about talking about it openly in the forums now.

    It really depends on your needs. My game is like Realm of the Mad God, so there are 'worlds' which are just server instances that will hold about 75 players. There is no large streaming world, so I don't need uZone. To my knowledge, there isn't another uZone type product for Unity.

    That being said, it opened it up to a lot more possibilities. I hopped on the Bolt bandwagon back when it was thriving. Bolt does a lot of stuff for you that was frustrating at times with uLink, and it keeps the network overhead about as light as possible. Compression, state synchronization, frame interpolation, niceties like a boolean takes 1 bit instead of 1 byte, events that are light (4 bytes) vs. RPCs that if you name it anything more than 2 letters uses more than 4 bytes.

    The downside is that it handles only a single connection between a server/client. So P2P is nonexistent, and I still use uLink to serialize stuff between server instances (player moving between realms) and keep track of that. Someday I might redo it using UNet LLAPI, but why rewrite the wheel right now.

    Bolt support also had some issues, it's owned by ExitGames now (Photon/PUN) and while it has support, the updates have been slow; but, there is still progress being made and stuff being fixed. It's just not the glory days anymore. As I like to joke on the Bolt JabbR chat, it's still better than uLink free support.

    Why did I move to bolt? The smoothing script that was provided with uLink broke down when you moved quickly, sometimes jittered, and just wasn't very good. One of the reasons I even went with uLink was that it provided these scripts for you and I do not want to be a networking genius. Bolts frame interpolation, smoothing, and transform replication is top notch. I love it. It works and it works well.

    Bolt does a lot of things right, but it could be better. It could have that old-timey super support. It was not made for a MMO, but I'm using uLink as mentioned earlier to shoehorn my game into it. It's more mature than UNet. However, there aren't too many 'big' games made with Bolt. It doesn't do WebGL and probably never will, as ExitGames does not deem it a priority. It still runs within Unity, which is good and bad. The 'frame' aspect for keeping everything in sync is a freaking dream.

    Other options are Forge. I own Forge too but haven't played with it. It sounds nice, but from what I've read the documentation is light, the developer just disappeared for months (like fholm at Bolt) and didn't say a thing to anyone, which is stupid, and it seems like it's the "kitchen sink" approach. Throw everything into the product and say you have the best ever, then open it up on GitHub and say how awesome it is when what you really want is for the users to fix your stuff and give you free updates.

    Lastly, there's using your own Lidgren. Just... don't... unless you are trying to do something outside of Unity completely. Use UNet LLAPI and write your own HLAPI.

    So, that was a lot of text. Maybe it will get deleted. I don't know. uLink isn't bad. It has the most MMO-large-world-scaling type solution I know of. It has lots of integrated stuff. The tutorials are AWESOME which let me pretty much build my whole networking setup without anyone actually answering my questions. This was great until I hit a brick wall. I reported a bug 2-3 years ago that, to my knowledge, was never fixed... still, with RPCs sent to others being sent to yourself as well.. It just wasn't cutting it for what I needed specifically and the support was... ahem... not that great.

    Again, it really stinks that for a multiplayer game networking is VERY important and it's one of the weakest characteristics of Unity. UNet is coming along, but I really feel like it's every other Unity feature: release something in it's barest form, have people develop assets for the asset store to make said feature incredible, assets are sold and Unity takes a slice of the sale. Problem is, no one has a UNet LLAPI Networking Suite yet. I don't think so at least.

    Well, if this does get deleted, that was 30 minutes of writing down the drain.
  • uLink uses minimal CPU if you don't send any RPCs. Look at the RPC / State syncronisation calls and what data is actually being sent for each object. Make sure you need to send it.

    We have over 5000 networked objects on full servers which runs at 500+ fps and 100+ clientside (which is bottlenecked by gfx)

    If something is dormant, putting it into a sleep mode is the easiest way to reduce bandwidth and CPU used by uLink.

    For things like AI, instead of sending 10+ updates of position per second, try sending a destination and the network time you expect it to get there and let the client interpolate towards it. This can reduce the positional updates to very low frequency (we use once every 2 seconds for active AI)

    As for the support for this product, if you are able, I would look into other solutions. It has all but been completely abandoned by MuchDifferent while they spend all their time consulting for what I assume is a large mmo client.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Tagged