syncronizing cell states on a lattice network

[jones]

I have created a proof of concept for a team vs team game mode, I have only did a small ammount of leg work just with a SP version. What I now faced with is how to effectively sync each cell state, there are 100 cells. I am trying to figure out a way to do it that would be the most efficient manner in regards to bandwidth.  What I am thinking of doing is setting the cell states server side and transmitting them to the client. the problem I see occuring is that after the 100 cells have changed states anyone that JIPs will cause a sever bandwidth spike. Ideally I would like this to be able to support around 60+ players, I am just not sure what the effects of 100 variables being synced would be on a server's badnwidth.
Anyone that has any good insight on how this could be done in the most efficient manner throw me a bone here. I will probably just have the server publicvariable the cell state variable, throw it on aserver and test it. But I would hate to waste time if there is a better way of doing it.

The capture zone is based off of a cellular automaton. Each side starts off with  one row of cells that is in their control and in order to capture a cell it has to be adjacent to a cell under your faction's control. Win conditions could be anything from capture %x of the zone, to connect a row of cells across the board or what not.

[kju]

How about a single value to encode all cells.

0 = empty
1 = blue
2 = red

For a 3x3 field:

111
012
222

=> 111012222

Not sure what the maximum number for a double is in ArmA.
For sure you can encode it more efficiently.

[jones]

I looked at the wiki and it states that publicvariable handles arrays and I process everything through a 2d array. So it might be as simple as passing the array every few cycles. I will have to test if publicvariable can indeed handle a 2d array. If not I will have to see how large of a number sqf can handle.

[JamesF1]

If you 'read' the cells like you'd read a book (left-to-right, top-to-bottom - or, frankly, any direction would work), you could do some primitive run-length encoding, coupled with something similar to kju's replacement suggestion.  It's a small amount of processing, but it reduces transmit, and you could obviously preprocess the functions to save on computation.

E.g., a simple grid, as in the right one would normally be represented as such (81 characters):

Code: [Select]

BBBBBBBBB
XXXBBXXXX
XXXXBBXXX
XXXXBBXXX
XXXXXRRRX
XXXXXXRRX
XXXXXXRRX
XXXXXXRRX
RRRRRRRRR
But can now be represented as this (36 characters):

Code: [Select]

10B3X2B8X2B7X2B9X3R7X2R7X2R7X2R1X10R
Which is, obviously, far shorter, and fits in one standard string... which makes sync'ing for JIP people painless   Obviously, the 'compression ratio' will vary depending on the individual grid... but given the nature of progressively taking regions (i.e. taking joined up regions), it'd be a very, very rare case in which the compressed string was much more than half the data length of the original.

Oh, as one final point, if you do try and implement this... it may pay to try and log the efficiency of such an algorithm in the four main reading directions (R-L, L-R, T-B, B-T), just to see which produces the best compression ratio for the way the game ends up being played!

[jones]

I did the quick and dirty pushed it across the network with a 2d array and it worked but it was not the most efficient. The array measures 667 bytes and when transmitted the bandwidth went from 1kbps to 8 kbps  with just myself on the server. Pretty sure it wouldn't scale well with 60 plus players. compressing it down to around 40 to 50 bytes would surely work well in a large MP enviroment.

I only scripted this as a test to see if it would be viable as a gameplay option, Myself and a few individuals that tested it with me liked it enough to warrant a project out of it. I might actually go back to the drawing board and redesign it from the ground up.

The most challenging aspects are how to make the grid on the server in the most efficient manner and the data compression to send across the network to update the markers to reflect the cell state. Right now I just proceedurally generate the grid using triggers and team  comparisons in every cell checked against it's 4 neighbors. I am not sure if using triggers wouldn't be more effective than say using nearestobjects to build an array of players and do the team comparisons for each cell. With 4 players on the server and a 100 triggers running I still had 50 fps on the server so the triggers didn't seem to have a huge impact like I expected.

[JasonO]

How often is this grid (or how often should it be) updating on everyones clients?

[jones]

I was updating it every 30 seconds when I tested it. Setting the refresh time on the server acts as a capture time so it would be a good thing to make it adjustable via the Mp lobby params.