![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
relee1:09pm - I still haven't been able to grok Recursive Shadowcasting but I'm figuring it out bit by bit. Figuring that out is my primary job right now, and it's painful, but I'm going to do it anyways because it's neccesary and I can do it.
2:01pm - And then I spent like an hour trawling Reddit. Geez. And nobody has vacated the cool table. It seems likely I'll end up at McDonalds today after all.
Anyways while I've still got some time and power, I'm going to try again to figure out this Recursive Shadowcasting thing.
2:29pm - Well geez, I think I've just gotten enough of a grip on this concept to try implementing it. But I've also realized that it's unneccesary for the step I was on. I only need to worry about field of view when I implement light and darkness. A monster trying to sense a target doesn't need field of view, it just needs a direct line of sight to be tested. At least for sight anyways. Sense of smell and similar things will probably involve putting invisible objects in tiles to represent scents or brainwaves or heat or whatever.
But still, I've come this far so I might as well implement light and field of view now.
Now let's see, what do I need to actually do to achieve that?
First off, the Tile class needs a 'lightLevel' property to represent how dark it is.
Then, hmm... How should I handle light emission? Not all Actors will emit light, and some InstalledObjects and LooseObjects will emit light, and now that I think about LooseObject, should it remain a LooseObject when an Actor is holding it or it's otherwise in an inventory? I mean, I could have it convert to a different object type when it's picked up or put in something, but it seems to make more sense for it to just be renamed to GenericObject or something. What's a good name for a basic object type that isn't taken? Oh, maybe Item? That could work. I'll have to change that soon.
Anyways with regards to the light, I'm thinking about giving Actor, InstalledObject (InstalledItem?) and Item each a property that holds a new type, Emitter. Or maybe a list of Emitters? I could have LightEmitter, SoundEmitter, SmellEmitter, HeatEmitter...
They might work differently though, and I'd have to set up holder properties for each one. That's a lot of, whatchacallit, something like connectivity, there's a word for it where you don't want classes to be dependant on one another.
Hmm... I'll give it some thought on my walk. I need power and the Library isn't getting less busy, so I'm gonna head to the McDonalds. Also I want a drink. XD
See you in the next work post!
2:01pm - And then I spent like an hour trawling Reddit. Geez. And nobody has vacated the cool table. It seems likely I'll end up at McDonalds today after all.
Anyways while I've still got some time and power, I'm going to try again to figure out this Recursive Shadowcasting thing.
2:29pm - Well geez, I think I've just gotten enough of a grip on this concept to try implementing it. But I've also realized that it's unneccesary for the step I was on. I only need to worry about field of view when I implement light and darkness. A monster trying to sense a target doesn't need field of view, it just needs a direct line of sight to be tested. At least for sight anyways. Sense of smell and similar things will probably involve putting invisible objects in tiles to represent scents or brainwaves or heat or whatever.
But still, I've come this far so I might as well implement light and field of view now.
Now let's see, what do I need to actually do to achieve that?
First off, the Tile class needs a 'lightLevel' property to represent how dark it is.
Then, hmm... How should I handle light emission? Not all Actors will emit light, and some InstalledObjects and LooseObjects will emit light, and now that I think about LooseObject, should it remain a LooseObject when an Actor is holding it or it's otherwise in an inventory? I mean, I could have it convert to a different object type when it's picked up or put in something, but it seems to make more sense for it to just be renamed to GenericObject or something. What's a good name for a basic object type that isn't taken? Oh, maybe Item? That could work. I'll have to change that soon.
Anyways with regards to the light, I'm thinking about giving Actor, InstalledObject (InstalledItem?) and Item each a property that holds a new type, Emitter. Or maybe a list of Emitters? I could have LightEmitter, SoundEmitter, SmellEmitter, HeatEmitter...
They might work differently though, and I'd have to set up holder properties for each one. That's a lot of, whatchacallit, something like connectivity, there's a word for it where you don't want classes to be dependant on one another.
Hmm... I'll give it some thought on my walk. I need power and the Library isn't getting less busy, so I'm gonna head to the McDonalds. Also I want a drink. XD
See you in the next work post!
