Daily* Devlogs

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!

Today was something of a day of hope for me. I went to the doctor and I might be on a path to help reduce the pain I'm always in. I don't mean this in the metaphysical sense, yes, I have serious anxiety issues, but actual literal pain. It is likely that lucky me caused some serious damage to a nerve. This happened about three years ago now I believe. Time has both been moving and frozen this entire time since it happened. The pain at times can be so intense that it erases all thought from me. But we'll see if I can overcome it. After meeting with my doctor I had a glimmer of hope and I channeled that into the project. Each node was a fair amount of work to…

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!

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…

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

No pictures today. But we've still made progress. After a hearty run of Randomized BG3 I started work on the collection system for Moosecats. This database will store all of the Moosecat information for each kitty that joins your care. These systems require creating the single unit object, I call those Datum as you've probably seen. Then it requires a Data object which is a collection of Datum with various helper functions for adding and getting data from the database. Finally we make an artifact that contains the Data Object so that we can easily share our data between any number of in game objects without creating a bunch of duplicates or otherwise doing something else …

Here we are, a late night, I've worked out and even played a bit of games. But still we need to update on what was accomplished with the game. To put it simply, a bit more than I expected and yet I wish I had done more. Tonight we managed to accomplish adding in the Handler class for Moosecat Gameobjects, then we hooked in the Moosecat Datum to that Handler. From here we integrated the interactable interface and told it that, for now, we want that to add the pet kitty to our care. This isn't necessarily how it'll work in the future but we are just trying to prove the function calls will work as intended. collectionExample.webm The first cube is our invento…

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…

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…

While today was slow goings, I can happily say that I've started doing work again. The last few weeks of my life were extremely hectic with occasional workdays literally going from 8 in the morning until midnight. My brain and body were both drained, by the end of it I was just completely exhausted. I knew if I tried to work on the project at the same time that I'd not get anything even close to quality as a result. So I took some time off, focused on getting work caught up and out of my way. With today being my first return back. Unfortunately coming off of going to bed at 1AM did not help for the return. But I've had a few days off from work and I'm feeling a lot…

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.

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!

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

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…

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!

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!

Today I did a little bit of UI work just to help unwind. It was a long and busy week and I both didn't want to do anything but also didn't want to do nothing. Stuck in some kind of weird middle state, I did a little. What was amusing once I was finished with some of the first pass code for the inventory was it revealing an issue with my character. As you know I had ID issues with my items. What I hadn't noticed was that all the prior iterations of the items have been sitting on my player this entire time. That's pretty amusing, all things considered. Sometime soon I'll clear out my inventory and save my player, just to fix that up.

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…

Per usual, today was a me day. I was tempted to do some work but I also recognize that I need to relax sometimes. Liz and I have been playing a good chunk of Pandaria Remix. There is even a checklist that was made by a user that I've been using to see how much of the things I've unlocked during the event. It can be a little hard to invest any kind of time into games like this for me. Especially with the rise of Private Equity gluttony and Public Company implosions. It just feels like every media controlled by a corporation is not long for this world. No real reason for it either, games like this make plenty of money. But they cannot realistically make more money year…

I find that UI work is both incredibly rewarding once it is finished and incredibly taxing while you work on it. Ever interaction point from people requires a lot more effort than linear systems. There are many intuitive ways that people expect things to work and making all those things work in harmony is quite a chore. I'm not sure how much we will get done tomorrow but I do think once more of the initial developer UI is done that the experience will start to feel more tangible. It is one thing to see an editor window updating but a whole other experience to see it live in game.

I think going forward on these updates I'm going to split them into two sections. Think of it like a mullet, we'll have business in the front, for anyone that only cares about that, and personal in the back where its just the things going on in my life. If you don't care about one side, don't read it, and if you don't care about either side then you've just saved yourself some time! The Front It took a strange amount of heavy thinking but I've managed to update the save system to be a lot cleaner! Now we have the concept of a UtilitySaveData class, utilities are classes that are neither SOs or Monobehaviors and will handle various needs of other classes. This is…

Outside of naming classes and folders, the next most complicated part of coding for me is the process of saving and loading. This is not because the idea itself is necessarily complicated. You are just saving some information as text (or whatever format you desire) onto your device. The major challenge for me comes in the most convenient way to have data that can be saved and also easily parsed within Unity. There are also some constraints when saving with Unity. Natively you can't save json strings that feature any content that won't naturally display in the editor. This means that things like dictionaries or multi-dimensional arrays are out. You can, however, creat…

You might not know this but Unity has some pretty strict serialization rules. It's a very lean system that is designed to be very very quick. Unfortunately as you get further and further into C# you'll find yourself wanting to use systems that aren't supported by Unity. You can achieve this through Odin but it does have some quirks. The first is that serialization will ultimately be a bit slower. I've never noticed the difference but we'll see if at scale it becomes much more noticeable. If push comes to shove I can always write an editor script to save all my data to disk, then swap back to the default unity serialization and have it apply the settings again. …

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…