It’s been a long time since Story Trick #2 and this time it not about a trick in any specific movie but more about the lessons learned from April’s Script Frenzy.
So, that was 30 days of script writing, and what did I learn from that (apart from being able to write a first draft feature length screenplay in less than 30 days while holding down a full time job and being a caring family man)?
One thing: Outline. Outline. Outline…. and… outline.
I know that many big time screenwriter and directors don’t outline at all. The Coen brothers have said in numerous interviews that they never outline, but for the rest of us, I truly believe that outlining is the way to go.
When I sat down the work out the storyline for my script Downfall I looked at what the “masters” of screenwriting said about structuring the story.
Listed below are the fundamental structure I’ve complied from all of these and for me at least it worked really well and always kept my writing on track and moving forward.
(Please note: The beats below are structured after a 100 pages script. If you plan to write a short script just take the page number and divided by 100, e.g. point of no return on page 50 is 50% of the script lenght).
The beats:
Page 1: Opening Scene: Setting up the main character. Hard to do, but just think of what you want to viewer to see first when sitting down to watch your film.
From page 1-10: Setting up the story: All the main characters (protagonist, antagonist, supporting characters etc.) are introduced here. The audience must know or at least have some basic idea of what kind of people they are.
Page 10: The 1st Turning Point: Something happens here that give the story a completely new direction. Someone dies, wins the lottery, the aliens attack, the long lost father returns home… you get the idea. This is the thing that sets the entire story in motion. Up until now we where just getting to know the characters, now the real story starts.
Page 10-25: The new situation: Okay, so something happened on page 10 and now everything is up in the air. What should the protagonist do? What is it all about? Should our hero embark on a journey to solve this new situation or should he/she just do nothing? Try to write down reasons to go and reasons to stay, and work with this conflict.
Page 25: The 2nd Turning Point (sometimes also called the Plot Point 1, but it’s the same thing): The start of Act 2 is all about going into the great unknown. The situation that started on page 10 is now going to be dealt with. The plans that the hero had for his/her situation in page 1-10 is now being changed completely. Some talk about going from the Ordinary World to the Special World.
Page 30: If you have a subplot (you don’t always need one) now is the time to introduce it. Be it a love story or something.
Page 25-50: First half of Act 2: The situation develops and the hero is slowly but surely moving forward in a positive way toward solving the situation.
Page 37: The symbolic scene: This is where the main character really commits to the journey. The audience might have known for a long time that this was the case, but this is where the main character expresses it clearly in some way, like taking charge of the search & rescue team. Can be very dramatic or almost unnoticeable.
Page 50: The 3rd Turning Point: The Point of No Return: This is where things can’t get any worse or any better depending on your story. The journey is almost over and the end is clearly in sight. Maybe the hardest part of the screenplay to nail completely, and also one of (if not the) most important points in the structure of the story.
Page 50-75: The 2nd half of Act 2: The plot thickens: The antagonist return. The antagonist has already been very much present in the story, but now the “attacks” becomes more frequent and clear. The complications and the stakes involved in the journey increases very much. Before the life of the protagonist maybe wasn’t at stake but not it most certainly is.
Page 65: The moment of regret: Maybe taking on this journey was a bad idea after all. Maybe we should just all go back. It’s not working out anyway. The hero of some of the supporting characters clearly states that they feel bad about doing what they are doing. Maybe we should just do what the antagonist wants us to do?
Page 75: The 4th Turning Point (also called Plot Point 2): All is lost. Major setback. One of the dear supporting characters dies, or the lovers are separated for good (it would seem), etc. The main characters are ready to give up. This is rock bottom it can’t get any worse than this so why even continue.
Page 75-100: Act 3: The race against time to finish the journey. The part where the protagonist solve the main conflict.
Page 85: The aha moment: “So this is how it works!” Aha. This one is not always used but good to get the third act some momentum. Could also be used to introduces a time-lock: They must get out of the building before the bomb explodes in 5 minutes, etc.
Page 85-100: The final push. All or nothing. Part of the third act where the main characters give all they have to complete the journey. Often the hero must face three tests that becomes more and more difficult in order to continue.
Page 9x: The 5th Turning Point: The Climax: Somewhere between page 90 and 99 the conflict is resolved. The antagonist is neutralized. The protagonist made it. The lovers reunite. The maniacl killer is captured
Page 9x-100: The aftermath: Use these pages to show the protagonist riding out into the sunset or whatever suits the story. Tie up any loose ends.
There you have it, 17 beats that make up more or less a typical movie. Use them at will; many really good movies (and Oscar winners) did not use them, not even close. But when you’re, like me, still new at this game, they help a lot more than hinders your story.
Gilroy both wrote and directed this film, which marks his debut as a director, but certainly not as screenwriter. Some of his other credits include the Bourne Trilogy, as well as Armageddon, and Dolores Claiborne.
In short, Tilda Swinton plays Karen Crowder, the top legal adviser to U/North a gigantic chemical fertilizing company.
Just before act two starts she’s about the give an interview on camera to be used in some internal marketing.
We start of by seeing her sitting in front of the camera crew and the interviewer with one of the senior partners at her side. She delivers a very thoughtful and serious answer to the interviewer’s first question and seems extremely confident and on top of the situation.
But after the first question is answered, we start to cut back and forth between the ongoing interview and her rehearsing in her room 30 minutes or so before. In the comfort of her private space she just the opposite; she’s nervous and fumbles with the words while she’s trying to find the right answers to the prepared questions.
The trick is that not only do we get a lot of exposition details about Karen Crowder, about her being a work alcoholic and very much theyoung rising star as the in-house legal adviser, but we also see her as a fragile and somewhat emotional unstable woman that is working very hard to keep her facade intact.
It’s a superb trick by Gilroy. In just over two pages, Gilroy manages not only to introduce Karen and sketch out her background, but also to show both her personalities; her calm collected professional one and her fragile and unstable personal one. Something that proves to be a vital clue for events later in the story.
Today I’m going to commence a feature on this weblog called Story Tricks. I don’t know how often I’ll post these Story Tricks but hopefully they’ll become a fixed feature.
The idea came to me after I watched David Cronenberg’s excellent “Eastern Promises” last night. The script is written by Steven Knight and he utilizes a very simple and very subtle trick that, for me at least, was brilliant in keeping the suspense going in the first part of the film.
The protagonist, Anna (Naomi Watts) is a midwife at a hospital in London and one day a young girl dies in her ward while giving birth to a baby girl. The young woman is unknown but she did carry a diary with her. The problem is that the diary is written in Russian.
Although Anna herself is Russian she can’t read the language and therefore she asks her uncle Stepan to translate it for her. He abruptly refuses as he finds it highly immoral and utters “Do you always rob the bodies of the dead?”.
So Anna must find another way to translate the diary in order to find the relatives of the unknown young girl and hand over the baby to them. Inserted into the diary is a card of the restaurant owned by Semyon (Armin Mueller-Stahl). Going there she meets Kirill and Nikolai and becomes clear that this restaurant is a meeting place for Russian gangsters in London.
Anna don’t know exactly why, but Semyon seems like a bad man. There is just something about him that’s off, maybe it’s because he’s too direct in offering to help Annie. On the other hand he seems like a very likable grandpa-kind-of-person and is very polite and forthcoming toward Anna and her request for a translation.
And here comes the trick. We as the viewer know that Semyon is bad and that the diary very likely contains information that he normally would have people killed for. The issue is then if Anna can trust Semyon to do a real translation or if he’s going to lie to her.
Parallel to this Anna keeps pushing her uncle to do the translation and he keeps refusing.
This subtle trick creates an enormous tension and suspense in the story, and we sit watching this part of the film on the edge of our seats hoping that uncle Stepan will come to his senses and help Anna so that she can get far away from Semyon. Even though this conflict is resolved in another way it moves the story forward in a very effective way.
I could easily imagine an entire movie centered on this; someone finds a book or scripture and has to get it translated. Unfortunately the person(s) he approaches with this task is someone whom stands to lose a lot if the knowledge in this book is to become publicly known. It’s simple trick and used many times before but it works very well.
I also highly recommend reading Steven Knight’s entire screenplay that Focus Features have so kindly made available online in this award season.
When people find out that I’m “into movies” it doesn’t take long before this question pops up: “okay okay… so what’s your favorite movie of all time? No, no, let me put that in another way; if you could take only three movies with you on a desert island, what would they be?”.
Then I look like I’m thinking really really hard even though I have the answer ready beforehand. I go something like this: “hmmm… that’s really hard to pinpoint only a few movies. There are so many that I like. But if I have to choose only three movie it would be; After Hours and XX and YY”.
I then replace XX and YY with some movies that would please the crowd so to speak, be that anyone of the 9 or 10 stared movies from the movie page.
Then they go something like this: “Wow, man that is so totally rad! I love XX and YY, they’re the best movies EVAR made… but what was that first movie again? ‘After’ what? ‘After Hours’?… Never heard of it.”
I truly think it’s one of the most overlooked film of all time. It’s it without a doubt Scorsese’s most overlooked. It dark and sad and funny and heart wrenching and because of all this, very realistic. And it all takes place in one single night.
I’ve seen many compare the movie as a modern day Wizard of Oz or an urban Alice in Wonderland, where it is Paul that goes through the rabbit hole and enters then land of weird. It’s like a 10-min Groundhog Day that brings one man’s world to its knees, and he sure as hell isn’t in Kansas anymore.
And the “funny” thing about the movie is no matter how absurd it becomes, and it really does become very absurd, you always view the scenes and say “man that could happen to me” or “I know a person just like that”. That’s the brilliance of the story, it so absurd that it in a way becomes very realistic and close to home, because that’s what life is. Absurd.
The trailer below is full of spoilers so don’t watch it you haven’t seen the film already.
The story is basically about about Paul who meets a girl in a coffee shop after work and everything goes does south after that. Wikipedia has a very long and very good summery of the plot (that is also full of spoilers).
There are so many scenes in the movie that are worth showing but this one is really telling of the overall premise of the film:
On YouTube there are also a 2-part documentary about the making of the movie.
Part 1:2
Part 2:2
On researching for this post I found this quote on Wikipedia:
The film was originally to be directed by Tim Burton, but Scorsese read the script at a time when he was unable to get financial backing to complete The Last Temptation of Christ, and Burton gladly stepped aside when Scorsese expressed interest in directing.
Very interesting. I can’t seem to figure if it would have been a different movie if Burton was helming it. Visually and all it most certainly would have, but in my view the story is so strong that I think it would have remained more or less untouched. But that is just thinking about things that never happened and never will.
What remains is my favorite movie of all time. So now you know.
I have just finished the first draft of my first screenplay.
Yes, I am indeed very proud of myself. It is very satisfying to finally to write FADE OUT. THE END.
It has been a rather long process and it have taking me around 8 weeks to write the 49 pages that the script ended up on. But I take it as much as a learning experience and it has never been the aim to produce a full-length script in the first try.
This last week or two, I have had some serious writer’s block and I tried many different approaches to battle this. The only one that seems to be working is; writing. Just writing. Writing crap and then some more crap. It is extremely difficult, but I really found that writing is the only medicine. It actually helped me to read the crap I have written and then say “man that’s bad. I can do a lot better than that!” It might sound strange but this last day I wrote almost 10 pages in one sitting and I believe that was only possible because I have kept writing the whole time.
Another great tip I found very useful was Hemmingway’s (at least I think it was Hemmingway) way of ending your day of writing in the middle of a sentence or a scene. You do it even though you know perfectly well how it ends. That way when you sit down that the computer or typewriter the next day you know what to write. You just finish that sentence or that scene and then continue. That way you always “hit the ground running” and never have to face the dreaded Blank Page.
Oh, the story. Yes, I am getting a bit ahead of myself here. It is actually an adaptation of one of Bram Stoker‘s short stories called The Judge’s House. It is a 12-page (give or take) short story and I have taken many liberties with the source material. It started out as being very close to the original. The outline process also produced a script that was very close to Stoker’s original text, but as the writing progressed, I took more and more liberties with the story. Both because I have moved the story to present day but also because there are many fundamental differences between a short story and a screenplay. I have introduced some other characters and removed others. Overall, it, at least in my view, plays better as a screenplay this way.
I will not publish the screenplay yet, as I fell that it clearly needs at least one or two thorough rewrites before anyone else than myself will be able to understand and appreciate the story. There are many scenes that I am very proud of and a lot of the dialog that is very good, but there are most certainly also some that is very close to the worst writing I have ever produced.
The next draft of the script will also be more in the agreed length of a feature film: 90-120 pages.
I have use the great open source editor Celtx to write the script. However, even though it is great, and free, it has some bugs and missing features that are rather annoying. And in one of my attempts to battle the before mentioned writer’s block I downloaded a trial version of Movie Magic Screenwriter and was very impressed. Therefore, I promised myself that when I finished this first draft I would shell out for the full version as a reward.
So this is this time of the year to look back at what happened this year. So these are (some of) the highlights;
I finished my third education and finally got my master thesis
I spent some time looking for work and was very picky about the job that I settled for
I did not discover any superpowers this year, but the year isn’t over yet. Apparently I can sleep through hours and hoursof fireworks being blown up just outside my window. How about that for a superpower; “Super sleeper”.
I thought long and hard about what I what I want to do when I grow up, but haven’t figured it out yet
I’ve stopped blogging. No really, I stopped, and then I started to tumbleloging (yes that is a word). Done writing on this weblog? Did I really say that? Oh, I meant I’m done writing on this weblog for some time, not forever.
It is very likely, as in very very likely, that I’ll restart this weblog under some new domain name and with a new focus. Stay tuned for more.
… The main reason being that the focus or the lack thereof of this blog is now and have always been a bit off. The other major reason is that my WordPress installation is now so bugged down by a very disordered mySQL DB and other various artifacts left behind by years of trying out The New New WordPress Plugin(TM)
I’ve regained my lifelong love for movies. So much so that I’ve started to write a screenplay in my spare time
… which is not only great, it might very well be the best thing I’ve done in years. I’m enjoying it so much that if I could, I would do it for a living.
… that is both watching movie and writing screenplays I’m speaking of.
… hmmm… that might be what I’m gonna do when I’m grown up
I’ve participated in NaNoWriMo this November. Did not complete the novel but it really got me started in writing again.
… one of the reasons why (there are many, and yes they are all very good and valid) might be that I found out about the website and the competition two days before it started and really had no idea what my story was going to be about. So I just plunged into it, but I did manage to write over 5.000 words.
I’m looking very much forward to Script Frenzy which will take place in April 2008. And this time I’m gonna be prepared. Totally.
Hm, that’s about it. Oh yeah, one last thing: work is…
I’ve been blogging on this weblog for 7 years. I guess that in internet years that’s well over 100 years. That’s a long time… a very long time. Most people hadn’t even heard of weblogs when I started out and now everyone and their grandmother has one (which is a good thing).
A lot of things have happened for me in the past 7 years. And most of it I’ve blogged about. I’ve become married to my wonderful girlfriend and she has given me the greatest gift of life a beautiful, smart and loving son. I’ve taken threedifferenteducations, and I’ve just landed a dream job which I’m looking very much forward to. I’ve had my 15 kb of internet fame and at one time had around 100 returning visitors to this site. I’ve meet some really cool people online as a direct result of this weblog and have had the distinguish pleasure of meeting some of them in real life as well. I truly feel that I’ve been part of some unique and grandeur.
But now I fell that it is time to move on. I’ll still very much be online, I, now as always, believe that the internet is the single greatest human achievement in modern time and I still very much want to be a part of that, but I fell that my blogging times are over and the “urge to blog”-energy that used to flow in my veins is no longer there.
This weblog will remain “open” and it will still be possible to comment on all the post and I still answer them as always, there will just not be any new ones.
This post turned out much mellower than I intended. Blogging has for me always been fun and still is, it’s just that I currently don’t have to time or the incentive to post and when that happens it’s better to stop entirely and simply to shuffle along (as this blog as been doing for some time).
I might return to blogging sometime in the future, then again I might not. I really feel that this is a done chapter for me. So until next time… Here’s looking at you, kid.
Update:
I now have a tumblr site that I try to keep a decent flow to. Really couldn’t leave this alone anyway. How about that.
Two years ago my son was born. It is really hard to fathom that it’s been two years already. He’s grown from the smallest thing to a full-grown boy with a (very) strong appetite for life.
He clever, funny, extremely fast learner, but I guess that all parents say that about their children. I just know that in the case of Carl is all true.
I can’t remember who said that having kids is just like having drunken midgets running around your house. I couldn’t agree more.
This is my master thesis that I wrote together with Bo Behrmann Jensen, Frank Wisnes and Thorvald Kingbo at IO Interactive during our stay at the company from August 2006 to March 2007. In it we present our own game development method called EVE, which stands for Experimentation, Visualization and Evaluation.
The following section is taken directly from the thesis. For the theoretical foundation that this method is based on please refer to the thesis in the link above.
The EVE Method
So far we have been looking at existing development methods in several different fields. We have discussed software engineering, innovation and game design theory in relation to game development. We also had a look at post mortem articles from game productions, and went on to identify some of the problems game productions are currently facing. In doing so, we found that the single largest source of problems is the pre-production phase and the process of verifying new ideas. This is where our method comes in. We want to give developers a set of tools to help them refine their ideas for game mechanics, a framework which at the end of the day makes the end product better and production run smoother. A small change in the beginning of the project can be all it takes, and in this chapter we will look at one way of making this change. We have called our method EVE: Experimentation, Visualization and Evaluation.
One of the main goals of our method is knowledge gathering. The more you know about an idea the better your decisions will be, and we believe in a hands on approach. In part, this knowledge gathering is done through early experimentation. The idea behind early experimentation is to look at an idea from different angles and through a refinement process of trial and error give the designers a better understanding of their own ideas. This can help reveal flaws in the design at an early stage of the process, saving considerable work compared to discovering them later on. Assuming that the initial idea is perfect is a high risk business, and experimentation helps reducing this risk. For this reason, creating a safe setting in which mistakes can be turned into cheap and valuable lessons is the first step towards implementing the EVE method.
Once that mindset is in place, it is time to start visualizing your ideas. While every idea usually starts on a piece of paper the written word will only take you so far. Nobody would even consider starting a game production without first making some concept art and the same should be true for prototyping game mechanics. That is why we suggest making lightweight prototypes as a way of giving designers an idea of how their ideas will feel when implemented in the game. A playable prototype makes it much easier to convey the idea to the rest of the development team, and the process of creating prototypes also gives the designers a better understanding of their own ideas. In addition, a playable prototype makes evaluation possible.
By evaluation we mean that constantly evaluating your own work as well as getting evaluation from others. By creating prototypes and experimenting with different solution, the designers create something tangible for them-selves and their team. Simply playing around with your own prototype can expose weaknesses in the design, and having other developers from the team try them can further help with this process. Another goal of EVE is to create a feedback loop for new ideas, where feedback is given as soon as possible so it can be taken into consideration. We have seen from post mortems that many developers went 6 months or maybe even a year into production before they had something playable up and running. We want to turn this trend completely around.
This method is designed for testing out new ideas, whether that happens in the pre-production or during the production. The thing to remember is that it is possible to evaluate elements of the game before the game is completely finished, and even before the design is finalized. The kind of prototypes we suggest can be everything from different colored dots moving around on the screen, testing A.I. behavior, to a fully functional inventory system implemented in the engine. As long as the process from idea to playable prototype is fast, the tools used to build the prototype does not matter. In pre-production the engine which will be used for the finale game might not be available or sufficiently understood, and in those cases it is better to use an existing engine to illustrate the different mechanics. Later in the process when a skeleton of the game is up and running, making something in the engine might be just as easy as using a different tool. As long as the prototype can be made in a few days, the tools used for making it are irrelevant. But there is one important point to remember; prototype code should not be reused in the final code.
If you are taking the time to make your prototype code of publishable quality, chances are you are wasting your time. This is the arena for hack solutions, shortcuts and dirty fixes. The goal here is quickly make something you can use to illustrate your game mechanics, not something you can copy-paste into the latest build. There is an additional pitfall here; the more time you spend polishing your prototype, the less likely you are to trash it if it turns out not to work. This concept scales perfectly: throwing away two days of work is easier then throwing away two weeks’ worth of work. Nobody wants to throw away half a year worth of work, and that is what our method is trying to save developers from doing.
However, some game genres will benefit more from this approach than others. For instance, strong story based genres like the adventure game will benefit less from this approach, yet it could be used to test mini-games and the usability of the interface. EVE is a method for testing new concepts and ideas for game mechanics, if a game’s main selling points are graphics and story there is less to be gained from using this approach.
In the following section we will try to elaborate and clarify what the three stages of the EVE method involves. EVE is more a mindset than a list of tools that are directly applicable in a game development. Lastly we will exemplify the method through a story which should give an idea of how to use the method in a more practical approach.
Experimentation
Failure is an option – the possibility of failure is something which every project has to deal with. Schedules, models, specifications etc. are all tools to minimize the risk of failure. However, precise as these may be it is still impossible to predict every situation that can occur in a production. The best way to prevent these situations in a production is to have tried them before doing it for real. So how do we do that? We suggest a way of working were you test the essential and cost expensive parts before you go into full production. By doing it in a much smaller scale it becomes less risky and more manageable to make errors. To cancel a project in full production can lead to economical disaster, so to testing the vital parts of a production in an environment which is both cheap and allows failure might end up saving the company a lot of money.
One thing is to be aware of failure; another thing is to embrace it. The essence of a preproduction phase is to test all the crazy ideas in an environment where failing miserably are indeed an option. To embrace failure in preproduction is to be financially responsible for the much more expensive production that follows. If you can weed out all the bad ideas by testing them in a cheaper preproduction you will save the effort and money when 50 people depends on your work in a later stage of the production.
Exploration as a design tool – it takes a thousand bad ideas to find a good one and to explore the bad ideas will help you understand the good ones. Exploration is easier said than done – it requires a lot of discipline and creativity to explore alternative solution to a problem you already solved. To explore different solutions is like searching for a proof of concept. You might find the perfect solution or you might not, but no matter the outcome the time spent should give you more information and by doing so increase your chances of making the right decision.
Set-based design is a way of thinking where the explorative element is an on-going process. You keep developing multiple prototypes of the same ideas were the one which fits the overall design best will be the one used. This way of working ensures that you always have a game composed of elements which work together as one unit. If something ceases to work in the context of the game it can simply be replaced by another element which have been tested and evaluated by means of prototyping. To try many possibilities without any prejudices is the key element when working exploratively.
Visualization
Playing is believing – one picture says more than a thousand words, which is the concept of visualization. Computer games are not something you can easily imagine or explain. You have to try it and in order to do so you have to build it or parts of it. What might seem fun on paper can turn out to be tedious when playing it. Our intention is to introduce the tangible element in game development as soon as possible through the concept of lightweight prototypes. The use of these makes it possible to clarify by means of playing if and how an idea works in relation to the overall vision. They act as a small confirmation test from which you can draw information on whether or not the idea is worth pursuing.
Lightweight prototypes does not mean first playable – the term prototype is used in many situations throughout the game industry and have different meanings. However where these often represent a bigger fraction of the finale game, a lightweight prototype is made to illustrate the smallest parts of a game – game mechanics. Prototypes such as first playable, vertical slice, alpha, etc. are all an important part of a game development, however they serve a different purpose than a lightweight prototype and when compared the amount of time and resources spent separates them clearly from lightweight prototypes.
The production timeframe of a lightweight prototype should be no more than a few days, even hours if possible, since the idea is simply to gain enough knowledge about the idea to be able to make a sound judgment regarding the future of it.
Keep it simple – lightweight prototypes are not just a way of working but also a way of thinking. It is easy to make things more complex, but the point of making a lightweight prototype is to illustrate the basic idea. The urge for doing beautiful graphics, animations, story etc. must be downscaled, since you only risk wasting valuable time at this point. That does not mean you should exclude everything that makes a prototype look great – of course not. However, looks or other features must never be prioritized over the game mechanics. If an idea cannot stand on its own without cool graphics or impressive sounds, it probably is not such a good idea anyway.
Single out the key elements – What is the core of your game? What do you want the player to experience? Why is this element important for the game? These are all questions which can help you find the core of your game – the game mechanics. Before the prototyping phase can start a clear understanding of what these are must be in place. The use of keywords, brainstorming and “the six thinking hats” method are all ways of working which can help you find and understand the game mechanics. If you end up with multiple game mechanics – which will probably happen – prioritize them after level of importance and use this as a starting point for the visualization phase.
When doing lightweight prototypes, keep the scope at a manageable size. Each game mechanic should get its own set of prototypes, and trying to prototype several mechanics at once will risk clouding the output. It is easier to test the idea if the variables are kept to a minimum. Make many small prototypes instead and test them individually. This should give a much clearer view of which ideas that could work in a final game and which ones should be scrapped, and once tested the good prototypes can always be combined later for further testing.
Abstract prototypes – a reason for using prototyping is to quickly reach a point where something playable provides a clear picture of the vision. Using a lot of time on fine tuning certain elements and details like graphics and sounds will only increase the impression slightly – a red dot which takes 1 minute to make can at this point work fine in contrary to using an animated character which took you numerous hours to make. One could argue that it is the details which differentiate great computer games from bad ones. True, however, it is testing and evaluation which is the goal of the visualization process, so save the details for the final game and instead use the time to explore other facets of the idea. Roughly said the process of making prototypes is about quantity and not quality – to explore the different possibilities by means of many prototypes instead of using time polishing a single one.
Modular prototypes – the success of a game production depends on how well you handle changes. Even small developments will face the need to change something at some point so you can either plan for it in advance or face the problems as they emerge. The use of prototyping is a perfect way to plan for changes. The idea is to think of lightweight prototypes as Legos; each prototype is a module that when, combined with others, is united to form something greater. Each game mechanic is tested through numerous prototypes where each implements a different version of the same mechanic. When combining the ideas in a final game it becomes easy to exchange one mechanic for another if you realize that it does not fit or the design has been change in some way. Modular prototyping is about having more red LEGOs ready if the one you tried first does not fit your house.
Evaluation
Play testing is a never-ending process – the first step to improve something is to understand where and why the flaws are and the only way to do this is through evaluation. The process of using lightweight prototyping is a dynamic and ongoing development of ideas which consequentially limits the possibility for formal and structured testing sessions. Instead testing must function as a natural part of the design process. Self-testing is a way to approach evaluation where playing the prototypes should help to understand what and why something is done wrong. Through this continuous testing you gain a broader understanding of the idea and the context in which it functions. To ask yourself questions concerning the idea and the relation to the rest of the game and to compare it to similar prototypes will help you see new perspectives or even whole new solutions to the problem.
However the most important way to gain an understanding of the idea is to have other people evaluate the prototype. Feedback is by far the most rewarding way to evaluate anything and neglecting it will only hurt the game. The use of confidant-testing fits the lightweight prototyping approach were colleagues or other confidants act as test persons. But it is important not to make this into a formal test session; at this point such an elaborate setup will be a waste of time. Instead, invite a colleague in for a cup of coffee while you show your work and simply make a mental note of the things he or she says and does relating to the prototype. You will go back to working on the prototype the minute your colleague leaves anyway, so there is no need to document the feedback more extensively then on a Post-it note. All information is welcome at this point, and you can always dismiss irrelevant comments later on. Remember, you are not building a game at this stage, but simply exploring ideas, so to receive all the feedback possible will only increase your chances to build a great game later on. Furthermore, the input from others helps you to see new sides and by doing so prevents your ideas to be single-minded.
Make throw-away prototypes – so finally you managed to make a really great prototype which is ready to be implemented in a final game. However tempting this might be it is important to stress that this should not be an option. Do not expect your work to be used for anything else than evaluating the concept. The prototype should be nothing more than a source to extract information from. When making prototypes there are no rules of how to make them and there should not be since the goal is to get something up and running as soon as possible. To demand that the work done can be used in a final game only limits the creative process and makes people think about is-sues such as implementation, appearance and re-usability which are not important at this stage – when doing lightweight prototypes it is always more important to focus on what you made instead of how you made it.
This way of thinking is something which needs to be adopted by the entire development team in order for lightweight prototyping to work. Appearance and eye-candy is an effective way to sell products that lacks quality them-selves and to promote this as an important feature when prototyping re-moves the focus from game mechanics and onto something which this process is not intended to be used for. To make lightweight prototypes is to accept the absence of high value concept art, setting, and sound and to focus on game mechanical issues exclusively.
Be proud of your work – in order to receive feedback you need to show your work to others. While this sounds good on paper, it is easier said than done. To show a prototype in which you have spent valuable time implementing a couple of dots that moves around does not seem as a good way to impress your boss. However, for a developing team using lightweight prototyping it is important to promote this behavior. If not, you risk that people start prioritizing visuals over game mechanics in order to “sell” their product better to colleagues. When working with lightweight prototypes it requires a show-off element among the developers for the process to work – everyone has the same goal and everyone should appreciate the value of a lightweight prototype.
Make decisions as late as possible – the information regarding game mechanics may be somewhat limited in the beginning of a production and to base the entire game design on these may turn out catastrophically. Instead of making important decisions at such an early stage of the production, the rational thing would be to wait until you know more. Evaluation of lightweight prototyping should be the key element in obtaining the knowledge needed in order for you to make a reasonable decision. Does it take one, five or ten prototypes to give me the information I seek? Well, the answer is of course not black or white, however, a rule of thumb is to keep prototyping until you simply cannot wait any longer to make a decision. The idea is to make important decisions regarding game mechanics at the last responsible moment since you might gain new information which changes the context and requires a new decision, making previous decisions a waste of time.
A day in the life of a rapid prototyper
An idle Tuesday morning, John is pouring his first cup of coffee for the day. As a designer on the company’s latest project he’s got his work cut out for him, and the expectations are high. Walking to his desk he runs the combat mechanics over in his head. They are still only a rough sketch, but the basics for the third person shooter are there.
Coffee in hand, John heads for his workstation. But before he gets there, Peter, one of the other designers, grabs his arm – his latest prototype is ready and he needs some feedback on it. Peter’s prototype is simple; a box moving through a blocky environment and a movable crosshair corresponding to the Xbox controller which has been hooked up. Pressing 1-5 on the keyboard cycles through different possible control mappings, allowing for a comparison later on once more pieces are in place. They discuss the prototype for a few minutes before John returns to his workstation.
On the wall in their office hangs Post-it noted describing different game mechanics, ranging from inventory system features and reload mechanisms to special AI behavior and suggestions for puzzles. John pulls down the note named “active reload”, reading the two line description as his computer boots up… “Make reloading more interesting by adding an element of timing”. He starts working on a small prototype, spending the first half of the day experimenting with different ways to implement this element of timing. Throughout this process all the designers are there to provide each other with feedback once something is ready. As soon as something playable is up and running, one or both of the other designers spend a few minutes trying it out and commenting on it.
Once the prototype is good enough to explain the idea, a short description of the prototype is written in the wiki along with a link to the file. Their wiki allows everyone to get a feeling for how the project is coming along. The publisher can see which direction the game is taking, and people on the development team can try the different prototypes and comment on them.
