7
« 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.
Show Posts
