So I'm in the stage of designing weapons for one of my games and I would like some suggestions on the layout of the documents. For example: I know that the documents should have the weapon name, stats, and a rough drawing, but is there any other information I should include? Should the weapon be drawn with incredible detail or just a rough sketch? Should each weapon have its own dedicated page or can I put multiple weapons on one page? As always all suggestions are appreciated.

Sweet. I've done a mostly good job of it so far then.

I'll say this: There's nothing the document should or shouldn't have. A template would be about the worst way about doing game design (in my personal opinion).

There are a few constants that are considered good practice in how the macro GDD is laid out (from general to specific, and then broken down) but everything else about the GDD's form and content should reflect the game product, and as such, is as infinitely variable as the amount of game concepts that could exist (close to infinite).

If there are few weapons, and their stats are critical to how your game scales, you could include a short table of something like:

NAME - small icon - Attack power - Price

NAME - small icon - Attack power - Price

NAME - small icon - Attack power - Price

etc.

If that doesn't sound like the first thing someone looking at the concept would need to go, probably best to leave it to an appendix.

A solution that rises in popularity (and with which I agree) is to do as jbadams says - one pagers.

You start with a GDD that is as concise as possible, giving the general ideal, and then breaking down the absolute CORE mechanics of how that game functions.

Then, for every 'satellite' mechanic, and especially content, you make shorter side-documents.

So, for example, the GDD would explain what weapons are, how they're used, how to equip them, etc. (possibly outlaying the UI ramifications of that) and THEN a standalone short document would be a list of weapons. If you work in something like Gdrive, the need might be less pressing, but for anything that's not inherently shared across the team during production, it really helps to be able to make 'localized revisions' (if only because the files will be less likely to be opened by other people, etc.)

'Satellite' (or secondary) mechanics also belong there because they're not required to 'get it' so people don't want to read about them until they understand what it is you are setting out to do, but by the time they do, they'll want to know how that feature works with 'everything else'. So a one-pager satellite feature does not just contain what the feature is, but also how it interacts with every other core feature.

Hope that helps a bit.