Author Topic: Grid-Based Lighting  (Read 19823 times)

lithander

  • Newcomer
  • Posts: 25
  • Karma: +0/-0
    • View Profile
    • pixelpracht.net
    • Email
Re: Grid-Based Lighting
« Reply #15 on: July 29, 2012, 09:52:30 PM »
I was trying to add lighting to a browser-mmo we're working on at my job. The game has animated character-sprites moving from cell to cell in an isometric perspective. Without support for sub-cell positions there were noticable jumps whenever an agent would pass the cell boundaries.

So I admit I hadn't roguelikes in mind at the beginning. But I could imagine some RLs to make good use of this algorithm. Visually, as you both suggested, being able to tween between two turns might be nice for a more fancy visualization.

Gameplay-wise I think the concept of something being semi-visible or semi-lit is interesting. In a binary solution a field is either in view or not and sometimes it's hard to predict the result before making the move. With a more sophisticated simulation gameplay could become more intuitive and varied - for example by adding a the option to stealth or hide in dark places. I'm tempted to prototype a little to explore the potential. If there's something to show I keep you posted.

As for releasing the source. I plan to make a blog post explaining the algorithm and would post the demo + source along with it. In it's current state and without a word of explaination you wouldn't want to see it anyway! ;)
« Last Edit: July 29, 2012, 09:58:45 PM by lithander »

requerent

  • Rogueliker
  • ***
  • Posts: 355
  • Karma: +0/-0
    • View Profile
Re: Grid-Based Lighting
« Reply #16 on: July 30, 2012, 12:14:32 AM »
I was trying to add lighting to a browser-mmo we're working on at my job. The game has animated character-sprites moving from cell to cell in an isometric perspective. Without support for sub-cell positions there were noticable jumps whenever an agent would pass the cell boundaries.

So I admit I hadn't roguelikes in mind at the beginning. But I could imagine some RLs to make good use of this algorithm. Visually, as you both suggested, being able to tween between two turns might be nice for a more fancy visualization.

Gameplay-wise I think the concept of something being semi-visible or semi-lit is interesting. In a binary solution a field is either in view or not and sometimes it's hard to predict the result before making the move. With a more sophisticated simulation gameplay could become more intuitive and varied - for example by adding a the option to stealth or hide in dark places. I'm tempted to prototype a little to explore the potential. If there's something to show I keep you posted.

As for releasing the source. I plan to make a blog post explaining the algorithm and would post the demo + source along with it. In it's current state and without a word of explaination you wouldn't want to see it anyway! ;)

Thanks man, looking forward to it.

lithander

  • Newcomer
  • Posts: 25
  • Karma: +0/-0
    • View Profile
    • pixelpracht.net
    • Email
Re: Grid-Based Lighting
« Reply #17 on: August 05, 2012, 01:21:33 AM »
I'm done cleaning up the code and here's a lengthy blog post explaining the algorithm.
http://blog.pixelpracht.net/?p=340

If anything is unclear, feel free to ask!

Krice

  • (Banned)
  • Rogueliker
  • ***
  • Posts: 2316
  • Karma: +0/-2
    • View Profile
    • Email
Re: Grid-Based Lighting
« Reply #18 on: August 05, 2012, 07:18:34 AM »
Nice. I wonder if it was easy to steal this routine and use in Kaduria.

Leaf

  • Rogueliker
  • ***
  • Posts: 64
  • Karma: +0/-0
    • View Profile
    • Email
Re: Grid-Based Lighting
« Reply #19 on: August 14, 2012, 05:46:43 PM »
I make objects that cast light register the brightness of light that they are casting into squares with those squares, when the object that is casting light moves.  That way there is only a FOV calculation once when the light source moves, instead of every time something looks at a square.  When the object moves again, it deregisters itself from the squares that it previously registered with, recalculates, and re-registers itself with the new squares.

The set that the light levels are registered in is a priority list, such that the brightest value stays on top and the dimmer values sort lower through the list.

When something looks into a square, the engine peeks at the top value of that priority list, and uses that value as the light level in that square.