Daily* Devlogs

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 …

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

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…

assignToActionBar.webm Aw yeah folks, things are really coming together. Will make this look a bit nicer tomorrow. Gonna need to start hooking up usage and placement soon!

Hey Folks, So I slightly recovered from the work week. Only a bit. But here we are! It isn't pretty but I've got the start of our action bar setup. The fields update when you press one of the keys, through the magic of events. Next I need to setup it actually showing the items you have in each spot. Probably have item pickups fill in the first open space. That's all I have for tonight though. Take care of yourselves! actiontime.webm

I need to update the name of this forum section. It's more like a daily dev log than anything else. Today we didn't see any meaningful progress. But that's super fine. I've had a hard time with work lately and I'm kinda burned out in general. But, tomorrow is the start of a four day weekend for me. I'm very excited and next week is the remodel! Looking forward to seeing how it goes.

I've got a bug that I already know exists and will need to clean up this coming week. When you send cats on adventures, if you save while they are gone and reload, the adventure will save at the proper length and finish as expected. But the "return cat from pool" logic I don't believe actually will generate the cat from scratch, rather it'll look for the cat in the pool and try to turn it back on. Once that is validated and repaired I can move onto the next steps of the inventory system. Spent most of today playing Pandaria Remix and doing some yard work. You can't have every day be a nonstop grind, and I've learned this. But I'm very excited that we are entering i…

Today I think is an important time to just take a step back. Only for the day, work has been extremely rough these past few days and I'm officially out of steam. But when we come back, tomorrow I'll whip together a simple GUI to test our our action bars and throw up an image or two maybe, if the day is kind. Take care of yourselves and thanks for the random visit, internet strangers.

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

I got it! Our action system works great with the adventures and provides us with a ton of flexibility with each new adventure. In this example our kitty goes on the adventure, then after the adventure finishes, they return and their need is satisfied. Tomorrow I'll see about doing an item award to the player. Obviously later these will need updating to include animations, sounds, etc, but the core is there! PARTYCAT_Smol.webm

Boy howdy my eyes burn! Tonight I updated the action bar so now it actually does save and load properly. This includes from a fresh run, so when everything else loads from the player so does that. I've also investigated that adventure bug I mentioned. Funnily enough it DID work but not for the right reason. All cats currently spawn on load, even the ones on adventures or otherwise away. So the cat would spawn in, then immediately go on an adventure. I've added in support now to track the active state of the cat. So if they are "off" when the game saves it'll spawn them off when the game loads the next time. Then when something like the adventure completes it'll fin…

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!

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…

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.

Tonight we've added a few concepts. The first is the save data for a held item. The idea is quite simple, when you select an item on your action bar you can press the hold item button, which I think will be Y on a controller, not sure yet. After you are holding the item you can then press interact, if the item can be interacted with this will trigger the game actions associated with that item. If it cannot be interacted with then nothing will happen with the item. However, if you happen to be interacting with an item in hand that can't be interacted with, AND you happen to also be standing near something interactable, you'll interact with that item instead. So, maybe…

I've added a new data collection to the player data. We've now got 12 slots available for an action bar. These are IDs that would match up with items in our item catalog. So now, lets think about how the interaction will work for the next code pass tomorrow. First I'll just set the keys by hand to match a few of the items we support. Then we'll hook up the input tracking for 1-12. If you press one of these items then we'll print out the item in that slot. I also need to add an integer to the player data that tracks the "current" item. Have it default to 0, but otherwise it'll be whichever number you pressed last. Just added that before I forget. So you press…

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.

We had a stormy night last night, and tonight sounds like it will be as well. I can tell I'm getting a smidge older because golly is this just absolutely dunking on me. Not only that but I had a long workday that ran later than usual. So it was little sleep and even less time to get anything done with the project. But do something I did! The action bar needed one final bit of polish before I could move on. Namely if you have an empty field it would try to find data for an undefined asset in the item catalog. This is a no-no and my checks worked as they should. The request was blocked and the error print out I wrote before was clear on the mistake that had happened.…

I didn't do much of anything for Moosecats today. But for good reason. I've had to strip down the office because starting Tuesday its going to be getting remodeled. This is a three week process and that means I'll be doing both my job and Moosecats from either the living room or occasionally the back porch. This should be interesting and I'm looking forward to seeing this room once it is done. The only hope I have is that by the end of it I have no regrets. The contractor we are using is not cheap, but if the result of that is no bumps then it'll be worth every penny. Anywho, tomorrow once I fully strip down this room I'll see if I can get a little something done.

It will eventually be mappable but the action bar support is added to the new unity input system. For now it defaults to 1 through = on your keyboard, but we'll eventually add in support for things like shoulder buttons on a controller. There is now an event setup that will inform all listening systems that the player has pressed one of these keys. Tomorrow I'll be hooking up a simple UI of some kind to alternate between these. What I haven't determined yet is how we will represent our items on the action bar. I'm not sure if they will have unique 2D art made for them or not. Heck, there is nothing stopping us from making our items in the scene 2D as well, perhaps …

Alright, I've hooked up the UI slots to be buttons. Now when we click on them they'll inform any listening systems of their unique ID. I did notice we've got a bug where your inventory is kinda "growing" when it shouldn't. I'll need to look into that. The reason will probably be pretty amusing and stupid, that is the way of things most of the time for me. Next steps will be hooking up the action bar to listen for these clicks. The main action bar handler will just be listening for the event and will assign the item to whatever your currently selected slot is. We'll see if we like that, in the end the preferred method might actually be clicking an item in your inven…

As I've said before. If you can, take a little step as often as you can. Eventually you'll travel a great distance. Today was another one of those small steps. Something that many people won't even notice because it'll feel intuitively like it should just work. The item setting takes care of moving your items around if they were already on the bar. In this way we don't have to worry about someone filling up all 12 slots with a cheese wheel or what have you. Not that I'm judging, sometimes you need a lot of cheese. Anywho, here is a fun little gif of it in action. togglebar.webm

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.

Alright, this is the final night before construction. The entire room is cleared out and I'm mighty tired. I've got to wake up early in the morning which isn't super great. And I've got work which will obviously take the morning and half of the afternoon. BUT once that is done we are back on the horse for getting work done. The next step will be hooking up the logic for using an item you are holding. I believe it should be pretty straight forward. When we pass you through the item we'll want to collect if you aren't holding something, since you I think we'll have you able to either hold something or interact with things. If you ARE holding something then you eat it i…

I've got the system setup now such that you can set yourself to "holding" or not. If you are holding and cycle through your action bar we will add your item to the hand, if it is something that can be held. Now unfortunately, I have realized a subtle nuance between interacting with say an apple on the ground, and interacting with that apple in your hand. When the item is on the ground I want you to collect it, but when the apple is in your hand I want you to eat it. I'm going to think about this tonight and figure out the smoothest way to handle this. I'm sure it'll be pretty obvious but for now it isn't striking me. On the bright side we are making some good progres…