Daily* Devlogs

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…

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…

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

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…

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…

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 …

Today was interesting. Every Saturday we take a bike ride downtown to have some very good food. One thing we are noticing is that when we DO take these long trips we basically pass out for the entire day after. Which is fine, it is a pleasant way to unwind. But for game development or game playing it isn't the best. I did manage to discover a mistake in the code before I ended up passing out for the day. I have duplicated code in the player info (save data) and the action bar. So tomorrow I'll probably take a moment to remove the duplicate code from the action bar and link it to the player more directly. This was just a matter of one of my past selves doing something…

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.

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!

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'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!

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

Woo boy! The exhaustion from work and just life in general really got to me. I reminded myself multiple times yesterday to not forget to post and yet I forgot! So today we are going to get yesterday's update and today's resolution. I was just not feeling the item and world actions flow when I tried to implement it yesterday. For some reason it was just not really vibing with me, I'm sure you've felt this before. You do something, anything really, and it feels off. There isn't anything morally wrong with it, not even nothing technically wrong, but it unsettles you. Your mind wonders what you are thinking and why you don't do something, anything else. That's where I …

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

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

No matter how hard Manor Lords tried, I did manage to do a small bit of work tonight. Trivially added a new action to the adventure system that lets us reward items to the player. I'm really pleased that it only took a couple of minutes, this suggests to me that I'm on the right path with that design. In the future I think I'll want the actions to be coroutines, just so we can yield on some as needed. If I've mentioned that before already, welcome, I'll be doing that a lot over the next few years. Lots of things to keep stuck in my brain and some of it loops.

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…

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!

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

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

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!

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

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 …