On 06/25/2017 08:18 AM, Matthew Giassa wrote:
My guess is with meteor, let's assume 10 projectiles in rapid
succession, each generating a 15 tile radius (approx) effect, that's
about 10 * 700 = 7000 objects. How does the bandwidth shoot up to
10MB/s though? What is the minimal unit/"tick" of time the server uses?
120 ms is the tick time.
However, spells (unfortunately), do not move that simply. If one takes a cone
(simpler) that is cast to the right, it becomes
So on the next tick, when a moves more, it adds an object in the same
direction (upper right) as a, as well as an object directly right. Object b
creates 3 new objects (in directions/spaces a,b,c), and c creates another one in
c direction as well as b.
A nice side effect of this is that something in the middle of the cone takes
more damage at the edges, becaus there are more damage causing objects in the
middle. But it means that for an even modest sized cone, it can be a lot of
objects (there is some merging logic, but a lot of these can not be merged.
A better approach, would be that when that cone is cast, an invisible object
is put on the map at the origin point that records various import details
(direction, how long, etc). Then, each ticket, it just extends the cone to the
next space as needed, inserting only the objects as needed on those new spaces.
Then, the number of objects used would match exactly the number of spaces the
object is on.
Merging may not be possible, because of different durations (the first fire
effects would burn out before the second. Though this could perhaps even be
handled by recording that information in each effect, eg, a fire object may
contain data saying it does 20 damage and burns out in 8 ticks, but within that,
says 6 damage burns out in 5 ticks, so that for the last 3 ticks,the spell does
14 instead of 20, etc.
But none of that is a trivial change.
I'm not quite sure why the bandwidth would go that high - the map information
is tried to be done efficiently (only send changed data, and each map space
isn't a huge number of bytes). However, I suppose if the fireball is killing a
bunch of creatures and burning up a bunch of objects, the map is actually
Finally, does the server employ any sort of compression when sending out
this data, or is that impractical in such a case?
I think this was investigated, but never done. One has to make sure that
adding the compression does not add more latency, which may mean that there are
many small chunks of data compressed.
Note also that bandwidth used is going to be pretty directly related to the
size of the map - a 25x25 is going to use up about 4x the bandwidth of a 13x13
in highly dynamic content, simply because it has that many spaces.
crossfire mailing list