I am basically (shamelessly) copying a question that has appeared on SO few years ago. The answers are good, but I would like to get more on this topic, so I'm trying a more specialized subreddit substackexchange. What I'm secretly hoping for is an answer from Byte56, I wonder if he has wrote a spec for AoG? :)

I'm trying to write a functional spec for a game according to Joel's article series (who wouldn't love anything this genius guy writes) and I'm not happy with my current approach. It's much easier to write a functional spec for a web application, or a website (my full-time job is still web app development) where I can describe every possible screen in a separate chapter, and also scenarios are easier to come up with.

The game is a turn-based logic/puzzle game, but it's fast and fun enough to play for many audiences, so:

  • Should I write scenarios based on various gamer types (e.g. nervous FPS players, macro-obsessed strategy guys, solitaire loving housewives, etc.) and try to describe what will they expect from the game and how will they use it?
  • What should represent "screens" in the spec; the game screens (e.g. menu, loading screen, main game screen, etc.) or should I rather describe all different possible in-game situations as screens (e.g. my turn, waiting for opponent's turn, possible turns, what happens if I make a invalid move, etc.)?

Just writing this question helped me to settle my thoughts about the spec, but I'm submitting it to see if I can get any good answers from this great community.

  • 3
    \$\begingroup\$ Unfortunately, I'm not that organized. I don't have any kind of formal document. Essentially, I just have a huge TO-DO list (using Workflowy, it's nice). It's broken up into different categories (zones, gadgets, physics, combat, etc.) where I list some high level goals for that category. Under each high level goal are further sub goals and resources for helping me accomplish that goal. I don't have scenarios for various gamer types, I'm making the game I want to play! I know that without writing it down. \$\endgroup\$
    – MichaelHouse
    Apr 13 '13 at 15:16
  • 1
    \$\begingroup\$ When you take 10 different paint colors and mix them together you get a nasty gray/brown that no one likes. I'm just sayin'... =) In the meantime, your "screens" should represent both current activity and transitions to other "screens." MainMenu is a screen, the activity is traffic cop and it transitions to options or start play. StartPlay is a screen, the activity is to show pretty pictures and the transition goes to GameInProgress. etc... \$\endgroup\$ Apr 13 '13 at 16:28
  • \$\begingroup\$ Do you have a prototype? \$\endgroup\$
    – Den
    Apr 13 '13 at 17:10
  • \$\begingroup\$ The game is simple enough that I could code a prototype in a weekend. But I've had enough examples in my hobby game development, where I started coding straight away, and the game never got finished, or had too many flaws due to issues a good spec would prevent. This is also my first game I'm not making alone, but in a small team, so we decided to do it the way the "big boys" in the industry are doing it. I know many say that for a small game it's better to rather start coding than writing specs, but I'm with mr. Spolsky in this one :) \$\endgroup\$
    – Teo.sk
    Apr 13 '13 at 17:59
  • \$\begingroup\$ @Teo.sk "...but I'm with mr. Spolsky in this one..." you are with his 13.5 years old thoughts to be precise :) \$\endgroup\$
    – Den
    Apr 13 '13 at 22:42

Videogames are very different from the kind of software that Joel is talking about. In several ways.

For example, Joel talks about taking the "spec" to "the customer". Yeah, that's not how videogames work. When was the last time you heard of Shigeru Miyamoto taking a design document out to the public and asking if a feature filled their needs? Game developers don't communicate with their customers the way that software engineers communicate with people who buy their software.

It's an artistic work; when you make art, you generally don't have a lot of interplay between the maker and those who might buy it. You can, but certainly not on the level of a "functional specification".

Another problem with a "functional specification" for a game is that it is, well, inflexible. Game development is obviously functional, but it is also artistic as well. So you need to be flexible. You might think that some aspect of your game will work like X. But when you actually code it, it doesn't have the intended effect. You therefore need to be flexible in your development; you need iteration time to smooth out the play experience. And I'm not just talking about UI.

A "functional specification" doesn't help here. You have to adopt a "guess and check" methodology. Change stuff, see if it plays better, change more stuff, etc. Your development needs to be flexible.

That being said, is a "functional specification" of value in game development? To varying degrees yes. It does still have its uses as a means for communicating software development issues across a software team. And the most important task is that it makes you do is think about what you're doing before doing it.

In game development, a "functional specification" is really just a "game design document," with some exploration of the technical sides of the implementation. If you're working on a team, then it's probably important to use that as a way to get everyone on the same page.

The key thing is to not get too attached to things. Your game design document may say X, but ultimately, you must decide if X is good for your game when you try it. A design document should be a start point, not an end point.

  • \$\begingroup\$ Yes, this is a very good answer, thank you. This is also how my document is starting to come out since I asked the question, I would really rather call it a game design document. I found also a good article about game design docs (bbrathwaite.wordpress.com/2008/11/30/…) and this, plus few specific parts of Joel's advices is what I'm sticking to, and I'll keep it really simple. Thanks once again! \$\endgroup\$
    – Teo.sk
    Apr 14 '13 at 16:40

A spec doesn't prevent issues, it just creates them at a different point, but you probably still won't recognise them until the implementation.

Writing a specification only serve two purposes, helping you remember your thoughts and sharing those thoughts with your team mates.

Writing down your thoughts is not going to make them better, it may force you to think about them some more, it may make it easier for you to share those thoughts with other people, but the same thoughts don't grow any better just because they are put on paper.

Ultimately specifications in a game design process are for throwing away. First you implement them, then you know how they are wrong, then you do something different.

Write the specifications for a prototype, they won't last any longer than that, so no reason to write more than what is needed for a prototype in the first iteration.

  • \$\begingroup\$ Good observations. A fuzzy idea is fuzzy no matter how much you spec it out =) \$\endgroup\$ Apr 13 '13 at 22:28
  • \$\begingroup\$ I noticed that another answer I wrote for a completely different question may also have some relevance: gamedev.stackexchange.com/a/21851/3505 \$\endgroup\$ Apr 14 '13 at 10:39

The mere act of writing a spec will clarify, illuminate, and "make better" an idea. The first person you are attempting to communicate your idea to is yourself. "Putting it down" is the first step. A designer who thinks "it's all in my head" is only fooling themselves. Start writing it down and s/he will find out exactly how much they were fooling themselves. Docs may be a necessary evil, but they are more necessary than evil.


Not the answer you're looking for? Browse other questions tagged or ask your own question.