Let there be light!

One of the most important aspects in a good looking game is lighting (and by implication shadowing). Without lights things typically look flat and while that is fine for many games, there are also many (2D) games that will benefit from having more advanced lighting, highlights and shadows. 

My current goal for supporting lights in my engine is to have a simple local light model (Blinn-Phong) with forward rendering. 

In case you 're not familiar with the technical details "local" lights mean that we only consider light in the context of a single object. How much light does this object receive from the lights in the scene? This disregards global lighting effects where light bounces around and reflects off of things and each object is not only lit by lights directly but by also with light reflecting off of things etc.

The term "forward rendering" means that our rendering loop uses a naive approach of computing light contribution per each light and object. The more complicated rendering model is called "deferred rendering" (or deferred shading, or deferred lighting) where light contributions are accumulated over the whole scene in to a separate data buffer and then computed per each pixel in the scene using the light buffer data after all the geometry rendering has been done. 

In a game engine like this we're mostly interested in slinging sprites where the sprites and sprite animations are based on textures. The textures already capture the the interaction of light and material in some way and encode that  information what we perceive as color. This is contrast to physically based rendering where objects model physical properties and the engine computes a simulation of light based on the material and light properties and how they interact. For mostly lighting up sprites this model does not lend itself well. 

A typical problem with the "forward rendering" is that when the number of lights and objects grow in a scene the amount of work becomes "number of lights * number of objects".  But I'm thinking about solving this by taking a shortcut and instead of finding lights that light up any given object in the scene per object I'll look up the N  most influential lights that currently pertain to all objects in the viewport and use that set of lights for all the objects.  Technically it's incorrect but I have a feeling it will suffice. And like we say in graphics work "if it looks correct it is correct". 

A massive issue though is the support for isometric tiles.  In isometric rendering you no actual 3D geometry but yet your rendering supports "perceived" depth and 3D scene by slinging tiles that display pre-rendered 3D content.  The problem with this is that when light computation is done the tile is only a 2D quad and lighting up the quad does not produce lighting as it should be in the 3D world represented by the tile's picture. 

A possible way to solve the lights in the isometric scene case is to create a light mesh that maps perceived depth (what the player sees in the isometric tiles) to  actual 3D information (including position and surface normal) and then use that information to compute the light. This will solve the problem but leaves us with the issue of manually crafting all the light mesh information which is a tedious operation.  So overall I'm not sure if this route is worth the effort or whether I should just drop isometric lights entirely.  Thoughs?