The design so far is here: http://dath.universityplus1.com/gamedev/top_down_melee_demo.html What are your thoughts?

I think it's good that you're ambitious and want to make computer games, and I hope you never give up on that. But I think you're gonna have to work a little bit more on your design document. This isn't really a design document, but more a "features" list like found on the back of a game box. You will have to get more deep down in the design of your game. The flash movie wasn't very exciting, and I don't know what it's meant to show. But keep working, there can never be enough game developers. We all started somewhere, and my first game was just text, so keep working. :-)

You don't understand. I know how to program games just fine. No, I will not give up game development. No, I will not program a text-based game. I've already made five of those. I've even made a 2D platform game. The application itself is quite nice, although the rest of the game is lacking.

To be clear: I already know I don't know how to design games. I posted on this forum so that I might receive help learning how to design a game.

.

Game design is much more than coming up with a set of rules (or a list of features) and programming them into the computer. I have known (and developed a game with) people who were great programmers, but knew nothing about designing a game.

Knowing "how" to program and knowing "what" to program are two different things.

You have an initial idea, which is good. In this "Concept Sketch" you have a vision of what you want the gameplay to be like and the animation is a step in that direction. However, your list of "Features" is, I think a bit premature.

Going off what you have presented, it seems that you have made decisions about specific aspects of the gameplay without being certain about other aspects. This usually stems from progressing too quickly from the original idea, to wanting to code it.

By jumping ahead too quickly from "Initial Concept" to "Game Code" you will find your self having to make decisions on the fly, and, unless you are really lucky (or an absolute genius the likes of which would make Einstein look dumb :D) you will make bad choices which will stop your game from being entertaining.

Ok, so now you know why a proper design is important, lets get onto something to help:

First write down the idea behind you game (in a couple of paragraphs - there is no real set size for this task, take as much as you need, but don't go into too much details). Think about what you want the player to be doing. What genera is the game? What type of player would be interested in this game? What is it that a player will be doing in your game? And so on. Don't go into too much detail, but try to answer as many questions about your game as you can.

Imagine if someone stopped you in the street and said: "I heard you are making a game, can you tell me about it?". This first part should be what you would answer in this situation.

Next you need to set out the goals of the player and their motivation (why are the goals important). For instance in a game of capture the flag, the goals are to score points by capturing their opponent's flag. The motivation for this is that the team with the most points at the end will win the game (so you are not needing a deep psychological thesis on why players play the game :D ).

Notice that you haven't yet though about how the players are going to achieve the goals much. But now you do:

Now that you know what the players are trying to achieve, you can start to think about what makes it hard for them to achieve it. These are the challenges the player faces. This will include what things a player can do to make it harder for another player to hit them in a multiplayer PvP combat game (like UT 2004).

Now list the abilities that the player has that will help them overcome these challenges. You should include expected player skills in this too if you think they are important for the player to be able to overcome your listed challenges.

You should allow multiple ways for a challenge to be overcome and you can reuse abilities for multiple challenges (like a quick dodge move might allow a player to avoid being hit by shots, but it could also be used to get past traps like crushing walls). You might also split the different ways for a player to overcome a challenge into groups (in your game these would then be listed as different classes).

Next comes the balancing of the game. From the above you should know what the player is trying to achieve, what makes it hard to achieve it and what they can do to achieve the goals of the game.

I think of balancing in 3 parts. Conceptual, Concrete and Playtesting.

In Conceptual Balancing you think about making sure that all players can achieve the goals (if you are making it a team based game, then you also think how combinations of players can achieve the goals). Most of this you would have been doing when you were thinking about the different ways the players can overcome the challenges. However, just overcoming the challenges may not allow a player to achieve the goals.

As an example: If you had a capture the flag game that used teleporters to move the players between locations quickly, but you didn't allow them to take a flag with them while teleporting, and a map was to have the player on islands in a sea of lava with the only way to cross the lava is using teleporters. Then this would stop players from being able to achieve the goals of capturing a flag as there is no way that they could return a flag as the only way to cross the lava is with the teleporters.

There are 3 solutions to this problem:

1) Allow flags to be teleported (but this might make other maps too easy if the teleporters are close to the flags).

2) Don't make maps where this situation occurs (but this can seem artificial).

3) Create some other way for the players to move over the lava (this might increase the development time and it will introduce new components that need balancing).

So there is no perfect solution, to this problem. And this is an important fact. During balancing you will not encounter many "perfect" solutions. You will nearly always have to compromise something. And that is why this Conceptual balancing is important. It allows you to make these compromises at a high level and with the minimum amount of effort.

In Concrete Balancing you need to start thinking about the actual values of the components of your game. How fast can a player move, How much damage does this attack do, How much armour can a character equip, etc. You then need to make sure that the values of these don't create a situation where a particular choice is dominant or dominated. That is no choice is always worth taking and no choice is never worth taking.

Part of this may involve going back to the Conceptual Balancing and changing what abilities a player has, but try not to do that too often.

During the later stages of Concrete Balancing you will be able to start to code the game, and this leads into playtesting.

During playtesting, you will fine turn the values that you came up with in the Concrete Balancing stage. Think of this as polishing and final verification of your ideas.

Of course this is a simplified method and other people will design in their own way (and sometimes you will use a different design method for different types of games), but this should help you to get your ideas down and to make sure that you think about all the parts of your gameplay design (also, this will not give you a complete game design, just a basic design for the gameplay).

Two books that I do recommend you getting hold of (from my own reading experiences) is: Game Architecture and Design (Andrew Rollings & Dave Morris : isbn 1-57610-425-7) and Fundamentals of Game Design (Ernest Adams & Andrew Rollings : isbn 0-13-168747-6).

I hope this helps.