Story — While not strictly necessary, most RPGs have at least a basic story behind the gameplay. MMORPGs are usually the type of games that dump you into a world without any main guiding force, but you could do the same thing in a regular RPG (although I wouldn’t recommend it). My personal feeling is that a good story is more important than flashy graphics in an RPG. The story shouldn’t interfere with the gameplay, however. Try to use conversations and interactions with NPCs to partially drive the storyline along if possible, without having the NPCs seem like they’re reading the story from a book. Speaking of books, they and other objects in the world can also be used to provide background and other information that fleshes out the game world and gives the players some idea of what they’re doing and why. If the player is given a quest to help defeat some evil king, he may wonder why he should bother. If he picks up a book and it turns out to be a history of that king that describes how the king killed all but a few of the character’s race, he now has some incentive to see the king taken down.

Good storytelling is an art and even more so in games where you have to do it in a medium different from those most people are used to. Don’t expect to win awards for the story in your game the first, second, or even tenth time. Even award-winning authors have penned stories and scripts for games that haven’t gotten great reviews. Do the best job you can though, and players should notice the effort.

Levels — Ideally you would have all your levels laid out before you begin designing them. This could be done by designing your world first, then creating levels that you can drop into areas of the world. That’s assuming, of course, that you don’t just make your world one big level and dynamically load portions of it as the user explores it. That would be an ideal situation and it can be done. The Dungeon Siege games were a great example of doing this, but of course those had a huge team of professionals. Most indie developers don’t have those kinds of resources, but they’re also not usually developing games on the level of a Dungeon Siege.

Don’t just create empty levels merely so you can say your game has 100 levels. If only a dozen of them are populated or interesting in some way, you can expect the community feedback to be appropriately negative. Compress the wilderness type levels to break things up a bit and give the players a decent chance at nice random encounters. Make sure the encounters are appropriate for the area as well. Players shouldn’t be fighting giant rats in the middle of a forest or bats in a desert.

As a player I could spend hours wandering around a town level as long as there are interesting things to do there, especially if I’m playing a thief type character and thief skills are actually usable. If there’s a thief guild in the town, even better. You could have quests just based around it — pickpocket x amount of money, put a shop out of business by stealing inventory because the owner won’t pay for “protection,” etc. The possibilities are almost endless. As long as there’s enough content to keep things fresh and interesting, one town can go a long way. This could naturally lead to…

More quests — This goes with the story item but there are also side-quests to consider. The main story itself can have anywhere from one to dozens of quests that have to be completed, but to keep the player on his toes, you should have side-quests pop up from time to time. If the side-quests cause the player to think about accepting them and possibly disrupting the main quest, making it more difficult to complete, or not accepting them and losing out on whatever rewards can be obtained from completing them… well, that’s part of what makes RPGs so interesting and different from other genres.

If your game has dozens or even hundreds of quests, you’re going to have to ensure that the player has some way of managing them all. This means not only a way to see all the quests he’s currently working on but also those he’s completed, as well as possibly a way to reorganize them in the GUI you use to display them. By default you’ll probably be displaying them in reverse order of when they were accepted, moving those he’s completed to the bottom. If quests are tied together, you’ll probably also want to give the player a way of easily seeing the thread that leads from one to another.

More loot — This goes without saying I think. Every RPG has tons of items for the player to find, steal, whatever. Making the character more powerful by getting new gear is part of the fun. Don’t just throw loot at the player for the sake of having loot in the game, though. There needs to be a balance to when and where the player gets it and how much of it they get. Avoid the Monty Haul campaign at all costs (see http://tvtropes.org/pmwiki/pmwiki.php/Main/MontyHaul for an explanation of this term if you haven’t heard it).

New classes, races, skills, spells, etc. — One new skill that can provide hours of gameplay is crafting. By allowing the player to create his own items, you give him the ability to play the game he wants to play, assuming that your implementation of crafting is fun, interesting, and useful. Forcing the player to make his own arrows and having that process be dull, boring, and take hours is not the kind of memorable experience you want your game to be known for. You can look at most MMORPGs for a way to not do crafting in my opinion. I’ve yet to play an MMORPG where crafting was interesting, fun, or immediately useful. This is probably due to the way MMORPGs work. Developers have to keep you busy doing something so you continue paying the monthly fee. Making crafting easy would be counterproductive. I’m sure there’s a way to make it fun, but I haven’t seen one yet. Fable 2’s smithing mini-game is about the closest to what I think crafting should be.

I’ve said it many times so far, but it’s so important I’ll say it again. You’ll need to be careful with adding things like races, classes, or skills to the game. It’s very easy to create an unbalanced, and therefore unfun (in my opinion anyway) game. If one race or class has superior power, making it easier to complete the game when playing as that race or class than as another race or class, most players probably will ignore the other races or classes and possibly miss out on content you’ve spent time creating for them, which means you’ve wasted time and possibly money on all that content.

Try to plan all your content before you even begin developing, prototyping on paper if possible. Create characters of all the race/class combinations and playtest combat with some of the creatures you plan on having in the game. If it’s obvious that one combination is better than another, tweak values for stats, skills, or whatever until it takes about the same effort with every combination. Yes, it’s going to take a lot of time, but it’s better to do this on paper, where it’s easy to change things, than in the game where you have to worry about breaking the game.

Saving and loading progress — It wouldn’t be very fun it you had to start from the beginning every time you loaded the game, would it? I haven’t bothered going over loading and saving an entire game because it’s not much different than loading and saving a class from a code perspective. You do have to think a little about what exactly needs to be saved, however. Rather than saving the entire level, you really only need to save any changes to the level. This includes things that have been removed from the level (dead entities, loot that’s been picked up, etc.).

In allowing the player to save his progress, you’ll have to answer the question “How many saves should the player have?” Unfortunately, there’s no one right answer to this except “It depends.” You can give the player the ability to save as many times as he wants, but if he can save every time the character takes a step, there’s no sense of danger in doing anything. Fear of having the character die and losing something (be it experience, items, temporary reduction of stats, etc.) is a good thing in my opinion and something that should exist in the game experience.

There’s the checkpoint method of saving, but this usually turns out to be more negative than positive from what I’ve seen. Picking the right place to save and ensuring that the state of the game at that point is always such that the player can complete the game can be problematic. More than a couple of games that have used the checkpoint system have been patched to allow the player to save at any point. It takes a little more work to allow the “save anywhere” feature, but it’s usually better than the alternative. That being the case, restricting the number of saves while allowing the player to save anywhere is usually a good compromise. There’s still the possibility of the reduction of the danger of the character dying, but there’s not much that can be done about that from what I’ve seen. Keeping the player on his toes by not making encounters glaringly obvious helps to heighten that sense of danger.

Options — Give the players the option to change things that can be changed. Some of these things include resolution, default controls, and sound and music volume levels (with the option to turn them off completely if they want). Make sure that changing or turning things off doesn’t affect the gameplay. (That quest where the character has to listen outside a door? Yeah, that one. That’s not going to work if the player’s turned off the sound!) One thing that I’ve not seen much of is allowing the player to adjust the brightness. Usually this isn’t a problem, but in dungeon-type levels there is the possibility of things being so dark that on certain monitor and video card combinations the player’s ability to make things out isn’t as great as it could be. Making sure you test your game on more than just your development machine can help spot this problem, especially if you can do it on a low-end machine without blazing graphical power.

Gamestate — The demo doesn’t have any real understanding of gamestate — things like pausing the game, pulling up a main menu to change options or save the game, or even handling ending the game gracefully. At a minimum, for the last item you’d want to prompt the user to save the game, not just shut down. Simply adding a menu system means you’re probably going to want to add some kind of gamestate management. Luckily, a sample exists on the Creators Club web site that shows how to do this. Modifying the demo to use it would be fairly simple, consisting mainly of moving the level from the Game class to the GameplayScreen class that the sample uses.