Forums

Alright, we are partway through the cats adding their own adventures. I'm taking notes as I move along. Our main challenge is that Unity doesn't serialize dictionaries and they don't serialize Guids. I need both of these things. I'm currently just building these on awake. But I think what we could use are some simple container objects that we can add to behaviors. Scriptable objects that act a bit like a dictionary. In fact...thinking on this, Odin can serialize our SOs so we can literally do this. We'll have the adventure containers be the keys and the need satisfying adventures be the values. This is stupidly simple, I'm a little annoyed it didn't cross my mind until I wrote this. You know what? Tomorrow I'm going to write BEFORE I code and see if I come up with ideas before I go. That seems like a good plan.  

We have now reached the point where none of the work is throwing errors. That's always lovely, this means that we can now move into having our Moosecats add themselves to adventures. Today was a long workday so I didn't have as much time as I wanted but did manage to hit a good point with this work. It feels like by around Thursday or Friday we should have the setup complete for our Moosecats to go on adventures when they can't satisfy a need and then return a bit later. Can also experiment with them bringing back items and dropping them near the player, that could be very cute if it works reasonable well. As always, feeling good about progress!

Ok! Progress is moving along on adventures. I feel it'll probably take most of this week given how exhausted I am in general. Not with coding, this is always a treat, but just combining it into days with working out and a literal job. The adventures now track how many teams an unlocked adventure supports by default, and how many slots each team has by default. It generates each team slot, then populates their fields for adventurers, and saves all of that to the unlocked adventure data that we store to the drive. I believe with this change, tomorrow we should notice that we can add an adventure trivially and have any number of team slots running actively at the same time (that code was finished on Sunday). Following that test I'll get the Moosecat hookups working. Each Moosecat will create a one slot team in the related unlocked adventure, add themselves to it, and set it to starting. In writing that I realize I don't think I have much to go! But I'm gonna head out because the literal Moosecat in my house is purring and keeps walking in front of me while I type, I believe she wants attention.

So this has actually been a bit more of an update than I was expecting. But I think we can discuss the high level of it. I'll do a more in depth document soon for my own sanity as much as yours. First I suppose we should figure out what the problem statements are. The first is that we want our adventures to trigger a series of actions when they complete. What these actions will be are undefined but we'll just add them in the sequence we want them to happen. The second is that we want our Moosecats to be able to trigger an adventure on their own. This is to satisfy their needs and it needs to be infinitely scaling. Now that we've got our two problems, in this case when I say "we" I mean you and I, we now need to talk about solutions. The first is actually already solved, we use the same GameAction system that we used for items. We simply pass each of the Moosecats through the actions, ignoring them where applicable, and doing whatever needs to be done to satisfy all the needs of our adventure completing. The next was, and still is, a lot more work. We need our adventures to not be singular entities, we need to have each unlocked adventure have a collection of "teams" it can support. That is to say, a number of instances of that adventure that can be running. We may never have more than one on the regular adventures, but for the Moosecat automated ones we need to be able to have arbitrarily many of them running! Naturally this is a rather large change, so I need to go through and update the Adventure logic that was assuming only one adventure at any one time being tracked. Now that "adventure" is really a team within the unlocked adventure. We are maybe 60% through the revamp, I'll be taking a break at this point though and finishing up the rest this coming week. Good stuff though!

Welp! I intended to do adventures first but it turned out we needed to do items! The good news is that I can use the same system for the adventures once I get to that tomorrow. There is no bad news. We can now create action lists to happen in response to something. Currently I only have one action list, but later we can have one for collecting, one for consuming, and so on. These action lists look something like the following: A keen eye might wonder how you can "collect" something and "consume" it (thus satisfying your need), but there is a reason this works for now. Players do not have needs that are satisfied, but they do have inventories. Moosecats have needs, but currently don't have inventories. So because of this nuance the system works as designed. Now in the future we'll have split action lists for each. Things like "Game Action Pool" would be in both, but one would have the adding to your inventory, and the other would have the satisfaction. Additionally when we add in the GUI where you can use items from your inventory we'll be able to just reuse these actions, or a system that is very similar. So tomorrow, we'll be doing something like this for the adventures. So that we can have each adventure act in atomic ways, no need for large complicated hard coding. Treat the logic more like lego.