《大型多人在线游戏开发》读书笔记

最新推荐文章于 2024-07-12 11:02:46 发布

jinnblue

最新推荐文章于 2024-07-12 11:02:46 发布

阅读量8.6k

点赞数 3

分类专栏：读书笔记游戏编程文章标签：读书笔记游戏开发

本文链接：https://blog.csdn.net/jinnblue/article/details/56488156

版权

原作名:《Massively Multiplayer Game Development》 – Thor Alexander

#一、MMP设计技术
##【卡通城OL:面向大众的MMO】

游戏设计问题：

①孩子家长也必须是销售对象 – a.儿童成人都喜欢; b.借助信赖的品牌; c.角色共通; d.可与家人分享;
②允许有冲突但是须禁止暴力 – a.取消玩家对战; b.工作和娱乐的冲突; c.卡通式战斗; d.机器敌人; e.笑槽;
③太多选择会让玩家无所适从 – a.指南(单人,互动,多人); b.任务(明确目标,提供故事线,多种升级系统提高趣味);
④玩家希望立即享受游戏乐趣 – a.下载时插播游戏要素/背景故事; b.创建角色(定制); c.瞬间移动;
⑤众人面前普通玩家惧怕失败 – a.确保成功; b.观看战斗; c.强调团队合作; d.新手老手一起游戏;
⑥复杂的系统令玩家不知所措 – a.避免用数字描述状态(优先图); b.适当的冗余信息; c.背囊有限; d.合并并统一界面; e.避免不合理的按键; f.使用熟悉的界面; g.隐藏不必要细节; h.让探索充满乐趣; i.不要过于简单;
⑦玩家通常只会玩一小段时间- - 明确的目标可以节约时间;

社会性问题：

①受众对"捣乱"容忍度很低 – 捣乱（指以降低游戏完整性,在游戏中反复骚扰其他玩家的行为）;
②玩家无法容忍那些在现实生活中也会发生的社会问题–比如贵重物品被非法转移等;
③家长不放心孩子上网 – a.提供安全的交流形式(基于菜单的聊天系统); b.现实朋友的私密聊天(48小时秘钥聊天频道);
④与社会特性不一致 – a.永远不要阻止朋友; b.社交(群组友好,聊天泡泡); c.合作性迷你游戏;
⑤刚开始游戏会害羞 – a.轻量级群组(任务临时队伍); b.打破沉默; c.共同的目标; d.朋友列表;

轻量级RPG经验：

①让玩家可立即享受游戏带来的快乐 – 比如游戏最初,游戏指南带入一场战斗;
②避免强迫玩家对不了解的事物进行选择 – 比如最初角色选择与游戏职业/能力分离;
③地理布局应该完全由游戏模式决定 – 比如矿洞挖矿, 码头池塘钓鱼, 空地地标玩家聚集;
④每次进行游戏的时间应该较短 – 比如3小时大任务分解成子任务,增量进行;
⑤允许并鼓励玩家成为观众 – 比如观战;
⑥相比独立做任务,团队合作更有意义 – 尽可能鼓励合作,加强玩家联系;

##【每个人都需要某个人:怎样让玩家合作】

让玩家合作的缘由：
- 降低系统开销 – 假设可承受3000并发玩家,不合作需处理3000个AI,反之,3人/队则只需提供1000个并发AI;
- 使游戏更富于变化 – 使玩家能自行创造快乐会延长游戏生命周期,并带动朋友家人加入分享快乐;
- 使玩家建立起牢固的社会关系从而不愿停止游戏;
玩家非必须下不会自主合作：
- 合作游戏多数情况回报更高,但别错误地去掉所有单独游戏的机会,OL中有很多内向的人,占比超过现实比例;
- 创建一系列不同的任务,它们中一部分适合独立游戏,另一部分适合玩家合作,这些任务最终提供了一个合作性的社会环境;
- 示例： Ultima Online(矿工,炼金等职业任务是搜集并提供冒险物品,可独立完成;同时,通过市场/NPC代卖与其他玩家进行合作);
角色扮演是主流:在玩家可以提供独特功能时合作最为有效;
- 人们参与MMP游戏是因为这些游戏可使他们获得成功,而所花时间比真实世界短很多[从心理学角度来说,这极具吸引力];
- 游戏中成功的定义非常多 – 使玩家具有独特功能,每种功能都可用来满足一类基本的个性化需求,并有助于满足其他玩家的需求;
功能提供模式:
- 预先定义 – “角色分类”(游戏加入很多特性使每种职业有各自的特色,并在合作中提供关键技能);
- 功能定义 – “基于技能”(游戏角色可学习掌握任何技能,但只擅长练习最多的技能,应提供技能指导和搭配建议);
为游戏角色提供挑战:
- 设计游戏内容不断地支持并加强各类型功能,只有组合各类型功能,才能发现和征服游戏中的每一个挑战;
- 挑战,应让不同角色可按照不同策略来组合征服,避免唯一方法导致缺少必备技能玩家而无法征服;
- 不要把角色设计得只能少数情况下使用,而应在不同情况下都有用,避免功能太窄而缺少意义;
保持功能的完整性:
- 拓宽功能时,小心保持每个角色在游戏世界黑暗能地位的完整性,避免削弱某类职业的价值;
- 不应该让某一类角色担当完成游戏中唯一类型的关键先生;比如死亡复活,牧师复活比跑尸复活装备掉更少耐久.
帮助玩家彼此找到对方:
- 视觉区分 – 用差异化的原型/装备区分职业,便于玩家更易寻找;比如在餐馆,我们会方便的找到穿着制服的服务员;
- 节点区分 – 创建可满足某种玩家共同需要的场所,比如拍卖行/教堂/广场,用于交易治疗或聊天;
- 功能界面–例如冒险小组可通过组队UI,搜索特定职业设置为空闲的玩家;
帮助玩家进行交流:
- 在实现玩家可便捷找到对方后,提供一些工具使玩家可管理彼此间的交互;
- 简化交流方式 – 比如战略游戏提供某种界面便于发出简短命令来协调行动;
- 交流不止于交谈 – 比如贸易系统; 比如玩家门口放置商人NPC售卖物品; 比如无主之地中的频死状态闪烁提醒;

##【游戏平衡】

为游戏中的数值建立基线:从项目中的核心系统开始,比如战斗系统;
为数值编写模拟程序:简单地获取用户输入的数据,使用一些原型系统算法对他们进行处理并显示结果; [程序示例见P25];
建立游戏中的度量:对所关心的游戏数值进行长期(按天、月、年或特定时间段进行维护)跟踪和记录; 项目中期;
需跟踪的因素:
- 玩家升级 – 统计玩家升级情况,确定游戏进展是否符合预期速度;
- 物品使用 – 统计物品使用频率如武器挥砍次数/装甲穿着时间,一般使用频率高的物品更强反之较弱;
- 动作行为 --了解玩家在游戏中的时间究竟花在了哪里,是打怪还是制造？比如治疗是战斗时间的两倍,则需提高治疗效果;
内部和外部测试:仅当测试玩家数量接近正式运营期望值时,才可能对游戏进行正确的平衡调整; 封测是无痛测试平衡性的最后机会;
观察玩家动作：
- 玩家对物品/技能/动作的偏爱,升级速度等;
- 注意力放在异常数据,比如过快的升级速度/大量财富; 游戏数据/行为异常通常可指出平衡中的错误;
- 用心观察那些玩家花费大量时间的地方; 增加难度或缩减难度;
发布后对游戏进行平衡：
- 如果某个修改对某些玩家不利,很可能导致他们离开游戏;
- “相对于修复,保留这个失衡的地方是否会导致更多的问题” – “是”,那就应该修改;
- 在修改前将问题告知玩家,并解释该失衡会对游戏的造成的危害;并尽可能补偿受影响玩家;
- 提供论坛,便于玩家提供建议或看法;
对新功能进行平衡:
- 即使加入非常小的功能,在和其他功能相互作用后都可能带来严重后果;须广泛测试避免失衡;
- 建立测试服,鼓励玩家访问并使用它,这样,设计人员可安全地调节数值,降低发布后不良影响的可能;
  ##【用支付矩阵来设计游戏平衡和AI】
支付矩阵：博弈论概念,表示博弈中两个或多个参与者在做出不同决定时的收益和损失;
囚徒困境：

简单的格斗游戏及其纳什均衡:
延迟和停止：定义每个状态所需最少和最多时间,然后为每个状态添加一个转换表,显示该状态完成后可进入哪些状态;
自动化：
- 自动化的矩阵测试; 记录模拟/游戏中的战斗日志;
- 选定敌对者后识别他们可选的动作列表建立矩阵,对当前合法的目标状态进行估价后选则新状态,从而构造复杂的AI系统;
- 估价函数是该AI系统复杂的部分,它必须考虑AI的当前状态及每个合法行为的支付;
- 要在选项中做出选择,加权随机数可用来创建一个简单的[模糊逻辑系统];

##【使用用例来描述游戏行为】

用于设计人员和程序员之间进行关于游戏需求的交流,把游戏设计中的创造性思想系统地映射到一个技术性的设计模型上;
每个用例代表了一个离散的行为单元,它具有定义清晰的作用域、清楚的步骤以及明确的前提条件和后置条件;
识别用例：
- 角色：展示行为的实体; 角色通常位于系统的外部; 比如玩家角色(PC)、NPC、怪物;
- 事件：需识别出产生事件的对象,并为每个事件提供一句话的描述;
- 规则：一个事件是一件单独的事情;一个事件可以用一句话简单地描述;
用例中的元素 – 一个标准模板：
用例模型图：
- 为系统的作用域提供可视化表示;
- 识别用例之间的关系;
- 有助于重构和组织相关的用例来进行子系统设计;
开始实现：不建议从用例直接编码,而是在用例基础上建立更充实的设计模型(特别是序列图);
- ①序列图 – 使开发人员有机会能更详细地考察类接口和对象互动,随着对对象和方法进行详细说明,可逐渐建模一个类结构;
- ②候选抽象概念 – 确定宿主结构; 第一步,识别用例步骤中的名词,将候选的抽象概念具体化为类、数据结构或重要属性;
- ③对抽象概念的分析 – 例如武器抽象:
  - 武器等装备与其他类物品有何不同?
  - 是否不能装备某些其他物品?
  - 是否每个装备了的物品都可以作为武器使用?
  - 为了让模型更简明,排除那些不会成为类、数据结构或属性的候选抽象;
- ④开发一个类结构 – 通过研究候选对象,帮助建立游戏的结构视图;
  随着编写更多的用例,游戏的行为和结构建模将更为充实;
用例的指导方针：
- 描写待解决的问题,而不是解决方案;
- 迭代–用例是探索工具; 从一个与其他未实现的子系统依赖很少的子系统开始,尽可能实现,接着编写相关子系统用例;
- 面对面的合作–设计文档很重要,但程序与设计的沟通与合作更重要;
- 不要指望用例可以捕获所有需求 – 例如安全、性能、延迟、运行期支持(行动报告/客户支持调停)等无法构建用例;
- 交流 – 在向团队领导、制作人、计划经理及其他团队成员描述正在开发的游戏时,作用巨大;
- 避免线性思考 – 刻板坚持第一印象会遗漏重要的游戏需求或识别出无效需求;
- 不要过于强调工具 – 超大型项目可能从某些工具受益,但多数情况会成为负担,最后造成放弃用例;
- 把重点放在清晰的交流上而不是格式上;
- 避免把注意力集中在客户端服务器细节上–比如哪个操作服务端执行,哪个在客户端执行等;
- 把游戏和UI分离开 – 用例不应关心UI交互,比如按哪个键/菜单会导致某某行为; UI是UI,游戏是游戏,要分离,各自进行用例描述;
- 不要强求完全覆盖 – 比如网络、数据库、进程管理等技术早已被实现者良好理解的,不需强求建立用例;
  ##【使用生命值来设计转换因子】
根据物品造成/治疗伤害的能力为其赋予适当的价值,并以此为基础,确定游戏经济系统中大多数物品的价值;
武器的价值：