quote:

---

Original post by Anonymous Poster
Yeah...but then you run into the problem of not being able to load balance the server if there is only one zone server so then that pretty much negates doing it that way too

How do the professional MMOG net engines do it? There''s gotta be a way we aren''t thinking of.

Synth0id

---

Corba/COM?

quote:

---

Original post by stodge
Corba/COM?

---

Oooof!, I've worked with CORBA, it is a wonderful solution when you have thousands of clients manipulating data over a WAN on multiple platforms (think client interaction with their bank account the Bank's web page).

But...... ORBs like TAO and VisiBroker are built for reliability and not performance. Discovery times can be measured in seconds
and then there is alot of communicating back and forth. It also makes a huge difference on how the (ORB part of the) server is configured, and that is dependent on how you implement your server.

The US Military is developing a real-time implementation of CORBA but the last I heard it is still in development.

I looked at it but I concluded, in the context of MMOG's, that it was like using a hammer to push in a thumbtack (IMO). I wouldn't use it for real time applications, especially not over the internet.



[edited by - DeltaVee on October 30, 2002 2:51:06 PM]

I read somewhere that an MMPOG (or middleware?) in development was using their own implementation of Corba. I can''t remember which game it was though.

So using something like Mico (www.mico.org) isn't an option? I think that the theory I described above won't work, so my next step was going to be looking into using Mico instead. Thoughts?

Thanks

Edit: found the link for the above post: http://www.atriarch.com. They're using ACE+TAO.

Also, BigWorld (www.bigworldgames.com) use a system similar to Corba but optimised for real-time useage for their engine.

[edited by - stodge on October 30, 2002 5:03:40 PM]

Synth0id, any more thoughts on this?

I found a couple of things that might interest people; Terraplay - www.terraplay.com, and Nel - www.nevrax.org. Nel is being used to develop a game called Ryzom (www.ryzom.com), and it''s open source (GPL). They have a great little demo (albeit simplistic and not highly optimised) called Snowballs that you can download and play with.

I think your zone slave is some sort of object views.

The idea is that each agent(players, npcs, nearby servers) on the zone keep a list of Object Views(OV) for the object on this zone.

The OV stores the knowledge of the agent about this object then each event is sent thru the OV associated with the object that triggered it. This makes dead reckoning piece of cake and make possible to increate the ammount of partial updates you can send to the clients.

This, unfortunely, requires a huge amount of memory, a zone with n objects and m agents m*n OV would exist. We can optimize this in may ways:

NPC agents can have a single OV for all object with npc agents as they might be running in the same process of the ZM.

Player agents only have OV for objects that are nearto them, for the rest we use one OV.

Server agents can share their OV''s between each other.

You can further optimize by making only a few objects having individuals OV''s, a brick wall is not going to change as much as a dragon fighting.

Something that seens to be pretty hard to me is how make 2 agents interact between each other if they are in diferent zones.

Well, Asherons Call 1 + 2 divide the world into vertical strips. Each server manages a vertical strip. Whenever a vertical strip becomes busy, it narrows itsself and pushes some load onto an adjacent strip - thus dynamically load balancing.

Personally, I think some kind of 2D load balancing would be better, but its more complex to implement.

Of course, the biggest problem when doing any kind of load balancing is managing events that cross the borders - like fights.

UO seems to use fixed rectangular areas for its servers. When you cross the server border any fighting just stops. And its very annoying when the game wont let you start a fight because your target is just over a server border!

I''ve been thinking about having semi-overlapping Zone Masters, so that any one spot is always shared between two ZMs, but one ZM still only manages a small area of the world. Looking at one dimension of the world:

X= 0..10 km: handled by ZM A and B
X=10..20 km: handled by ZM B and C
X=20..30 km: handled by ZM C and D
X=30..40 km: handled by ZM D and E

If I''m at X=15 my state would be tracked by ZM B and C (I can be connected to either B and C and they update eachother).

A bad guy at X=25 spots me and aims an arrow at me. This is registered by ZM C and D. C will notify me of the arrow coming at me/through me.

A bad guy at X>30 is at least 10km away from me and probably can''t be aware of me. I''ll always have at least one ZM in common with anyone closer than 10km from me.

Another advantage would be that there''s no fixed border where my client will pause to connect to the next ZM. I can switch from ZM B to C anywhere between X=10..20.

I guess the problem is the load of having ZMs update eachother. In a 1D world, one ZM will overlap 2 other ZMs. In a 2D world, one ZM will overlap something like 4 other ZMs.

Eotha - Thanks for that tidbit about the dynamic strips in AC I and II. I can use that.

As for Zone managers there would probably be too much overhead between the Manager and the Slave to justify the gain during peak period.

Instead you could try the having a three part strip. In the center part of the strip the server is solely responsible for all activity that is going on. It does not have to do anything but deal with what is happening. In the smaller secondary parts at the edges the server is responsible for all activity AND sending all information to the adjacent strip. This would include firing across a boundary line, etc. All strips align vertically or horizontally. Strips can exist in a couple of sizes - a "large size" used for uninhabited or sparsely inhabited areas, a normal size for regular population, and a thin strip used to handle high traffic areas. One design consequence would be that cities would tend to be built on boundaries so that the strips can be easily divided. Strips would probably be in multiples so you replace a large with two normals, a normal with two thins. If you discover something is really tight you might even have the city divided initially on a boundary and then be able to devote one or nor thin strips to it.