better coloring (a roguelike in Python #8)
I’ve started to experiment more with cell coloring. Up to now I’ve defined cell colors explicitly — if a cell is of the ground type and visible for example, it was a ‘visible ground’ color, and similarly for a ‘dark wall’ and so on. However I felt this wasn’t a very good way to do colors, especially when you start mixing light and dark and other affects, like mist, smoke, fire, and so on. I don’t want to get too crazy here but I do like the look of colors and it’s one of libtcod’s strengths.
So after a few experiments I have a first pass at what I want to do. It looks like this:

If you look at the samples.py file included with the libtcod Python wrapper you’ll see a similar thing going on in the field-of-view sample with the torchlight (though that is more sophisticated, using noise — I hope to do that soon).
My colors dictionary now looks like this:
self.cell_colors = {
'wall' : libtcod.Color(67, 65, 52),
'ground' : libtcod.Color(145, 140, 140),
'dark': libtcod.Color(20, 20, 24),
'lit': libtcod.Color(255, 255, 33),
'visible': libtcod.Color(254, 254, 233)}
And what I do now when figuring out the color of a cell is find the distance of that cell to the field-of-view origin (for example, the player) and use that distance as a scalar for the affect color. I should note that affects are colors like ‘dark’, ‘lit’, and so on. Also you don’t really need to find the distance, just the distance squared to get the appropriate scalar — this will save a bit on computation, or so I’ve heard.
In other words, the ‘visible’ affect is most intense at its point of origin, and least at the maximum distance of the field-of-view radius. I think it does look better than using hard edges on affect boundaries.
This scalar is linear at the moment, so it creates a somewhat odd but not displeasing affect to my eyes. However I think I do want to randomize it a little with noise as done with the torchlight for samples.py.
No comments yet
Leave a reply
Subscribe to Kooneiform



