5
\$\begingroup\$

Yes so this is a question more oriented towards the planning / project part of game development. What software do you use to plan your game, I am talking about visual stuff like a mindmap application for making some neat diagrams and so on, sort of like database design only it's for the game instead, is there any good ones?

Thanks

\$\endgroup\$

5 Answers 5

3
\$\begingroup\$

Freeplane is an awesome fork of Freemind, but you may also like VUE.

For me, the best tools for game design have always been a pencil and graph paper. Then Google Docs or a wiki to disseminate information throughout the team. Google Groups is useful as well.

\$\endgroup\$
1
  • \$\begingroup\$ VUE was exactly the thing I was looking for, thanks a bunch! I tried freemind but did not like how it arranges nodes, VUE is awesome! \$\endgroup\$
    – user5150
    Feb 4, 2011 at 14:31
4
\$\begingroup\$

When I was at EA, we used some mindmapping software especially during meetings. Design docs were mostly done in Word, although the company has moved to doing most of that in Mediawiki now. Personally, I think wikis are a great fit for game design:

  1. They're non-linear and easily cross-linked.
  2. They support images inline.
  3. Content is easy to edit by many people (since designs change often).
  4. Anyone can view the docs with just a browser.
  5. A history of changes is stored with every page.
\$\endgroup\$
1
  • 2
    \$\begingroup\$ An additional wiki benefit is that they can also be easily cross-linked to future projects as well; this encourages creating reusable systems and content! \$\endgroup\$
    – Bill
    Feb 4, 2011 at 2:28
2
\$\begingroup\$

The most important element in game planning is a good design document. The typical example is Chris Taylor's game design document. Also check out this question: "Design Document Contents"

Also for the technology involved in storing and editing documents and team management, check out "What type of document for game design?"

\$\endgroup\$
4
  • \$\begingroup\$ That Chris Taylor example is great. \$\endgroup\$ Feb 3, 2011 at 20:37
  • \$\begingroup\$ It is, there is also the design doc to Total Annihilation floating around somewhere I think. In fact this sample design doc might be based on that. \$\endgroup\$
    – Ricket
    Feb 3, 2011 at 21:58
  • \$\begingroup\$ The poster is pretty clear about asking for visualization apps rather than a simple doc. Chris Taylor's has been floating around forever and it's a solid example of the basics of documenting your game design, but I don't think it properly addresses the question here. \$\endgroup\$
    – Bill
    Feb 3, 2011 at 22:20
  • \$\begingroup\$ Schematic diagram is to database design, as design doc is to game design. Nowhere in the question was it mentioned that sqa was looking for something more than a design doc; rather I got the impression that sqa was not aware of the concept of a design doc and was trying to find the equivalent of a database diagram for game design. If this question is not useful then he/she can accept a different one or even downvote it if I did something wrong. \$\endgroup\$
    – Ricket
    Feb 3, 2011 at 23:15
0
\$\begingroup\$

Nothing too exciting:

  • Word Docs for initial outline
  • Powerpoint to flesh out the pitch and get people excited
  • Transition to Wiki once getting into actual prototyping. Wiki's are great for splitting up design tasks among several designers, showing how mechanics cross link and giving the rest of the team and easily sorted and searchable database of what should be in the game.
  • Continue with focused powerpoints for mechanics when needed. Lots of people are visual learners and I've found you can just communicate ideas more quickly this way.
  • Post-it notes and a big section of wall somewhere for doing scoping and auditing exercises.

NOTE

Wiki's don't police themselves and can get out of control or just die if you don't have at least one resident Nazi who keeps the whole look & quality consistent. Build out templates for content pages and stick to them. For information that changes regularly (like tuning numbers), put it in source control and just link to it from the page. Keep all other information in the Wiki.

\$\endgroup\$
0
\$\begingroup\$

My personal workflow is as follows:

  • A Google text document to capture the initial set of ideas under a meaningful title.
  • Later, I'd move those ideas into a mind-map to start organising and building upon them.
  • Then, I just keep a To-Do list of tasks necessary to complete the project.
  • I might draw out complicated systems as UML, although I've never been happy with any of the tools for that so I tend to use pencil and paper.

That works for me as a lone developer. When working in a team we had good results when working with a Wiki for the design (my preference was DokuWiki but there may be something better, eg. Confluence) and issue and task tracking software for tasks (again, we used JIRA but you can get by with Bugzilla, Trac, Redmine, etc)

\$\endgroup\$

You must log in to answer this question.