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

分享创造游戏原型的3个经验和要点

发布时间:2012-01-21 16:44:28 Tags:,,,

作者:Dave Toulouse

我过去也尝试着自己创造“原型”,但是比起真正的原型,它们看起来更像是一些“技术演示”。我会将游戏代码组合在一起,而如果我认为这个组合体具有潜质,我便会围绕它开始制作游戏。但是如果我只是认可它具有某些模糊的潜质而不是确信“它很有趣”,那么这个原型便还不足以变成一款游戏。

以下我将列出创造游戏“原型”的注意要点:

game prototyping(from lostgarden.com)

game prototyping(from lostgarden.com)

避免将太多时间浪费于无意义的内容中

尽管我正在使用AS3创造原型,但是我却不敢保证在创造最后的游戏时是否仍会继续使用AS3。在AS3的帮助下我能够轻松快速地实践一些设想好的理念。同时我也发现有时候当我尝试着去修定一些针对于AS3的内容时,例如安插多个位图时,其它程序的运行速度将会同时放缓。虽然我们必须立即明确这个问题,但是现在却不能浪费多余的时间去解决它。这并不是创造模型的要点。我们现在应该关注的是测试理念,而不是去考量那些不能用于最终游戏中的代码。

这种情况经常发生,而每次我都会极力地提醒自己看清楚要点。我必须暂时努力忘记自己是一名程序员,而更加专注于制作一些有趣内容而不是编制合理的代码。在这之后我将会有更多时间去解决这些问题,而现在在我眼前还有更加重要的工作。我总是需要不断地问自己“现在所做的是否还有意义?”

缺乏情境的游戏机制

我最初的想法是在思考关卡设计之前应该尽可能地创造出有趣的核心机制。但是事实证明我的这个想法是错误的。如果我是在一个较为混乱的情境下执行机制,我可能误以为这个机制出了毛病,尽管事实上是情境造成的影响。这就意味着为了能够更好地测试核心机制,我们必须添加一些看起来不是那么重要的功能。

举个例子来说,我的目标是测试我是否能够在太空中创造出一个秘密的游戏场景。虽然这么做很简单,但是如果只是单纯的秘密设置便会非常无聊。我必须避免雷达,避免到处飞行并避免那些NPC等。为了创造出秘密的原型,我创造了一个简单的任务。虽然创造任务很简单,但是我同时还需要思考任务系统(游戏邦注:包括开始,目标,结束)以及一些我认为当前不会接触到的内容。但是如果不设置这个任务,我又很难去测试游戏机制并判断它们是否合理。

所以我便开始致力于创造任务系统,而这时候我就需要再次注意是否会在一些不重要的内容中浪费太多时间。当我在添加任务系统时首先需要思考的是“我想要添加的是什么类型的任务”。因为我并不是要创造一个完整的任务系统,我只是想借此测试我之前所创造的内容。如果这么做能够获得关于原型的有益反馈,那就达到了我在这个阶段的目的。

可使用过去代码但不一定是旧理念

在过去几年里我曾经参与了3款太空主题游戏的开发。这就意味着我拥有一些关于这类游戏的代码,为了节约时间我可以将其复制到现在的游戏中。但是这么做的弊端在于,我将会把自己禁锢在之前的思维中。因为之前的那3款游戏都不甚成功,所以我自然不会愿意再复制那些相同的问题。因此我便从头开始自己编写代码,并从不同角度去思考游戏理念。这么做让我能够明确地区分现在所创造的原型与早前太空游戏的区别。

一个很好的例子便是AI。我需要某种“追随路径”的行为,而这也是我在之前的游戏中找不到的,并且因为游戏代码都太过混乱,如果要节省时间,我只能重新编程。目前为止我都能够轻松地添加一些新的行为,所以我认为这是一种创建原型的好方法。

结语

虽然我尚无法给予太多建议,但是我认为,比起“潜质”,“乐趣”更加重要。因为如果原型本身是有趣的,我便会想围绕着它创造出游戏。

本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

Learning how to build a prototype

Dave Toulouse

I built “prototypes” in the past but they were more “tech demos” than actual prototypes I guess. I would put code together, look at how it feels a bit and if the answer was “yes there’s potential here” I’d go and build the game from there. It wasn’t enough as I should have said “yes this is fun” instead of just admiring some obscure potential.

I’m now working on what I hope will be a proper prototype. Now that I’m trying to do this properly I’m finding this way harder than I thought it would be. You could say that creating a bad game is way easier than creating a fun prototype… well beside the whole “I need to make sure this looks really good” part …

Avoiding to spend time on meaningless stuff

Even though I’m using AS3 to work on this prototype I’m not sure if I’ll indeed be using AS3 for the final product. It’s just easier and faster for me to get something done with AS3. Still I found myself at times trying to fix some stuff specific to AS3 like when you put multiple bitmaps with their alpha >0 && <1 on top of each other it really slows down everything. While it’s nice to know about this problem right away I can’t waste time trying to fix this right now. This is not the point of the prototype. The point is to test an idea and not to prepare code that will be used in the final product.

It happened a few times so far and each time I feel like slapping myself when I get distracted this way. I need to forget about my reflex as a programmer and focus on making something fun instead of something nicely coded. I’ll have plenty of time later to refactor what needs to be fixed once I know that I have something good in front of me. Maybe it sounds easy to others but I’m struggling a bit with this. I constantly need to ask myself “is this part of the cake or the icing?”.

Mechanics without context

My first thought was that I needed to make the core mechanics fun before thinking about level designing. Seems I was wrong at least for this specific idea. If I implement mechanics in a context that is a mess than I might be lead to believe that there’s something wrong with the mechanics while it’s really the context that screw everything. This means that to test the core mechanics I have to add what might be considered less important features.

Here’s what I mean. My goal was to test if I could create a stealth game set in space. Easy enough but stealth just for stealth is quite boring. Avoid radars, fly around, go far far away to avoid NPCs… Well the prototype needed a goal to make stealth matter so I created a simple mission. A simple mission but yet that meant that I had to think about a mission system (start, objectives, end), something I thought I wouldn’t touch at the moment. Without this mission there was no flow to test the mechanics and it was hard to figure out if they sucked or not.

Now of course working on this mission system I had again to be careful to not do too much about it to avoid spending time on things that are not important at the moment. First thing I thought about when adding the mission system is “oh what are all the types of missions I could do”… I took a deep breath and focused on just one. I’m not building a complete missions system… I’m just adding it to test properly what I’ve been trying to test since the beginning. So far it paid off if just to get people to talk a bit about what they think of the prototype (feedback still welcome by the way!).

Using previous code but not necessarily previous ideas

In the past year I worked on 3 games with a space theme. This means that I have a lot of the math involved in this type of games already figured out and that I can copy/paste a lot of code which saves me a lot of time. The downside is there’s the danger of limiting myself to what I have done before. The 3 previous games were not quite successful so obviously I don’t want to just build yet another clone with the same problems. Because of this I forced myself to rewrite from scratch some parts of the code just to approach the concept from a slightly different angle. It helps me to draw a line between this prototype and the previous space games I built.

A good example here is the AI. I needed some kind of “follow a path” behavior which I didn’t have in the other games and the code was a mess anyway so I probably saved time by starting from scratch anyway. So far my approach has allowed me to easily add new types of behavior so I’d say it’s perfect for prototyping.

Tips on how to build prototypes

A quick Google search should give you plenty of tips but here’s a bunch I’ve seen recently: https://plus.google.com/111531678448813802110/posts/9ra8bwfPAhb

I wouldn’t be able to give advice on prototyping since this is my first “real” one but I’d say that the only word I have in mind is “fun” and not “potential”. Once the prototype is fun by itself I’ll move on to create a game out of it. You can search this blog and I’m sure you’ll find some posts talking about prototypes but they’re just some demo of code I put together without caring about how I’d turn this into a game. I had these games in my mind only and never bothered to check if I was on the right path before investing way too much time.

So yeah I guess building prototypes is a bit more complex than what I thought it was. Good for me if I learned something here.

Oh and why another prototype so soon after Star Corsairs? Well let’s say that with experience you develop a sixth sense that tells you where you should be investing your time next…(source:over00


上一篇:

下一篇: