寫一個一級棒的策劃書(譯文)

Game2遊戲:


Creating a Great Design Document

寫一個一級棒的策劃書

必須拿出一個產品。在這種壓力下,我的頭都快被屏幕射線擊碎了。如果這時有一個老銅燈裡面鑽出來的神魔,要我說出三個願望,那我一點也不會猶豫地說:我要……

I've got to get product out. In the panic and dizziness, my head smashes against the CRT and next thing I know this genie whiffs up out of a virtual bronze-texture-mapped lamp and offers me three wishes. Without missing a beat , I answer, 'I need…

一隊天才的、高超的、敢拼命的工程師和藝術家,彼此密切配合。 (還得有一個非常懂事的妻子)(快客說: me too ,sir !)。

足夠的錢和時間,可以隨便用。

一個一流的設計文檔。

A great team of talented, skilled, and dedicated engineers and artists (including a very understanding wife) with strong interpersonal skills.

Enough time and money to allow for a mess-up or two.

A first class design document.

以前,一個程序(或美工)做一個遊戲的時候,自己幹自己的,沒必要編策劃,現在不同了。

Once upon a time, when coding a game involved one programmer (and maybe an artist) with a take-it-as-you-go budget and a loose deadline, documentation didn't need to be taken so seriously. You knew what you wanted to make and you made it. If there were a few major changes along the way, the only one to complain was you. Nowadays, a thorough and readable document can mean the difference between a swift descent to budgetless Hell and a smooth ride to shrinked-wrapped Nirvana.

How the System Works

系統是怎樣工作的

大部分遊戲要經過三個開發階段:靈感、紙、和苦行。

Most games go through three development stages, from concept to design to production. Think of them as 'flash,' 'paper,' and 'grind.'

在第一階段,紙有兩個用處–記下你的創意,免得你往了。還有做為一個工具,向可以幫你把遊戲市場化的人,提供參考。這個時候最好有個小演示,可以驗證和修改你的想法。

In the first stage, the concept paper acts both as a letter to yourself – setting out your goals clearly so you won't lose sight of them – and as a sales tool for whomever takes the product to market down the road. Sometimes, this stage involves a working mini-prototype as well, which gives you a chance to experiment and revise your ideas.

下中間的階段就是去吵架(快客說:對,我們現在就在吵架。),和美工、和動畫、和音樂、和程序,去吵。把東西整出來,找到一個途徑組織和落實你的想法。

The intermediate stage of design involves a lot of discussions with artists, animators, musicians, and engineers – trying things out, and finding ways to organize and set down your ideas.

最後的階段,製片過來實施計劃。這時,有組織能力的策劃可以做團隊的中心,但是多數情況下–特別是大公司,策劃成了旁觀的顧問。

In the final stage, production management is often left up to some expert in moving trains and tracks without major collisions. The original designer may be an integral part of the team, but in many cases – especially in large companies – the designer ends up as a kind of outside consultant.

 

毫無疑問,策劃書是一個項目的原型,對今後的小貝貝的成長有極大的影響力。至於你–策劃師(快客:這是說陣雨),就算你兼任項目經理,也別以為你已經控制了整個局勢。一個複雜的項目涉及到很多天才少年,有能力的程序和美工都有自己的想法(快客:嘿嘿,你怎麼知道的這麼清楚?)你想搞一匹馬,美工肯定給你畫一頭獨角獸,到程序哪裡,獨角獸肯定會變成一頭高清晰度的駱駝。 (快客:嘿嘿)

好的策劃書,必須保證每個人做出一樣的東西。讓所有的人對你的精神都能吃透。就像一個爵士樂隊指揮,把所有人的想法攏到一起,做出明星級的表演。

Without question, the design document is where the original parent of the project exercises the most influence on how this little baby is going to grow up. Even if you, the designer, have decided to double as project manager, don't delude yourself into thinking that you hold all the reins. A complex project involves many talented people. Skilled programmers and artists tend to have minds of their own. While you intend to create a horse, the artist may be envisioning a unicorn and the programmer a highly efficient camel . A good document ensures that you are all planning to make the same thing. A great document ensures you all have the same feel for the inner soul of this thing. Think of it as a big band jazz score – it puts everybody's mind in the same place, even when there's still plenty of ro​​om for the stars to improvise.

你的策劃是現實與你的思想之間的橋樑,必須保證你​​想的,在現實中有依據,還有你最後得到的東西,是你心裡想的東西。

Your document is a sort of intermediary between your mind and the real world. It ensures that what you have in mind is something that the real world is able to handle, and that what you end up with will be what you originally had in mind.

最後,記住一句諺語:藝術在於細節。 (快客:下面一句不懂。)

Finally, remember the adage to which any salty gamer will attest: 'Great art is in the details.' Brilliant details flow naturally from the general gestalt as though they were present in that first flash of inspiration. But once you get into the hands- on implementation, it's easy to lose that spark.

The Challenge

挑戰

Prototyping parts of the project yourself is definitely a good idea – make whatever rough sketches you can. But again, it's those details that count. The more details your imagination can hold, the greater a masterpiece your work will be.

做一個精彩的遊戲,本身就很精彩。最好的想法往往在最後的交稿期的一分鐘出現(Working from a document has a flip side, as well. Developing an exciting game has to be exciting. Some of the best parts of many projects were discovered in the heat of last-minute deadline panic. True, the pressures of time and cost budgeting don't allow for perpetual reiteration of concept, but you simply cannot expect a killer game to come out of dry, predictable work. The challenge is to create a design document that will allow your project to tolerate surprise adaptations without losing the integrity of its original direction and scope.

Table 1. The three stages of documentation.

策劃的三個步驟

Contents Purpose

1. Concept Paper Genre;

一般概念階段

目標顧客、說明、特徵、市場情況投資和時間表。定義遊戲的概念、範圍、價值和可行性。 (快客:這個就是現在我們要搞的東西)target audience; de​​scription; most compelling features; market information; cost and time to develop. It defines the concept, scope, worthiness and feasibility; sells the idea to your client, publisher , employer, and venture capitalist.

2. Design Document

設計文檔階段

說明項目所有的細節,所有組成部分的實現方法。

Description of the body and soul of the entire project, with all the details, and the method by which each element will be implemented. It ensures that what is produced is what you want to produce.

3. Production Documents

產品文檔階段

時間表(甘特圖、PERT圖等等)任務、預算、技術。 Time-management charts (Gantt, PERT, and so on); task database; budget spreadsheet; technical specifications; Q/A database. It implements the design document on time and within budget.

Ten Points for a Successful Design Document

好策劃十要點

1. DESCRIBE NOT JUST THE BODY, BUT THE SOUL.

說明身體、更要說明靈魂(創意優先)。如果做遊戲僅僅是一個簡單的I/O系統–比如寫代碼並預言它如何運行,–那麼你可以湊合一個乾巴巴的、描述性的東西。但實際情況是:開發活動是很多人,很多有創造力的人,一起做的,每個人都有他的思想,都想在任何他們做過的事情上打下印跡。 If game development was just an automated input/output issue – something like writing code and being able to predict how it's going to work – you could get by with a dry, descriptive document. The reality is that development is done by people, many of them creative people, who have their own minds; most will want to leave a stamp of that mind on everything they do.

可能會是這樣:你拿一個說明給美工,和他討論怎麼做。你找程序給他看說明。小組的每個人都對你說的任何東西點頭。 (快客:啊,真的?)

It works like this: You provide specs to the artists and discuss with them what to do. You then visit the programmers and go over their specs. Both groups nod to everything you say.

當晚半夜兩點,當C++星在西方升起,正出在“中年心理危機”的程序(快客:誰?我?)開始想:“怎麼?就做這麼個破程序了此一生?這是我媽媽希望我做的?為什麼?我也可以向某人一樣策劃,比他還棒。”想著,手裡還打著鍵盤。

That night, around 2AM, just as the constellation of C++ is rising in the west, the programmer reaches a mid-life crisis and begins to think, 'What, a geek programmer the rest of my life? Is this what my mother expected from me? Why, ​​I can design a game just as well as anybody else!' And the hands keep typing code.

同時,美工剛剛在他機器前醒過來,因為等一個非常費時的3D渲染,他剛才睡著了。 (快客:佩雷斯將來可能就這樣。)不清楚他是否還在做夢,也許已經醒了,在藝術想像的曠野和現實的夢境中,混沌著一切。驚奇的造物以從未想像的方式凝結了。

Around the same time, the artist has just woken up before his machine, having fallen into a deep stupor while waiting for a complex 3D rendering to finish. Unsure and not really caring whether he's dreaming or is actually getting paid for all this, immersed in that wild world of artistic genius where fantasy and reality blend as one, the phosphors come together in ways previously unimagined – certainly not by you.

第二天,你的馬變成了一個有兩個峰的駱駝。

對有思想的人,灌輸是沒有用的,你還要激勵。

By the next morning, your horse has become a unicorn with two humps. With creative people, instructing is not good enough. You need to inspire.

 

 

在設計中,不要滿足與你對所有美學和細節的說明。費點時間說明遊戲應該傳達的感覺,每個部分後面應該表達的目標。以及所有你能描述的,遊戲的各方面的精神。

In your design document, don't satisfy yourself with a detailed description of every article and nuance. Take time to describe the feel that the game should have, the purpose behind each element, the experience each user will have, and any other aspects of the game's soul you can envision and describe.

例如:設計了一個槍手,你想在實際操練前,讓你的玩家練練。所以你在這裡降低了難度。你得向每個團隊裡面的人解釋為什麼這些東西在這兒、為什麼這些東西這樣運行。到你的團隊的人不看你的“紙”也清楚的時候,你興許可以期待出來的東西與你想的近似或者–更好。

For example, say you're designing a shooter. You want to train your players to deal with certain challenges before they actually meet them, so you place less lethal mini-challenges a few steps in advance. You're going to have to explain that to everybody on the development team, so they'll understand why certain things are where they are and why they work the way they do. That way, even if (read: when) your team toys with and mangles your ideas as they exist on paper, you can still harbor hopes that the outcome will have the same or similar overall effect. Or maybe even better.

2. MAKE IT READABLE.

注意可讀性,整齊漂亮。 Go ahead, provide your people with full pages of 10-point, sans serif, 80-characters-per-line text, and demand that they read it. You may want to bundle Advil in the package – for those who actually take the pains to obey orders.

I try to follow at least some of the guidelines of good page layout.

Plenty of white space

Serif font for body text

Bold headers

Spaces between paragraphs

Short lines of text

Direct the eye towards important material

Use a hierarchical, '2D' format (see what I wrote about outliners in the 'Design Documentation Tools' sidebar)

Many instances call for a table, spreadsheet, or chart. Use them and make them sensibly attractive.

3. PRIORITIZE.

注意優先考慮的東西。 (快客:看不懂)

Now that you realize that you're working with other conscious egos, you'll appreciate the urgency of tagging certain game elements as sacred. True, there are no guarantees, but if you use the tag sparsely enough, it may get some respect. But don't stop there. As long as you're tagging ideas, you'll also want to distinguish between things that you intend to do and things that you'd like to do if time, budget, skill sets, and technicalities permit .

Then there's the trash bin – things that sounded great, but were trashed for good reason. Refer to them explicitly and explain the reason that they were trashed. If you don't, I can almost guarantee that they will be resurrected. Here's your list of tags:

 

 

Indispensable

Important

If Possible

Rejected

You may wish to use visual symbols to represent these. Don't rely on color, since documents aren't always printed in color.

4. GET INTO THE DETAILS.

沒有細節的文檔是沒有用的。

當你說實際的細節時,適當地給出一些例子。

A document without details is useless. Generalities can be interpreted by anybody in any way that they like. 'Thou Shalt Not Kill' meant one thing to Moses and another to a Spanish conquistador. Detailing whom you shouldn't kill and under which circumstances would have been more helpful. The same holds true for your document: Once you've described some practical details and given some examples, your idea becomes more concrete – and harder to shove around.

比如說:青銅鳥無敵。還要精確地說出在各種被打擊的情況下,這個東東會怎樣反應,還有怎樣回復原狀。如果動畫和美工不高興,你可能不會從他們哪裡得到你想要的東西,但是,他至少已經對你的想法有清晰的概念,他所做的修改不會損壞遊戲的整體。

For example, don't just say, 'Bronze bird is invincible.' Describe exactly what happens to this creature in each possible instance of its being hit, and how it recovers afterward. True, if the animator has any spunk and artistic dignity, you can rest assured that he won't follow your specifications. But at least he'll have a clear idea of​​ what you want to achieve, and his modifications won't seriously alter the related portions of the game.

別說:這時,用戶必須按“跳”和方向鍵,爬上這堵牆。說明如果用戶做其它所有嘗試時,如何回應。解釋為什麼你認為用戶會使用你說的那個組合鍵,還有當時環境中為什麼可以爬這牆。

Don't just say, 'At this point, users will have to press the jump key with the arrow key to climb the wall.' Describe what will happen if a player tries anything else. Explain why you think users will be able to figure out the combination that you've provided. Explain what about the environment suggests that it's possible to climb this wall.

可能,你的美工提出一個更好的方案,可能比你原來想的更符合你的要求,這太好了。你的人對你的理解已經超出了你寫在紙上的東西。但是記住:如果你沒有在一開始把你的意圖寫清楚,這種事不會發生。

Again, your artist will come up with something else, perhaps something even more suitable than what you originally conceived. That's real success: When your developers' results come out even closer to your original flash of conception than what you were able to describe on paper . But this won't happen unless you first lucidly describe your concept.

不要說:大人比小孩壯,但小孩比大人反應快。用一個表,說明各個角色的屬性值。

Don't just say, 'Bongo Man is stronger than Bongo Boy, but Boy has faster reflexes.' Use tables, spreadsheets, and charts to assign real values​​ to the character's speed of movement, how many hits the character can take, how much damage the character's hits do, how many cels it takes to animate a hit, and so on. This sort of spreadsheet is invaluable in the Q/A and tweaking stages of production.

 

 

同樣,用圖表預測產品的接受程度。

Don't just say, 'Most people will figure out the whole game in a few days.' Make a chart of predicted product life in different households, indicating at which points in time you expect various features to be discovered. User testing will later provide valuable feedback for designing your next game.

5. SOME THINGS MUST BE DEMONSTRATED.

有時一個粗線條就可以。但如果一個東西對你的項目的概念非常重要的話。你可能會做一個動畫;有時一個東西不好說清楚,你可能做一個模型。

Sometimes a few rough sketches are enough, but if the idea is truly important to your concept of the project, you may want to make a rough animation yourself. When behaviors of elements become too complex and ambiguous to describe on paper, you'll want to make a prototype. A side benefit of prototyping is that this practice often leads to a simpler, more elegant solution.

用動畫加主題詞的方法最好。 (快客:太難了)

Even when you provide animations and prototypes, put the concept in words as well. True, an animation is worth a gigabyte of words, but words can communicate in ways that animations can't. Words also clearly spell out the vital nuances that may be missed when watching the animation.

6. NOT JUST ‘WHAT’ BUT ‘HOW.’

不僅說“做什麼”,還說出“怎樣做”。 (快客:你盡力吧。)

In the real world, the 'how' determines the 'what.' For example, suppose you've opted for claymation. Work out the process of how the images will be captured and document everything. What material and what color should the backdrop be ? What camera should be used and why? What are the steps for processing the captured frames? And on and on. If you've tried it, you'll know that any one of these factors can have a serious impact on the end result .

比如一個摩托車遊戲,你說出摩托必須馬力與製動平衡,你拿一張表說明如何平衡,你可能還想要有反作用力,說明編程思路(快客:不必、不必,但能否實現應該問問。)給出鍵盤的映射表(map)。

Or suppose you're working on a motorcycle racing game. You state that the motorbikes must be balanced by their differing pros and cons. You even provide a chart that shows how balanced they are. Then you state that tweaking will be necessary. State how you plan to tweak – what is the process? Suppose the main character in your game is the Phantom of the Opera. Describe how the player's keyboard is mapped as a pipe organ. Provide a map of each key. Specify how many channels of sound will be available. Talk it over with your programmer and work out every detail of how. Then document it. Two different 'hows' can mean two very different results.

7. PROVIDE ALTERNATIVES.

提供備選方案

項目經理在甘特圖和PERT上費了很多時間,我沒法說這對遊戲開發有什麼用(快客:還是有用的,甚至很有用)。主要原因是未來的不可知性,如果你想讓你的人按時到達你指定的地點,最好讓他們有更多的路徑可以選擇。

Project managers spend a lot of time with their Gantts and PERTs. Personally, I can't really say that this stuff is effective for game development –​​ principally because there are just so many unknowables. The more radical and pioneering your game technology, the less predictable the development stream is going to be. The best thing you can do to ensure that your team reaches your milestones on schedule is to provide more than one way of doing things.

 

比如上面的例子裡,你的工程師可能耗費大量的時間,用你的不太好的辦法到達你的目標。不如提一個目標,讓他自己選路徑。 (快客:與上面的說法是有矛盾,策劃是繁還是簡確實要足夠的經驗才能把握。)

Lets go back to the keyboard as pipe organ example. Your engineer describes to you the ultimate method of getting awesome and funky results with tremendous power and depth to the user – at a cost of about 50 person-hours to implement. As with everything else we've discussed, you doc​​ument the whole thing.

You can't stop there. You've got to ask, 'What would it take if we just wanted a trimmed-down, eight-channel pipe-organ? And what will we need to achieve the bare minimum? And what if we just had some assistant doing this?' And then you doc​​ument all that as well. When the FedEx truck is on its way over for the final daily pickup, you'll be able to save your skin with a simple, 'OK , do Plan C.'

向程序詢問時:答:沒問題或不可能。都沒有太大意義。最好能得到這樣的回答:“這個我可以這樣做,但是要化兩星期,或者我在這裡改一點,但是化5小時”。

One of the biggest mistakes I've made in product design is asking engineers, 'Can it be done?' Unless you're asking a first-class programmer, the question is useless. More specifically, responses fall into one of three categories:

(Lousy programmer) 'Sure, that's no problem.'

(Mediocre programmer) 'Nope. Can't be done.'

(First-class programmer) 'I could do it like this and it'll take two weeks. Or I could make a slight modification like this and it'll take five hours.'

多問,以得到盡量接近事實的情報。

Always ask for more than one alternative and an estimate of how long each will take. Then indicate your preference – do this is if we have time, or this if we don't.

8. GIVE IT A LIFE.

我警告你:不要被靈感或看著某個東西在你手裡變成現實的快樂,以及由興奮帶來的自發的創造性等等刺激的東西所憋死。

你必須允許你的文檔被修改,——被你自己修改,被別人修改。

I've already warned you against strangling the inspiration and spontaneous creativity that comes with the excitement and fun of seeing ideas become living objects in your hands. You've got to allow your document to tolerate change – by you or by (hopefully intelligent) others.

I first learned this lesson as a music composition major at the University of British Columbia. With much toil, I had written a neo-renaissance brass quintet of which I was quite proud. My professor ​​liked it, too. When we brought it to the college's star brass quintet for rehearsal, however, I passed through several stages of horror, disbelief, indignation, and clinical depression within ten seconds. The quintet began to play, then stopped on signal from the tuba player. The fellow took out his pencil and began to change a few notes, and then everyone continued. It happened more than once.

 

 

我在大學寫一個樂曲時學到這一課。當時評審的時候,從一個傢伙開始,他們都在我們樂譜上改起來。

我的教授,注意到我突然停止呼吸,昏過去了。他弄醒我,說:“別在意,他們對莫扎特也這樣改,而且他們總是改得更好。”(快客:將來我們也會遇到的)

My professor, noting my sudden faint state of health, turned to me and commented, 'Don't worry, they did that to Mozart as well. And they're usually right.'

The fact is, no matter how good something looks on paper, the greatest expert still modifies things when it enters the concrete world of objective perception. Nevertheless, you don't want to witness the ruthless rape of your design and dreams. Rather, you're hoping for a kind of organic growth – ideas growing naturally out of the seeds you've planted without needing foreign limbs and bodies grafted onto them.

Here are some tips for creating a document that can tolerate change without corrupting the original idea or sabotaging the development process:

注意你的“靈魂”,主題要表達清晰,主題要讓每個人都能領會到,這樣就可以了。

還有,改動不能改主題。

Make certain to engrave in stone those aspects that are so essential to the game concept that they must not be changed.

Make certain everybody understands the feel that the game is supposed to have and the purpose of each of its details.

If information is repeated, it must be cross-referenced. Otherwise, if there are changes, you can end up with contradictory instructions.

And here are some tips for the actual implementation stage:

When a change is suggested, check back in your design document and see if it is in concordance with the 'soul' of your game.

Check whether this is just an isolated change, or it's of major global ecological impact (see 'The Ecology of Improvement'). If it's the latter, save it for your next project.

Update the design document and include the reasons for the change. Or if you didn't make the change, say so and explain why it was rejected.

Changes, deletions, and rejected ideas should be retained in a master document to avoid discussing the same thing twice.

Everyone must be working from the same version. Past versions should be destroyed.

Crucial, Vital, and Urgent: The design document must be maintained under one person's supervision only.

9. NOBODY SHOULD BE ABLE TO SAY, 'I DID IT THAT WAY BECAUSE I COULDN'T FIND ANY REFERENCE TO IT IN THE DOCUMENT.'

不能讓人說:我這樣做是因為文檔裡沒有這方面的參考。

要有清楚的頁碼,標題和頁眉頁腳,清晰地指出各個要點。讓人好找。

I've seen documents that didn't even have the pages numbered. And then they complain that people didn't follow instructions. Every good word processor ​​will auto-number pages and print the date and title in the header or footer of every page . Some will even allow you to change the header at new chapters. Use bold text to direct attention to important material. Repeat yourself in different parts of the document as much as you like, as long as you cross-reference so you can update everything together as well. Make a thorough Table of Contents.

You may wish to write your document using HTML and provide hot links. Some progressive word processors provide hot link capabilities without HTML. But remember that more often than not, people prefer to work from a hard copy. (That way there's something to read while rebooting after the hourly system crash.)

 

 

10. DELIVER IT IN GOOD CONDITION.

完整地遞上去。指:裝訂好遞上去。

After all this, you need to do whatever you can to facilitate everyone actually reading and using the thing. A pile of papers doesn't get read – it doesn't look important enough. Only things with hard covers look important.

Create a list of everyone who is supposed to have a copy. Keep the list. Print out the whole thing with the date in the header of each page. Have holes made and put it in binders. Label the spine and cover of each binder. When there are updates, provide everyone with the revised pages. At some points, you may need to provide new books and throw out the old ones.

In Sum Check…

Movie makers use move scripts. Architects use blueprints. Musicians use a score. According to ancient hearsay evidence, even the Cosmic Creator created a design document –​​ which He later let a few prophets take a peek at – before the primal 'Let there be light!' So game developers, following their Supernal Role Model, can certainly do the same. Do it right and it's smooth sailing the rest of the way.

Tzvi Freeman teaches Game Design and Documentation at Digipen School of Computer Gaming in Vancouver, British Columbia, Canada. He has designed several commercial games and has acted as a consultant on many others. He can be reached at TzviF@aol.com .

總之:清晰地表達遊戲的精髓——主題“靈魂”“Soul”。讓人接受是策劃的最終目的。

遊戲網誌:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系

Comments are closed.