Treatment Writing Pt II


Published on

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Treatment Writing Pt II

  1. 1. Treatment Writing<br />3 March 2010<br />
  2. 2. What is a Treatment?<br />But what about games?<br />
  3. 3. Treatment Dos and Don’ts<br />5. In addition to the prose and the occasional list, game designs often also need to use other sorts of ways of conveying information (depending on the need). <br />a. Tables - sometimes the best way to provide info is by means of a grid or table. <br />
  4. 4. Treatment Dos and Don’ts<br />b. Pictures with callouts - an old Japanese proverb says it best. "Hearing 100 times is not as good as seeing once." (In our case, substitute "reading" for "hearing.") Some folks pepper their designs with tons of pictures but with minimal text and no callouts! Gotta use all the tools at your disposal. Show what the screen looks like during your game, and use callouts to point out the interface icons. <br />
  5. 5. Treatment Dos and Don’ts<br />c. Flow Diagrams - flowcharts can be an effective tool for communicating with the programmer who will code your game, or for illustrating the overall structure of the game. Here's a flowchart I made to illustrate how flowcharts work. This one shows how a simple old arcade game (or Atari 2600 game) might work. It is vastly over-simplified and is just here to illustrate the concept of flowcharts as applied to games.<br />
  6. 6. Treatment Dos and Don’ts<br />6. Here are a few basic rules to keep in mind:<br />a. Games should be "Easy to learn, difficult to master." (That one rule is very broad and encompasses a number of smaller "rules" I don't have time to go into here.) Another way to say something kind of similar [but not exactly] is: "Simple but deep." <br />b. Games should be Fair, Intuitive, Fun, and Accessible. <br />You probably already know what "fair" and "intuitive" and "fun" mean, but you might be wondering what I mean by "accessible." In a nutshell, that means that the game's subject matter is something that the game playing public already knows and loves, or at least will "get" very quickly after seeing it. If the game is about some weird far-out theme that the public can't “brap" within 30 seconds at most, then the game is "inaccessible" - it's beyond their reach, and they won't buy it. <br />
  7. 7. Treatment Dos and Don’ts<br />c. The user interface should be consistent with standard usage. If your game uses the left index-finger trigger to make the character jump, then everybody's going to just get frustrated with your game. (Everybody knows the jump button should be the A or B button!) Players have become familiar with a "standard language" of games. Don't start speaking Klingon. <br />d. Strike a balance between user-friendliness vs. control. The more control you give the player, the more complexity you burden the player with. Remember rule #1 above. <br />
  8. 8. Activity<br />Look at a game you know – work in pairs please. Assess what the UI (User Interface) is actually about. Ask yourselves the following questions:<br />Does it work?<br /> Is it user friendly?<br />Does it feature highly in the game?<br />What is wrong with it? Or, how could it be improved?<br />
  9. 9. Treatment Dos and Don’ts<br />e. Keep in mind the difference between Videogames vs. Computer games. Videogames are typically played in the living room, den, or kid's bedroom - by younger players interested in action more than emotion or intellect. Computer games are typically played in the home office or the, um, office-office - by older players who may appreciate games that have more than just action, action, action in them. Also consider multi-player. For videogames the players usually have their own controller but have to share a TV. For computer games the players either have to share the keyboard and mouse (if both sitting at the same computer) or they can each have their own system entirely (if playing networked). And of course, network play is likely to become more common for videogame systems as time goes on - but I dread the image of all those telephone wires having to snake across the living room between the TV and the phone jack. <br />Consider your audience, always.<br />
  10. 10. Treatment Dos and Don’ts<br />f. "It is better to do three things well than five things poorly." - Nathan Mates. <br />What he means by this is that simple designs are often better than complex designs. Quality is more important than a long feature list. Mates, a programmer who has to implement the brilliant creations of designers, says: 'Concentrate on getting what you've got (now) working well. Then, and only then, think about expanding. Saying "more" is often a cheap and easy design "decision" that's about as useful (and appealing) as tossing a can of concentrated orange juice into a swimming pool because "more is better." It ain't. "More" and "better" are independent variables, or loosely linked at best.' <br />More or better? You decide!<br />
  11. 11. Treatment Dos and Don’ts<br />g. The Inverted Pyramid. This is a practice begun by news reporters during the American Civil War. Reporters sending news by telegraph (a cutting-edge technology back then) knew that the line could be cut before they were finished sending, so they started by giving the most important points first, then expanding on that, and finishing off with the least important parts. This principle is still used today in newspapers, and it applies to game designs as well. Put the important concepts and the exciting stuff first, and put the boring details at the back end of your design documents and treatments. <br />
  12. 12. Activity<br />Write an inverted pyramid for Killzone 2.<br />(If you haven’t played it – write the pyramid with someone who has)<br />
  13. 13. Treatment Dos and Don’ts<br />h. Communicate clearly, and put yourself in the place of the reader. You see the game in your mind's eye, but the readers can't, unless you explain it very succinctly.<br />As you are writing, if any sentence you've written raises a question in the mind of the reader, you need to answer that question either in that very sentence or at least in the next one. <br />
  14. 14. Activity<br />1. Describe it<br />2. Scribe it!<br />Get into pairs! Sit back to back, or use blindfolds...<br />
  15. 15. Treatment Dos and Don’ts<br />i. Pictures are worth thousands of words. Diagrams, illustrations, charts, and tables are very illustrative. The use of words is unavoidable, but the dev team will greatly appreciate being shown how it works as opposed to having to read a telephone book. Try to keep your prose short and to the point, without leaving anything unexplained. <br />j. All rules are made to be broken -- even this one. You can even try making a game that breaks them all (but then, of course, it wouldn't be breaking this one). The trick is to know when to break which rule. But when a game can be interesting WITHOUT breaking any rules, then you've really got something! <br />k. Write a one-sentence description of your game. Write a one-paragraph description of your game. Write a 45-second "elevator pitch" describing your game. These three exercises are very important - they force you to distil the game's key features down to their essence. <br />Taglines a go-go!<br />