Hi everyone, I am working on a web game that revolves around managing your own professional wrestler and having matches against other players. My first version of the game was created during a project at the college where I am currently studying. However, after the project was turned in, I was not satisfied with the breadth of the game along with the fact that I didn't design the web pages on my own (I used a template). As such, I decided to scrap my then-current version and begin creating a new one. Now, I have all these ideas about how the game is going to function, but the problem is that I feel sort of suffocated by the weight of all the ideas. There is just too much stuff that I want in the game to keep in my head, and if I try to document a game plan, it just becomes really disorganized and chaotic. It just bogs the whole development work down, and I end up thinking about scrapping the whole thing. And another thing is, that when I started working on the game as part of the school project, it was fun trying out new functions and watching the game grow. Now, when my ambition is to create the entire game with all the functions on my wishlist at once, it's not fun anymore. So my questions are: What general steps should I take when creating my own web game? Should I start with the barest essentials of the game and then add functions as I go? Or should I create a complete game plan first that covers everything I want in my game, and then start implementing the game? How do you think I should go about this project? All answers are truly appreciated!

The data model perhaps could come first. Assuming you know fundamental SQL and the first 3 rules of database normalization, you should be able to come up with something adequate.

This should give you a good overview of the functionality that you've come up with already. Add on as desired.

A good idea is to come up with a use-case scenario, where you begin documenting the system by how the user would interact with the application. ie: What do they perform in order to do task X at screen Y?

From there you should have a very compartmentalized and linear view of the application, making it just like a Lego set in a way. :)

This compartmentalized model also makes for very easy unit testing.

Blabber: It reminds me of the fractal geometry behind L-Systems, because this design view can be imagined as tree-shaped in one's mind. Also, not far from the "choose your own adventure" books from the 1980s. Cheers Stevey.

I will definitely try both suggested models. Hopefully they will allow me to see the big picture of the application more clearly.
I should mention that the single biggest problem that I have right now is figuring out an algorithm for simulating a match as realistically as possible. I also gather not knowing the algorithm also means not fully knowing what data will be needed, which is frustrating.

VS SCREEN
- User is shown the final VS. information screen. Screen contains only a large "Go" button, which when clicked proceeds to the MATCH BEGIN SCREEN.

MATCH BEGIN SCREEN
- Player stats are placed on either side of the UI.
- A wrestling ring image is superimposed using DHTML with PNG transparent images of the wrestlers.
- A random number is generated to determine who goes first. The concept of initiative may be useful here.
- Upon turn, a wrestling move menu appears (again PNG transparent image using DHTML).
...

I was thinking more along the lines of automatic generation of matches (though your idea is quite intriguing) rather than manual. This would mean that both players involved in a match wouldn't have to be logged in at the same time (á la Utopia) for the match to take place. It is the automated generation of match events that is really bugging me at the moment.