$12256 / $11500
I'm creating this thread to get a discussion going about Dynamic Lighting and Fog of War.
By simply darkening areas the player can't see, games add a ton of atmosphere. Players quickly get a "survival horror" feel when they can't see what's around the corner.
Some notes:
Because it's not strictly necessary, it's low on my priority list. Reminder: I'm talking about Alpha on a 1.0 version of an engine. This would be pre-alpha tool creation on a regular video game timeline.
Now. Flare sticks to the tile system pretty closely, so a simple per-tile lighting algorithm (as seen in Diablo 1) would probably work okay. The basic algorithms are easy to understand. What I lack in plain SDL is a blit function that draws a sprite with lower luminance. I could pre-render those at lower light levels and keep them in memory instead, at the cost of long map load times and more memory usage.
Anyway, I haven't given this much thought because it isn't a high priority for me right now. But feel free to discuss ideas, post links to existing algorithms, etc.
This website's content is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
First, at the risk of sounding pedanting, let's not confuse terms.
[b]Lighting[/b] is one thing - it's based on radius and areas closer to player character are brighter. This is what Diablo1 did, in a primitive way.
[b]Fog of War[/b], for me - is something from an RTS game, especially Warcraft 2. It's closely linked to exploration. Areas you've never been to are dark, and once you visit them [b]they stay revealed[/b]. That's what I would like to call Fog of War. Do we agree with this definition ? I think this feature is completely unneeded in a Diablo-like game, because its function is performed by automap.
[b]Line Of Sight[/b] is self-explanatory, but I'll try to describe it anyway. Imagine a line leading outwards from your character. If that line hits an opaque obstacle, everything on that line up to and including that obstacle is visible, and everything past the obstacle is not visible. Line is just that - a line, and it's often used as a way to measure if two beings of a game world can see each other.
[b]Field of View[/b] is just lots of Lines Of Sight spreading in all directions (at least conceptually). This is what makes stuff past corners and walls invisible. Diablo1 does it only for characters. Nox does it for everything, and I think it looks amazing, much better than in any Diablo game (and plays very well):
http://www.youtube.com/watch?v=KGbJvbDMEf8
Note that algorithms that do it this way (calculating lots of lines), particularly tile-based ones, are not necessarily the best ones for the job. In Roguelike games, raytracing and raycasting FOV algorithms are known for being quite slow, and more importantly produce artifacts (like A can see B, but B can't see A). It's nice when Field of View is mutual. If you use a simple tweak and just assume that if A can see B, then B can see A, you're asking for trouble. Half-Life 2 is famous for this. In order to make things "Fair for the player" they've made it so if you can't see an enemy, he can't see you. So if there's an entrenched soldier, you can walk right up to him by walking backwards, or by carrying a crate in front of you. In a fantasy game the exploit could be performed by drinking a potion of blindness. And if you have spells or abilities that allow you to see farther or through walls, it may be detrimental to you.
Rogue Basin, a roguelike development wiki site, discusses a lot of tile-based FOV algorithms used in roguelike games.
http://roguebasin.roguelikedevelopment.org/index.php?title=FOV
The general consensus is that so far there's no holy grail. There are algorithms without artifacts, but they may leave something to be desired in other areas. "Permissive" algorithms can reveal too much, making it hard to use cover against ranged attacks.
@b0rsuk:
I think the field of view in Nox is a matter of taste. I have to admit I've never played Nox myself, but, from what I've seen from the videos you posted, I think I would be quite confused and it would make me mad. But, on th other hand, it's quite realistic. So, in my opinion, it should be implemented into the engine, but only as an additional option to some standard lighting system.
@Clint:
I could give it a shot if you wish so. But, as I've only little experience in SDL by now, don't expect the result to look too great nor to be done too soon.
I think the vision system in Nox is a bit much. It's well done, but kind of nauseating to look at if you're not the one playing.
I am open to a much simplified system, at first anyway. Example:
It wouldn't look amazing, but it would be easy to implement and the hooks could be used for a better algorithm later (e.g. blending the tile's brightness based on the four corners of the tile).
This is not a priority to me at this stage of alpha. If it never was added I'd be okay with that (it's not strictly necessary to the enjoyment of the game).
You should seriously switch from SDL to OpenGL for graphics. With SDL you just restrict youself to low quality effects with horrible performance.
It may be to be an harder task to learn OpenGL but it is worth it.
I feel very special. Apparently I'm among the very few people who don't feel dizzy playing Nox ! I wonder what extra talents I also possess.
Spell: I think Flare looks and performs decently as is. But also I'm charmed by the simplicity of high-quality 2D games from the 90s era.
I am sure the more advanced isometric games all didn't use such sluggish software graphics rasterizer like SDL but rather GPU acclerated interfaces like OpenGL or DirectX.
Why use 90% of your CPU if you can make it use 3% of your GPU instead? ;)