Forums

I got it! Our action system works great with the adventures and provides us with a ton of flexibility with each new adventure. In this example our kitty goes on the adventure, then after the adventure finishes, they return and their need is satisfied. Tomorrow I'll see about doing an item award to the player. Obviously later these will need updating to include animations, sounds, etc, but the core is there! PARTYCAT_Smol.webm    

Today was kind of an awful day physically for me. But regardless, the cats send themselves on adventure, pool themselves, the adventures go through their timer, then complete as expected. So all that remains is to create the adventure reward actions! That's quite exciting, one of those will be unpooling the cat, another to satisfy a need and so on. Looking forward to playing with that tomorrow.

Alright! I took a huge detour tonight to work on an EDH deck of mine, but we've got the kitties able to send themselves on adventures based on their needs. In this case I made my kitty tired and there are no available beds in the scene. So they go to the adventure node to leave on an adventure. They find and add themselves to the right kind of adventure and start it. Tomorrow we'll get the hooks tested for them pooling and unpooling themselves and finally handle the adventure actions which (I hope) will be much easier. So that's nice! Also yeah, I need to name my cats so they stop just showing their guids for their name... Huzzah!

Dead ass loaded up Kingdom Come: Deliverance and had a WAY BETTER IDEA the moment it loaded up. More details tomorrow, already tested it and it'll work!

So I've found a flaw in our adventure design but believe I've already got the solution. Much like our adventures should use modules to determine "what" they do when you finish them. We should also use a modular system for determining "who" they are as well. The plan then is as follows.   Our Datum Adventure, so called because its a single unit of Adventure Data, will contain an Artifact of a Container Datum Adventure Info. This one gets the name from being a container of a single unit of Adventure Info. We name our assets like this so that you know what they are, generally, just by reading the name. The reason Info doesn't come before Adventure in this example is that Adventure Info is our object. The prefixes are all the special class design styles I follow.   We can then have this adventure info take in an artifact that implements a specific interface.   Though! Like is so true with all sorts of ideas, this is making me wondering if I could just create a catalog that expects an interface instead of an object. So perhaps before we finish this we'll investigate making that. I could see that being supremely useful going forward. Good going me...good going.