I want to share with you some thoughts about 4 game design "weapons" that I use every day.

I see these tools as a way to :

• Make games in an efficient way
  
• Organize and keep track of my ideas
  
• Get (visual) results as soon as possible
  
• Easily test a game
  
  Here is the link to my blog post : http://www.gameplaypassion.com/blog/4-powerful-game-development-tools/
  
  What do you think about my ideas ?
  What (other) tools do you use and how do you use them ?

What do you think about my ideas ?

Well, here are my two cents

1. GDDs are really overrated ! They are a good way for unexperienced designers to get their mind right, or to write down the basic game play for larger productions, but most of the final game will be developed during ..well.. development time.

2. Journal: very similar to the first part, it helps to write down your mind.

3. Prototyping: yes, this is a good idea

4. Cheats: they are necessary, but they are really dangereous. Using cheats is a way to avoid certain game play, the danger is, that you start testing the end-game only and negclet the start of a game. But the start of the game is the most critical part for new players.

1. GDDs are really overrated ! They are a good way for unexperienced designers to get their mind right, or to write down the basic game play for larger productions, but most of the final game will be developed during ..well.. development time.

I think any team needs some sort of "document" to keep track of their game design. The document will be enriched during the iterative process of making the game. By "document" I don't mean a big fat word document made prior to developing the game. The document can be empty in the beginning and filled along the way.

Then again, I'm a beginner in game design so I learn a lot by writing down stuff.

4. Cheats: they are necessary, but they are really dangereous. Using cheats is a way to avoid certain game play, the danger is, that you start testing the end-game only and negclet the start of a game. But the start of the game is the most critical part for new players.

I agree with you on this one, there could be a bug in the beginning of the game that you'll never see during your tests. And new players are very important because they judge a game by the first minutes of play. So testing the final product as-is is also a good idea.

A GDD is not useless, but in my opinion overrated and have not the often desired theoretically impact on the final product. Nevertheless, presenting, or even better, talking and discussion helps to clearify your own view and gives often very valuable feedback on feasibilty.

I wouldn't bother with a "fully fleshed out" GDD, but I advocate having at least a high level design mapped out. No need to go into details (the end result is ALWAYS completely different to the original formulas) but a high level design document (or scope document if you like) makes sure everyone has the same picture of what type of game you're making.

Not that I have a great deal of experience working with teams (my projects have always been solo, thus far), but it seems to me that Ashaman is right that a GDD for any realistic project is only a loose guideline. Details both large and small will change on the fly as implementors realize better ways to do something or systems are redisigned with an eye to maximize enjoyability or ease of implementation.

I prototype heavily. Sometimes I even design simple games to model the gameplay of a single part of the larger project (this has varying levels of effectiveness). If something isn't fun, it's good to identify it early before your game depends upon it.

Don't forget the pipeline. Different pipelines involves different planning. The act to design a document should be in the pipeline (and in the Gantt of the project).

GDDs are really overrated !

Daniel Cook (Spry Fox) recommends "Design Logs" to document decisions during an iterative design process.

1. GDDs are really overrated ! They are a good way for unexperienced designers to get their mind right, or to write down the basic game play for larger productions, but most of the final game will be developed during ..well.. development time.

While I am just a novice game designer (working on my first title now) I have to disagree that GDDs are overrated. They are an essential part of developing a good game as they allow the team to all have an idea of what direction the game should be heading in. Of course things will change from the original document as you prototype, test, and iterate your games, but that is exactly what the version history section of a GDD is for. It helps to show what has changed and why for the betterment of the entire team, not just the designer who "needs to get their mind right". The designer has an important job in making certain that things are heading in the right direction to ensure the game turns out like the company (be it indie or big name) wants it to. Documentation of the teams goal and the endeavors they have made in producing games is not a thing to be taken lightly.

2. Journal: very similar to the first part, it helps to write down your mind.

Agreed on this point, as a personal journal is more for the individual to look on their own ideas for reflective purposes, or to ensure they don't forget a valuable piece of information or idea.

3. Prototyping: yes, this is a good idea

Once again, agreed. Prototyping is an absolute must in the cycle of iterative design. Without consistently testing your mechanics, levels, and even looking over graphical elements you are almost guaranteed to make a sub-standard game.

4. Cheats: they are necessary, but they are really dangereous. Using cheats is a way to avoid certain game play, the danger is, that you start testing the end-game only and negclet the start of a game. But the start of the game is the most critical part for new players.

This I have to disagree with to an extent. While some cheats can be fun to play with if you just want a relaxing playthrough where you mercilessly slaughter everything in your path (God-mode) or you type in a few keystokes to earn unlimited money to build your dream city in a simulation, cheats that are put in to obviously cover up bad design should be frowned upon.

This I have to disagree with to an extent. While some cheats can be fun to play with if you just want a relaxing playthrough where you mercilessly slaughter everything in your path (God-mode) or you type in a few keystokes to earn unlimited money to build your dream city in a simulation, cheats that are put in to obviously cover up bad design should be frowned upon.

Cheats can be a useful tool, not necessarily for the benefit of players, but during testing and balancing of your game. Say for example you want to test that a certain trigger is working correctly, but it's in an area with a lot of powerful enemies -- rather than having to deal with the enemies you simply activate God mode and perform your test.