![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
relee3:27pm - I'm at the McDonalds now and I have a drink, though I probably picked the wrong one. Alas.
On the walk over I spent some time thinking about my Emitter idea. There is definately a problem that whatever the emitter emits to would have to have a property to recieve to and report from. But I thought, what about an EmitterReciever?
I could have Tiles, Actors, Items, and InstalledItems have not only a list of Emitters but a list of EmitterRecievers, so they can pick and choose what types of emitters they recieve from.
Hmm... Now I'm thinking about implementing a component system!
So, like, a Fire Elemental Actor has an LightEmitterComponent and a LightRecieverComponent and a ScentEmitterComponent for that Brimstone smell and a MagicAuraEmitterComponent 'cause they're a magic creature and a SoundEmitterComponent for the crackling fire, and a SoundRecieverComponent for hearing you. They also have a Component that ignites things they touch maybe? Or other components.
It feels kind of weird to be implementing a component system in my Model layer, apart from Unity's built in component system, but here we are.
4:04pm - Hmmmmmm... Alright so let's try to bring this back down to earth.
To get light working, I need to either make the player Actor have a LightEmitter, or I need to also make the inventory system. Ahh hah hah hah hah... hah.
Maybe I should write all this down in the design docs?
4:22pm - I put a little design doc note in the game's design folder so I'll remember all this when I get around to actually implementing it.
4:40pm - Now I'm having an interesting conversation with some people on the RoguelikeDev discord and they're saying I shouldn't go so crazy with these systems. ^.^;;
4:54pm - Alright so I'm thinking I'll roll it back a bit, and instead of using emitters and recievers and multiple senses, I'll start with a simple property on the tile for light and only worry about what the player can see.
This'll help with the problem I saw on the horizon of the player seeing what the monsters sense on their turns. XD
Now, I don't need to implement this right away if I'm not implementing light based vision for monsters, so I should go back to what the HackNPlan says I should be working on. I'll make a LOS test that Brains can do to see what they can see. Then they'll fill up a list of potential targets, pick the closest one, and approach it.
That'll push me ahead to needing to figure out pathfinding.
5:06pm - As for actually implementing all of this, I'll do that later. I'm tired and energetic at the same time. Stupid sexy hot chocolate.
On the walk over I spent some time thinking about my Emitter idea. There is definately a problem that whatever the emitter emits to would have to have a property to recieve to and report from. But I thought, what about an EmitterReciever?
I could have Tiles, Actors, Items, and InstalledItems have not only a list of Emitters but a list of EmitterRecievers, so they can pick and choose what types of emitters they recieve from.
Hmm... Now I'm thinking about implementing a component system!
So, like, a Fire Elemental Actor has an LightEmitterComponent and a LightRecieverComponent and a ScentEmitterComponent for that Brimstone smell and a MagicAuraEmitterComponent 'cause they're a magic creature and a SoundEmitterComponent for the crackling fire, and a SoundRecieverComponent for hearing you. They also have a Component that ignites things they touch maybe? Or other components.
It feels kind of weird to be implementing a component system in my Model layer, apart from Unity's built in component system, but here we are.
4:04pm - Hmmmmmm... Alright so let's try to bring this back down to earth.
To get light working, I need to either make the player Actor have a LightEmitter, or I need to also make the inventory system. Ahh hah hah hah hah... hah.
Maybe I should write all this down in the design docs?
4:22pm - I put a little design doc note in the game's design folder so I'll remember all this when I get around to actually implementing it.
4:40pm - Now I'm having an interesting conversation with some people on the RoguelikeDev discord and they're saying I shouldn't go so crazy with these systems. ^.^;;
4:54pm - Alright so I'm thinking I'll roll it back a bit, and instead of using emitters and recievers and multiple senses, I'll start with a simple property on the tile for light and only worry about what the player can see.
This'll help with the problem I saw on the horizon of the player seeing what the monsters sense on their turns. XD
Now, I don't need to implement this right away if I'm not implementing light based vision for monsters, so I should go back to what the HackNPlan says I should be working on. I'll make a LOS test that Brains can do to see what they can see. Then they'll fill up a list of potential targets, pick the closest one, and approach it.
That'll push me ahead to needing to figure out pathfinding.
5:06pm - As for actually implementing all of this, I'll do that later. I'm tired and energetic at the same time. Stupid sexy hot chocolate.
