When it comes to table structure, I would personally lean toward keeping all items in the same table. Remember, you could have a whole bunch of fields that aren't necessary for every item. Like Effect and Duration wouldn't be applicable to a list of swords. On the form where you need those fields, just display what you need based on the item type. The fields aren't going to take up any extra space. Well, not much anyways; it's negligible.

Or you could go a little more advanced and have a name-value pair secondary table. Where you got your name (such as Effect or Duration) and then the value (the actual effect text or the duration). This gets a lot more complicated. But from a simple perspective, I wouldn't have any problems keeping all of these items in the same table and just giving each one an item type ID.

To answer your question, yes, a lot of it is school of hard knocks. I could teach you all the theory of normalization in the world, but until you've built a handful of databases and seen it in action, it's not going to click as well as if you just do it yourself. This is the perfect example. A few of the first databases I built were Dungeons & Dragons related (storing characters, storing monsters, all that kind of stuff). I built a character generator in Access (way back in the 90s) and even a database to store dungeon maps (data in an XY grid format with doors and traps and stuff).

Games are a fantastic way of teaching people computer programming and database design.

This is going to be in QQ39.