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

分享制作《刺客信条4》海战原型的方法

发布时间:2014-07-23 16:22:59 Tags:,,,

作者:Sebastien Lambottin

我是《刺客信条4:黑旗》海军玩法的主设计师,我将在本文与各们分享我创建原型的方法:创建一个玩法原型库。

我知道制作原型对于游戏开发团队来说并不陌生。我认为这其中的特别之处就在于我是重复使用相同的外部引擎来制作原型,我已经创建了一个可让我重用于多个项目的功能库。

以下就是我们用这种方法为《刺客信条4》创造原型的一些例子:

figure 1(from gamasutra)

figure 1(from gamasutra)

-这是用于每艘船的AI原型,是其AI最基本版本的原型(护卫舰、战争中的人……)

figure 2(from gamasutra)

figure 2(from gamasutra)

-这是我们的弹道射击机制原型,对于评估我们的制作难度来说尤其有帮助。

figure 3(from gamasutra)

figure 3(from gamasutra)

-这是用于船只的基本AI导航原型,用于确定船队将对玩家构成的挑战。

这些原型的部分结果就是产生了玩家武器舰的结构:

这个方法的要点

现在你已经看过我们原型的一些例子和结果了,我想进一步详述我的方法:

总体上来说,我利用这些原型所瞄准的目标就是加快设计的迭代速度,并且让我在AAA开发团队中获得更多创意。

在一定程度上可以说,我是受到概念美术人员工作方式的启发而创建这个玩法原型库。

他们通常会在多项作品中使用相同的工具:Adobe Photoshop。它是一项外部工具,并且拥有庞大的用户社区。

photoshop 1(from gamasutra)

photoshop 1(from gamasutra)

他们持续使用相同的工具,并因此创建了一个可用于多个作品的笔刷和纹理库。

photoshop 2(from gamasutra)

photoshop 2(from gamasutra)

A-选择并坚持使用一个外部引擎

正如美术人员使用Photoshop一样,我也选择了一项不同于团队开发游戏所使用工具的外部引擎。

这里有3个主要原因:

*外部引擎已经拥有一个可能支持你使用该工具的成熟社区。

*你并不需要依赖内部技术团队的特殊支持(你就不必去麻烦他们)。

*你能够持续在多个项目中使用这项工具。这可以让你接触你过去所开发的任何功能,最终就能够创建出一个持续发展的功能库。

B-创建一个功能库

创建你自己的功能库是这个方法中最重要的概念。

当你已经开发了一个基本功能集时,你就能够重用和结合这些功能,并快速创建新原型。

以下是我从创建和维护自己的功能库所得到的一些益处:

1.迷你地图例子

针对射击游戏原型的需求,我编写了一个迷你地图来观察玩家周围的同盟。

之后当我必须为《刺客信条4》的海战编写原型时,我就只需要输入自己数年前为射击游戏原型编写的代码和资产即可。

minimap(from gamasutra)

minimap(from gamasutra)

2.多人模式例子

带有多人模式基础的游戏引擎很棘手,因为它的编写需要花上一些时间。

我在两三年前花了几个月时间掌握了这个复杂的编写基本多人模式的方法。

multiplayer(from gamasutra)

multiplayer(from gamasutra)

出于好玩的目的,我在海战原型中植入了多人模式。我只花了2天时间就在这个原型中添加了多人模式。这是我证明自己的库能够极为高效编写新原型的最佳例子之一。

3.船舰和剑战例子

我编写过许多战斗原型,所以在我的库中有许多清晰的代码和资产。我们也为海战制作了一个原型,之后只是测试了我在海军玩法原型中所植入的剑战系统的一些理念。这花了我一天多的时间,并且再次证明了我将不同原型的不同功能相结合起来的高效性。

sword fight(from gamasutra)

sword fight(from gamasutra)

距离我刚开始编写这些原型已经有4年时间了。所以这个功能库开始变得十分庞大。通过一点一滴地创建这个功能库,我也掌握和提升了自己的游戏编程技能。

C-自己编码

作为游戏设计师,拥有自主编码的能力,并且能够以可玩的方式展示想法,令我在设计中更具创意和准确性。

code it myself(from gamasutra)

code it myself(from gamasutra)

预制作的优秀工具

由于在编写原型方面更为高效,你就能够测试这其中的许多功能。这些原型对于降低风险和测试最为复杂的功能,以及准备投入制作来说十分有帮助。

我这个方法最具雄心的实践应该就是一直用这个方法为所有游戏制作原型,并且只着眼于玩法。

以另一个娱乐行业来打个比方,电影行业就使用了故事板这一超级高效的工具在早期开发阶段来预览自己的电影未来将呈现的模样。

story board(from gamasutra)

story board(from gamasutra)

我一直认为我们在开发游戏之前遗漏了一些评估自己想法的步骤,而完成故事板可能就是我打算用自己的方法来尝试的下一步。

总结

希望本文对其他设计师有所启发。总体上我想表达的是作为游戏设计师,不断提升我们的自主能力,并且在团队中更具高效性总不是件坏事。

我这个方法的关键要点可以用以下这个简单的示意图来概括:

schematic(from gamasutra)

schematic(from gamasutra)

坚持使用相同的原型引擎,这可以使你:

1.扩展你的创意,让你探索新功能:新摄像视角,新交通工具类型,新AI行为车辆……

2.更具高效性,加快你的迭代速度和沟通效率。提升可玩功能的易用性并借此来制定决策。(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

The prototype methodology we’ve used for the naval of Assassin’s creed 4

by Sebastien Lambottin

Gameplay prototyping library

My name is Sebastien Lambottin, I was the principal designer of the naval gameplay for Assassin’s creed 4 black flag and with this article I would like to share with the developer community my prototyping methodology: building a gameplay prototyping library.

I know doing prototypes is nothing new for a game development team. What I consider special about the way I’m doing prototypes is that by using the same external engine repeatedly, I’ve build a library of features that I can reuse from one project to another.

Here’re some examples of the features we’ve managed to prototype on AC4 with this methodology:

- For every ship AI archetype, a prototype of a first basic version of the AI (the brig, the frigate, the man of war…. )

- A prototype for our ballistic shooting mechanic, especially to evaluate how hard and difficult we could make it.

- A prototype for basic AI navigation for the ships. To define the challenge a group of ship would create to the player.

A part of the result of those prototypes was the architecture of the player’s weapon ship:

(For those who have read my article about the pillar of combat design -http://www.gamasutra.com/view/feature/175950/the_fundamental_pillars_of_a_.php – this schematic above will remind you what I was explaining about designing very different and complementary weapons for the player)The main points of the method

Now that you’ve seen some examples and some result of our prototypes, I’d like to go in detail about my methodology:

Overall I’d say the goal I’m aiming for with those prototypes is to increase the iteration speed of the design and also, as a game designer, to give me the ability to be more creative within an “AAA” dev-team.

In a certain way what inspired me about trying to build a gameplay prototyping library is the way concept artists work.

They generally use the same tool from one production to another: Adobe Photoshop. This tool is an external tool, and there’s a big community using it.

As they keep using the same tool, they’ve built a library of brushes and textures which they keep from one production to another.

A- Choose an external engine to work with and stick to it

Just as the artists which are using Photoshop, I’ve chosen an external engine which is different from the in house engine the team use to develop your game.

There’re 3 main reasons for this:

There’s already a community which might exist and support you to use this external engine.

You don’t rely on any specific need from your tech team. (You don’t have to bother them)

You’ll be able to stick to it and keep it from one production to another. This will let you have access to any feature you had developed in the past, which ultimately tends to build a library of features which keeps growing.

B- Build a library of features

Building your library of features is the most important concept of the methodology.

When you have developed a base set of features, you will be able to re-use and combine these features to create new prototypes rapidly.

Here’re some concrete examples which demonstrate the benefits I’ve obtained from building and maintaining my library of features.

I- Mini-map example

For the need of a shooter prototype I’ve coded a mini map to be able to spot the player’s allies around him.

Then when I had to code the prototype of naval combat for AC4 I just had to import my code and assets I had coded few years ago for my shooter prototype.

II- Multiplayer example

Having the base of a multiplayer working in a game engine is quite tricky, and it takes a bit of time to code it.

I spent a few months 2-3 years ago to learn this complex exercise of coding a basic multiplayer.

For fun, I’ve implemented the multiplayer in the prototype I did for the naval combat. It took me just 2 days to add the multiplayer in this prototype. This is one of my best examples to showcase how my library starts to become very efficient to code new prototypes.

III- Ship and sword fight example

I’ve coded many combat prototypes so I have a lot of clean code and assets in my library. In parallel, we did a prototype of naval combat. Then just to test a few ideas I’ve implemented a sword fight system inside the naval gameplay prototype. This took me little more than a day to implement. Once again it shows how quickly I can combine different features I’ve developed for different prototypes.

It’s been 4 years that I’ve really started to code those prototypes. So the library of features starts to be quite big. Also by building this feature’s library, little by little, I’ve learned and improved myself a lot about game programming.

C – Code it myself

As a game designer having the ability to code by myself and showcase my idea in a playable way has turned to make me more creative and more precise in my design.

A good tool for pre-production:

By being more and more efficient at coding prototypes you’ll be able to playtest a lot of feature with them. Indeed those prototypes are super helpful to de-risk and playtest the most complicated feature and get ready for production.

The most ambitious exercise with my methodology would be to prototypes all the game this way, only focusing on gameplay.

To make a parallel with another entertainment industry, the movie industry uses a super-efficient tool to give them an overview about what their movie is going to look like in early development stage: the story board:

I’ve always felt that we were missing some steps to validate our ideas before developing a game, and reaching the level of completion of a story board would be the next step I’d try to go with my methodology.

Conclusion:

I hope this article will inspire other designers. Overall I wanted to express that as game designer it’s always good to push our abilities to be as autonomous as possible, and be more efficient within the team.

As a reminder, the key takeaway from my methodology would be this simple schematic:

Code it yourself + keep using the same tool + build your gameplay prototyping library

1: Expand your creativity, explore new feature by yourself: new camera view, new type of vehicle, new AI behavior…

2: Be more efficient; increase your iteration speed, your communication. Accelerate accessibility to playable feature and rely on it to take decision.(source:gamasutra


上一篇:

下一篇: