Issue is the game I'm working with uses a rather massive map, and a player often has more than 50 units at once. For starters the only way I really found possible to have the entire map be covered in black images, as in forum_account's fog of war library, and then have them be recalculated each time a unit takes a step. (Or have a client looping proc re-calculating all visable areas every 3 seconds or so)

The first issue I encounter is covering an entire map with images in the first place takes a huge amount of time when we're talking 1000x1000x4, (4 million). Then we have to link those images out to the clients, and recalculate if an image should or should not be visible whenever a unit who can see a tile leaves viewing distance of that tile. When working with 4 million images BYOND seems to enjoy crashing utterly. I managed to pull it off before though, only issue is, the best CPU usage I was able to come up with with the most simple code I could come up with was a 70% CPU usage on 5 units walking around, which admit ably would be fine in a single player game but I'm hoping for at least 20+ players at once.

Currently BYOND's luminosity and basic sight limiting built-in system for one guy doesn't even take 1% CPU when there's opacity turning on and off and moving at extreme speeds across the map and we still get a quality output, if we use any work-around image system we end up costing a hell of a lot more with a far more glichy output. Managing with images indeed works, but it doesn't work well, and only functions in a limited number of situations. I'm hoping for something that's far more... capable, and simple. We shouldn't have to make a huge complicated work around to accomplish something that in nature is pretty simple, and has been seen so commonly in the past in games as old as Age of Empires with no issues.

Edit:
Sorry about the length, I have a habit of ranting, and didn't actually notice how long this was..

I don't mean to sound rude, but doesn't that seem a bit extreme to you? Should we really have to 'settle' for such a dramatic work around to accomplish a lesser version of something found so commonly found elsewhere? And even if we did use that method, and I might even be desperate enough to if I could... but it would still require massive constant calculations to get accurate non-lagged visual results, by testing oviewers(MAX_VIEW_DISTANCE) on the mob in question whenever relevant, and then doing tests on the mobs in oviewers() to see if they provide sight to anyone. That can result in 1000s of calls to oviewers() every frame, that alone costing a huge amount of processing, without even counting the extra calculations related to determining display. Even if our computers can handle that it leaves little room for any customization to the viewing rules.

SuperSaiyanGokuX wrote:

Instead of having a black-out image that covers the map, why not let the players see the entire map (or, well, the entire chunk that fits in their view), but use selectively-displayed images for each unit they can see?

That's close, but it's not really what he wants. We are talking about a fog of war here! You should first be thinking about the turfs, not the mobs. For the purpose of making a fog effect, we care about the turfs in view, not the mobs. Once you have the turfs, then you can worry about mobs that exist in the contents of those turfs. Limit the searching that will be done as much as possible, without sacrificing functionality.

I would also wonder why anyone thinks it's a good idea to cover the entire map with images, when only a limited number of them will be seen at a given time. An excessive number of images can easily take up large amounts of CPU. You should only need as many images at a given time as it takes to fill the view's area. This means there will be less images and unit mobs you have to worry about, which will also result in less CPU. Why have any images past the client's view if the player will never actually see them?

Basically what I mean is something like this:

This is just an example. It might not actually work correctly. When you recalculate the display, essentially what you would do is maintain 2 lists of turfs. The first list will contain references to the turfs that were in view before your last step. The second list will display the turfs that are currently in view. You would then remove any images found in the turfs in the first list, then add the necessary images to the turfs in the second list. You can make this even more efficient if you compare the lists to only add and remove images to and from the turfs that have recently entered and left the view. Hopefully this makes sense.

I think Forum_account's Fog of War library desperately needs optimization, which is too bad, because I don't plan on using it. As usual, no library out there is capable of doing what I want, so I will be writing my own fog of war from the ground up, when the time comes.

Hmmm. I'd be more concerned with which mobs/units can be seen vs which turfs. I'd say that it should be reasonably plausible that you'd "know" all of the terrain around you (maps, recon, etc.; no one goes into a battle without at least knowing the lay of the land...), but just not necessarily know where enemy units are located within that terrain.

Yeah, I know the idea behind fog of war. I just think it's pointless...lol Any army worth anything will already know the terrain before the active combat (or even just troop movement) comes up. There should be no need to hide any of the terrain, at any time (even if it's just temporary, only until they travel through it for the first time)

(Again, sorry about the length.. I'm REALLY bad at communicating a point with a small number of words)

Most people in ancient times probably didn't know the details of the terrain a thousand miles away, unless they were frequent sailors. You have to consider that in some RTS games, units and buildings are way out of proportion compared to the land, so a given area might look small when it actually isn't.

I think a fog of war is relatively justified for games that take place before modern times, but not past that, for very obvious reasons. Realistically, for people in ancient times, anything outside of a 1-2 thousand mile radius would have been mostly unknown. I am talking about people who believed the Earth was flat, so I don't think fog of war is going to hurt anything there.

However, I will admit that in games like Age of Empires, the total starting view radius is ridiculously small.

Niche? I'll give it that. It does only truly benefit RTS style games, as well as a few team-based action games, which does not encompass all of BYOND.

However, my argument is that it's something that BYOND can't accomplish efficiently as is, and it 'in theory' would be easy to accomplish in a similar manner to as is.

Allow me to explain my theory: As I said, I was playing around with the illumination, dark vision, infra-red, and all that. I noticed that if I could make my player capable of seeing through solid objects on his own, the illumination system in place would be perfect for what I want to accomplish, in a single player game however. I however want to accomplish a multi-player game, and don't want my enemies seeing what I see. In theory it wouldn't be hard to apply the same process for illumination, but make it so that illumination was capable of being set to be mob-specific, so that you could say it only illuminated for if you were in its list of applicable mobs. This would allow us to set illumination to the mobs we control in an RTS game, and have them set to only give illumination to ourselves and our allies within the game. That is the basis of my theory, and theoretically it would work smoothly based on how effective the current illumination system is.

A further theory however, which admit-ably logically speaking could be harder being it would actually go through operations we don't already see.. would be to instead of having per-player illumination, simply root the dark_vision of mobs in a list on the player to the player as needed, in addition to the dark_vision of the player object himself if he had any. This theory however does not logically run on the same operations as anything already built into the game, and might not work as it would sound.

My first theory however appears to me to be logically sound in easiness to accomplish, and if it is indeed as easy as it would appear I would see no reason not to include it, even if it is a tad focused onto the RTS field.

By per-player dark-vision, I think you're asking for mob.see_in_dark.