Twitter  Facebook  YouTube  E-Mail  RSS
The One Man MMO Project
The story of a lone developer's quest to build an online world :: MMO programming, design, and industry commentary
Design Fail
By Robert Basler on 2011-02-02 10:47:59
Homepage: email:one at onemanmmo dot com

Sometimes you design something and it seems like it is a good solution, efficient, easy to implement, and then there's the reality.

My system for updating entities across the network was based on a simple idea. Everybody who is interested in a particular area gets updates for all entities within that area. Sounds simple right? But here's the problem. The areas are relatively small, so entities move from area to area pretty quickly.

Each time an entity moves to a new area, it needs to be synchronized with everybody interested in that area, ie the game needs to send the full entity definition to the new guys. There are a couple ways to do that, one is to send everything to everybody, the other is to send full updates only to the new guys. I implemented the latter since it is more bandwidth-efficient, but it turned out to be pretty expensive anyway. Too expensive in fact, but not in the way you'd think.

The system I created which distributes these updates takes a little while to set itself up with somebody new. Not a long time (under a second) but still too long.

So I'm rearranging my entity updates so that updates are per-entity. Which entities a player gets updates for are still area based, but once those updates are started, they continue without interruption until they are deliberately stopped. Synchronization is easy, there's just a bool for everyone to indicate if they are synchronized and it only has to be done once per client. The cost here is bandwidth within the datacentre network as per-entity updates are not nearly as efficient packet-count-wise as per-area updates. The bandwidth to the client should decrease with the number of full entity updates, so that's the win here. Also, the code which did the full-unit synchronizations was rather unwieldy, so having that gone will also be an improvement.

This is going to require quite a few changes and ripping out a large chunk of working code, but hopefully when I'm done, the logic which updates everybody still runs fast enough to scale. That's the unknown this time.

New Comment

Cookie Warning

We were unable to retrieve our cookie from your web browser. If pressing F5 once to reload this page does not get rid of this message, please read this to learn more.

You will not be able to post until you resolve this problem.

Comment (You can use HTML, but please double-check web link URLs and HTML tags!)
Your Name
Homepage (optional, don't include http://)
Email (optional, but automatically spam protected so please do)
Plastic or paper? (What's this?)

  Admin Log In

[Home] [Blog] [Video] [Shop] [Press Kit] [About]
Terms Of Use & Privacy Policy