But I'd still need to write the 100 different constructors to populate the itemHashmap or use XML.

Well, the data has to come from somewhere, right?

P.S.: I know I wrote it didn't matter, but XML is truly unnecessarily verbose for something as simple as this, consider JSON or something even simpler.

I don't know if I want to take the time to learn another language and how to import it, or write a lot of methods. I prefer clean code though

My 2 cents: the "better" way is definitely reading in the data from a file, but early on, it doesn't really matter. If you don't feel like fiddling with file parsing right now, write it in code (a couple items will likely be enough for testing while you build the game), in a well separated place. Then, when you have the time/mood for it, move it into data files. Perhaps you will be stuck on a difficult design issue and it will be refreshing to take a breather and work on some file parsing, while still feeling like you accomplished something meaningful

Thats a good idea. Its always good to take a break from one piece of the project and move to the next

in addition to non-generic variables, each object_type_struct in caveman also contains seven arrays of generic variables. with all the benefits and hassles thereof.

Thats a good idea. Its always good to take a break from one piece of the project and move to the next

have to be careful that doesn't lead to a number of unfinished features at once. usually best to do "one thing at a time, do it very well, then move on". gets you milestones quicker, and tends to keep the project in a more ready to go (as it stands so far) condition at all times.

for a break, but with continued productivity, i find having a second project, perhaps for fun or learning or experimentation is an excellent option. you don't get multiple unfinished features in the primary project due to boredom, and when the first project is done, you might already have a head start on a second one worth pursuing. handy tools and libs that you could use but are not mission critical for the primary project (and thus at the top of it's todo list) are great candidates for second projects.

Alright so this is what I have so far. The items are going to need more parameters eventually, but I'll handle them with strings and integers in the constructor of each item.

    HashMap<String, Item> ItemList();

    private static void Hoe(){
        Item hoe = new Item();
        hoe.itemName = "hoe";
        ItemList.put(hoe.itemName, hoe);
    }

Each of my item constructors will look like this, and then I populate the HashMap by calling the static method at the start of the game.

putItem(Item.ItemList.get("seed"), 2);

public void putItem(Item item, int itemQuantity){
        for(int i = 0; i < playerInventory.length; i++){
            if(playerInventory[i].itemName == item.itemName){
                playerInventory[i].itemQuantity += itemQuantity;
                break;
            }
            else if(playerInventory[i].itemName == "empty") {
                playerInventory[i] = item;
                playerInventory[i].itemQuantity += itemQuantity;
                item.itemIndexInInventory = i;
                break;
            }
        }
    }

This is how I add the item to my inventory. It works right now but as I add more parameters like different seed types and strength of tools, I'm sure ill need to change some things.

For stuff like this I find that a component system is really easy. That way, the only thing that everything that goes into the inventory needs is the IsAnItem component. After that, you can give seeds the IsSeed component and have that allow it to be planted, maybe it has a variable that indicates what type of plant it will grow into. A hoe, then, would instead have a IsTool component that handles whatever its uses are. But the inventory ONLY cares about the IsAnItem component to see if it can hold onto it.

Hope that's useful.

Alright so this is what I have so far.

I can see a couple potential issues based on the code you posted. You didn't post the code for the Item class itself (which would have been the most relevant part), but based on the usage it has fields like itemQuantity and itemIndexInInventory. If you wanted to separate the "prototypes" from the "instances" like we discussed, these fields definitely do not belong in the prototypes. Seems to me you have the two mixed together, however I cannot tell for sure without seeing more of the code. Like you said, you will probably have to change some things as you add more code, and you will probably see what does and doesn't work yourself. That's okay - it's really rare to get everything right on the first try (especially since the definition of "right" tends to change a lot during development )

I think the most effiecient method would be to set item properties depending on the item's id. For example if thr item ID is 11 then it would be a sword. You could store the properties of a certain item in a file, and on runtime make an index of ID properties, so everytime you want to check for an items properties you don't have to load a whole file.

As for the inventory, an array is a good idea if you want the inventory size to be static, but if you want to expand/shrink inventory, I would recommend using an std::vector. Also you could just have that array or vector contain a list of ints that represent an ID.