As a side note… second life’s back-end architecture is pretty sneered at by most of the MMO development community.
I’m not sure id take second life as an example of how to do anything, other then market.
See this analysis of their back end…
http://news.com.com/Second+Life+Dont+worry,+we+can+scale/2100-1043_3-6080186.html?tag=nefd.lede
I haven’t used it very much either, but I remember kicking a ball down some steps or something like that. I have not used it a great deal.
Understood. I brought it up mostly because they are able to seemingly shuffle in and out what must be a large amount of textures and models, albeit kinda slowly.
Well… looking at their docs they have physics primitives in the scripting language.
I don’t know if their scripting is all server side or a combination of server and client though. if i had to guess, id guess they were running the physics server side. Have you veer noticed any lag in its response? that would be the give-away.
Jeff,
Is what you are suggesting something along the lines that a player has a bounding box that is their “viewable” frame, and once another client is inside this viewable frame that the position/state changes are sent directly to the other clients quicker than they are to the server… ie if your tick timer is 500ms to the server then changes should be sent directly to the other clients as they occur and to the server at the end/beginning of the tick? And that once combat is occurring the tick timer is reduced to the server so that server can accurately predict movements?
regards,
Shane
Kind of. there are really two different mechanisms at work here.
For motion you can indeed limit inter client updates to an area around the player. You can then break the zone down into a regular grid of cells, each of which should be , for example, the size of the most space you could see when at maximal camera zoom out then assign a channel to each one. The player would report his movement at a high resolution to the channel of the cell he was in, and listen to that cell and the 8 surrounding ones.
The characters could 'free move" at whatever their movement rate is and separately report their position at a much lower frequency back to the server.
Now for combat, I’m suggesting something a bit less rigid in space and more rigid in time.
How you handle the combat really depends on your movement rules. if combat does not effect movement,as is true in many MMOs which only use a vauge sense of “distance” and “direction” in their combat logic, you can keep movement the same in combat. You run the combat actions on a tick but you keep movement free flowing. In this case all you need to "clock’ is the combat actions.
the simplest way to do this is to put everyone in combat in a zone on the same clock but this limits your ability to parallelize different combats occurring at the same time. Instead, you can have "mele groups’ where all those fighting each other are in one group and handled on one tick,. but other groups can also be fighting at the same time and be handled on different, parallel ticks.
The tricky part of that scenario is one someone from one group suddenly decides to attack someone from ANOTHER group. Now you have an inter group dependency. The solution is to merge the two groups into one mele when that happens.
Now above I said you could leave motion free if position isn’t critical,l but if your going for a more D&D miniatures like feel then position becomes very critical and motion needs to be limited during combat. The solution I’ve toyed with for that is to give each combatant a zone of control. Any character who enters that zone of control becomes part of the mele, even if they don’t attack and aren’t attacked, and have to make “mele moves” that are coordinated by the combat logic in order to move through the zones.
Moving in and out of little zones might be awkward and frustrating, so it might be advantageous to coalesce zones that re close by into a single wider radius zone.
regards,
Shane
[/quote]
Can channels be created directly to the other clients in this way? My understanding is that channels are connections to the server??
Functionally, channels are primarily for client to client communication. They transfer data from one client to another.
For security reasons this is implemented as a star network, which is to say that the data passed through the bottom layer of the back end infrastructure, but (unless you attach a server side listener which is not recommended) it does not involve the logic or persistence layers at all. It is effectively acting as a router.
Depends who you talk to. I respect that they chose a model that makes the business remain profitable no matter how popular or unpopular the service is (if they get lots of new user-generated-content, they get many new servers, which the generators of that content pay for in proportion to how much they’re generating). Their business isn’t to license high-quality technology to other people, so they instead get maximal profit from making technology which is “just good enough” rather than abstractly perfect.
I think the absolute quality of the technical solution is a lot less important than making sure you don’t waste lots of money building a technology which no-one uses, a common trap that a lot of games industry companies have fallen into in the past (especially core technology groups).
OTOH, they’ve open-sourced the server (so you can go look yourself), and said they’ll be letting anyone connect to the service with their own privately-hosted servers. When I last heard that bit, they had a photo of a Sun server on the screen at the time :), so I thought you might already know about this.
For physics, IIRC it wasn’t always thus, but now absolutely everything is server-side.