Oafkad

Summaries will be coming up in later videos. Just trying to catch up.

I'll start doing actual summaries or scripts in the future. Just want to catch up on these in general on the forums.

When we think about a workout plan we've got two different sets of information that are carrying alongside one another at the same time. The first is the immutable data of the plan itself. A plan, as noted prior, will have a series of workouts, those workouts will contain exercises, those exercises will contain sets, and those sets will contain metrics. But here's the thing, for most of these steps we have user configurable data that wouldn't be immutable. A workout plan has a custom name. The workouts consist of exercises yes, but each of those exercises will have metrics saved when the user completes them. We need this because without data tracking we'll struggle to...track data. We don't want to include our user configurable data in ScriptableObjects generally because ScriptableObjects tend to be stickier. By that I mean they'll end up holding onto data a bit like a singleton, or any static reference. They'll even hold onto data in between sessions regardless of what scene you jump to. In some cases this is rad as hell, but in other cases it can be really problematic. Additionally when you want to save data you can't actually save an SO straight to Odin's system. It gets...upset would be putting it lightly. Just don't do it. We'll use my save and loading interface from the other Moosecat projects, I've already tested this and we are gucci. Ok, cool, Oaf, but when you aren't busy abusing the comma can you tell me what the problem is? Well, like so many things in life. Words are hard, I'm trying to think of a good naming convention for these two environments to keep them nice and clean. I think I've come to the following conclusion. Literally as I'm writing this to you, so it might be trash. We'll be learning together. Workout Plans, Workouts, Exercises, Sets, and Metrics will all be the conventional DatumNoun system. So DatumWorkoutPlan, DatumWorkout, DatumExercise, and so on. Then for all of the Savable data, we'll go with SavableWorkoutPlan, SavableWorkout, and so on. Also, how weird is the word "Savable?" I really feel like English shouldn't have cut the E out of that. It really messes with my Synesthesia. This is a minor refactor. I think once this is done I'll be able to start on the Workout Plan GUI. As with everything else I'm just doing something that "works" but isn't the final setup. Honestly we don't know how much data we want to make configurable. Because of that there isn't much I could do now that WOULDN'T be a waste of time. Alright, I suppose I better get back to it.

Alright! You might not know, I forget if I mentioned it, but I've slightly pivoted for a few weeks. I was using the RP Hypertrophy app and my subscription ran out. To my great surprise I tried to get in to see what my prior workouts had been and I was completely locked out. I was pretty livid and naturally this spurned me on to create my own fitness app. The purposes of this first post, before I create a section for this is to discuss where we sit so far. Base Data laid down for 277 exercises. Exercises are broken up into their primary and secondary muscle groups. You can quickly filter and find the ones you want to do. The IO structure, I believe, is completed. Now I need to build the UI to actually interact with it. With this I'll have a VERY rudimentary workout system where I can track workouts. What I haven't created are the workout plans. Think of it this way. A Workout is composed of Exercises, Exercises are composed of sets, and sets are composed of reps/weight or time/weight. All of this is contained within a workout plan. So I'll need to work on that next after this. Once this is working for me I'll see if I can get a WebGL build of it running on the website. Then you can try it out for free and see what I'm missing! Eventually it'll be an apk and...whatever the hell iOS uses on their app store. I've got a few class names that I regret at this point but I'll see about fixing those in a refactor once the whole thing is working. Basically there is a subtle distinction between an immutable ExerciseSheet, and a modifiable Exercise. Unfortunately I had already called the former "Exercise" so I called the latter "Exercise Stats". Not a huge fan, but it works for now.

I've been battling with the dialogue system for a while here. I have repeatedly overthought the problem. So, thinking I need one less headache I bought a dialogue package off the store. I used it for a bit and realized it had way more than I'll ever need or want to use. I'm trying to enjoy myself developing and don't want to spend a bunch of time learning someone else's system. I'm sure it is great, I'm not going to spend this update complaining about it. Instead I want to talk about what I've got setup so far! We now have a dialogue system that can handle branching narratives. It also supports conditions for displaying information with a fallback message. So if you are expected to collect say 10 apples and you only have 9, it'll display the message telling you that you are shy some resources. This does make me realize I'll want to figure out something for things like showing how many items remain in a response message. But perhaps we just won't do that. Not everything needs to be dynamic. I'll keep it in the back of my mind though. talky_example_half_frames.webm I haven't hooked it up yet, but we'll have support for multiple possible messages too. This is needed for quests or situations where you have a few incomplete conversations to have with an NPC. What I haven't worked out is having truly random visitors that would have their own random dialogue. But I'm also thinking I'd rather craft each of the visitors that can come. Keeping this personal is a much better path to take. Tomorrow likely I'll test out the fallbacks and then I'll look into doing a few fun conditionals for the sign. This is our debug buddy and it would be nice to see how a Dr. feels about apples.

I forget if I mentioned this in my last update but I've finally got the project in Unity 6. This is my last planned update for the game engine. At this point I have everything I want and really any further updates are just me looking for excuses to delay work. As of today I've got a few weeks off from work and I want to make the most of it. The biggest challenge with these large delays is that you have to piece together where you were prior. I'm noticing that a past incarnation of me put together a system for finding a "valid" random point for the Moosecats. I don't think it was the best choice as designed. But it will get us to where we need to be. I just needed to work through it and see what was updating it. I found that StateActionPopulateWorldPositionDataAction is updating it. The name has some redundancy in there that I want to fix. A buddy at work would have my ass if he saw me writing Action twice in the same class name. The good news is I just checked all my other state actions and this was the only one where I did that. Phew! Easy enough to rename. Find a Journey you Love and Love the Journey This is something that has been on my mind recently because I work out a fair bit. Not as much as I'd like to but as much as my mind will allow. But I think I know how I can enjoy my life more. Perhaps it'll help you too, I'm not sure. Basically at least in the US we've become absolutely obsessed with the destination. Get rich quick, get strong quickly, lose 10 pounds in 10 days. All sorts of promises that tell us we can skip the journey and get directly to the destination, if only we trust them. Nearly all of these things are scams, enough to just throw them all into the same pot. But how do you not fall for them? It's one thing to be vigilant and try to stay ahead of the game but we are all busy folks. So I propose instead to find a journey that will get you to the destination you desire that you think you'll love. From that moment your only job is to love the journey you are on. When I work out I'm not thinking about how many more days until I'm buff. I just glance in the mirror from time to time and notice my arms are bigger or my chest is bigger. I could be stressing that I'm not Bane after a few years, but realistically what am I rushing for? It's looking like none of us are getting out of this alive, so its best that we find the most joy in what we are doing. And if the journey you are on is not one that you love, at least take some time to see if there's a way to change that. Because as long as you love the journey you will be basically immune to all scams. Because why would you want to skip the journey if you love it? And where is the big money maker in sensible solutions? This I think is the crux of not falling into despair about these plagiarism bots that are being built. Just keep in mind they are selling a destination. They want people to skip picking up skills, to skip learning, and to become dependent on the brute force of modern silicon. You can't fail if you love what you are doing. I'll see if I can articulate this better in the future. But this is where my head is at currently. I'm gonna get back to this little journey with Moosecats. Maybe we'll get back into streams soon.

The Front Today was a pretty slow day to get started. But once I got rolling it felt like a lot of things were coming together. Each new game that I start is saved in a separate slot. I've somewhat arbitrarily only given you 10,000 to work with. This may eventually change to just be however many your PC can manage. Just keep in mind that the UI I'll be designing might not be the most convenient when you've got far too many games running. Realistically I would think most people will only have one given all the collectibles and progress folks will have access to. I've also updated the artifact system so that my serialization updates from yesterday...or two days ago...is even more efficient and convenient to use. This is good because a system really needs to be convenient or I'm likely to nuke it. A system that is both convenient AND good is always a nice surprise. So this means that the next step we need to take is having continue work. Once I can click on any of my prior saves and load into them I'll know that I'm in a pretty good place. Obviously things like loading from Save A to Save D while actively in game might be a little messy. What we may end up doing is unloading the game scene, taking the player to some kind of loading scene, and then have it load up the same way each time. I'm sure I'll miss something leading to data persisting between them, but if it isn't super bad that'll be fine. Those kind of goofs are fun for speed runs or challenge runs. The Back I'm a few days removed from my last work out but it was a real beast! Stair Calves - Two Sets - Body Weight @ 31 Reps Barbell Squat - Two Sets - 150 lbs @ 7 Reps Seated Cable Row - Three Sets - 100 lbs @ 13 Reps Bench Press - Three Sets - 105lbs @ 6 Reps Barbell Curl - Two Sets - 55lbs @ 17 and 14 Reps Respectively. Cable Triceps Pushdown (Rope) - 50lbs @ 11 Reps, and 40lbs @ 7 Reps respectively. My biggest mistake here was those Cable Triceps, the list of exercises above IS the ideal order but I didn't do it in order. I misread my sheet and did 50 lb pushdowns which, as you might guess, is quite hard! It completely gassed my arms and when I double checked I realized my mistake. But at that point I still had curls and press to go. Talk about a grind. I managed it but only with a lot of grunting and perhaps a bit of praying to the iron gods. I'm pretty happy overall with my performance and I really enjoy working out. I'll see if I can manage some more Phitness & Philosophy videos this year. If I can plan them properly they might not be the worst amount of effort. Perhaps I should just do more unedited long form videos. Its not like I'm trying to become the next big thing on YT. So the success, or lack thereof, really shouldn't be a limiting factor in what I want to do. Just a matter of keeping a positive mindset and approaching things in a healthy way. Lets see if I can muster that.

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 hardly revolutionary but like all my other naming structures the important thing is having some level of consistency. It is the fact that these are neither MB nor SO that makes them a "utility" class. And that mentality in the future will help me manage what is what easily without a lot of hovering. These new classes can be utilized as easily as: var USD = new UtilitySaveData(_keyArtifact.Value, _saveIndexArtifact.Value, _objectToSave); USD.SaveState(); and var USD = new UtilitySaveData(_keyArtifact.Value, _saveIndexArtifact.Value, _objectToLoad); USD.LoadState(); Simply generate a copy of the USD and give it a go! This will read from shared artifacts between the behaviors that are creating these classes and that results in us never losing sync between our savers and loaders. It also means they don't have to be one monolithic class. You might say "Well, Oafkad, why is your Utility a monolithic class?" To that I say, its been a long month. But also its still a pretty defined operation that doesn't require a lot of different events and communications with the outside world. The same is not true of the behaviors that are saving and loading. Those have a lot of moving parts outside of themselves and I want them to be simple and contained. Plus I think this utility is darn near feature complete for now. We'll see as I use it! We've got our savers and loaders setup in the scene for the main menu. So the next time I'm developing I'll need to hook those up to their neighbors. The loading system will be what determines if continue is clickable (and indeed what you see after you click it). The saving will be called by the player submission request, and following that save succeeding we'll transfer into the introduction of the game. It's been a long and slow road for a month or two here, but I can see some level of progress on the horizon. The Back I'm a little bummed that I don't have a lot of mental energy lately. Which itself kind of feeds back into the problem where you are constantly in recovery mode. This does mean that doing work outside of work gets harder and harder. That's especially bad because then I end up feeling more tightly bound to work as that's the source of my income, and thus the few freedoms you can manage as an adult. But the more that happens then the harder it is to shut off from work and the cycle repeats. I'm hoping that as I get back into fitness this will become less and less of a problem. I can already tell that the muscle soreness from my last routine has given me a bit more pep in my mental step. That might sound weird, I know a lot of people don't like to be sore, but I generally like it when I know why it happened. Soreness tells me that I really gave it my all with whatever I was doing. And yet I hate headaches, so perhaps not all soreness is equal. I'm going to probably get back into posting on my YT channel soon. Not because I expect anyone to watch but because that also makes me feel better. We'll have raw videos of gameplay, development, and fitness. Like these front and back posts, if any of it appeals to you, please check it out, but if none of it does that's fine too. The internet is a dark and scary place, and if I'm not able to give you a bit of levity then that's fine. We all gotta find what works for us. Maybe after tomorrows workout I'll include what I did in the backend of the update for the day.

Welp, you can officially click new game, pick a name, a birthday, and then move into the main game proper. This is great but it does raise a few things that I need to overhaul. The first is our saving and loading system. Currently it is using interfaces in a way that should literally be impossible in C#, how I got it to work I'm uncertain. But it is impossible to breakpoint which is very annoying. This week we will update the saving and loading such that it is done properly and can be properly breakpointed. This will be very helpful and part of this will be creating checks for whether or not the loading data exists. You might be saying "Uh...how do you load at the moment if you don't know the state of the save data?" Well I DO know, but it is loaded immediately after checking. This was perfectly fine for a few months of development but now I need to make it more robust. We will check if save data exists on open, if it does then turn on the continue button. From there you can select one of the save data that currently exists. And ah hah! That's another thing we need to validate, saving to different index values. Currently it only does a rolling save, so it'll save to spot 1, then 2, then 3, and roll around after it hits the limit. But I want you to be able to pick a slot and always save to that slot until you pick a new one. Perhaps with "-1" being our autosave slot. We'll see. Overall though, making some core progress. I'll also talk about how I solved the "state to state" communications in an upcoming post. It isn't super clever but it was a refreshing moment when I saw it work on the first try.

So I'm realizing today that I need to make the primary state machine of our system a system that exists outside of the primary scenes. It hit me like a ton of bricks when I was clicking on one of my main menu buttons and...nothing was happening. Well shoot, I thought, that's definitely unexpected! I've been using this system for years, how could it be failing now? Well, when a tree falls in the wood and nobody has registered a listener, does it raise an event? The answer, at least in my system, is no. This isn't an insurmountable problem. What I can do tomorrow is create a class that I add to my fresh scenes, this will check to see if we've instantiated the state machine yet (and placed it in the do not destroy scene). Once this has happened we'll have our system setup and ready to rock for all other places. This is a bit different from a singleton in that we won't actually have any static references to it. This is simply a system that exists in the ether and communicates back and forth with the rest of our game world through events and our scriptable objects. This is an exciting moment for me because it gives me a very direct thing to solve and given how fatigued I've been lately that'll be a welcome adventure! Once that is done we'll move onto the next game action I need which is spawning the player at a particular location and rotation. We'll need this for the introduction sequence.