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

游戏关卡设计经验之内容由简入繁

早前,我决定在《THE OCTOBER GAME》中植入有计划的关卡,而不是随机关卡。这个决定令我遇到众多复杂问题:

游戏的核心理念非常简单,玩家向上跳跃,攻击飞过屏幕的敌人。

core mechanic from eliolhan.com

core mechanic from eliolhan.com

一个复杂元素是,有些敌人击中后能够带来收获,有些则会带来糟糕影响。

good enemy vs bad from eliolhan.com

good enemy vs bad from eliolhan.com

游戏需要具有多样性,所以我设计各种积极的攻击反馈:食物和奖励。

food and bonus types from eliolhan.com

food and bonus types from eliolhan.com

更具体的子类型包括不同分数、行为和外观。我可以随意扩展机制。在这款小型游戏中,我将设置6种敌人、3类食物、2种奖励、1种危险及1种无形的无效元素,旨在间隔各类内容。它们从屏幕上看面积很小,而且移动非常迅速,所以我保持色彩的简单性。

full cast from eliolhan.com

full cast from eliolhan.com

我添加更多能够进行调节的参数,例如线性和弯曲路线,外加不同的飞行方向。

curves and directions from eliolhan.com

curves and directions from eliolhan.com

移动空间局限于5个飞行跑道上,所以我能够有目的地堆积成列的敌人或者将危险物放置于离玩家更近的地方。

lanes from eliolhan.com

lanes from eliolhan.com

这让每列敌人能够拥有350种变体。

columns from eliolhan.com

columns from eliolhan.com

连同速度和间隔,这能够带来更多的变化,让我们设计出趣味横生的关卡。

这样你就能够基于少量的可调节参数呈现出丰富的多样性。若我不是从简单元素着手,那么融入多样性很快就变得让人招架不住。

虽然手动制作关卡并不是非常困难,但我们无法基于此预测关卡所将呈现的感觉:

raw level spec example from eliolhan.com

raw level spec example from eliolhan.com

所以我需要创建关卡编辑器,这比我想象中的难很多。

enemy spec cell from eliolhan.com

enemy spec cell from eliolhan.com

我在《THE OCTOBER GAME》尝试的首个关卡编辑器是个颇具启发意义的失败案例。

编写代码颇具趣味,这促使我一股脑投身于项目之中,然后逐步陷入日益提高的复杂性中不能自拔。为避免这一问题,我从具有可行性的最简单内容着手。

最简单的内容就是不融入关卡编辑器,但这存在相应的问题。就如我之前提到的,我们可以通过指定敌人的各种属性(游戏邦注:包括类型、方向、运动曲线、飞行数量和飞行跑道)制作关卡。

enemy datum from eliolhan.com

enemy datum from eliolhan.com

1列敌人被称作AttackGroup。1组AttackGroups组成1个关卡。1组关卡组成1个游戏。

game entity hierarchy from eliolhan.com

game entity hierarchy from eliolhan.com

关卡将变得越来越难,目的是向玩家呈现真正的挑战。我发现30是游戏长度和关卡创建所耗精力的最佳平衡点(游戏邦注:作者称这个数据是经过适当考虑和认真研究的,绝非凭空捏造)。

结果证明,手动创建关卡很难进行预测,不仅容易出错,而且还非常缓慢。最明显的解决方案就是,从更抽象的层面着手。这意味着我们需要创建图形工具以设置敌人,呈现他们的即时互动。从理想角度看,这将带来一个能够植入游戏应用且配合测试工作的格式文件。

swarmful app icon med from eliolhan.com

swarmful app icon med from eliolhan.com

这里的核心构思是创建包含动态预览的网格编辑器,无需融入详细结构,而只是切换分布于网格中的各类敌人。时间是由一个简单的滑动器控制。我觉得我可以先从这些基本要素着手,若内容运作顺利,再进一步进行具体化。

Swarmful interface sm from eliolhan.com

Swarmful interface sm from eliolhan.com

创建这些内容花费我几天的时间,我学到许多关于制作自定义控制装置的知识。我对此非常满意,直到我意识到,简单运动机制无法容纳重要的玩法功能:各种敌人飞行模式。我没有移植实际游戏应用中的动画机制,相反我决定终止有关编辑器的工作,专注于更直接的游戏功能。

所耗时间:2天

所获经验:从最低关卡着手,逐步提高其复杂性。将简单的控制装置拼凑成更大规模的内容。设置自然的停止点,这样项目就不会无限期延续。

所犯错误:应该在制作代码前更多地进行设计内容的规划

随着手动创建关卡难度的提高,我转而创建另一关卡编辑器。(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

The Level Editor Sprint, part 1 & Pt.2

Early on, I decided the THE OCTOBER GAME would have designed levels rather than random ones. That decision led to significant complexity, here’s how:

The core of the game is simple, the player jumps up to hit enemies flying across the screen.

As a complication, some enemies are good to hit and some are bad.

The game needed variety so I made multiple kinds of good hits: food and bonus.

Further subtypes allow for different scores, behaviors and appearance. The system could be expanded as far as I wanted. For this small game, I wound up with six kinds of enemy. Three food types, two bonus types, one danger type,  plus an invisible null type, used for spacing. They’re rather small on screen and they move fast so I kept the colors simple.

I added a few more adjustable parameters like straight and wiggly paths plus different flight directions.

Movement is restricted to five flight lanes so I could predictably stack columns of enemies or put danger closer to the player.

This allowed 350 variations for each column of enemies.

Along with speed and spacing, that would allow enough variation to design fun levels.

And that’s how you get complexity from a tiny number of adjustable parameters. If I hadn’t started simple, adding variety would have quickly become overwhelming.

While it wasn’t that hard to generate a few levels by hand, it soon become impossible to predict the feel of a level just by looking at this:

So I needed to construct a level editor, which was harder than I expected.

My first attempt at a level editor for THE OCTOBER GAME was an instructive failure.

Writing code is fun and this leads me to jump into projects, then drown in rising complexity. To counteract this, I try the simplest thing that could possibly work.

The simplest thing was no level editor, but that had it’s own problems. As I mentioned before, it was possible to make levels by specifying all the attributes of each enemy by type, direction, motion curve, number of flybys and flight lane.

A column of enemies was called an AttackGroup. A set of AttackGroups made up a Level. A set of Levels made up a Game.

The levels would become progressively harder in order to present a real challenge to the player. I figured about thirty would strike a balance between game length and level creation effort. That number was arrived at after due consideration and careful research, and in no way from thin air.

As it turned out, building levels by hand was hard to predict, error-prone and very slow. The obvious solution was to work at a higher level of abstraction. That meant creating a graphical tool to configure enemies and display them interacting in real-time. Ideally, it would output a formatted file to drop into the game app and playtest with.

The big idea was a grid-based editor with motion preview. No need for detailed configuration. Just touches to toggle through the various enemy types laid out in a grid. Time was controlled by a simple slider. I figured I’d get the basics done and if that went well, I could elaborate later.

It took a couple days to get it built and I learned a lot about making custom controls. I was pleased with it until I realized that the simple motion system (just sliding two grids of buttons around), wouldn’t accommodate an important gameplay feature: multiple enemy flybys. Rather than migrate the animation system from the actual game app, I decided to halt work on the editor and concentrate on more direct game features.

Time spent: 2 days

Lesson learned: Start from the lowest level and build up complexity. Compose simple controls into larger ones. Have natural stopping points so the project doesn’t drag on.

Mistakes made: Should have planned the design more before coding.

Later, when the pain of hand-building levels grew again, I built another editor.(Source:eliolhan part 1part 2


上一篇:

下一篇: