Godot .tres items, Equipment window
I went all-in on inventory development. It was the most intense period yet, with the steepest learning curve so far. I felt like everything wanted to turn into spaghetti with every new addition. As mentioned in the previous post, I finished a basic inventory window with a simple drag and drop function for items. It was just a means of following a tutorial. This time I expanded on that. In the initial iteration items were based on the .tres Godot format (text resource). Items would have a name, icon, some description and a variety of stats like category, target, cooldown. The first was a potion. Equipment items, like a weapon or boots would need different stats like damage, armour, healing. I made about 7 items and realized that this parameter list will look really messy soon and explode in complexity. I needed to separate them into categories so that not every item would have every possible stat, only the ones relevant to its category. I didn’t want a massive parameter list where every item had dozens of irrelevant stats that simply had to be left at zero. The solution was to add a dropdown selector with 3 distinct categories: equipment, consumable, object. Equipment is what the character would wear, armour and weapon pieces; consumables are food and potions; objects are everything else, like a quest item, a key. This way, some stats would strictly be selectable for equipment items. These categories could further split into sub-categories. For example, equipment can be head, chest, boots, weapon, etc.
Next, I added the equipment window to give items some real use other than sitting there. I realized it was almost the same thing as an inventory, except it needed stricter rules. The subcategories I just mentioned matched this perfectly. Each slot here can store an item, but only according to the ruleset. A head item slot can store head items only. Now I could equip an item or put it back to the inventory. This really felt like a big jump in progress for such a small amount of work. They are still far from having a real gameplay purpose, but I’m a bit closer to the goal.
Database-like pipeline
.tres worked perfectly well for the initial prototype, yet the method bothered me. The problem wasn’t that the format couldn’t represent the items; it was that manually maintaining hundreds of individual resource files would become tedious and difficult to balance. Imagine changing the stats on hundreds of separate item files. If I wanted to add a few hundred items eventually, this method would scale badly.
Since I had a long background with Excel, I thought I would want something that worked in a similar manner. I had never made an actual database, and I didn’t need anything that complicated for this project, at least not at the moment. I would just put the items into a spreadsheet. That way, I could just fill a row with the parameters to make a new item.
It was clear that the current method cannot scale for an RPG, this is meant for a game where there are only a few items. I gave the spreadsheet method a try and it turned out to be feasible at least. Here you can see some of the first iterations of [equipment_items] table, where a few items are added. Consumables and Objects have their own sheets. The method is the following: I fill the sheet and save it as .CSV file then convert that to a .JSON file, then load that into Godot as a database-like data source, mapping the columns into the specified item parameters in the code. To help with data type validation, I added the types directly to the column names, so my makeshift Python translator could type the columns properly: :str, :bool, :int. Also added some VBA code into the Excel data file, so I can one click export the .CSV for any modified sheet and call the Python translator too. This saves time in the long run. Anytime I add or modify data, I just need to click a button and the changes are available in Godot right away.
Stat philosophy
With the basic structure in place, I started thinking more about what the items should actually do, what is my stat philosophy. The priority goal in mind is to make this system a bit more realistic than a traditional fantasy. I know some of these conventions exist mainly as balancing tools, but I’m attracted to a more simulation-oriented design anyway. For example, a weapon would have no armour stat, while an armour piece would have no damage stat. This is a bit different from the model used by most RPGs. Traditionally all equipment pieces can have damage stats (+strength or just simply +damage). In my model, pieces would be more functional. I don’t know yet how it will turn out. It may cause major balancing issues. I may end up with less knobs to turn. If only the weapon controls how much damage the character deals, that makes it extremely special, while if several pieces just add protection – which is the purpose of an armour of course – may not work in a game. I think I will try to tailor weight into the formula in some way. If armour is heavier, it might provide more protection, but it could also reduce mobility. That could indirectly reduce damage by making the character slower. Light armour, on the other hand, could provide less protection while making the character faster, potentially increasing their damage output. This could create a choice between a tankier fighter and a more agile one. Still, having many pieces contribute this way could become a huge problem, which I will need to solve if I stick to this path. For weapons, I want a less generic-sounding stat. Drop damage and add sharpness. Sharper swords surely deal more damage. Still the same, just a naming convention. Keep weight for weapons too. If it’s heavier, it might hit harder but less frequently. Imagine a huge two-handed sword versus a small but sharp dagger.
By the way, I did not mention that the main character’s base archetype is a warrior, if it wasn’t obvious yet from the stat philosophy paragraph. I would obviously like to add more class options, but as a solo dev, I should not go that far yet. I would be happy if I could even pull it off with just one.
Refactoring
While it might not show from these steps, it took several refactors to get these systems working as intended. Any major change made parts of my previous work obsolete and required a partial or complete redo according to the new philosophy. I went from single .tres items, to layered and categorized items, and finally to the database-like pipeline. Oftentimes it took hours to hunt down some bugs that somehow made it not work at all. Sometimes the smallest things took the longest to fix. For example, adding the equipment window ‘shadowed’ over my inventory so I could not click that. It took hours to figure out that it fills the screen and not just the window I see. I had to set up some ‘pass through’ option in the editor, so it would not block mouse clicks on the whole screen.
Previously I mentioned I used AI to teach me. I also used it a lot to help with bug hunt. I didn’t give it my whole workflow and ask it to add features or fix everything for me. I used it selectively, mainly to teach me methods and help hunt down bugs with limited inputs. For bugs, I would only describe the problem or paste just fragments of my work where the error is suspected. I guess it would have taken even longer to solve these totally alone, but with it, it was still a pain. Usually, it answers with so much confidence that the proposed solution will work. Then I try it, and it doesn’t. I ask again, try another solution, and sometimes that doesn’t work either. After 10+ tries, either some solution finally works, or I’ve figured it out myself by that point. It really is an alternative to reading through forums trying to find a solution. It’s faster, but it’s definitely not always spot-on. Step by step, I feel like my knowledge is growing, and I need less assistance. This matters to me.