Daily* Devlogs

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 particu…

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 inc…

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 …

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. Th…

Over the next few days I presume I won't be getting a lot done. We are preparing to see the eclipse and that means I'll be away from my standard hardware. However that doesn't mean we won't be able to do a little bit of theorycrafting as we lead into the next steps. For now I know what I need to do is get the hooks in for our Moosecats sending themselves on Adventures. We know that we can do it through UI (or direct function calls) but we haven't discussed is how to handle it happening automagically. Can the same adventure be running with multiple instances at the same time? I mean...do multiple people go on vacation to Hawaii at the same time? Probably. Also, a ra…

I've now setup the logic on the Moosecats to work as follows. And I'm pleased to say that it looks like it scales for hundreds of kitties. So basically our little friends will notice they are, for instance, hungry. If they are, they will search out for food. If no food exists they will say "Tata!" and go on an adventure to find some themselves. In the example below we aren't yet de-spawning them and sending them on the adventure. But you'll recall I do have support for that from a month or two ago. So next I'll hook them into that system, updating their needs, so when they return they'll be happy and healthy and who knows...maybe they'll bring some presents or new fr…

I love watching the systems fleshing out in the game. We have issues, certainly, but over time, more and more of it is coming together. We still have an issue with needs for the cats but this comes from the new artifacts generated to store our data. The ease that you can access any component on any object has really pleased me. I do have a bug involving polymorphism which I think I mentioned, I haven't solved that yet, for now on those RARE cases I'm going to just use getcomponent for now. Once I have time I'll look into it more, find a smarter way to hand the key side of the key object dictionary. And as I'm saying this to you I'm realizing... We could alwa…

I'm almost finished with the first draft of the world item database. This will be our lookup table for all the items that are in the world for our kitties to path out to. We could find this data each time a cat is curious, updating it constantly, and generally just making a lot of garbage. Or we could track it through a table like this and have a fairly consistent memory footprint. I do have a bug with my component return feature. I'll need to look into that and see what I'm forgetting, it'll likely be obvious and silly but for now I'm not entirely sure. Otherwise I don't have much to add! I don't have any gifs for you at the moment but the cats are able to navigat…

So off and on for a few weeks I've been toying with having a unique identifying value for each object in the scene. A big part of this is just being able to guarantee uniqueness and to keep the data that guarantees that information as small as possible. I tried a number of things, some involving pretty complicated editor scripting, and ultimately in the end I felt like the effort wasn't really paying off. I was making something that would not be fun to maintain and might be hiding secret evils in my future. I decided today that I would instead have a catalog (well Artifact) that tracks every item in the world. I specify item here, because we don't really car…

Alright! First we've got good news, N number of cats is now working with the state machine. My individual cats all have their own behaviors and are walking around, eating, sleeping , etc, on their own time and personal needs. This is HUGE! I'm very happy with this and it will be a good stopping point for the night for me. A very, very large commit to be pushing. I've moved away from custom plugins for Guids and Dictionaries, I've just spun up my own solutions and they work without issues. This will also help reduce variables going forward in case anything breaks. Also for those of you playing the home game, I realize now my mistake on ID management for assets in th…

So I've noticed that the serialized GUID system I'm using is struggling with equality in certain situations. So my plan is to actually alter my design tomorrow slightly to just use regular system.Guid. This will help reduce the chances that we might hit a wall later with this system and it'll reduce the variables by 50%. I don't think it'll take very long but it is the source of my cats being a little hokey. So tomorrow we'll update this and I'll try to write my update earlier so we can get more details! I'm just excited at how quickly I ironed out the issue.

I had been mulling all the different ways that we could validate if the actor receiving an event response is the one that should be responding. But seeing as our act calls are unique per actor I can just do a simple equivalency check. if (data != Accessor.ReturnComponent<HandlerMoosecat>()) { return; } It is literally this easy. At the start of my act function I just compare the incoming data to the same data that is on this state machine. If they match its the same object that made the call, if not it is just another live actor that matches the type. You might think "Will this scale?" and the answer is basically yes. We'll have a finite number of actors,…

Currently for the cats I am simply doing a lookup of behaviors in the scene and checking for those that implement the satisfier interface. In doing this I can tell if they are something that *could* satisfy the curiosity or needs of a cat. Classically this hasn't been very efficient in Unity and I'm not even sure I need to do it. If we think about it, when assets are created or "destroyed" I'm actually just activating and deactivating them. If we lack a sufficient number of "pooled" assets then I create a new one and add it to the pool. Eventually when a player has played long enough they reach a point where no new assets are created or destroyed. This means I've a…

Our little buddy is finally coming together! The Moosecat will now transition between Idling, Wandering, and Traveling to precise needs. These will also transition between one another as you'd expect. I still need to take care of the listeners for multiple Moosecats but I'm real excited! We are finally getting things actually going. Just check out how fast this little one is going? Look at that terribly slapped on trail renderer for effect!

Alright I need to do a few things tomorrow. We need to add in a declination (or veto) feature to our event system. That way I can do things like cross reference uniqueIDs or other data to see if an event should be respected by all listening assets. Once this is done we can then move into the next step of finishing up our wandering system. That will get us pretty close to having the baseline logic system done and allow me to move onto other work. I still want to add a few debugging adventures and have Moosecats travel to them when they can't satisfy a need. I also need to think about how kitties will act if their target gets taken by another cat while they ar…

I've been adjusting some of my work. We now have a food spawner. It currently spawns the food at the base of my player's feet. This has consequently meant that with each spawned food I was a little bit higher in the air. Needless to say...I ended up being QUITE high up. So I suppose tomorrow we'll work on making it spawn around the map instead of under my feet. Then we can have kitties searching it out!

Per usual it is late at night and I'm writing this up. So I'll try to make this quick. But we have a few enhancements that were finished today. The first was that I can now add and remove listeners when entering and exiting states. I haven't fully tested it at scale, as we don't have a scale TO test at. For now it is sufficient that I experience no errors. The next update was with the event system that I use. The problem was that adding events at runtime to the event listeners would result in an empty field instead of a populated one. This doesn't matter at runtime for builds but in editor it is very annoying. Here are some before an afters to help visualize the is…

Alright, we've shifted away from needing response objects. I believe this will be fine. One thing I need to sort is having our kitties enable and disable their listeners as their states change. This will help reduce the number of objects listening for certain event calls. I can't imagine this will have a HUGE impact but its one less variable when testing out new systems. That'll come tomorrow. But for now? I need to go get some sleep, it is mighty late.

Alrighty! We now have our standardized transition system for the state machine. Conveniently this helped me discover an error with prefabs and adding components. That is now fixed so we are golden. Additionally I found a bug in the unique ID system (again? Yeah, I know) and that is now patched up! It is such a good time looking through your code, patching up holes, and adding new systems. If you can ever find the energy I really recommend it. More gifs are incoming probably next week, but for now have a lovely night!

Tonight I worked a bit, admittedly not as much as I wanted, on the response system of our state machine. I need to update it for two reasons. The first is so it has the same rad component access that my actions do, but ALSO because I want to standardize how we switch scenes. Why? Well if I do this I can actually write a script to visualize the state machine and how each thing transitions! If I do that then I can even post them here. Start generating something akin to automatic UML diagrams. It'll be fun! So hopefully soon you'll see that. It is critical I fix this now before moving on further for the game because having state transitions all willy nilly will…

Alright! We are getting closer and closer. The cats now will correctly search out a source for their needs. Unfortunately, I forgot I had critical set to 25% so the moment our kitty ate a few things were obvious to me. eatingEverything.webm The cat ate BOTH food items in range. Very cat like but unintended. The cat immediately went towards the ball because that status was ALSO in critical. So at least we know it transitions through states properly. The cat then...ate the bed? Huh...I didn't know that was an option. I guess I'll be looking into that tomorrow.

niceballs.webm I've begun work on the interactable logic for non-consumable items like balls, beds, doors, etc. I was feeling a bit silly after I added them so I gave them a bit of physics. This revealed a really amusing problem with the inverse kinematics in our fella. You notice that he just steps ON them instead of walking into them? That's because they are so short he knows he can hop right on up there. That's a definitely mistake and very amusing. I'll save that problem for later. For now we've got some nice shiny, somewhat bouncy (shockingly dense) balls. For now I'm going to have interactable objects set your needs that it can satisfy back to 100% instantl…

At this point I think the food portion of the Moosecat AI is good. We'll need to hookup our interaction state but I want to wait for that until after we've put in a bed object and some kind of fun object. This will be my project for tomorrow and tuesday. Because at this point it is late on a Sunday and I'm kinda tired! I've been up very late the last few nights working on the game and I'm very excited to see where it is. kittygoesfoodhunting.webm Our little buddy got hungry and went searching for food. Obviously its a bit rudimentary, they are not set to stop at their interaction distance, nor do they call interact yet. But once they do it'll feel a lot …

So today I noticed I've got a mistake in the logic for assigning IDs to assets. So my question is how much time should I put into fixing it now? Would it make more sense to just move onto other work and simply make a note that I need to fix this? That's kind of a hard question for me to answer. I'm sure it'll just annoy me until I do solve it. Perhaps just in terms of mental health it might be best to handle it now. If not, perhaps I should start a section for this game that is known bugs. Then as we solve them we can update the bugs as fixed. That could be fun for tracking how many things are good (or bad). And it allows me to have the fun part of bug fixing witho…