Daily* Devlogs

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…

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

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

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…

I'm reminded today of a Stephen King book and film called "The Langoliers" as I stare off into the distance and wonder what is approaching. It could be a great many things. A friend, a foe, something beyond mortal comprehension. I stand and wonder. Squinting a bit as the objects grow bigger. They are moving quite fast...which does leave me wondering. Have...have I fed the cats today? Oh god... inthewrongpartoftown_50Percent.webm Run while you can! Also, I suppose I should mention. Individual state machines for actors is up and running. In this example we have five Moosecats that have initialized and then switched to "wander". …

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

I'm sorry to say that it isn't fully working yet. Not for your sake, by the time you read this I'll likely be done with much of the game. But for me this is an unfortunate night. There is something about my adventures that is serializing differently from items, Moosecats, or even the player data. They look to my tired eyes to be exactly the same. But clearly something is unique. I'm curious if the problem is the self contained classes and their location. Tomorrow I'll try splitting out the classes so that they match the same design scheme as everything else I've done. At this point we can select an adventure, add adventurers to that adventure, remove them, a…

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…

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.

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

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…

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

Some days are more productive than others. For tonight we didn't get a whole lot done. The action bar slots are now hooked up to the player's save data. This will mean that your action bar status will persist between sessions. Or at least, it will once I hook up the state actions to initialize the action bar. This will be pretty straight forward, I need to implement the initializable interface, then add our action bar to the initialize state action. That will trigger after the load event and BOOM action bar is populated. Won't be doing that tonight though, too tired. Long work week, lots of challenges. But hopefully the coming weeks will be much more quiet. I'll ac…

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!

So! Sorted the bug that was giving me tons and tons of copies of the items to our inventory. It was actually quite simple and very silly. We might as well cover it really quick. The original code, first adding, and then removing. So the mistake here is very subtle, specifically how does equality work with Datum? For two datum to match they must be the same in ALL ways. Their name, their ID, and their count. But what if, lets say, you are adding a single copy of an item to your inventory and you've got...oh I don't know, 25 of them? Well congratulations you just got another entry in your inventory. Following this we increase the count of the orig…

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…

Alright! This week we will be touching up some of the UI. None of this will be final but it gives us some feel for where the game can go. I think first we will connect the inventory to the action bar and then we will go from there. No pressure just fun! That's the plan at least 🙂

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 …

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

Today was kind of an awful day physically for me. But regardless, the cats send themselves on adventure, pool themselves, the adventures go through their timer, then complete as expected. So all that remains is to create the adventure reward actions! That's quite exciting, one of those will be unpooling the cat, another to satisfy a need and so on. Looking forward to playing with that tomorrow.

Alright! I took a huge detour tonight to work on an EDH deck of mine, but we've got the kitties able to send themselves on adventures based on their needs. In this case I made my kitty tired and there are no available beds in the scene. So they go to the adventure node to leave on an adventure. They find and add themselves to the right kind of adventure and start it. Tomorrow we'll get the hooks tested for them pooling and unpooling themselves and finally handle the adventure actions which (I hope) will be much easier. So that's nice! Also yeah, I need to name my cats so they stop just showing their guids for their name... Huzzah!

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!