Game Design Document

0 favourites
From the Asset Store
Fly Bound
$2.49 USD
Design for game, asset for game, game kit, UI design, completed design for game FLY BOUND
  • For bigger projects i use a wiki. For smaller ones just a google doc and some excel sheets for tracking all the assets and animations.

  • I don't write design document. I first write down the ideas organised in to groups: Player, enemies, levels, menu etc. Then I'm choosing what to do first, and then I starting to explore possibilities and expand on basic ideas with added one to few words descriptions. I look at how elements would connect to each other, how they suppose to work etc. At some point I will start programming the part I've just worked one. Once I have it programmed, I'm moving on to next idea. And so on. Everything I plan I'm doing on A3 paper. This way I am not constrain to fixed layout of digital tools, and I can write annotations quickly, sketch basic concepts next to the plans etc. And it's nice to have it in front of me and be able to quickly go between pages while programming.

  • Even Tarantino agreas with me! :)

    http://youtu.be/u5ck9Ci0zN4

  • Yeah that's good when you're working on your own. A GDD isn't really made to remind you of your own ideas...it's so that a team has the same collective vision for the game.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • For small games, use Post it notes. It just works.

    Starting from complex games, yeah, GDDs are the way to go.

  • I'm also a huge fan of the Lost Garden "Design Log" method for small team projects, though it doesn't really scale up when you get really big team sizes.

    At my company, we designers will often make visual design docs to convey a pitch or a general idea for a feature, with the intent that it's a one page glance that can get everyone on the team on the same page about the vision for the feature, and is highly visual. They've proven to be very useful in early development.

    Even those fall out of date quickly, though, and you have to be on top of archiving and culling them. Nothing worse than a new person coming onto the team and try to catch themselves up based on outdated docs.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)