Oafkad

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.

Tonight I updated the state machine so that we now have a series of legal vectors across our navmesh. Kitties can choose to wander to any one of them at random when they lack interactable objects to play with. In the future what we might do is just have cats go to sleep if they can't find things to do. Then once their needs are unavoidable they'll go on adventures to solve it. But for now I'm going with this. It might be that once we flesh out the map it becomes physically impossible for cats to have nothing to do. Or perhaps we'll have a "nothing to do" option for cats where they just go on a random adventure on their own to find cool things for the player. Be it new friends or items. Regardless the game is now in a state where I believe nothing actually gets broken state wise. This leaves us back on adventures to start adding in adventure actions upon completely. For now the first one will be updating the status of the cat depending on the adventure they go on. We'll save that for tomorrow or Friday. I'm going to rest for the remainder of tonight.

About the only negative is tomorrow I need to fill out a few SOs, luckily we only have debug assets currently so this won't take long.

Alright, I didn't expect to do a bunch of coding today. But sometimes you get inspired and the changes just kind of flow in a beautiful way. I've now got three unique concepts for data storage. The keyed database, this acts like a very fancy serializable dictionary. The keyless database, this acts like a very fancy list with all the bells and whistles. Finally there is the catalog which acts like a read-only combination of the prior two sentences. I was able to remove between 1 and 2 hundred lines of code today. Without actually limiting myself in any appreciable way. As far as refactoring goes, this felt exceptionally productive. But now, my eyes are heavy and I want to make sure I get a good night's rest. So I'll leave you with a part of the commit for the night.

Switching the adventures over from the old system to catalogs was fast and basically painless. There is still more to be done to make adventures less poor to work with. I've split the adventures out from the auto adventures that kitties can start up. I may even split out the adventure handler to be one for regular adventures and one for Moosecat auto adventures. I figure the UI can just read both to populate things. There was no real reason to put them together. This is a mistake I won't make again, until I do. At any rate, I'm going to reward myself for a long work week of Moosecats and actual work. Time to play some kind of game, not sure what yet.

Alrighty! Spawning is now gangbusters! I really like where it is. So I think the next thing we need to refactor is the needs system for the Moosecats. There is "something" about it that I'm not liking. It is too easy to get a mismatch with data. This might be from my old bugs that caused it but fundamentally I don't like the issue. So tonight I'm going to ruminate on a solution and hopefully tomorrow we can implement it!

Alright, well, that IS less than ideal. I've moved our spawn request logic into a state action. Because it honestly makes more sense for it to live there than it would on a particular gameobject. The plan is pretty simple, anything, anywhere, can request items from the spawn system and then they can choose to position those spawned assets anywhere they need and do anything extra to them after the fact. Unfortunately I need to fix a few things tomorrow. The first is that the positional data is wack, clearly a few problems here: 1) They are all spawning in a thin line. 2) They are all spawning under the nav mesh (woops). Otherwise though, if you ignore these two game breaking issues it is basically perfect! So, given how heavy my eyes are at the moment, I am going to do just that.

Sneaking in real late tonight! Just finished the Fallout series (season 1) and it was incredible. Absolutely soul crushing at times, anxiety riddling at others, and all around just filled top to bottom with misery. I couldn't do that kind of show all the time but it made me feel things and all around I'm happy that it exists. What an exceptional example of truly talented people pulling off something incredible. As for my own work, the spawner is refactored! It is much more powerful than the prior version and now it isn't limited by a single type of item. Now *any* item can be spawned as long as I have the ID for it. They'll be spawned enabled or disabled as needed, pull from the pool as needed, and just all around I'm pleased as punch. I forget what I said I need to resolve besides the spawner in our prior post. I'll check it tomorrow and get started on that. But overall, what a day.

I know for some folks this is the most miserable part of coding. You hit a golden point in your work and realize certain systems are unsustainable. As you get better these become less common but I do think there is merit in trying things then iterating on them to get the perfect outcome for you. We are nearly done with the refactoring of cataloging and spawning. I'm very excited as these are pivotal systems for the future of the game. I'm on a phone at the moment because we watched Fallout late into the evening but tomorrow o don't have a workout. That gives me plenty of time to go over it in more detail and maybe include some visual aids!

An interface is a promise between scripts. In theory these cannot actually implement functionality. I say should not because I've found a gap in C# where you can implement functionality in your interfaces. I actually think this is a bad idea. But it is also a really interesting one. Perhaps we will start a coding guide section and I'll put how I did it in there. I still suggest you don't do it, as you can't breakpoint, but the fact that it works is fascinating!

I am pretty sure I skipped a day lol... Anyways, I've come to the conclusion that I need to change up my development schedule. I'm noticing that on the weekends I'm usually pretty burned out. Between work and working out, I just don't have much left in the tank. This actually isn't the fault of this project, I really enjoy working on it. But I need the energy to do so. We are still going to have daily updates. Perhaps I'll take some time on Weekends to update documentation. Or if I'm feeling energetic get some coding done. But I don't want to stress or strain myself and ultimately get little to nothing done. This all said, today while we did take a very long bike ride, and I am physically and mentally drained, made some good progress on the game! Our GUID updating system now should properly not update anything beyond the first time. So if we clone items they'll be updated properly, and when we load for the first time we won't nuke anything that already had been updated. I've fixed the bed item as well. It had some issues with navigation that are now resolved. Finally, the adventures themselves are moving along at a good clip. I was hitting a lot of bugs today, and putting them down just as fast. As I was updated the code I was also updating the PUML you saw yesterday. So overall I'm quite happy. With that all said, I'm now going to relax for a bit and play something. Help refresh my mind and body and we'll see what tomorrow brings.

Today was one part updating Unity because of a bug with the specific version I had, and another part UML documentation! It is nowhere near done but I'm writing up docs on the adventure system so that I can more easily integrate new features into them. As you can see we don't have a lot, but this is the beginnings of it. Adding commentary to every function and attribute so that I can better keep things in line. Cause I'll tell you, this brain of mine struggles sometimes. Especially when we haven't touched something in a bit. And in the case of Adventures we made it a bit ago and then came back to it with a needed overhaul. I should have all this finished tomorrow though so I'm not too vexed. Then after I write this up I can think about what I'm missing. But per usual, the real life Moose is heckling me and telling me to get to bed. So I suppose I better do so.

I believe we will need to clean up the Adventure system in the future but for now it is in a pretty good place. What we do for cats added by themselves is as follows. Has any cat run this kind of adventure yet? If no, add this kind of adventure to our unlocked collection. We do this so it can be saved and loaded. Next we ask if there is an empty team slot on the adventure. If yes, we add this cat to it and start it, huzzah. If no, we create a new slot and add it. Then we raise the send cat on adventure. This allows us to effectively cache slots for these adventures. Which does make me realize I should probably standardize this logic and add dedicated calls to do so. Overall though looking good!

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.

This weekend we'll be finishing up the adventure work I highlighted in the previous post. Then after that I've got a solid idea I think for items. We won't have "Collectible" Items and "Interactable" items etc, we'll just have "Items" and use interfaces to determine what cool functionality they provide. This will simplify the maintenance and really make it so we can add functionality at any time without needing to overhaul TONS of items, or create class after class. Obviously each item will have unique functionality (to some degree) but we won't be enforcing much at the base level. I forget the terminology but basically we'll code them through promised functionality rather than strict inheritance. As I always say, should be fun!

Today you can join me in thinking out loud about solving Moosecats sending themselves on adventures. We presumably need 1 adventure for each kind of need that can't be satisfied in the map. For now this means that we will have a relaxation adventure, an adventure to relieve boredom, and an adventure to refill their tummy. Currently the adventure system assumes that you will have an "active" adventure, this is the one you've selected from the menu, and you will add your Moosecats to that active adventure. But in the case of automatic adventures we don't have one selected. So instead we need to select a specific adventure and send our Moosecat on it. These particular adventures are defined already, or will be once I make them, so I suppose I could just make Artifacts for each of them and add them to either the node point or the handler. I suspect the Handler makes more sense. We can achieve this with a new function call, SendCatOnAdventure should be sufficient. From here we could actually read the "needs" on the Moosecat, and send them on an adventure based on that. So we'll make a collection that contains the need ID as the key, and the resolving adventure as the value. Then we can simply set it active and pool the cat. This requires either adding that logic to the function OR creating a new function for StartSpecifiedAdventure or something similar to that. We'd pass through the adventure to be started and handle the starting inside of that. I've got a pretty bad headache tonight, so I won't be doing this for now. But this will be my gameplan tomorrow. I'll leave this open so I don't forget.

Working through the catalog system now. One of the first we need is for prebuilt kitties. These will be our friends like Moose and Bean. Because obviously they'll have a specific look. But other custom kitties will exist beyond this. I'll need to have the collection store both the cats themselves and some ID Artifacts for easily finding them in other work. This will require a bit of thought on my part, maybe I'll write something up tomorrow. For now you can find them via the unique IDs assigned to them, but that might not be entirely sufficient. I may also add in a getter lookup by string, or something else identifiable. If we do go the artifact route we can just include those same artifacts on the classes that'll be making the request to spawn our kiddos. Many options, whatever we settle on needs to be fairly robust. Luckily the way the catalogs work you implement the getter largely agnostic of how we will index it. Maybe with ints, maybe with strings, maybe with Guids, but that all comes from the secondary interface that you attach to it. This helps allow us to have a single kind of catalog but have it work for anything. Currently we return strongly typed objects but I may end up going with loosely typed since this won't be happening very frequently.

While I wouldn't say it is perfect, in fact I want to update it tomorrow. We now have a working component caching system that works for both the class name you are looking for, all interfaces that class implements, AND any parent classes it inherits from. In this way we can use it a lot like get component but it'll be much faster and not require searching each time. Now with this in mind, something I want to do is have it cache lazily. That is to say when you "return component" it will find the component, cache it in all the different ways we need, and then return the cached entry. That way we only store exactly what we need. This should be helpful seeing as there can be a lot of components on an object and we might never need most of them for editing. We'll also have it cache all the components you need from the children as well, whether I'll add "ReturnChildComponent" or just have it work seamlessly I'm not sure. But regardless I'm happy to see I sorted the issue of using interfaces for lookups. Not a bad bit of progress after a long weekend staring at celestial bodies.

Today was quite an experience. Truly something that I was never expecting to see. And I'm happy to report I did not blind myself. Also last night when I should have been sleeping I had a revelation about naming conventions for collections of data. We'll use DataBase to represent any collection of data that can be modified at runtime and Catalog for any collection of data that is read only. I'll adjust my classes when I get back home tomorrow to meet this. The nice thing is that will also mean that I can tell which is which much easier, right now they are kind of interchangeable and I think that's not good for my own mental capacity. Anywho, have a great night!

Alright, we've got our adventure system that currently rewards items. But what I need to do is have the rewards be actions rather than just raw items. In this case we can have the actions be something like "reward item", or "refill moosecat state", etc, etc. With that in place we'll be future proofed for all adventure outcomes. I also noticed that I've got some foundational code that is currently featuring manor only code. I'll just need to go back through that sometime and fix up those connections. Things like saving and loading should work in all of the game projects. But for now we can't stress about it too much, just need to make note of it and focus. This is a healthy process to me. Trying things out, making them work, and upgrading them as we find new needs. The alternative is planning for months before you ever start and then realizing you missed things anyways. I much prefer this process.