首页 | 互联网 | IT动态 | Cisco | Windows | Linux | Java | .Net | Oracle | 华为 | 存储世界 | 服务器 | 网络设备 | IDC | 安全 | 求职招聘
IT培训 | 数字网校 | 技术专题 | 电子书下载 | 教学视频 | 网页设计 | 平面设计 | 解决方案 | 直播室 | 虚拟考场 | 搜索 | 博客 | 沙龙 | 论坛
 您现在的位置: 中国IT实验室 >> 游戏开发 >> 游戏策划 >> 文章正文
一级棒的游戏开发的策划书
来源:中国IT实验室收集整理 作者:佚名 时间:2008-4-9


 
  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 document 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 document 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.)

上一页  [1] [2] [3] 下一页  

【责编:Luzi】

中国IT教育热线咨询

相关文章
游戏开发中显示对话的特殊句法
游戏开发项目管理的现状
游戏设计中俳句与禅文化
评论:中国网游市场迎来08年第二轮洗牌
中国游戏业的2囧囧7
推荐文章

 精彩友情推荐
·神州数码交换机
·神州数码交换机价格
·神州数码网络交换机
·netgear交换机
·网件交换机
·IDC资讯大全
·机房品质万里行
·IDC托管必备知识
·全国IDC报价
·网站推广优化
 基础入门  开发文档
 最新推荐
  多数的Windows程序都需要Windows.h和Windowsx.h这两个头文件,要确保使用它们。当然,你还需要其它......
游戏引擎演化史
在Windows上安装OGRE的方法
关于滤镜遮罩概念,Sobel 遮罩
游戏开发新手入门之Windows编程
游戏开发新手入门之位图化图形
教你实现卡通渲染的另类勾边方法
游戏设计大师谈如何成为一名游戏设
Visual C#编写 3D游戏框架示例
真正的 Java 学习从入门到精通
游戏开发经验——游戏开发的基本常
  为什么要研究攻击行为在人类有记载的5600年的历史中,共计发生了14,400次战争;今天,平均一天要发生............
游戏开发中显示对话的特殊句法
游戏原型设计的介绍
网络游戏中的攻击行为
谈动作类游戏的必要条件
规则的多元分析模式
载入位图文件到DirectDraw
Archer Game Suite 是什么?
浅谈游戏企划-新手入门篇
暴雪称霸游戏业界的六大秘密绝招
骨骼动画及示例Skinned Mesh的解析
  培训中心