Dynamic map loading && such..

#1 there are resources that allow you to change the server, i think there might be one about a map change too. But i think it wont be seamless, i would make it more obvious like everquest so you know your heading into a new map.

#2 @Tyler - hrm, I've never actually played EQ so could you give me an idea how they do it? (Not "an idea" as in coding it, but what it looks like, how long it takes, etc)

I feel the map loading speed is still a problem, so something would have to be done to speed that up at least..


-Nate S.

#3 umm I was gonna respond till I noticed you stated
"gutting the network code"
just what does that entail?
why?

do you think you could get more players in the game than what this code would do?

I would be impressed.


but anyhow ..
your only real issue with dynamic loading ..
would be lighting.

It would be trivial to do a level check against your current resources to make sure the required obj's are loaded.


but having to calculate the lighting, and then apply it.

#4 Lighting -
If you keep the precompiled lightmap files (.lm?) then you don't have to calculate the lighting, thus saving time.

Networking -
The networking system currently in Torque isn't adequate for a MMOG game (From what I can tell..). The lack a zone system && DOS (distributed object system) among other things really weakens it.

Basically I'd gut it down to the bare renderer and scripting system, then build from that.


-Nate S.

#5 @Nate: Zones have squat to do with the network layer. And Torque DOES have a distributed object system. Have you actualy taken the time to understand all the ins and outs of the Torque networking layer?


You might want to build an additional netowork layer for things like OO based RPC (i.e. Twisted Matrix) but I'd leave the Torque based simulation / netowork alone execept for minor tweaks. But that's just me.

#6 the lack of a zone system.

.. well maybe not intergrated to the networking side of things.
but im pretty sure it is.

there Is a Zone system.
and it is used extensively thruout the renderer.
so im sure only pertinant data is sent across the network.


I havent really examined it beyong that point.

I cannot be sure What is sent at this time.

as for the lighting.
yea the ml file being precomiled and then applied saves that portion of the calculating.. but there will be more to it as you work towards a seamless lighting solution during traversal


Edit :
Stan .. you can use the zone system to lighten the network load
if it is not doing it already.
so that is one of the relationship's between the two.

#7 A "zone" is typicly defined as a single playfield. In Torque those are referred to as a mission.

What I *think* you're referring to is typicaly called "region based ghosting" in which a zone is subdivided into regions, and the client is only sent updates for a handful of regions. This has a dramtic impact on the bandwidth requirements.

Or are you talking about implementing a seamless world?

#8 When I use the term "zone" I'm refering to a collection of maps that are assigned to a set of servers that can handle a certain player load.

@Donavan - 1) No I haven't looked into the Torque networking system, but I could swear I read somewhere that it didn't have a DOS. Oh well, thanks for the information on this.. 2) Yeah I'm talking about implementing a seamless world, thus the dynamic loading of maps (topic).

Anyhow, thanks for all of the replies guys!


-Nate S.

#9 Nate - 'fore you decide the Torque networking code has to go, you should really make sure you understand what it gives you. I don't claim that it will necessarily work perfectly for an MMORPG, but it represents a huge amount of work that you can build on and tweak to do what you want.

Ripping out the networking code means touching every module in the engine... You might be better off just writing a new engine, rather than trying to retrofit it so extensively!

#10 Nate you're making some odd use of terminology so I can't honestly say if Torue has what you consider to be a "DOS" or not. I highly suggest you spend the next while doing some serious hoemwork. The fact that you say "I've already started gutting the networking code in place of a more MMOG geared system" and then later say "No I haven't looked into the Torque networking system." gives me pause.

I'm not trying to be mean or nasty or anything of the sort. I'm trying to HELP you. You REALLY don't want to go mucking around with one of the foundations of this engine without have at LEAST figured out how it works and how it could be adapted to suit and MMO first.

You also might want to research the complexities and tradeoffs involved in a seemless world setup. In my opinion the cons of a seemless world outweigh the pros.

#11 @Nate: The effect you are trying to accomplish can be searched for in the forums under "portal". In-game objects that connect you to either another map or another server running another map is the desired effect as I understand it. I have a master server that controls which server can connect to who (to support a feature of my game in order to prevent hacking the jump points). A player hits the portal for Destination B on Spawn Map A, the master server is queried to verify that the Destination B server is a) alive, b) not full and that c) is a valid link. It then tells the Spawn Map A server that it is ok to begin the transfer. The rest is fully explained elsewhere. Exploring the FPS example for the server connection code is highly educational. I made no modifications to the 96 client limit for the server because I'm not worried about being that massive or that multiplayer. Avg bandwidth per client so far is 3kps. That's around 300kps per server and until I see some more money the T1 is just going to have to do. :)

@Donavan: I think what you were referring to is more commonly called "network culling". Similar to object culling for rendering. What you initally described is this functionality.

Which leads to my question.... Can the "network culling" distance be changed with the existing Torque code, or is that linked to the ViewDistance as with the renderer? Badguy mentioned an "assumption" but I'm still a little green to fully follow its operation myself.

#12 @Ben - Good points.
@Donavan - I understand your not trying to be mean man, your just very blunt; which gets your point clear quickly :)
So the cons of a seamless world make it not worth it; I follow so far, but if you don't suggest I use that, then what would you suggest?

@Cogburn - Thanks for the portal info, will check into it asap..

On to the networking code, when I say I was removing it I guess I didn't explain myself too clearly.. I'm removing the guts of the sample networking code, not the guts of the torque networking code..

Next, I abbreviate things all the time, thus when I say DOS I'm refering to a Distributed Object System (Get it? heh)

But honestly I'll admit, I haven't done much research on this engine even if I've known of since 2001. Since the major replies to this thread where about learning it, I'll attempt to do just that (In my free time that is..)


-Nate S.

#13 I looked long and hard at the various tradeoffs you have to make for seemless worlds. Here's a quick rundown:

Pros:
1) It's seemless so you don't have "zone time".

Cons:
1) The number of models in the game must be kept down since any monster could conceivably be anywhere at any time. The alternative is to not allow monsters to chase past a certain point which leave you open to explotation.

2) Item transfer, combat, chat, line of sight and just about every other piece of code becomes much more complex becuase you have to deal with "boundry" areas, leaving open the possibility for exploitation.

3) Related to #1, you have to allow monsters to travel across sever boundries and back.

There were more (in both columns) but I'm operating on 3 hours of sleep and I can't seem to find my notes.


The solution I came up with was to use a zoned system similar to the EverQuest model. You have a set of models and textures that are considered global. These are things like player models and skins, weapons, mounts, common "flavor" graphics and the like. Then each zone can have a MUCH wider variety of models and textures within it. If you've played the major MMOs you can see that the ones that have deiscrete zones (EQ and AO) have a wider variety of enviroments than those that are seemless (AC, DAOC).

My topology uses a lobby server from which the user can select which world they want to enter. The world server acts as a traffic cop directing players to the various zones. The whole thing looks like an inverted tree.

Honestly the whole zoned vs seemless thing is about choosing which set of problems you want to deal with because they both have problems both in terms of code and exploitability by the players.

Edit to add: I'm glad you didn't take my tone personaly. I'm a fairly blunt person, but I'm normaly a lot nicer.