Consider objects, the less hardcoded it is the more you are able to extend the functionality of it (i.e. adding more items or adjusting items without touching code).

Item Object

Weapon Object derived from Item Object

Armor Object derived from Item Object

Inventory Object

Item object container

Store weapons in Inventory Item container

Because you are setting the container to hold Item objects you are able to pass Weapons in there because it is derived from Item object. Now your character can have an Inventory object which keeps track of what he has on him.

Then the question belongs to you... How in depth do you want your skills? Just a list of strings, I don't see why you would need that to have its own class. But if you want to get into skill levels, skill affects, how would you do that? It all really depends on how in depth your system is going to be. I would start out shallow till you have a firm grasp on it. Experience over time will tell you "Does this need to be its own object?" and how abstract do you need to make it.

For example of the items abstraction I pointed to you,

I load my items via a json file using boost json parser. The structure would look like this:

{

"weapons": {

"100": {

"item_id": 100,

"name": "Deathbringer",

"damage": 10,

"weight": 3,

etc....

},

etc...

}

}

Looks like an awful lot of information to try and store statically in non objects

I could easily go name, item_id and weight are going to be on every item, but damage however will only be on weapon. You could do something similar to Skills.

Like I said before it depends on how in depth you want to go. I am not saying it is always the right choice to make everything an object in cases like this I don't see why you wouldn't want it. Allows for easier extendability when adding something new you don't have to fly all over your code making changes every where you created a new item. Especially if you are iterating through an above like example of a weapons json file.