Edit: throughout whenever I mention the “Value-figure” of a coordinate, I mean darkening its colour, so yes the “Value-figure” of a given pixel's HSV values would decreases but I guess its “Saturation-figure” also sometimes.
I'm considering how a graphics-engine lights any given environment, at the level of code.
So I guess perhaps the simplest way to light a scene is just to provide a Value-figure (i.e. Value as in the HSV colour-model) to each pixel according to whether you think the area of the scene is more or less in shadow, and just forget about light direction and light sources etc. I guess this is probably how it was done until relatively recently, and probably is still done this way in a lot, if not most, cases. This way being very lightweight in terms of calculations and processing.
A slightly more demanding approach for an outdoors scene in which day-night are operational would be to again assign a Value-figure to each pixel, but also give each a ‘sun-height’ value between 0-180, where each coordinate's Value-figure maximises as that ‘sun-height’ value reaches 90, and minimises at 0 and 180. The rate at which that ‘sun-height’ value changes simulating the course of a day. And then to avoid pitch blackness, keep each coordinate's Value-figure above-zero at its very minimum, so as to provide each with enough plausible visibility in the absence of the sun.
A more demanding approach further still is to then have each coordinate's Value-figure increase in accord with its relative position to a point light-source. So if indoors, and there's a single medieval torch on the wall, then let the light-source of the room be the coordinate that is exactly at the centre of that torch; and then let each coordinate's Value-figure increase in-proportion to its relative angle to, and distance away from, that point. Again, give each pixel a minimum Value-figure below which it can't drop (as before) in the absence of the torch. This now becomes more difficult as secondary-reflections have to be considered a little bit, which I'll say a little bit about now.
Regarding secondary-reflections, in theory I guess you let each coordinate that is illuminated by the light-source become its own light-source of a lesser intensity to the original's, which then illuminates further any pixels within its range, and which pattern then continues until the reflected light's intensity drops to zero. But in practice this must surely be impossible, or at the very least extremely impractical to execute at a reasonable frame-rate and hindering to the game's functioning. So I guess secondary-reflections should be limited to simply looking at the environment and deducing which areas would have more or less reflected light enter them and then scale the Value-figure of coordinates in those areas accordingly.
The most demanding approach--excepting the extreme case of millions of secondary-reflection calculations that I just talked about--would be to calculate for a point-light-source as before, but to do so for multiple light-sources: so if there were 6 torches in a corridor as well as a fire-place, then calculate each coordinate's Value-figure according to the angles it tends with, and its distance from, each of those torches as well as the fire-place.
Secondary-reflection for the side of an object that faces away from the light-source would be challenging without doing those extreme calculations I mentioned earlier: how otherwise do you judge how dark the away-facing side of a sphere should be whose opposite side faces a torch? Surely you can't just let the Value-figure of any coordinate that has a different coordinate ‘eclipsing’ it be zero, as there has to be some gradient…
