I would like to have a map for my game, something the player could pull up with the “M” key. I would also use it for the mini-map. Okay?
Now, I don’t want the entire map revealed at game start, I want it blank, and for it to reveal as the player explores. This seems easy enough. I just have a texture with the entire map on it, and use a bitmask to cover over the parts where the player hasn’t yet been. I translate where the player is in the level to the corresponding area of the bitmask and modify that part of it to be “transparent”. I then do a blend between the texture and the bitmask. That part is easy enough.
The tricky bit is how to reveal areas to the player (i.e. how to modify the bitmask). Now, I could just say that anything within a certain radius of the player’s location becomes revealed, and modify that area of the bitmask. But that is not ideal, because it would not respect the level’s walls (e.g. if you were in a corredor with a room just on the other side of the wall, the radius reveal would show part of that room, even though you have never been there).
What I would like is a modified radius reveal, but one that is affected by the level’s geometry, so that it only reveals on the map what the player can see (or has seen). If there is a wall in the way of the player’s line of sight, it should not reveal what is beyond that wall. Similarly for a closed door (but an open door should not truncate the reveal area, obviously).
Go get a couple of game programming books from Amazon.com on Strategy Game Programming, AI Programming Wisdom, Game Programming Gems, RTS Game Programming. Many of those books cover this very topic and contains lots of useful code and algorithms. Visiting your local book shop with a good game development section will give you useful guidance too.
Okay, fair enough. I guess this isn’t really a place to talk about algorithms in general, more of a “I have this specific problem with this script” kind of place. I will hunt for the answers I am looking for elsewhere. Thanks anyway.
It kind of can be that place, but this is quite a broad topic without a specific answerable question. You asked for suggestions, so I pointed you at some books that I know have the solutions. I am sure there will be other forum members with deeper solutions you can use, that will post.
Perhaps it wasn’t made clear to you but fog of war is a non-trivial problem. There is no simple answer, it is highly application specific. I have seen a few questions about fog of war pop up before, I don’t believe there is a general purpose solution for everyone.
www.google.com.au/search?q=unity+fog+of+war.
It seems you want your fog of war to be based on line of sight, that seems reasonable but it also increases the complexity of the problem significantly. I would suggest you look through some of the other approaches people have taken and see if you can find a way to modify those to include your line of sight requirement. When you’ve made some progress it should be easier to post a more specific question which is easier for us to help you with.
I’m looking at the possibility of using a raycasting technique right now. But I haven’t implemented it (or even started designing the algorithm). I’ve been distracted by other things (between learning my way around Unity and trying to get some models done, it’s been a bit busy).
My main worry would be with performance, since we are talking about quite a bit of raycasting, being done every time the player’s view changes. Do you think it would be better (in terms of performance) to write such a routine as a C++ program and call it from Unity? (I know that’s a Pro-only feature, I’m fine with that, I’ll have pro in the next month or so). Or would I get the same performance using the bult in C# scripting?
Unity exposes highly optimized raycasting methods from the physics engine. Whether you call them from scripts or C++ it won’t make much difference. It still quite algorithmically expensive.
One way to approach it would be to voxelize the game world into discrete chunks. Have some kind of precomputed connectivity graph and just traverse that data structure for visibility checks. That would be much faster than trying to do ray casting against world geometry. Depending on the resolution of the chunks you could use that alone, or just to reduce the amount of raycasting.
That would be similar to how Umbra operates, I don’t think there is any way to access their visibility data but if you could that would be ideal.
Fair enough, point taken. I kind of figured it might be prohibitively expensive. So much for that idea
I’ll do some research into creating some sort of PVS graph, as you suggest. It seems to me that I read something similar to that concept on GameDev or a siggraph paper not that long ago, but I’d have to find it again.
Anyway, I’ll keep researching it. I have some time, I’m not really ready for this particular system yet.
Cool, bump this thread when you do start working on it, I would be interested to see what direction you go with it. My current title doesn’t need fog of war but it’s an interesting problem and I’m curious.
Ray casting may not be prohibitively expensive and you may be able to time-slice it to reduce the overhead to a manageable level.
I’m working on a project where i will be needing fog of war functionality. Not with LoS, but only a circle around the player will be revealed. So kind of like drawing with a circular brush on a black sheet. I think that’s the approach i will be taking. One think i’m wondering about is how to effectively save the “image” of the fog mask on a mobile device. This would need to be saved quite often to not loose any progress.
