Splitting Client/Server

#21 Tweaking the size of the packet by itself is not enough.

I found the thread and its probably way outdated compared to the current version of torque but it might be worth a look.

It is a thread discussing getting hundreds to thousands of players
running around on a map (in my case all connected clients, not just ai bots) and what I did to speed things up.

http://www.garagegames.com/community/forums/viewthread/25423/1#comment-204228

if anything its interesting to see how the engine has changed over the years.

#22 Hi!
Do you know how to speed up a loading process?

The game over internet:
if in a level there are 400 objects it is loading less than 1 minute;
and if in a level there are 3 000 object it is loading greater than 3 minutes;

The game on a local computer:
in both cases a loading is quick

#23 Look into datablock caching. When you connect to a Torque server it sends the datablocks over the connection. I'm pretty sure that this is unnecessary, since the server will ignore client-side datablock changes anyway.

Also, see if it's doing a mission download while it's there - also probably not necessary.

#24 What do you think about prefabs and about others design features?
Can these play a role in the time?
Maybe World Editor includes powerful features to optimize a level?

#25 I had changed these:
$pref::Net::PacketRateToClient = "100";
$pref::Net::PacketRateToServer = "100";
$pref::Net::PacketSize = "1024";
in scripts/client/prefs.cs

And a speed of a level loading increase 3 times

I wanna more :)

What do you think?

#26 Right now I don't think prefabs make any difference in load times - they're just a convenience in the editor.

Another thing - check that in the mission download phase that it doesn't just download the level; make it check to see if the existing level on the client machine is the correct version and only download the mission file if it's incorrect (it should already do this, but it never hurts to verify).

#27 I don't understand you where I should to check?
In scripts (scripts/client/missionDownload.cs) there are 3 loading phases and these are not interesting cause nothing happens here. What do you say about?

#28 I wanna add: the stage: "Loading Datablocks" is very fast to complete, the stage: "Loading Objects" is slow;

Then I could guess that datablocks load for a little time but game objects load for a long time, could I?

#29 Ok, notice in scripts/client/missionDownload.cs you have a callback onFileChunkReceived()? This is called from the engine in sim/netConnection.cpp in NetConnection::chunkReceived(), so when you're getting that "LOADING MISSION" message you're receiving a file over the network. When the server and the client are on the same box you're still "sending" it and "receiving" it using the transfer parameters you have already been tweaking.

I think the key is to use that CRC check to see if the file needs to be sent at all - basically, if the CRC checks out the server should load the file, and the client should load its local copy. Of course, it might already do that but it's not looking that way to me. I need to look at it more closely myself.

#30 in my game chunkReceived isn't called
it seems strange

#31 The loading of objects is the process where the server queues up all ghostable objects in the zone and serializes and sends them down one at a time to the client.

I actually chased this down once for a different reason. Now, lets assume you have 4 thousand objects in the zone, that means that it needs to release 4k objects to the client.

The heavier they are, (Pack/Unpack'd variables) the more bits that need to be sent. so, think about it, you have a object that passes lets say 1 point3f, a 2 bools, and a int in it's pack/unpack routine.

That could be based on implementations, 3 floats (3*32) + 2 bools (2*1) + 1 int (1*32) or a total of 130 bits. Usually though, the objects are much heavier when you go up the inheritance tree and see the pack/unpack for the parent objects.

So for simplicity sake, lets say that each object uses 200 bits. So, that means when a user connects, you are streaming 200bits * 4000 for the initial ghosting setup.

or 8,000,000 bits or 100,000 bytes, or 100 kilobytes. Now this doesn't seem like a big number, I mean I've downloaded pictures bigger right?

Well, if it was just the transfer speed of the raw data it would be fast, but instead, the engine is breaking this bit stream into objects, kinda reading it like a buffer. And it needs to create objects from this data as it goes.

So the logic goes

Read x bits from stream
-Read 32 bits for int,
-read blah for blah etc.
--create object

Rinse and repeat for each object.

Then the client needs to register the object in the simdictionary, etc.

Once the ghosting is done, it then starts it loops in relation to painting the screen etc.

(I assume you've stopped reading by here, but I am coming to the answer:))

The answer to your problem is to write your own objects which are lighter weight. The stock player.cpp is very heavy and a bit of the information stored in it isn't exactly needed depending on what you are trying to do. The same can be said about other objects in the engine.

So, the short answer is you need to evaluate the objects your broadcasting and trim them down where you can, and always remember your not building a FPS, your building a MMO, so it's not necessarily how accurate it is, but how accurate it APPEARS it is to the player.

One other thing you could look into doing would be limiting the intial ghost down to just objects around the player versus the whole zone. In Stock T3D it sends down the whole zone to the player. If I remember right, the mod I mentioned above limits even the inital ghosting to just objects around the player.

There is a warning about doing that though, I read in the engine several times where the original devs got into arguments over what was more expensive

The two paradigms where:
1) -Send everything and then just send updates from there out (The way it is now)
2) -Send just what is needed and create/delete stuff on demand.

For a FPS, the first paradigm was the best, because after load in, it was important for the players to see what was happening the quickest. For a MMO, it's not as important since your not dealing w/ projectiles and such.

Hope the info helps,

Vince.

Winterleaf Entertainment L.L.C.

#32 Wow, this is the greatest answer ever!
I had released a resource you mentioned above, but this didn't help.
I will look in send information stream, and will try to decrease this.
Thank you for your expanded answer!

#33 @Vince

Thinking that packUpdate/unpackUpdate is influenced on a in game process because it is called every tick

I try to decrease a loading time, and unfortunately this doesn't help

#34 @Genomegame,

How many objects are in your zone? Are we talking 10k+?

#35 @Vince

5000 objects in a level

#36 And just to recap,

You modified Netconnection.h kinda like:

enum GhostConstants
   {
//Winterleaf Entertainment
/*
Little note here, we aren't building a game, we are building a world editor, and since each edit is a ghost
we need the ability to have alot of ghosts.  Since ghosts never update, they will only send a update once
to a single player during the lifetime of the session.

So for the default setting 12-3 = 9, and 9 can be stored in a 4 bit uint(0-15)
So for the new setting, 18-3=15, and 15 can also be stored in a 4 bit uint(0-15) thus no changes need to 
be made to the GhostIndexbitSize You can calculate it by Ciel(Log(GhostIdBitSize)/Log(2))

*/
      //GhostIdBitSize = 12, // This is 4096 max ghosts
      GhostIdBitSize = 18, //This expands it to 262,144  18-3 = 15
//Winterleaf Entertainment
      MaxGhostCount = 1 << GhostIdBitSize, //4096,
      GhostLookupTableSize = 1 << GhostIdBitSize, //4096
//Winterleaf Entertainment
      GhostIndexBitSize = 4 // number of bits GhostIdBitSize-3 fits into
//Winterleaf Entertainment
   };

And when you say you have 5k objects in the zone, your talking 5k objects in the mission file (or however you load them) i.e. statics?

Of those 5k objects, how many are unique? i.e. different models, materials, etc?

The problem might not be on the ghosting side, but instead maybe the art side in the time it takes to load the materials into memory along w/ the models.

You might end up needing to load something like developer.amd.com/tools-and-sdks/heterogeneous-computing/codexl/ up and seeing where the expense is in calls. I use it a bit when I need to see where a bottle neck is in an application.

#37

Quote:You modified Netconnection.h kinda like:

I used these values:

GhostIdBitSize = 16,
MaxGhostCount = 1 << GhostIdBitSize, //4096,
GhostLookupTableSize = 1 << GhostIdBitSize, //4096
GhostIndexBitSize = 6

After changed nothing happens

Quote:And when you say you have 5k objects in the zone, your talking 5k objects in the mission file (or however you load them) i.e. statics?

Yes, 5k objects in the mission file and they are static

Quote:Of those 5k objects, how many are unique? i.e. different models, materials, etc?

I don't sure while our designer on a holiday. Does a count of unique models can slow down the loading process much?

Quote:The problem might not be on the ghosting side, but instead maybe the art side in the time it takes to load the materials into memory along w/ the models.

Designer says: all art are optimize completely.

Quote:You might end up needing to load something like developer.amd.com/tools-and-sdks/heterogeneous-computing/codexl/ up and seeing where the expense is in calls.

Well, it is very interesting, I'll try to dig it.

Thank you again, @Vince!

#38

Quote:
Yes, 5k objects in the mission file and they are static


Quote:Of those 5k objects, how many are unique? i.e. different models, materials, etc?
I don't sure while our designer on a holiday. Does a count of unique models can slow down the loading process much?


Quote:The problem might not be on the ghosting side, but instead maybe the art side in the time it takes to load the materials into memory along w/ the models.
Designer says: all art are optimize completely.

You missed the point - Five thousand fully optimized but different textures take longer to load than five hundred poorly optimized textures. So, how many are unique? Of the five thousand objects, are there ten different models replicated fifty times each?

#39 There are 100 unique materials/textures