So, after last week's fiasco I figured I should actually work on the game. Lighting and shaders are really cool, but only going to be useful if they have a game to run on. Lately, working on the game has felt pretty difficult because everything needs work. Character sprites, environment, UI, primary mechanics, fixing bugs; the entire project has felt like it's on fire. So what do I do? Well, on Monday I sat down, looked at the project, and was like, "Yea, I can definitely clean some things up and have a working demo by the end of the week." Sounds great right? Well I immediately proceeded to spend 2 WHOLE DAYS on just the character sprites. (I suck at art) After FINALLY getting some pretty rough walking animations finished for our blacksmith I was like, "Uh... this demo is not getting done." So I went back to the drawing board and put what is hopefully a more appropriate timeline on things. I outlined what the rest of the week would look like, but still felt that it would be hard to get done. Well, today is Friday and I'm happy to report that the programming side of things has gone much smoother than the art. (Not surprising since I'm a far better coder than I am an artist)

On Monday, when I planned out what needs to be done for the demo, I outlined a number of things that I needed to get done. This helped a lot in my opinion because it organized the bonfire of a project a bit and helped clear up what I needed to do. Two simple things on the art side were the character sprites and environment. These may seem like polish things, but even simple art can contribute so much to how a game feels. Playing previously with just a general outline of a character felt strange and I didn't like it, and I need a box for the player so they don't just wander endlessly in the void. (We've all been there, we've all done it, and no one is for the better doing that.) After that, There were a large number of programming issues that I needed to clean up before finishing the prototyping. The three largest of which were that objects didn't calculate temperature when outside of the forge, there was no way for the player to tell what temperature an object was at, and there was no way of putting or taking out of the forge anything other than the crucible. After that, I need to get the quench tank, grindstone, and workbench working so the player can actually make a sword out of the blade. This means I need new UI elements, better item art, and figure out how everything is going to interact with each other.

After getting past the character animations, things went much quicker. I got blade and sword assets put together in both sharpened and unsharpened states, and shifted focus to the forge. Now, this was THE thing stopping my development. Whether I knew it or not, I had been kicking this decision down the road for at least a month or two. I needed some system for the player to interact with the forge in a way that allowed them to see what was in it, what temperature everything was at, and felt like being a blacksmith. I had thrown around the idea of creating a whole UI page with everything on it similar to the crucible table, but really was avoiding that idea. It felt too clunky in my mind. I plan on having the player consistently swapping back and forth between the forge and anvil as they are taking an ingot out, working on it until it cools, then sticking it back into the forge to heat it back up. The idea of a page popping up every time this happened just didn't feel right to me, but this decision was blocking all other progress on the game. The anvil couldn't function correctly without being able to put metal in the forge, I couldn't work on the quench tank or grindstone because the anvil wasn't fully functional, and since all of this is basically what the game is, it meant I couldn't really do anything other than just stare at different code and cry just a little. 

Finally an idea hit me this week. Something way back in the recesses of my memories remembered some game (One of the monster hunter games I think) that would have a selection bar pop up. The bar showed three icons and two arrows. From there you could cycle through the list and select what you wanted. I know there are many, many other examples of this but that was the one that came to mind. With that, you interact with the forge, that bar pops up, and you select what you want  to pull out of the forge. It is simple, elegant, and feels like you're actually interacting with the forge. Also, the selector could be a pair of forge tongs that make a lot more sense than our brave blacksmith just grabbing molten metal with his bare hands. (Although I do think the latter idea is far more badass of him) So, I threw together a sketch on my scratch paper, then jumped into Aseprite to get assets thrown together. After this I threw together a basic UI scene in godot and worked on getting the selector working. I also threw a text element over the selected item and made it display the temperature of that item.

This took a little bit of work to get going, but from this point on development actually went really smoothly. I'm really happy with this because most of my development so far has been racking my brain over and over of what systems I want in the game. This is probably my biggest struggle in game development currently. In my experience, the abstract systems that the game runs on are far more important  than the "content" that you build with those systems, and I think the last couple of days is a good example of this. Questions like how the items and components are going to work, how will the player interact with stations, and how temperature objects will run in the game are what most of my time has been spent on in development so far. It's been hard working on that because I have to consider every way each of these systems are going to be used and how each one will interact with each other.

A quick side note before everything runs smoothly, I realize somewhere in here I also overhauled the temperature system. This kind of works actually because it's a good example of how I approach working through these system designs. When I had first put together the "TemperatureObject" base class I had primarily been trying to get the fuel and the forge working. I had an array of environment objects that each object would have, basically telling it what things were effecting its temperature. This worked, but it meant if you had say, 13 pieces of fuel in the forge, each piece of fuel had a reference to all the other pieces of fuel and the forge itself. This meant a lot of copy data that after thinking about it a lot I realized I didn't need. Now, before coming to that conclusion I thought a lot about making a temperature manager that every "TemperatuerObject" would be a child of. That manager would then run whatever was needed in changing the environment variables of objects and each object could have a switch determining if it was calculating temperature. I sat on this decision for a couple of days thinking long and hard about it. If I went with that, I'd have to overhaul the "TemperatureObject" class and all its children. (basically every item in the game) I diagrammed out how everything worked and what its parents and children were and realized, every object really only has its parent that effects its temperature, and the forge is already calculating the variables it needs from all the fuel. 

So, I overhauled everything. Basically, each object now just gets a parent variable set to reference their parent. From there, they read the variables they need for their temperature calculation. I can then create an environment node for whatever objects are in the player's hotbar or anywhere else other than somewhere that will effect their temperature. This was actually awesome because I was able to cut out a TON of clunky code. Because the forge is calculating all the math for each fuel for it's own temperature calculation, I can just overload the fuel class to take those variables from the forge because that's the only place they will be. This literally shortened my "TemperatureObject" class from like, 5-6 functions down to like, 2. Super clean and easy to use. This system now works in tandem as well with the item system and interact system and makes moving entities around super easy. This is the kind of thing I'm talking about when it comes to working on the systems more than the content. Now when the player puts something into or pulls something out of the forge, I don't have to do any complicated array clearing and resetting, but I change a single reference and it just works.

Coming back to things going smoothly, after I changed this system, the forge UI went super smoothly. It is crazy how some of this is working because these systems are drastically different than what I had originally designed. When first coming up with the idea for the game, I figured each station would have its own UI that would take up the whole screen and display all the data in that station. After working on the game for a bit and making quick fixes to get things working, I realized a different set of controls made more sense. I found myself changing what I'm doing with the stations based solely on the selected UI slot. Basically now the player can have three different interactions with a station. I've labeled those three as Interact, Put, and Grab. If no hotbar slot is selected, the player attempts to interact with the station. If a hotbar slot with an item is selected, the player will try and put one of that item onto the station, and if the hotbar slot is empty, the player will try and grab or take an item from the station. With this, a single interaction (the player walking up to a station and pressing 'F') has become three and give a more tangible feeling to the game.

Now, there was a brief issue. How does the player get the selection bar in the forge and take an item from it with this system. Well, I can simply check if the UI is visible in the Grab function. If not, we set it to visible and do nothing else. If so, then the player sees what item is selected and is trying to grab that item, so we pass that item to the player and set the UI to invisible again. After putting this together and testing it out, I feel it really fits the game. It makes things feel like you're actually going over to the forge and taking something out of it. It's elegant, simple, and once you get the idea, intuitive. So, my focus has largely shifted when it comes to stations to primarily working with those actions rather than building full screens of UI for the player to use. Obviously there will still be cases like the crucible table, but the feeling and way that the player interacts with the world are turning out very differently than I first imagined. It's just a really good reminder for me that things don't always go as planned in development, and that can often be a good thing once you get it figured out.

We have a working forge! The core of our game is functional and I'm now excited to get the rest of things working. I quickly put together the quenching mechanic, taking the blade's temperature divided by its melting temperature to determine its quench percent. Then I reverse the process by taking the inverse percent to temper the blade if its in the forge. Folding an ingot, then quenching and tempering the blade is what I intend on the player spending most of their time doing so this is great. I added a quick sharpening bool to get the grindstone working and changing the blade sprite based on if it has been sharpened. With this, we are almost at both the core gameplay loop being established and being able to make our first sword. I have to figure out the UI for the workbench, how the math for the blade values is going to work, and how we're going to display the sword stats in the workbench. I would like the player to see the stats of a sword before they craft it so if they don't like it they can mess with the blade more or melt it down and start over with that metal if they want.

Now, the math for the blade. I think this part is going to be the most fun to work with, but also will need to be tweaked a lot to work correctly. Essentially, the main values that determine the stats of a sword are a metal's strength and hardness. For those of you who don't know, hardness is a material's resistance to being deformed, and strength is a material's resistance to breaking. With that, if a material's hardness goes above its strength when being quenched, it will crack. Now, I have to figure out how the math is going to work for folding a blade will increase both strength and hardness, but the full hardness value isn't established until the blade is quenched. So, the player has to experiment with how many times to fold the metal before stretching it out into a blade. After that they have to control the heat of the blade to determine just how much they want to quench it. Fold it too many times, or quench it too hot and the blade might crack, meaning the player must melt it back down, turn it into an ingot, and essentially start over again. That's the core loop of the game and I'm super excited to see how it feels to play once it is made.

I'm hoping to implement that this week and have something that is a personal proof of concept for the game. After that I will be spending the following week getting the buy and sell counters built and getting the environment setup so that the demo is actually playable as a game. I'll also be doing a lot of personal playtesting to get the numbers right for the game so it feels how I want it to, but I'm super excited to see what people think once its built. So, feel free to stay tuned for that demo!