Your biggest potential trap is using your Excel brain to design a db. That will only cause you grief, and the deeper you get in, the worse it will become and the less you will feel like dumping everything and starting over. If you have not studied normalization that is your #1 task. Understanding it is your #2 task. Let me give one example of where I get the impression you don't fully understand it (assuming I understood details of your post):
You want to put fields for what equipment a player uses, along with their name, phone number, etc. WRONG.
Let's say there will be 5 equipment fields. For every one of them that a player doesn't need, you have no data. Worse, if you decide to add a 6th type, now what? Add a field, fix all your queries, fix all your code, fix all your reports? The equipment is not an attribute (field) of a player (entity) - it doesn't belong in a player table. You would likely have a table for equipment thus every new type added becomes a record not a field. You would have your player table with player info. To relate equipment to player, maybe a tblPlayerEquip table, which is commonly referred to as a junction table because you have a many-to-many relationship there.
Because of the foregoing I didn't study your entire post because I think you're in danger of heading down the wrong path. Don't forget jobs 1 and 2!
The more we hear silence, the more we begin to think about our value in this universe.
Paraphrase of Professor Brian Cox.