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

适合小型游戏快速创建原型的方法

发布时间:2016-12-28 16:30:04 Tags:,,,,

作者:Jakub Kasztalski

对于我最初的两款游戏《Postmortem》和《Karaski》,使用的传统工具去管理游戏数据,以下便是有关游戏对话树的例子:

karaski129-indie-game-dialogue-sneaking(from gamasutra)

karaski129-indie-game-dialogue-sneaking(from gamasutra)

我使用了免费的yEd图表编辑器以及一些自定义编码将XML数据输入我的游戏中。我同时还为所有游戏内部文本内容解析了一些简单的文本文件。这一系统非常有效,但却需要花些时间进行设置与调试。当我开始致力于自己的故事/冒险游戏《HEADLINER》时,我便更倾向于快速原型创建。我不想再去想全新的数据结构并再次在JavaScript上编写分析程序。正是在这时候我想到了,为什么不直接在代码中明确我的数据呢?

newspapers中的简单字符串

阅读newspaper数据字符串的“适当”方式便是去创造一份清楚的JSON文件,对其进行解析并创造适当的对象。但我略过了中间人而直接在独立的JavaScript文件中定义了它们。如下所示:

headliner-newspaper-files(from gamasutra)

headliner-newspaper-files(from gamasutra)

它几乎没有任何语法问题,我可以通过简单整合JS文件而拥有一个即时可行的数据结构。我并不需要进行任何“加载”或解析。我同时也添加了一些脚本对象(如ReqApproved),如此我只需要检查每个游戏日去判断是否需要呈现特定paper。

交谈中的条件分支

因为我并未计划太多分支,反倒我希望看到的是条件反应,所以我需要设置一些if/else条件,这是参考world-state变量并设置它们的一种方法。即意味着编写一个分析程序并执行一些脚本形式。再一次地,我意识到,不,等等,为什么要编写代码去解释代码?我可以直接写下代码的。所以我的交谈将变成另一个JavaScript文件。我写下一些辅助功能去设置NPC的讲话或获取代币等等。

neverwinter-nights-dialogue-editor(from gamasutra)

neverwinter-nights-dialogue-editor(from gamasutra)

我们并不需要去解析代码,因为它是自动执行的。它需要的是更多语法问题,但一旦你能理解一个奇怪的结构和辅助功能,这些语法问题便是可解决的。

headliner-conversation-files(from gamasutra)

headliner-conversation-files(from gamasutra)

实体和NPC

为了创造一个充满真实的生物和吸引人的战利品的世界,大多数游戏都使用了编辑器在3D或2D空间呈现这些内容。然后游戏将在开启时加载这些“场景”并创造所有明确好的实体。然后就是各种解析。

我并未使用Phaser和JavaScript去这么做(而如果你想要一个开箱即可使用的方法我还是会推荐你Phaser Editor),基于各种不同条件每个游戏日也会有所不同。所以就像之前那样,我划分了代码本身:

headliner-npc-spawning-code(from gamasutra)

headliner-npc-spawning-code(from gamasutra)

基于一些辅助功能以及关于位置标记的预设常量,我将能够快速创造游戏世界。因为这是一种代码,所以我可以通过检测变量,事件触发器或随机结果去自定义每个游戏日。如此无需输出或解析第三方编辑器,我便能够马上呈现出所有改变内容。这非常适合在一个地方调整内容并确保所有内容的清楚有序。

这一方法并不适用所有人

需要注意的是,这一基于代码的数据方法只适用于原型创建或拥有容易管理的数据且所有参与游戏制作的人都清楚代码基础的小型游戏。如果使用得当的话这将能帮助你省下许多时间,但是对于基于更复杂结构或拥有明确团队角色的更大型项目来说就不是如此了。这也是我要设置整个系统从第三方图表编辑器(拥有关于我的前两款游戏的交谈的脚本支持)中输入XML数据的原因。在两年的制作中我发现从视觉上编辑对话的能力非常重要,即使是我那非技术型作家也能有效使用该方法。但如何尝试在代码中定义这一方法将会很可怕:

karas64-indie-game-dialogue-tree(from gamasutra)

karas64-indie-game-dialogue-tree(from gamasutra)

所以就像在线游戏开发教程那样,考虑一些常识也很重要。这也只是一种适用于特定情况的特殊工具。

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

Rapid Prototyping Tip: Defining data as code files

by Jakub Kasztalski

I used the free yEd graph editor and a bit of custom coding to import the XML data into my game (read about it here!). I also parsed simple text files for all the in-game text items like newspapers. The system worked great, but took a while to set up and debug. As I started on my current experimental story/adventure game HEADLINER, I was embracing a more rapid-prototyping mindset. I did not want to come up with new fancy data structures and write parsers yet again in JavaScript. And it occurred to me – why not define my data directly in code?

Simple strings in newspapers

The “proper” way to read the newspaper data strings would be to create a neatly laid out JSON file, parse that, and create appropriate objects. But I skipped the middle-man, and instead defined them in a separate JavaScript file directly as objects and arrays. Here’s what it looks like:

It’s barely a little bit of extra syntax fluff, and I had instantly-accessible data structure I could reference by simply including the JS file! I didn’t need to do any “loading” or parsing either. I also dded a few scripting members (like the ReqApproved) that I’d just check each game day to see if given paper should show or not.

Conditional branching in conversations

Previously I used graphs for flexibility, and many RPG games used flat text files or the (godawfully difficult to follow) trees, like in Neverwinter Nights.

Since I didn’t plan on too much branching but wanted conditional responses, I’d need to set up some if/else conditions, a way to reference world-state variables, and a way to set them. Meaning: coding a parser and implementing some form of scripting. Again, I realized – wait, why write code that interprets code? I can just write code directly. And so my conversations became yet another Javascript file. I wrote a few helper functions for setting what the NPC says or getting tokens like Player Name, and boom!

No need to parse code or tokens, since it’s automatically executed. Yes, it does require more syntax fluff, but it’s pretty manageable once you get the hang of the weird structure and helper functions (like SetThread() or AddResponse()).

Entities and NPCs

To create a world brimming with lively creatures and lucrative loot, most games have some sort of editor to visually place those in 3d or 2d space. The game then loads these “scenes” at startup and creates all the entities as defined. Parsing, parsing, parsing…

I didn’t have that with Phaser and JavaScript (though I recommend checking out the Phaser Editor if you’d like an out of the box solution), and each game day would vary a lot depending on numerous conditions. Like before, I differed to the code itself:

With a few helper functions (Spawn two NPCS with a dialogue, spawn a group of protesters, spawn a rioter who runs and throws a molotov etc.) and pre-defined constants for locations markers, I could quickly create my game world. Because it is code, I could customize each game day by checking for variables, event triggers or randomizing results. All my changes showed up instantly without any exporting/parsing from a 3rd party editor. And it was good for tweaking, keeping everything neatly in one place (rather than closing/reopening multile “day scenes” or tracking conditionals on each entity individually).

This solution is not for everyone

An important caveat needs to be made. This data-in-code approach is really meant for prototyping or small games where you know the amount of data will always be manageable and everyone working with it knows the basics of coding. It can be a huge huge time saver when used properly, but a hindrance on bigger projects with more complex structures or delineated team roles. There is a reason why I set up a whole system to import XML data from a 3rd party graph editor with scripting support for conversations in my first two games. Over the two years of production, the ability to visually edit the dialogue was very important, and it allowed my non-tech savvy writers to work with it as well. Trying to define THIS purely in code would have been a disaster:

So, as with any online game dev tutorial, exercise a bit of common sense. It’s just a specific tool meant to be used in specific situations.

Curious about my games?

The project that inspired this blog is HEADLINER, story-driven game where you control public opinion and (potentially) start a riot. Check out the official page here. Better yet, why not follow me on Facebook or Twitter for updates and other game dev nuggets of wisdom?(source:gamasutra

 


上一篇:

下一篇: