脚本系统
我们从第 7部分
游戏网络问题来到了脚本系统
其呈现故事叙述机会最近已经形成
种很大游戏元素
在个需要以受控制方式解释情景预先编制电影脚本是解决问题思路方法在电影中这通常用来处理或者由主角向个伙伴解释情形或者敌人对英雄解释当然有其它思路方法来做这件事情 -- 叙事者倒叙等等 – 但通常是使用实时情景人们和事件来完成当然游戏是区别游戏开发者在他们平常FPS中不应该做太多倒叙通常会需要载入新环境或者关卡以及新纹理和/或模型所有这些额外处理和渲染能影响到主要游戏序列性能你可以重用已经存储在内存里面场景元素来倒叙但那样会看上去明显比较粗陋RavenSoft
Star Trek Voyager: Elite Force广泛利用了脚本序列产生游戏中事件和使用游戏引擎本身剪辑场景在游戏中设计脚本情节
个有趣趋势是使用当前极大改进了3D游戏引擎自己产生剪辑场景现在这可能像是相当地明显但是数年以前当 3D 图形卡还比较简单时候剪辑场景通常使用高端3D工作站制作得到3D动画然后被记录为个数字视频文件以流式文件存储在CD-ROM你从剪辑场景漂亮图形画面回到真实游戏相对粗陋3D画面这是相当令人不愉快失望事情但像Half-L
e 和 Star Trek Voyager : Elite Force这样游戏很好地利用了它们自己引擎产生所有剪辑场景结果是剪辑场景和游戏的间过渡更加平滑把脚本和人工智能区分开来可能是个很好
主意脚本是你完全控制着个给定场景建立玩家几乎总是没有控制事件游戏者‘沿着轨道’移动到个给定地点或者建立个游戏玩家需要解决情形个好例子可能是巨石掉在走廊上需要游戏玩家找到个新逃脱思路方法 如今有
些区别类型脚本系统可供
员或者美术师使用而且它用非常有条理和逻辑思想恰当地做这些第种是简单基于文本单线索风格就像我们员习惯编码在许多情况它实际上基於 C尽管以种非常简单形式 大量这种类似“ thisthen do that”东西大部分脚本倾向在范围内是相当线性—意味着它通常由许多在次序上彼此相接命令组成在世界中移动角色A指向B当完成以后让他讲话完成以后移动他指向C相当简单事情然后有复杂
东西--允许多重线索和实际上允许可变情形可变情形是当脚本开始时你实际上不能确知谁会出现在附近但是你必须按这样方式编写脚本以便任何人出现在附近它都将会工作举例来说--个正常简单脚本会有 3个家伙全部被预先定义全部有组他们将会讨论情形个可变脚本将会有 3个人,你不能保证是某个特定人并必须按相同方式工作或者在个极端情形中也许只有 2个或者甚至个家伙将会在那里使得 3方交谈有点困难 Raven在Star Trek Voyager: Elite Force中面临
个很大问题是这样情形使用者可能会想要把个角色从条船某个地方带到另外个地方但是从A点到B点路径可能会随着每次游戏根本地改变举例来说他们需要让Munro(你所扮演游戏主要角色)从发动机舱室到输送舱 不幸是由于游戏非直线性在事件到达这点以前你可能已经破坏了涡轮升降机或者也许 Jeffries 管被损害不能通过假定当脚本开始时候我们不知道世界状态我们不得不为几乎各种可能发生事情编写脚本以便适用于这些‘如果如何办’情形而且它仅仅从那里变得更加糟糕我们能建立些情形提供了如此多可能组合情形以致于为了个满意结论而准确测试每个可能发生事情几乎是不可能请和在SiN, Star Trek Voyager : Elite Force or Deus Ex中工作任何人谈谈QA部门传统地憎恨这些类型游戏这已经使他们工作比以前更加困难了 50 倍 你能够想象为这些情形编写脚本是何等
困难但那是今天非线性游戏路径要求事情而且它为何博得了较多开发支持从而能够努力实现它Jim Dose有关脚本系统
论述去年底我访谈了Jim Dose--Ritual
前任开发者现在是Id Software个开发者Doom3脚本系统(和其他些事情)设计者尽管这次访谈有些久了但仍然是很有洞察力 Jim谈了脚本系统和创建
个易用且健壮系统( 和包含设计者传统想要使用所有特征相反): 设计
个脚本系统最难部份是知道何时该停止旦你完成了并开始运行你发现有许多能够利用它系统对于Sin最初主意只是要有个比较容易思路方法让关卡设计者描述对象怎样动态在环境中移动在项目后期我们也使用它来让声音和游戏事件和动画同步在多个关卡跟踪任务目标控制HUD布局和游戏内部电脑控制台用户接口描述人工智能如何对区别情形产生反应以及粒子系统控制复杂度可能也是相当
困难当你把脚本力量放进有创造力人们手中时他们开始探究他们所能做界限时常他们受启发做些刚好轻微超出系统能力范围事情很容易陷入到这种增加‘仅仅再多个特征’就允许他们做他们想做事情的中随着语言增长个可能对最初规格有意义语言结构变得严重过度扩充了在些时候重新研究系统变得有意义但在那时你可能已经积累了数量巨大必须重新编写脚本和FAKK2样Sin遭受了这样损失我没有得到对脚本系统进行大规模彻底检查机会直到我为Rogue's 'Alice'.重写了脚本系统阿们
吉姆-- Raven已经看到这个恰好在他们ICARUS系统中出现了ICARUS 实际上是种和Jim在上面描述相同种类脚本系统而且负责在Star Trek: Voyager: Elite Force中所有脚本事件它在Soldier of Fortune II和Jedi Knight II : Outcast中被重复使用为了解决系统需要处理新问题这些问题在最初实现中没有被预见/不需要脚本系统很多部分已经被重新编写了可视化脚本系统
第 2种类型
脚本是可视化脚本系统使用这种思路方法而不是文本文件编码方式实际上你能够在真实游戏环境中使用真实角色建立你脚本你能够追踪角色在世界中行走路径定义使用动画并且通常得到有关你脚本实际上将看起来如何更好主意它对我们已经讨论非线性问题没有太大真正帮助但它确实可以很快速地生成最初脚本其次
Jim谈论了可视化脚本系统 可视化脚本系统确实有它们
用处但往往实现更加困难如果设计得很差当复杂度上升时就容易让开发者感到困惑举例来说人工智能可以用个流程图似结构来进行可视化设计你能非常容易地可视化地表现人行为举止方式用盒子代表状态箭头代表转化到其它状态指示角色能够从个状态转换到另外个状态方式脚本
种通常使用是在游戏世界中控制物体指示他们他们如何在世界中移动在个编辑器中可视化地移动物体到关键位置并播放整个运动能力对个设计者可能会更加直观然而它确实有它极限将需要另外个接口来设计物体在它移动中必须作出任何决定那种能力是把脚本动画片断和类似3DS Max或者Maya 这样产生动画区分开来在
些时候使用者可能需要些思路方法决定个脚本为何没有做他们所期望事情些形式除错工具能使这件工作非常容易至少决定哪些脚本正在运行和脚本当前位置些思路方法必需在脚本中检查变量开始停止和单步执行能力也是有帮助通常个师能够在他们调试器中进行除错但这个过程要比如果有些内建脚本调试器可用时花费时间更长以上就是第8部份
在接下来章节中我们将讨论使用现成产品和定制游戏引擎设计工具功过得失然后探究游戏控制机制开发游戏对象和些刺激有趣事情 (武器系统)
最新评论