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

 / (a)
-- (b)
 \ (c)

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 changing considerably.

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

Reply via email to