PlaneShift

Gameplay => General Discussion => Topic started by: Jessyn on December 17, 2002, 08:37:41 pm

Title: Ideas to improve performance
Post by: Jessyn on December 17, 2002, 08:37:41 pm
I had an idea to reduce lag, and figured that some(if not all) of you might have ideas to improve performance, so if we come up with enough crazy ideas, maybe the devs will like a few, and we get a better game, so....

1) Store characters locally - hacking the char could be prevented by transmitting a \"hash\" to the server to verify that the char hasn\'t been changed.  the server would only have to store a single number per character, and verify it when appropriate.  It would still have to be updated whenever the char changed, but it might reduce lag times.

btw, for those who don\'t have backgrounds in programming/cryptography, a hash is a number derived from any one way mathematical procedure.  any set of stats would have a unique hash, which wouldn\'t match the char stats if they were changed by anything other than the server(ie - hacked)

Just a thought,

Jessyn
Title:
Post by: Link on December 17, 2002, 09:45:27 pm
There is still to big of a risk storing them locally, which is why most MMORPGs don\'t, storing them server side only adds a second or two to loading time and guarantees safety.
Title:
Post by: Vengeance on December 17, 2002, 11:54:52 pm
For those who don\'t have backgrounds writing MMORPGs, ;-) the lag is not, repeat not, caused by network bandwidth.  The lag in the demo and whatever lag you experience in MB are caused by graphics overload and the 3d engine, not by the network.

Our engine keeps getting faster but our world keeps getting bigger and more complex.

- Vengeance
Title:
Post by: Tomaseth on December 18, 2002, 12:26:28 am
I\'m not experienced in writting online games or anything, so I guess I\'m not really sure how it all works. So when the world keeps getting bigger how do you deal with lag problems?
Title:
Post by: Jessyn on December 18, 2002, 12:31:13 am
ok venge, didn\'t know that, thanks

tomaseth, they will may have to do what everquest(shudder) did, and break the world into \"zones\"

Jessyn
Title:
Post by: kinshadow on December 18, 2002, 12:37:59 am
Quote
Originally posted by Tomaseth
I\'m not experienced in writting online games or anything, so I guess I\'m not really sure how it all works. So when the world keeps getting bigger how do you deal with lag problems?


Zones are the usual solution (first seen in UO & EQ).  You only load the area (city, forest, etc) you are in and only get world data about that area.  More advanced systems stream the data, but I don\'t see that happening unless someone hacks a more dynamic mapping system into crystal space.  UO did zone change overs real well (you didn\'t know it was happening), but it was 2D and took a lot less to load.  In EQ you have to sit in an inter-zone limbo waiting for the next to load.  Zones have the benefit of being distributed....you can have a seperate server or seperate process for each zone.  Allows scalability as the game grows.

The bandwidth becomes more of a problem the more players you have and the more dynamic objects the server has to tell the client about (MOBs, equipment, treasure, etc).
Title:
Post by: Vengeance on December 18, 2002, 03:34:12 am
kinshadow is right about both issues.
Title:
Post by: Tomaseth on December 18, 2002, 01:39:25 pm
Okay, thanks.  :]
Title:
Post by: Voldengrath on December 18, 2002, 09:40:26 pm
Also, that locally thing

Knowing computers, even if you are clean might send out a bad hash or whatever and cause your character to be concidered Corrupted =(
Title:
Post by: Jessyn on December 20, 2002, 02:40:44 am
once again, i bow to those with superior knowledge... :P    However, i notice no one else has come up with any ideas..... :rolleyes: oh well...

Jessyn
Title:
Post by: Snodgrass on December 20, 2002, 05:16:06 am
My guess is that most of this information is in the forum for coders which we don\'t have access to.  However, it would seem the biggest performance increases would come from compressing the data stream from the server.  When I have had to do this it took quite a bit of knowledge about the data set that you are trying to transmit.  Usually the best approach was to turn it from a text format to binary.  I got further mialege by taking standard flag information and making it parts of a byte.

The problem is premature optimization is the root of most evil in most projects.  Since this is a pre-alpha release I wouldn\'t expect that it is a hot topic right now.  However, I\'m often wrong.  
Title:
Post by: Vengeance on December 20, 2002, 07:13:21 am
Quote
For those who don\'t have backgrounds writing MMORPGs, ;-) the lag is not, repeat not, caused by network bandwidth. The lag in the demo and whatever lag you experience in MB are caused by graphics overload and the 3d engine, not by the network.


See above.

- Venge
Title:
Post by: Snodgrass on December 22, 2002, 04:26:56 pm
At this time with say 20 or so characters in a single area, with nothing really going on, I would totally agree.

However, let\'s take an example that was talked about previously and expand on it.  It was stated that if you want a hoard of monsters to come charging down the hill you could use a flat polygon per monster with an animated image on it.  In the problem statement it must also be able to be piped through a 56 K modem.  The server speed and band width are not an issue.  

On a hot day I never saw my modem ftp something in better than 3 kbytes per second.  This might be due to a less than desirable phone line but let\'s go with it.  

X,y, and z are 4 byte floats.

Pitch, roll and yaw are 4 byte floats.  

We can get rid of z, pitch and roll because the monsters are standing on the ground.  Total 12 bytes.  

You might want to add another byte to determine what texture set to place on the poly so they don\'t all look the same or 13 bytes to determine the object.  The last 2, the yaw and the poly set, determine what picture is on the polygon.  

There is an issue of update rate.  Assuming you\'re using interpolation to make the screen run smoothly the update rate is just viewed like lag.  I\'m going to use 5 updates per second.  I\"m kind of pulling it out of my hat but it the ping in some sites is about 200 milliseconds roundtrip, going any faster than that would be a waste.  

13 * 5 = 65
3000 / 65 = 46

46 is hardly a hoard.  If you forced everyone to use a cable modem or better there might be a lot more.  
But if we looked at it differently.  Since we know a lot about this data set maybe there\'s a way to compress it that is fast and easy to code.  Instead of looking at it at individual monsters we look at it in a group.  Let\'s use a group of 16 because it is a computer friendly number.  And isn\'t unwieldily as groups go.  
Some other constraints to make life easier is that the collision border is group sized not individualized (ie. Groups don\'t mix except within themselves) and go around objects, never split, and we will say each member is killable and everyone in the group faces the same direction.  We create a group grid of one by one byte and all members are within that.  

X,y, yaw, Group position and direction.
Since yah does not have to actually be a float it can be one byte, another shortcut.  X,y and yah = 9 bytes.  Plus, type byte = 10.  Then each group member sub(x + y) = 2 bytes.
  So,
members * 2 + 10 = 42 bytes.

That\'s 42 bytes as opposed to 192 bytes for 16 monsters.  42 X 5 = 210
3000 / 210 = 15    15 X 16 = 224

224 monsters is not bad but I want a real hoard.  Fortunately we can do better.  Let\'s try another approach at the problem statement and constraints.  Say that instead of having 2 halves, each element independent, we have an orbital pattern or each monster in the group is assigned to a position via a look up table.  To make it interesting we will have 64 K entries in the look up table/ or up to 64 K, since ram is cheap.  Then we will have 2 kill status bytes for our 16 monsters.  

X,y, yah, kill status, group position, and type = 14 bytes.
14 bytes for 16 monsters not bad.

14 X 5 = 70.

3000 / 70 = 42

42 X 16 = 672 monsters

So that\'s 672 independent monsters all moving around.  That might work for a small battle but wouldn\'t it be cool to compress in some serious carnage.  We\'re going to need some more tricks.  There is always culling based on distance but it would be better to have it all on screen to give the gamer a scene of true panic and mayhem.  We don\'t want them to be stationary.   A group of monsters just standing there looks stupid.  So the obvious solution is large groups that can be broken up (ie formation).  Formations can then be broken up into groups or individuals for combat against characters.  Let\'s show an example for a formation of 256 monsters.  

256 = 32 Kill bytes for individual monster killing
X,y, yaw + kill bytes + formation position = 43 bytes.
16 X 5 = 215
3000 / 80 = 13
13 X 256 = 3,328

3,328, now that\'s a hoard of monsters.  So you can have individual groups and divisions  mixed and have enough bandwidth left over to do the other required communications on a 56 K bod modem.  Okay, so we can\'t use 3328 monsters but if you want two armies fighting each other with 1,000 monsters apiece, where there are different levels of interactions required, this approach might work.  

Some of the numbers I used here, for instance update rate, I just had to pick something to show a comparison.  However, in concept whatever system you used, compressing by using grouping, would probably get more monsters on a field for the same bandwidth.  It\'s possible that this is the way it\'s really done anyway or something similar.  This is something I just came up with as an example of data compression concepts.  

I hope this clears up my point.
 
Title:
Post by: Severed Hope on December 22, 2002, 09:08:53 pm
Well, would using \"flat\" animated pixie-characters (ALA Final Fantasy Tactics ALA Jet Set Radio) -- which would also give any artists we have here a chance to flex their creativity, would that help in processing speed for them?

I mean -- if you take the 3-D out of the characters and monsters, leaving only 2-D animations, aside from flags and stuff, or maybe even just removing the 3-D out of every non-static picture... first of all if its done right it can look wicked, if dated -- but this is a free game and we can\'t expect people to need a huge high end super computer to play it anyway -- so if the graphics aren\'t the best on earth, no one can really complain.  But like I said if its done right it can look wicked.

Im just not sure of that would actually help.

And if I sound like a moron, feel free to tell me all about it.
Title:
Post by: Bigfoot on December 22, 2002, 11:20:43 pm
Nothing realy to do with Network lag, but...

Clipping plane clipping plane clipping plane... there has to be a clipping plane. Im shocked one hasnt been put in already.

also people have to stop refering to low FPS (frames per second) as graphical lag. lag, latency and ping have nothing to do with graphics ^^. Low FPS has nothing to do with network speed or codeing but has every thing to do with the rig thats running the game, and slightly less so but still with the polycounts of the games models

On teh network side Daoc used a bubble system, where the player client asked for all relavant information within a defined radius. the result was that you had no zone loading, expect where they wanted it, such as the capital cities and entering dungeons I was playing on european servers and had very comfortable gameplay (network wise) sept for the odd ping spike.
Title:
Post by: kinshadow on December 23, 2002, 08:04:06 am
Well, first off, its a MMORPG, not C&C online.  Don\'t expect hoards.   Next, 5 updates /sec for every actor seems a little high, but thats a moot point do to the fact that you can\'t probably approximate the bandwidth off just positional stats and non-compresible packet headers and error-checking codes will eat up more bandwidth than the game anyway.  In the end system, each new actor will have a range of data to queue up with everything from visible inventory (for building the mesh) to visual enhancements.  Never-the-less, bandwidth is still not that big of a concern with more of the action being interpolated more than you think (updates/sec will scale to your available bandwidth).  Hyper-accurate position is only important where aim is a factor.  With this being an RPG, I doubt that will be the case (see EQ style targeting for an example).  Also, I don\'t believe the \'zoning\' issue has been completely resolved.  I would like transparent zoning that scales nicely and maximizes bandwidth, but we\'ll see what comes up.  Lastly, I don\'t see what \"3D\" has anything to do with net-lag besides the fact you have a couple more coordinates.  The client does all the work for build and displaying the graphics, the network traffic just gives it the abstract data it needs (i.e. Bob the dwarf with Platemail and Shiny Sword and current position, then next position, then next, etc.).  Compression of the data-stream just adds more work for the client and server, leaving you less time and resources to do that labored 3D rendering.

Yes, the 3D performance (in fps) will go up with a dynamic (scaled to constant fps) or user configurable clipping plane (there is almost always a clipping plane, its just farther out to show off the world I imagine) and fog.  Then again, most slow speed you\'ve been seeing has been sovled with the new CrystalSpace engine.  Smart culling and good level design are much perfered to hacking off arbitrary scene data.  Possibly some good-old diminishing detail models a\'la terrain engines for larger scenes?  In the end Bigfoot is right, if you want a faster game, buy better hardware.  Yeah Capitalism!
Title:
Post by: Bigfoot on December 23, 2002, 11:08:25 am
As of so far I havent seen anything to suggest a clipping plane in MB, and most of the time when i brought it up (ans will be bringing it up again with the coders) id get ignored or get told thered be one eventualy. Good level design is one thing and haveing a nice culling system is good to, but put those along an infinate Z axis and you still have considerable drops in FPS. Distacne fog is used to hide the clipping plane ^^...

But one thing you have to remeebr with your last statement is that a game has to be scalable in some way for as smany users as possable, and just haveing a top line system doesnt mean you can go nuts  in teh graphical department, Ive got quite a hefty machine and it still chugs at full settings in some situations on some games, you primarily want some 50-60FPS on your recommened machine specs 70%+ of the time, and at least a 30FPS frame rate on your minimum specs. the user shouldnt have to buy a new mahcine to play a single game. Nothing worse than devs that grossly lie about there games required specs.

might be wrong with this but, im not a capitalist and have quite a dislike for them myself... sorry if that comes over rude but im not sure of what context your last sentance was meant to be in.

heh im as red as a radish today, was working in teh garden and am like crispy bacon... got a heat headache and tired maybe even a bit of sun stroke ^^.

If any Devs read this sorry havent been in the Dev channel alot lately, been a little busy here and will be for at least another week and a half since its christmas. Ill get those models to you tommorrow Boon

now im off to take a disprin, and get some sleep... heads killin me
Title:
Post by: Link on December 23, 2002, 11:13:49 am
Who cares about building/buying new PC\'s they are cheap. The cable and dsl companies just need to get off their lazy bums and run us rural people broadband!  X(
Title:
Post by: Kiern on December 23, 2002, 04:41:42 pm
Quote
Originally posted by Link
Who cares about building/buying new PC\'s they are cheap. The cable and dsl companies just need to get off their lazy bums and run us rural people broadband!  X(


yes, thats the best idea I have ever heard
Title:
Post by: Cyonamie on December 23, 2002, 06:53:22 pm
Considering I\'m pulling between 65-100 fps with a Radeon 7000, the low frame rates you guys are getting must be from voodoo cards or something :p
Title:
Post by: kinshadow on December 23, 2002, 07:21:18 pm
Quote
Originally posted by Bigfoot
As of so far I havent seen anything to suggest a clipping plane in MB, and most of the time when i brought it up (ans will be bringing it up again with the coders) id get ignored or get told thered be one eventualy.

The plane I\'m talking about is defined by your view frustum.  If they are specfically defining it by rendering to the farthest out polygon or making it insanely large, then I guess you can say it was \'turned off\'.

Quote
Originally posted by Bigfoot
 the user shouldnt have to buy a new mahcine to play a single game. Nothing worse than devs that grossly lie about there games required specs.

Scalable graphics is a given.  I think there will be enough options in the end game to allow anyone to get the performance they want.  This may mean things like turning off shadows and lowering your resolution, but the game will still look decent and be playable.

Quote
Originally posted by Bigfoot
might be wrong with this but, im not a capitalist and have quite a dislike for them myself... sorry if that comes over rude but im not sure of what context your last sentance was meant to be in.

That was a joke.  I wasn\'t implying that you support the Beast that is Capitalism.  Purhaps I should say \'Yeah Socialism! Free GeForce FX\'s for everyone!\'.

Title:
Post by: Ragnarok on December 23, 2002, 08:48:01 pm
Is streaming the world in the way of a 2D image possible?  Such that the client renders the world in view by processing a color coded 2d image sent by the server?  I realise that this would offload almost all the work onto the client (and im not sure if this isnt already done) but if a more efficient process for sending the user the world is not already in place, then the computer would have to render less that is not in view... im not sure how one would make a system like this, but if you could simplify the process of rendering what the server sent, then maybe users would experience less rendering based lag.

(Please tell me if im talking out of my @ss here... because while i am somewhat of a programer i have no experience with 3d rendering)
Title:
Post by: boonet on December 24, 2002, 12:25:09 am
The server only sends players positions and such... the whole world is already included with the client. The engine actually spends a good amount of his time deciding what objects are possibly visible and which ones are not, in order to render to screen only the visible objects. If I understood correctly what you are saying (language differences may have created interpretation difficulties to me ;) ), you want the server to render what each player sees and then send the image to each player. This is clearly absurd for different reasons:
a) if a client may have problems rendering what a single player sees, how could a server render what hundreds of players are seeing?
b) you expect a framerate of let\'s say 30FPS when playing: this means rendering 30 different images to screen every second. Do you imagine how much bandwidth would be necessary to transmit a 30 1280x1024 (in example) images each second to each player connected to the server?
You talk about rendering lag in your post, and I think you are referring to the freezing you may experience sometimes in the tech demo: well, that lag is absolutely not related to the rendering. It\'s a data exchange problem existing between client and server, nothing more.
Title:
Post by: Vengeance on December 24, 2002, 07:28:25 am
Can an infinite number of semi-technical monkeys code a non-lagging MMORPG given an infinite amount of posts to a forum thread?  :-)

- Venge
Title:
Post by: Jessyn on December 24, 2002, 10:43:13 am
well, it worked for war and peace, tolstoy had all those monkeys hidden away in his basement, and besides, we\'ve got more monkeys than he did.

Jessyn
Title:
Post by: Ragnarok on December 24, 2002, 06:38:48 pm
Quote
Originally posted by Vengeance
Can an infinite number of semi-technical monkeys code a non-lagging MMORPG given an infinite amount of posts to a forum thread?  :-)


HAHAH Thats one of the funniest things ever.

Quote
Originally posted by boonet
you want the server to render what each player sees and then send the image to each player.


Thats not really what i meant, but it was a stupid idea so dont worry about it. ^_^;;
Title:
Post by: num4 on December 25, 2002, 08:27:03 am
I just bought that card :D...but i cant figure out how to turn off my old Integrated video card through the BIOS...how do you do that?  I am running Windows 98 SE on a HP.  ?(
Title:
Post by: Culsoron on December 25, 2002, 11:57:50 pm
I don\'t know much about programming, but its like everything else right. If you try to balance 20 plates you have to use a lot of strenght right. So if you cary the plates one at a time, and go 20 times its much easier. I think the simpler the code is the faster and more stable our beloved game is. As long as people struggle with little bandwith, dividing the game as most as possible without distroying the experience is my best sugestion. And cleaning up code is important I think.
Title:
Post by: Monocle on January 05, 2003, 08:34:03 pm
How can you check your fps in PS?  This game doesn\'t run that well and i have a Radeon 8500 LE, AMD Athlon xp 1700+, 256 ddr, and I get a 8000 in 3d Mark 2002 SE.
hmm... i do have wierd stuttering problems in other games, could be that too.  If someone had the same problem please help me!