My desired final shape for the standard view/map/light system

[GlyphGryph]

Right now, darkness and moving around is a bit of a binary proposal - it’s all or nothing, in a way. We’ve got things that are a bit inbetween, like traveling inside houses during the day, but I’d like to see it expanded. I’d like to see darkness play more of a varied role, mechanically, and contribute more thematically.

So I propose the following visual “changes”. Some of them may already be in the system in some form, but they all serve to form the foundation of my vision.

• Squares have light levels. At the very least, we need “well lit”, “poorly lit”, “dark”, “very dark”, and “pitch black”.
• We have three different visual states for objects - Identified, Seen but not identified, and Unseen.
• Seen (but not identified) objects should display as a grey “X” for barriers or walls of some sort, a grey “O” for large upright objects that aren’t walls (like playground equipment, zombies, etc), and a small grey “o” for small objects or prone objects like a pile of items, a corpse, a creature like a rat or a zombie that is lying down. When moused over, these are describes as “something blocks the way here”, “something stands here”, and “something is on the ground here”.
• Light level influences, but is NOT the sole determinant of, which state an object falls in. Proximity, perception, the size of the object, the number of objects on the tile, recent actions by the object (moving things are easier to spot, if not identify), and the object’s stealth value (if it has one) also play a role. For creatures stealth is obvious, but things like glass walls may end up getting a stealth value as well. Finally, having identified something already, you gain a bonus to continue to identify it until it is no longer visible.
• Night time is NOT (generally) “pitch black”. Even from a distance, you can see barriers fairly easily, and make out “things”, maybe even shuffling around, but you may have trouble identifying whether something is a potential loot pile or a corpse waiting to get up and attack you. You no longer have a “square of vision” around your character - instead, you have the same vision range as during the day, but the darker it gets the more likely distant objects are to wind up Unidentified or Unseen. Instead, night time time will be “dark” or “very dark”.
• Night vision simply raises the darkness level by one.
• Many lights sources will raise the darkness level depending on distance, but may not always raise it to “well lit”. A vending machine at night may only raise this level by one, meaning you’ll still fail to identify something standing in it’s light… but you’ll probably be able to determine much easier that something is, in fact, there.
• Indoors areas at night and many underground areas are often considered “pitch black” or “very dark” (at best).

Enemies suffer the same limitations (though perhaps in a simplified way). Even if zombies see you, they may not identify you as prey thanks to their fairly low visual perception. The longer you are in their range of vision, though, the higher the chances of you being identified.

[Tase]

All these things sound good. Sounds like a large change so it would be cool to do this incrementally starting with tiles having a light level and evolve around that, making a solid system.

[GlyphGryph]

I’d like to work on the “noticing” things mechanic, myself. Though, as always, I doubt my coding skills will be up to the task.

[Tase]

Yea but the noticing system would take into consideration the light level of the tile of the thing to be noticed.

So start with the simple little thing, like variable light level depending on context, then once that’s working well, implement features that use it, instead of shoveling the whole thing in there and trying to figure out which system (lighting or noticing) is at fault.

[GlyphGryph]

If we were starting simple, it doesn’t matter which one we do first, because the noticing things wouldn’t take into account the light levels at first.

Most normal approach would be to have a visibility method on tiles, and then have a visibility call on objects (monsters and items) that grabbed that and modified it with their stealth rating before turning it, and visibility checks on objects compared to this value.

Then it wouldn’t matter how tiles determined their visibility or what was going on on the inside there, at least for my component.

Unfortunately, I’m pretty sure we don’t have the strongly OOP approach that something like that would require, so it may not even be possible for a tile to keep track of it’s own visibility.

[kevin.granade]

A quick optimization of the lightmap code is rapidly sliding into a full-scale refactor, including translating the coordinate system used, inventing a new LOS algorithm based on bresenham line drawing, slurpung the lightmap class into the map class, and expanding the lightmap cache to cover the whole map, and building the lightmap’s caches into the map clas itself so they’ll be utilized by everything.

This foundation will allow all the other stuff to be supported without killing performance (I hope).

Also I agree with all your proposals for viewing, I like the default classes for barely-seen objects in particular, hadn’t thought of that.

[Tase]

[quote=“GlyphGryph, post:5, topic:462”]If we were starting simple, it doesn’t matter which one we do first, because the noticing things wouldn’t take into account the light levels at first.

Most normal approach would be to have a visibility method on tiles, and then have a visibility call on objects (monsters and items) that grabbed that and modified it with their stealth rating before turning it, and visibility checks on objects compared to this value.

Then it wouldn’t matter how tiles determined their visibility or what was going on on the inside there, at least for my component.

Unfortunately, I’m pretty sure we don’t have the strongly OOP approach that something like that would require, so it may not even be possible for a tile to keep track of it’s own visibility.[/quote]

From a design perspective, if you design the noticing system then implement the tile light level, you’ll have to come back on the noticing system and redesign it for it to consider the tile light level. Doing it the other around (light level then noticing) lets you do the light level system, then implement the noticing system that uses the light level system.

It would be the foundation to the whole light system, you need to approach it with the broader idea of “what do I want in a light system” and not the narrow mindset of “what do I need to get the noticing system to work”. Doing the later might just produce a light system that only cathers to the needs of the noticing system. If we end up with this then start adding stuff that uses the lighting system, it might come short of our needs and we’ll need to redesign it and everything that uses it.

Its sorta like the problem Kevin has; the lightmap code wasn’t optimized/“properly done”, so to do this he had to redesign it around, and therefore have to redesign everything that uses it.

Always logic (light level system) before mapping (using logic, noticing system) before presentation (UI, showing the oOx stuff).

[GlyphGryph]

Tase, I see you do not have a very object oriented design philosophy.

Again, with decent OO, it would be trivial to design the notice system to be agnostic to how the light system works or even whether it exists, and appropriately so since we’ll want some sort of notice system before finishing EVERYTHING it works through, and simply trust the whatever-it-is it ends up getting it’s information from.

If you “design the noticing system” in such a way that it has to be redesigned because the inputs are of a slightly different value, well… you didn’t design it that well. At worst, you should have to add a line or two to pull in an additional component/source of information in a completely predictable way (not exactly a redesign).

But I understand that this is not the way our system works, and hoping for it is kind of silly.

[Zyuta]

Does this include items on the ground and headlights on vehicles too?
For example, if I leave the lights of my Mobile Fortress of Death on and get out, will they still be on? Will they emit a sort of “square” of light, or is it in the shape of a beam?
Or, if I turn on a flashlight and drop it, does it emit light?
And finally, will there be streetlamps? Perhaps some sort of power plant that turns on street lights in a certain area of the map?