Aussiemandias!
That’s an excellent question, though having no experience with multiplayer games in UE4, I might not be well suited to give a very meaningful answer. However, partially as you proposed, I think that doing the FOW-texture update (the contents of the tutorial) solely on the client should work just fine. The responsibility of the server would then be to give an array of visible enemy units to each client per tick. This solution decouples the FOW and the hiding/unveiling of the enemy units.
I would also consider letting the server calculate which texels in the FOW-texture that are visible to each client, and replicate these (not as a two-dimensional array but as a List/Set of visible texel coordinates). The FOW-textures will still only reside on the clients, and the blurring and texture-updating would be carried out clientside based on the visibility-data from the server. However, here is where your concern about packet-size comes into play. If you are making an RTS with 200 units per player where each unit has a long sight range, the number of texels visible to each client could get quite large. Thus, I would avoid replicating visibility-data to the clients if you know that the amount of visible texels will get large.
Note that the tutorial in its current state isn’t doing any kind of visibility-blocking neither from static nor dynamic geometry (there’s a TODO in the code). Since writing the tutorial I have changed the FOW-system quite a bit, and my current solution
does visibility-blocking and performs updates on the texture in a separate thread, which is necessary to get acceptable frame times with larger FOW-textures. If I’m able to find the time, I will try to update the tutorial during the weekend. If you want to, I could then get back to you with some pointers on how I would change the code to make it work in a multiplayer environment.
Cheers,