Game Design: The Basics

I haven't designed a game before. Or, to be more accurate, I haven't finished a game before. So take this how-to as descriptive, instead of normative- if I'm suggesting something silly, point that out.

At the beginning of a project, it's nice to have in mind the skeleton of the project. What will the game look like to play? What will be in the game? What will the back end of the game look like?

The last one seems most important. It's easy to waste time fiddling with the interface (should health be here? Or there? What about there?) and ignoring important things like where that health is stored (a property of the character object, which is possessed by the player object? Or do you not need a player object?). Generally, game companies will have different people working on different things- one person figures out how many classes are necessary while another person figures out how many classes are necessary. That is, character classes and data classes. I'm going to assume a basic programming background in most of my posts, but that shouldn't be too important- if you're only interested in the design parts of the post, or the technical part, just skip through the parts you don't like (and to facilitate that, I'll start putting "design" and "technical" labels on my posts).

So, here are some crude graphics and explanations:
This is how I want the work to look (well, hopefully with a better art department). There's some number of regions that all have the same basic layout- a tavern where one can interact with other players and modify the characters in their party, a training zone where they fight monsters or groups of monsters one at a time (i.e. running around in the woods looking for things to kill), dungeons where you fight a predetermined arrangement of monsters (first you fight the two guards, then three cultists, then a group of skeletons, then two more guards, then a priest and a demon), and a raid zone which is essentially dungeons with more than one adventuring party.

I'll go into the various things in more detail later, but first I wanted to mention procedurally generated dungeons. I didn't think about it much before reading a post of Squidi's on it, but it'll be familiar to anyone that played Diablo (I or II)- making content with extremely high replayability by having it randomized from predefined pieces. It's something that I'll get into when I work on the dungeons themselves- which will probably be once the tavern and the training zone are both up and running.

Interface:
I'm actually going to ignore interface for a while. The battle and dungeon interface seem relatively straightforward- the combat will either be similar to Final Fantasy or to Final Fantasy Tactics, and there's little wrong with either of their interfaces. For the rest of the game- should the tavern just be a chatroom, or more like Habbo Hotel? (I can't believe I linked to that in all seriousness. I'll get over it) Should there be an attempt at overland consistency (i.e., you wander through the training zone until you find dungeon entrances) or should there just be a screen that says "travelling" and then poof, you arrive?

Players need to be an object because the server is going to have a list of players; each player then has a list of characters owned, items owned, current party, etc.

I'm going to digress for a bit and talk about class-based systems vs. skill-based systems in RPGs. Oblivion (or Morrowind) is probably the most famous skill-based RPG out there, whereas D&D is probably the most famous class-based RPG out there (or, a probably more relevant example would be the early Final Fantasies). In a class-based system, a character can be described in one word- their class. Other changes are largely decorative or minor specializations- your wizard might focus on evocation spells, but his difference from other wizards is still smaller than his distance from other classes. In a skill-based system, the common baskets of skills and abilities don't exist- and so instead of "paladin" my character would have "blade, restoration, block, heavy armor, speechcraft, armorer, and athletics." Switching out, say, heavy armor for medium armor will change how the character plays and isn't restricted.

Generally I prefer skill-based systems. The freedom in making whatever archetype you like is one I like. The primary problem is that it's harder to have special abilities (it's clear that paladins should get Lay On Hands, but it's not clear if everyone who gets the Healing skill should get that ability, or what level of Healing they should need to get it), harder to communicate information quickly (which took longer to say, paladin or those seven skills?), and harder to compare character combinations. No one wants to have to deal with this, especially if you have multiple characters you're adding to the group- it's much better to be able to go "ftr/ftr/rmg" than listing the skillsets of three characters.

I'm not sure the best way to code this, yet. I could make a different object class for each character type (class, but type helps lower confusion a bit) with the Character superclass, or I could make the Character class that has however many instances, each of which is a different class, or I could just have character type be a variable in the Character class which other things look up.

This doesn't talk about things like abilities being their own class, which seems like the best way to do it, and I've largely ignored items. This post is already pretty long, so I'll get to them later.