游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

有关快速创建游戏原型的经验教训

发布时间:2012-12-10 15:26:07 Tags:,,,,

作者:Douglas Lynn

在大学生涯中,因为学期制的压缩属性,我总是需要在连续数周内,每周快速完成一款独特的原型创建。虽然之前已经参加过一些类似的过程(游戏邦注:如48小时原型创建),但是我却从未真正面对过反复的快速原型创建过程。而之前的经验告诉我,当我们在设计一款游戏原型时,任何有关游戏设计过程的理念都将被抛到九霄云外。很多时候,对于设计一款完整的游戏来说非常重要的元素却并不适用于原型创建中;而其它看似很琐碎的元素却变得更加重要。所以我将在此分享我在原型创建中所吸取的经验教训。

Rapid Prototyping(from thomasnet)

Rapid Prototyping(from thomasnet)

规模与范围的不同

在大学课程中我们经常会听到,为了保持适当的工作量,我们需要同时限制项目的规模与范围。尽管我知道这意味着什么,但是我却从不愿意去思考这两个术语间的差别。而通过快速原型创建过程,我知道了范围决定着能否维持合理的工作量。

在制定项目建议书前,最理想的情况便是你已经拥有了一份原型,从而避免了时间约束,但很多时候你也会发现自己不得不匆匆忙忙地创建一份游戏样本。如果你马上就需要一份原型,那么规模和范围便是你的两大主要考虑因素。

就像我们所了解的,规模便是指游戏的大小。如你所面对的是多大的游戏空间?当基于规模进行思考时,我们最好能够从整体的游戏时间开始。这是只需要3个小时的独立冒险游戏还是长达40个小时的角色扮演游戏,或者是只需要10分钟便能够完成的休闲游戏?明确这些问题能够帮助我们判断游戏的大小(和深度)以及最终呈献给玩家的游戏体验。

而范围则是指游戏中所需要的材料数值。也就是规模代表大小而范围代表密度。即关于你需要面对多少不同的游戏元素?你需要使用多少不同的角色和资产?最重要的是,你需要编译多少不同的功能?

在快速创建原型时,最后一个问题非常重要。就像我们常说的,游戏产业充满创意,所以开发者不需要花费大量时间去思考角色所拥有的不同技能或玩家可能面对的挑战等。如果你创建了游戏原型去演示游戏理念,特别当你是设计者时,你便会希望能够尽可能多地传达更多这类型元素。最好的情况则是你能够在将游戏交给发行商前编译出所有内容。而做到这一点的诀窍则是,始终以做不到这一点为压力去推动自己。

在现实生活中,创建计划非常重要,而在遭遇了失败后,我们便需要创建备份计划,然后再创建备份计划的备份计划。而在原型创建过程中,一份真正出色的计划必须已经包含了备份计划,并且备份计划是以不断扩大的范围形式呈现出来。也就是一开始先基于较小且简单的范围,随后基于此进行扩建。

也就意味着我们需要在创建过程中不断调整项目的整体属性。如果你所设计的原型是突出一个关卡,那么这个关卡需要基于所需要执行的功能数进行设计。

根据标准设计去调整范围

让我们假设你正在设计一款平台游戏。其中包含了最基本的平台元素——跳跃和奔跑,以及其它标准的元素,如二段跳,提速和三角跳。你同样也希望能够设置重力调整机制去控制个人的碰触。你已经设计了一个原型关卡能够传达这些能力,并且只有合理设置每种能力才能达到真正的效果。这么做能够让玩家们更加期待你的游戏。

接下来你需要制定一个原型创建计划。你将创建一些基本的平台机制去保证基本设置的运行。因为这是一款平台游戏,所以你需要在进一步发展前搞定这些元素。也就是你将在此执行你的重力调整系统。这是设计的关键——这一元素将能够让你的平台游戏区别于市场上的其它游戏。而如果缺少了这一元素,你便没什么好展示的了。

但是随后问题便开始浮出水面。现有的平台游戏机制的物理属性与你所希望呈现出的物理系统是相互矛盾的。也就是说你需要为此投入更多的时间。当然了,你也可以略过其中一些额外的功能,毕竟对于游戏的运转来说这些功能并不具备多大功效。但是仍存在另外一个问题,即你所设计的原型关卡必须包含所有的这些元素。除非你一开始便使用了加速和三角跳元素,否则你的重力调整系统便很难发挥作用。而现在,你便会因为没时间去整合其中的某一元素而不得不重新设计整个关卡结构。这么做需要花费更多时间,从而让你不得不舍弃其它功能而再次进行关卡设计。

尽管你不能完全阻止这种问题的发生,但是你却能在原型创建(而非制作过程中)中缓解问题。这便是我所说的可调节的范围和标准设计。虽然我始终提倡创建具有凝聚力的游戏体验,但是原型并不是完整的游戏中所看到的混合元素——它只能用于呈现出游戏的运行。所以原型的创建将基于一些独立运行的关键机制。

举个例子来说吧,你可能想要创建一个专门演示加速机制的关卡模型,以及另外一个用于演示重力调整机制的模型等等。最理想的情况便是你可以按照自己的想法去创建关卡顺序。如果你想要混合某些元素,并且你已经接近原型创建后期了,那就将你所创建的内容组合在一起而生成一个完整序列的事件。后面的这种方法将能够创造出更连贯且更具凝聚力的原型,但却需要投入更多的设计时间。

外观远比想象中重要

这并不是说你应该聘请一些专业人员为一个10分钟的技术演示创造花俏的角色和视觉效果,而是需要牢记“电子游戏”中的“电子”的含义。在原型中明确游戏机制的可行性非常重要,但是从整体角度来看电子游戏是关于将所有的代码数字和符号转变成能够轻松理解的形式。如果代码能够有效运行的话,玩家便能够在屏幕上看到所有效果。就像开枪时能够提到“Bang!”声,添加能量时能够看到自己越来越亮之类。如果你使用“喝牛奶”功能,你便能看到牛奶在眼前逐渐减少。

同样还需要考虑到反馈。我们总是很容易遗忘或忽略这一元素。如果玩家执行了某些行动,我们就需要去证实这些行动。不管是在原型还是完整的游戏中,这一点都非常重要——以证实代码真的能够有效运行。代码能够确保机制的运行,但是如果缺少了视觉元素,玩家便不可能意识到这一点。并且对于传统的玩家来说,调试屏幕并不是一种可行的视觉反馈机制。

总之,一定不能忽视原型中的反馈元素。尽管你并不需要在这一阶段设置超现实主义式的爆炸效果,但是玩家也希望确保受害人不会给自己造成任何威胁。除此之外,写着“Boom!Headshot!”的文本框也许算是一种可行的反馈机制,但是如果让我反复看到这一内容,我将不会愿意继续玩这款游戏。

在原型创建阶段做出改变

因为在大学课程中我曾经遭遇了半途重新设计游戏的经历,所以我希望可以不再重蹈覆辙。在游戏创造中,当我们发现游戏原型并不有趣时,事情就糟糕了。

其实我并不确定快速创建原型的实践在游戏产业中是否常见。我要说的是,在你将项目递交给上司前,你不可能根本地改变游戏设计。一周内生成一份可行的游戏原型是件极具挑战性的任务;而在24小时内完成更是自找麻烦。当然了,如果你的游戏原型并不有趣,别人便不可能接受你的游戏,而如果你只是在最后时刻才开始修改原型,也不可能改变最终结果。

为什么我要提及这一点?因为原型创建是我们开始明确游戏理念是否有趣的第一个阶段。所以我们最好能在这一阶段决定各种改变。如果这时候你发现游戏原型并不有趣,我便会说,不用担心,因为你还有机会创建另一个游戏原型。

结论

不管你所面临的是何种情境,你最好能够在创造一款完整的游戏前便找出更多问题。这便是创建原型的真正目的。原型是一种测试过程,能够让你在将理念投放市场前验证它的可行性。当然了,知道自己的设计不能有效运行时总是会很受打击,但是如果你能在投入更多时间去开发游戏前意识到这一点,那么这种打击力度便能够大大减少。(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

Lessons of Rapid Prototyping

by Douglas Lynn

I’ve recently found myself back in school again after three years of post-college oblivion. Due to the compressed nature of the quarter system, I was presented with the challenge of building a unique game prototype every week for several weeks on end. I’ve been involved in a small amount of this sort of process with 48-hour game jams, but I’ve never truly faced the prospect of repeated rapid prototyping before. If there’s one thing the experience has shown me, it’s that many of the concepts you can have about the process of designing a full game go out the window when designing a prototype. In some cases, what seems immensely important in the design of a full game becomes completely trivial in a prototype. Other elements that seem like trivial additions to a prototype are actually much more important than they seem. I’d like to share some of what I’ve learned.

As I sit here reviewing this entry, it all looks incredibly obvious, which makes me feel a bit embarrassed to bother writing about it. But the deed is done. Captain Obvious to the rescue!

The Difference Between Scale and Scope

One thing we were repeatedly taught in my undergrad program was to limit both the scale and scope of our projects in order keep the workload reasonable. While I always knew what was meant by this, I never really bothered to figure out the difference between the two terms as I always found them bundled together. One thing the process of rapid prototyping has shown me is that scope is everything when it comes to keeping your workload acceptable.

Now, ideally, you want to have a prototype ready to go before you even make a project proposal, thus limiting the time constraints, but there are still instances in which you’ll find yourself rushed to build a working demo of your game. If you need a prototype and you need it quickly, scale and scope are two vital considerations.

Scale, as I’ve come to know it, refers to the size of the game. How expansive of a game space are you going to deal with? When thinking in terms of scale, a good place to start is thinking of your overall play time. Is this a three-hour quirky indie adventure, an epic 40-hour RPG, or a pick-up-and-play casual title that someone can get through in ten minutes at a time? Determining this can serve as a useful guide for how expansive – and how deep – your gameplay experience will be.

Scope, on the other hand, refers to the sheer amount of material that goes into the game. Whereas scale (as per its name) represents size, scope represents density. How many different gameplay elements will you be dealing with? How many different characters or assets are to be used? Perhaps most importantly, how many different functions do you need to code?

This last question is key in rapid prototyping. As is often said, ideas are abundant in the game industry. In devising a game concept, it doesn’t take long to come up with a wide array of different skills or abilities an avatar can have or an array of challenges and obstacles the player might face. If you’re making a prototype to demonstrate a game concept, particularly if you’re the one who designed it, you’ll probably want to give a sample of as many of these elements as possible. That’s all well and good…as long as you’re capable of programming everything in before it comes time to present your game to a publisher. The trick, as far as I can tell, is to always assume you can’t do this.

I know, right? Way to build up the confidence, pal.

Now I’m not talking about breaking yourself down (or, if you have separate programmers working on the prototype, breaking THEM down). As with anything in life, the point is to have a plan, and then, failing that, a backup plan, and then, ideally, a backup for your backup plan. In the case of prototyping, a good plan should have the backup plan already built into it in the form of an incremental increase in scope. Start ridiculously small and ridiculously simple, then worry about building up from there.

This means adjusting the entire nature of the project build as you go. If you’re designing a prototype featuring one level, that level could be designed in multiple ways depending on how many features are going to be implemented.

Adjusting Scope through a Modular Design

Let’s say you’re designing a platformer. It’s got the basic platforming elements of running and jumping, as well as some other fairly standard ones like double-jumping, speed boosting, and wall jumping. You’d also like to throw in your personal touch with a unique gravity-alteration mechanic. You’ve designed a prototype level that demonstrates each of these abilities, requiring each one to be used correctly in order to make it through. Great. That should give people a good idea of what to expect from your game.

Next, you work out a plan for building your prototype. You’re going to start with the basic platforming mechanics to get the basic setup going. It’s a platformer, so these elements need to be in place before you can move on. From there, you’re going to implement your gravity-alteration system. This is the key to your design – this element distinguishes your platformer from the rest of the market. Without this element, you have nothing to show.

But then, things start to go wrong. The physics of the existing platformer mechanics are at odds with what you want the gravity system to do. This is going to take a bit longer than expected. No problem – you’ll just skip one of the extra features you wanted to implement. They’re not vital to demonstrate how the game works, after all. But there’s another problem – the prototype level you’ve designed incorporates all of these elements. Your gravity-alteration system doesn’t come into play unless you first use your speed boost and wall jump elements to access the appropriate area. Now you’ll have to go back and redesign the entire structure of the level because you don’t have time to incorporate one of those elements. This eats up even more time, forcing you to cut out another feature and redesign the level again.

Of course, you can’t entirely prevent this from happening, but it’s a much easier problem to avoid in the prototyping stage than it is in production. This is what I’m talking about when I mention having an adjustable scope and a modular design. I’m a big advocate of building cohesive game experiences, but a prototype isn’t so much about this careful meshing of elements that you would hope to find in a full game – it’s a demonstration of how your game works. As a result, a prototype can (and I would argue, SHOULD) be built with many of its key mechanics operating independently of each other.

For instance, you might craft a level segment that specifically demonstrates the speed boost mechanic, another which specifically demonstrates your gravity-alteration mechanic, and so on. Ideally, you’ll just be building your level sequence as you go. If you want to mix things up a bit, you can generate each module and then, as you near the end of the prototyping period, put together what you’ve built to generate a full sequence of events. This latter approach will likely produce a more connected and cohesive prototype, but it requires an additional design stage.

Visuals are More Important than You Think

This isn’t to suggest that you should bring in the professionals to give you fancy character models and visual effects for the sake of a ten-minute tech demo, but keep in mind that the term “video games” contains the word “video” for a reason. The important thing in a prototype is that you prove the viability of your game mechanics, but the whole point of a video game is to translate all of the mind-boggling numbers and symbols of your code into a format that can be understood without years of training. If the code works, the player needs to see it working on the screen. If you shoot a gun, you should at least hear a “Bang!” of some kind. If you’re charging up for your super-mega-special-energy attack, you should see yourself…I don’t know…glowing brighter and brighter or some such thing. If you use your “drink milk” function, you should see milk disappear before your eyes.

The word here is feedback. It seems obvious when you think about it, but in a way, it’s so obvious that it’s easy to forget about it and simply leave it out. If the player does something, it needs to be witnessed happening in some way. It’s important in a prototype for the same reasons it’s important in a full game – to demonstrate that the meticulously-written code is actually doing its job. The code makes your mechanics run, but the player doesn’t know that without the audio-visual element. And no, a debug screen is not a viable audio-visual feedback mechanism for the typical player.

In short, don’t ignore feedback elements in your prototype. While it’s true you may not need a head to explode in a hyper-realistic shower of gore at this stage, your player will still want to know that the afflicted victim isn’t going to be a threat anymore. Incidentally, a hastily-placed text box reading “Boom! Headshot!”, may technically be a viable feedback mechanism, but if I see this more than once, I’m going to stop playing your game with immediate effect.

Drawing the Line Between “Engaging” and “Practical”

After the experience of completely redesigning a game halfway through its production cycle during my undergraduate program, I hoped I wouldn’t have to go through that process again. But, silly me, I apparently forgot that I was getting into an industry in which this kind of thing happens without warning. When you make the discovery that a game simply isn’t fun, bad things happen.

Ultimately, I’m not sure how common the practice of rapid prototyping is within the industry. I will say this, though – the day before you’re pitching a project to the higher-ups is not the time to make a fundamental change to the design. Generating a viable prototype in one week is challenging enough. Doing it in less than 24 hours is just asking for trouble. Sure, your game might not be accepted if your prototype isn’t fun, but if you change that prototype at the last minute, it’s still not going to be fun.

Why do I mention this in reference to prototyping? The prototype is the first stage of the project where you’ll start to see that your concept isn’t enjoyable. As a result, it’s probably the stage at which you’re most likely to decide that a massive change is called for. In general, I would say it’s not something to worry about…if your prototype doesn’t sell the concept, you should have the opportunity to make another one in the future.

I also mention this simply because I just so happen to have been involved with a prototype that was redesigned from the ground up 12 hours before it was due. Don’t do this, okay?

Closing Down

Whatever the situation may be, it’s better to let your mistakes shine BEFORE you start making a full game. This is the true purpose of the prototype. A prototype is a test run, allowing you to give your concept a chance before risking the world. Sometimes, it can hurt to know that your prized design doesn’t work, but it hurts a lot less to discover that before you’ve invested the time to develop the game.

Incidentally, prototyping also allows you to imagine, however briefly, that a typical crunch period only lasts for a few days.(source:gamasutra)


上一篇:

下一篇: