游戏开发中的Gameplay - 知乎

游戏开发中的Gameplay - 知乎切换模式写文章登录/注册游戏开发中的Gameplay董董董纸上得来终觉浅，绝知此事要躬行写在前面，很多参考文章中还有一些更深的内容，我并没有将其在文中全部展示出来，原因有二，毕竟也是别人作者的知识成果，此外我可能也没有完全理解；小伙伴们有需要可以点进去细读。一、谈谈Gameplay需要强调的点是，Gameplay可能没有普遍接受的定义，本身定义仍然很主观，每个人基于对它的理解可以有一套自己的定义。学术讨论更青睐讨论游戏机制（Game mechanics），而非Gameplay，就概念上而言他们认为后者更加模糊。Gameplay是一个术语，用于定义玩家与特定电子游戏交互的特定方式；进一步拓展则是游戏的玩法，包括：规则、情节和目标，以及玩家的整体体验。以玩家为中心的方法将Gameplay定义为：在游戏体验期间，玩家可以执行的一组活动。Wiki百科中，Gameplay由三个部分组成：“操作规则”，定义玩家在游戏中可以组什么；“目标规则”，定义游戏的目标；“元规则”，定义如何修改或调整游戏。电子游戏中，Gameplay有多种不同类型，如多人合作类型、反应类型（如FPS、节奏游戏）、非对称类型、非线性类型等。此外，从wiki百科中的这张图里，也能反应对Gameplay的理解确实存在差异性。二、Gameplay、游戏机制、可玩性、美学性游戏机制：游戏机制是构成一个电子游戏的基本元素之一，可以理解为游戏的规则，这些基本规则相互搭配，构成一个模型，决定了玩家和游戏之间如何进行互动。从更抽象的角度考虑， 这些规则组织了一系列游戏活动并将其变成一个完整且连贯的内容，单个机制本身更像一个基于原子规则的交互子系统，接收输入并以产生输出的形式做出反馈，输出的展示形态一般体现在机制本身的状态变化或游戏内状态变化；此外该输出还可能会间接触发其他游戏机制的新交互，游戏机制能够持续接收输入并连续做出反馈，对玩家而言，机制具有触发不同交互反馈的功能。图片来源：参考文章美学性：美学性内容核心是触动人的内心，渲染能够在情绪上吸引玩家的氛围，使玩家感觉自己是虚拟世界的一部分，提高沉浸感。引文-“大体上可分为：美术、剧情、动作、音乐、环境设计，但绝非是一个简单的融合体，好的游戏，本质目的是要玩家在过程中有所得；也许是快乐，也许是悲伤，也许是哲理，也许是释放，唯有在游戏中有了获得感，才能打动玩家，吸引玩家持续体验游戏。如果说游戏性是游戏艺术大厦入住得舒适感，那么美术就是游戏得地基，剧情就是游戏的框架，场景设计是材料，动作和音乐是装潢。”可玩性：可玩性指游戏玩游戏的难易程度或玩游戏的持续时间，是衡量游戏玩法质量的常用指标。可玩性通常也用于描述特定游戏系统的玩家体验，当玩家独自游玩或者选择多人游戏时，通过可靠和令人满意的内容来提供享受和欢乐的体验。这样看起来尤其主观，但其实也有一些基本属性用于量化可玩性带来的体验，如满足感、沉浸感、情绪、社交、学习曲线等。Gameplay、游戏机制、美学性、可玩性的关系图：图片来源：参考文章三、设计考量的因素从受众角度出发会是一个不错的思路，了解玩家及其偏好对游戏设计而言至关重要，由此推出真正重要的问题：玩家对一款好游戏的期望是什么？玩家的意见和判断始终源于游戏体验。这一部分基于我的理论知识和经验都不足，暂时作为一个坑吧，具体关于如何设计一个好的Gameplay，如何去将机制、美学运用于实际游戏设计工作当中来，目前来看只能靠大佬们来了。引用的文章链接：Gameplay in wikiGameplay什么是“游戏美学”？到底什么是一个游戏的机制、玩法、内容？为什么游戏性专指玩法？GAMEPLAY AND GAME MECHANICS DESIGN: A KEY TOQUALITY IN VIDEOGAMESWhat is a Game Mechanic?发布于 2023-08-18 01:32・IP 属地广东游戏开发经典老游戏独立游戏开发​赞同 3​​添加评论​分享​喜欢​收藏​申请

游戏程序与开发（gameplay部分）应该如何学习？ - 知乎

游戏程序与开发（gameplay部分）应该如何学习？ - 知乎首页知乎知学堂发现等你来答​切换模式登录/注册游戏设计程序员游戏开发单机游戏游戏开发者游戏程序与开发（gameplay部分）应该如何学习？题主高一，挺热爱游戏的（主要接触的是ns和pc平台），目前有一定C#基础（基本语法会写，除了程序还想做游戏的设计，除了大标题，还想请教知友下面几个问题…显示全部 ​关注者35被浏览36,892关注问题​写回答​邀请回答​好问题 7​添加评论​分享​6 个回答默认排序广鲲开发者中的小学生​ 关注0 想学习的gameplay部分是指想自己实践开发还是想设计好玩的gameplay？那么就当题主的标题问题也是两个吧。0.1 如何学习gameplay设计？多玩，多分析（做笔记，做功课），多实践。先从最基础的非电子游戏开始，如象棋，斗地主，狼人杀开始，分析游戏机制（纯的），游戏的数理逻辑；再到简单的电子游戏，俄罗斯方块，连连看，三消，雷霆战机这一类，自行挑选，也是每个都分析游戏机制，数理逻辑，重点是开始研究关卡（节奏）的机制和数理逻辑；再然后是中等难度的，随意挑选一些类似以撒，恶魔城，空洞，饥荒，炉石传说都可，重点是分析核心战斗系统的操作与玩法的关系，当然上述的基本功一样要做；最后就是想办法实践（抄袭最好），自己去完成一款简单的，好玩的游戏。可以是粗陋的，用免费资源，用其他游戏编辑器来开发均可。但目标是自己真的玩进去，最好能玩个几小时不觉得无聊。0.2 怎么去学gameplay部分的游戏系统开发？那就是简单的把上述游戏笔记里的核心玩法都亲自去实现一遍，所有学习就是从模仿开始。而且，只有真正的自己实现了游戏机制，才会更深刻的理解gameplay，有助于0.1。题主运气太好了，刚好，今天，刚刚发现一个学习利器：杀戮尖塔的mod开发工具，（杀戮尖塔应该知道吧？不知道赶紧steam上买来去玩下！）自己百度下，练习gameplay设计和开发编码两不误。这是我目前见过的开发上手难度最低，设计空间最高，设计见效最快（好改好测），最简洁最省美术资源，做出来就立刻能玩，水平高的话真的无敌好玩，甚至还能卖mod赚钱的超级无敌好东西！（我特么入行时咋就没有这种神兵利器呢。。）1 竞赛有必要吗？对提升编程（解决问题的能力），这种实践还是很有效的，看你有没有时间吧。因为毕竟还是没有0.1， 0.2里的基础技能重要。2 想去做一个优秀作品这个当成目标来一步一步实现会更靠谱。但更需要的是一步一步的去实现。出国留学是可选加分项，但并不能让你真正的懂得如何去实现目标（开发出优秀的游戏）。话说回来现在什么游戏国内玩不到？挨个去学习（抄袭）一遍才是成长的道路。能出国当然好，但目的是到底是什么呢？优势在哪里呢？我能想到的就只有融入国外开发者的圈子了。能做到，当然好，但重点还是要基础，要自己能实现能开发，然后是能找到志同道合的人。当然，能认识国外的开发者那肯定是好的，但肯定没有认识国内的简单嘛。可能是觉得国内没有开发3A大作的公司？emm，读到这里了，你是觉得开发3A大作重要，还是一步一步打好基础，先开发出好玩的游戏更重要？如果就是想加入p社/蠢驴，把自己的名字写进牛掰游戏的开发者名单，体验下国外开发者的生活，以这个为目标的话也不是不可以，但毕竟投胎在国内，走这条路。。。远比投胎在欧美难很多很多。。。如果你出生在欧美，把0.1，0.2做到了，挑个公司上班是较容易实现的。但要从中国跑到国外实现这个目标，就难上很多很多了。而且，还是那个问题，这重要吗？个人觉得还是基础重要（得多得多）。个人经验，自己去主导开发方向才是开发一款优秀作品的开始（仅仅是开始）。而加入好团队，名气显赫的团队，也还是打工而已。当然，要是原本你就定好计划去留学，那肯定是锦上添花。不过呢，再去最好的学校，有最好的老师，加入最棒的团队，都只是加分项，重点永远都是你自己会什么。编辑于 2020-09-15 00:50​赞同 23​​3 条评论​分享​收藏​喜欢收起​腾讯游戏学堂​已认证账号​ 关注Gameplay开发，需要理解游戏玩法，这是一个跨越多职能的工种，需要对玩家的体验有很好的感知能力，对策划需要的功能做出规划。Gameplay程序是一个整合的工种，需要广泛的领域知识，它和渲染、引擎、工具、美术、策划、UI/UX、构建、物理、动画等多种领域都有持续的互动。发布于 2023-05-16 20:50​赞同 1​​添加评论​分享​收藏​喜欢

游戏开发中的Gameplay（程序向） - 知乎

游戏开发中的Gameplay（程序向） - 知乎切换模式写文章登录/注册游戏开发中的Gameplay（程序向）董董董纸上得来终觉浅，绝知此事要躬行终于聊到程序角度的Gameplay了，之前在任意地方一搜Gameplay，显示的内容大多都是和UE的Gameplay框架相关的推送；诚然，UE的Gameplay框架确实把这个概念推的更广了，这也是我后续一段时间会深入的内容，但今天并不会基于UE的这部分内容做详细展开。有一些前置内容，是之前整理的，里面有一些别人的参考文章，也希望大家有时间去看看，深度比我讲的好很多。游戏开发中的3C游戏开发中的Gameplay一、程序角度的Gameplay以3C入题来谈gameplay看起来比较好：“玩家如何控制角色在虚拟世界内游玩，如何观察这个虚拟世界，如何和游戏内的元素交互，同时借助输出设备接收来自虚拟世界的反馈，同时这个过程是持续的。“这句话点出了Gameplay和3C应该包含的大部分内容。对程序而言，这部分从实现角度更像是一个纯工程学的内容，如何从代码层面去实现角色的移动控制（甚至包含攀爬等更复杂的移动方式）、如何控制视角的移动和呈现、如何将游戏反馈最终展示给玩家（通过镜头、外设震动、声音等）、优化游戏体验（包括手感等）、还包含融入游戏的毫不生硬的引导等内容。图片来源：参考文章看看两段对gameplay程序的职位定位”gameplay程序编写交互代码，使游戏变得有趣，策划提供战斗的设计思路，程序负责实现它；和关卡设计师合作，研究如何使Gameplay发挥作用，编写控制角色行为的规则，注意平衡和调整游戏的玩法，同时修复bug和优化游戏体验。“”Gameplay开发，需要理解游戏玩法，这是一个跨越多职能的工种，需要对玩家的体验有很好的感知能力，对策划需要的功能做出规划。Gameplay程序是一个整合的工种，需要广泛的领域知识，它和渲染、引擎、工具、美术、策划、UI/UX、构建、物理、动画等多种领域都有持续的互动。“其中，也可以得到一些信息，Gameplay程序底层逻辑依旧是工程学逻辑；需要理解游戏的体验和玩法，了解如何往好的方向去实现；工作中会持续与其他多个职能岗位的同事协作；Gameplay的开发是一个持续迭代、不断优化体验的过程。二、具体的内容方向这里挑几个工作中碰到的方向来讲一讲，覆盖面肯定不全。框架：很遗憾，对Gameplay而言，并没有所谓的一套底层程序框架就能覆盖所有开发内容，对于不同的游戏品类，之前的一些积累也许部分有用，但大概率很难再新的玩法里全部使用起来；但所幸，日常对Gameplay内容的一些开发工作也会帮助你去提取一些通用模块出来，这些模块哪怕后续不能直接使用，相关的设计经验和思路也能帮助你更快的去搭建一个新的框架原型出来，其实这块就比较考量程序的抽象能力以及有没有这部分的思考了，毕竟日常工作占据了大量时间。方向的话参考：”面对一个问题区间，可以搭建出匹配的有生命力的逻辑架构，这个架构可以完善进化以适应问题需求的适量变化。“。具体例子比如实体管理框架（其中可能还包含属性管理、属性同步等）；另外提下网络同步框架，这块有很多东西是能够抽象出来做一些通用性提炼的，就UE而言，就提供了属性同步、RPC两种形式去做实体属性的同步，也在应用层去构建了握手、重连的机制等.....系统：系统好似游戏机制的一个具象化表现，日常gameplay开发中也会涉及很多系统的开发如任务系统、交互系统、战斗系统、引导系统等等，一是定义一些可玩的游戏机制来承担游戏内容，同时也是基于多个系统间的配合来提高玩家的沉浸感。拎一个常见系统战斗系统出来说说，舒适的镜头控制系统、细腻的打击手感、物理交互效果、不同动画间的衔接、流畅的网络同步环境下，这些需要你对相关内容有一定的把握度已经有一定的经验才能比较好的处理它们配合起来共同呈现；此外技能一般策划会进行堆量，所以合适的配置导出使用机制也是应该考虑的。性能：性能优化的意识要在开发的全过程都有这个意识，稳定60帧和稳定达不到20帧从体验上讲是天壤之别，复杂的游戏性能优化是一个很重要的点，每一帧可能都包含各种物体的交互、逻辑tick模拟、网络同步、动画的展示等，这么多内容需要在一帧里面去展示出来（部分内容不会逐帧，会降频率），留给每一种逻辑的运行时间非常有限，后续这些都会成为游戏性能的瓶颈。具体性能优化考虑两点，一是去使用各种性能测试工具，二是基于经验，分析并发现性能问题，并尝试用更优的优化方案达到优化效果。工作流：影响最终内容产出节点的，一是开发工作本身导致的，二是与其他协作岗位的流程配合上出现了卡点，这里谈谈和其他岗位协作导致的吧。gameplay是一个和美术资源接触很多的内容，也会有很多资源接入的工作配合，有概率会出现程序这边等待资源接入，然后资源延误，所以在最初节点，多岗位间应该讨论资源到位的形式（如分批给到）和节点，同时同步给策划、测试同学确定风险，动态调整节奏。三、引擎向、Gameplay向、工具向浏览游戏客户端招聘信息的时候，会发现三种常见的分类，如游戏引擎程序、Gameplay程序、工具向的程序，当然还有更细的划分，这里暂且不谈论。引擎向：工作内容更多的是为游戏开发提供底层的扩展能力、优化框架和系统，增加游戏开发的技术边界。Gameplay向：工作内容更多的是为基于框架和系统来做玩法内容和乐趣体验。工具向：更多的工作集中在工具管线上，包括编辑器功能的开发维护、日常开发部署工具的维护等。其中这种划分更多的是对专精方向的划分，两个方向的工作有概率出现一定重叠，如果gemeplay开发过程中，从业务层设计了一套更高效的动画存储和加载框架，那么它是属于引擎开发的；而引擎同学仅仅从引擎开了个接口出去供上层使用，这种更多属于gameplay向的工作。引用的文章链接：游戏开发血泪史-Gameplay碎碎念Gameplay programmer游戏程序与开发（gameplay部分）应该如何学习？游戏开发与设计中的“3C”是指什么？（Gameplay程序必看）游戏Gameplay程序员的核心竞争力是什么？游戏Gameplay程序员的核心竞争力是什么？Unreal Engine的Gameplay框架和重点除了渲染，游戏客户端程序员还有哪些进阶方向？如何评价游戏《对马岛之魂》（Ghost of Tsushima）？发布于 2023-08-18 16:20・IP 属地广东游戏开发独立游戏开发​赞同 29​​1 条评论​分享​喜欢​收藏​申请

Unity Gameplay工具集 - 知乎

Unity Gameplay工具集 - 知乎首发于iStep切换模式写文章登录/注册Unity Gameplay工具集DonaldW求知若渴的游戏前端概述本文就数种重要的Gameplay框架及插件，简述它们的原理，介绍这些Gameplay框架的适用场合，并进行对比。本文假设读者有一定的游戏开发经验、Unity开发经验。本文会写得比较随性和啰嗦。关于GameplayWikipedia:Gameplay is the pattern defined through the game rules.Gameplay，游戏性、玩法、游戏规则。Mario & Luigi RPGHearthstoneOverwatch做游戏还是玩游戏，Gameplay都是最最最重要的因素之一。玩家开始玩一款游戏的原因是多样的，表现、心流、炫耀、交友，但其中最有可能的是：好玩。玩家停止玩一款游戏的原因也是多样的，难度、重复、劳累、孤独，但其中最有可能的是：乏味。为了让我们的游戏不乏味，我们必须持续添加内容、更新规则，让玩家持续地感受到新意和有趣。但项目组的人员是有限的、工作时间哪怕加班也是有限的、玩家的耐心也是有限的，如何能让项目组在有限资源的情况下，更好更快地进行游戏Gameplay迭代更新，是Gameplay框架的一大责任。（另，可能一般不会太关注到的点是，我们也不能过度更改我们的游戏。一个游戏当前玩家是已经认可之前版本玩法设定的、受之前版本重重过滤后留下的玩家，如果玩家手上的版本本来是个RAC，我们下一个版本把它改成RTS，那玩家肯定都流失了。比如笔者之前负责过的一款游戏，个人觉得其2.0版本因为对战斗外体验更改过大，是造成2.0版本上线后数据滑落的重要原因之一。）Gameplay框架开始实现各种各样Gameplay时，我们常会编写符合需求，却相对更hardcode的Gameplay代码。这做法有一定好处，其在时间紧急的情况下，能在初期就立刻见成效。随着时间推演，Gameplay需求越来越多、越来越复杂、越来越和自己之前所想不一样的时候，这些之前hardcode的代码就越来越难以维护。此时我们需要重构，需要针对这些各种各样的Gameplay需求，进行归纳总结。（换句话说，上述这种更hardcode的Gameplay代码还有一个好处：其的确能让我们更早地了解细节，更早地知道自己为何重构、如何重构，甚至给重构提供集成测试用例。）世界万物都可被归纳、被总结。我们不能拒绝归纳总结，否则解决一个问题后、再出现类似问题我们又得从零开始苦思冥想。归纳总结可以帮助人去理解并记住结论，让人有可能举一反三。但过分的归纳总结是抽象、甚至可能是无用的、不严谨的。不存在万金油。（“ToE”也尚未被证实。:P）框架也是。框架是必须的，为了更好地提供服务解决某一类问题，我们搭建底层框架。但从我们写框架的第一行代码开始，给它带来功能的同时，也给它带来了限制。即，没有万能的框架、只有适用的框架。在游戏行业中，根据前人的实践、思考，已归纳总结出不错的几种重要Gameplay框架。本文将讨论几种Gameplay框架，讨论它们是什么、它们之间的联系和区别、它们各自的适用场合。它们是：实体组件（Entity-Component）节点可视化编程（Node-based Visual Scripting）状态机（Finite State Machine）行为树（Behavior Tree）事件驱动可视化编程（Event Driven Visual Scripting）非线性编辑（Non-linear editing）并非说以上框架能满足一切Gameplay，但它们组合在一起，相信已能满足颇多需求。这些框架是实用的。本文之所以会提到这几个框架，并非生硬地把它们堆砌在一起。恰恰相反，而是因为作者本人在游戏开发中遇到了实际问题，思考后发现，“这不是恰好可以用这种Gameplay框架来解决这个问题吗？”，通过实验和实践，才体会到这些框架的实用价值。实体组件（Entity-Component）Unity的GameObject/Component是很好的Entity-Component例子之所以把实体组件系统（Entity-Component，以下简称EC）放在最前面，是因为它是最最最重要的、同时也是我们最熟悉的、可能也是我们最容易忽略的。EC不复杂，本人亦曾2度写过EC，分别是Flash游戏《弹道轨迹（TNT）》和一个开发中的Unity帧同步游戏。如果我必须做出N选一，我会放弃其他所有Gameplay框架而选择保留ECS。另，从《Game Engine Architecture》将ECS这个话题收编于其Runtime Gameplay Foundation Systems一章，重点着墨介绍，也能证明其与Gameplay的密切关系。Is-A转为Has-AEC最核心的功能很简单：将传统继承的is-a换成了has-a，将Component保存于Entity的一个容器中，Entity提供API进行Component的查找访问。因为针对任何一个事物进行有限的功能拆分必然是不完整的，选取任意一个维度将其作为基类，都是不那么严谨的。所以，将这些功能有限拆分后，与其不精确地必须选取一个作为基类，倒不如把它们公平地作为组件，公平地处于Entity里。EC能让我们更好地分解复杂的问题、整理复杂的关系。狭义的EC只包括上述这个功能，但一般，广义的EC也会被修改成拥有以下几项重要功能。生存期EC还可以提供API，进行Entity、Component的生存期管理，以及生存期相关事件的回调。生存期以Unity的术语为例，一般指的是：创建（Awake）有效（OnEnable）启动（Start）轮转（Update）无效（OnDisable）销毁（OnDestroy）实现生存期的重难点在于：如何确保“同时”创建的Entity的所有Start都发生在Awake之后。比如可以使用ms_gameObjectsWillStart列表实现。如何确保创建销毁不会影响轮转阶段。每一次Tick()都会对组件列表进行遍历调用Update()。用户在Update()内调用创建或销毁后，如果ECS立刻将其从列表中添加或移除，这将可能影响遍历逻辑。所以ECS会在Tick的开始阶段或末尾阶段才真正将Entity、Component添加或移除到最终列表里。比如可以使用ms_gameObjectsWillStart列表和ms_gameObjectsWillDestroy队列实现。如何确保高效的轮转。比如通过接口（Unity通过反射检测Update()等函数）让用户有权限规定某些自定义的Component是否接受Update。通信Entity之间可以通信、Component之间也可以通信。通信的方式可以是多样的，包括：事件（GameObject.SendMessage()）搜索并直接依赖（GameObject.Find()、GameObject.GetComponent()）也有一些做法，是将数据（黑板）也作为通信方式（GetProperty()、SetProperty()），但Unity并无此设计父子从属关系Entity之间可以有父子从属关系，从而进一步拆分功能。比如人是一个Entity，它有Human这个Component；如果游戏需要重点关心心脏及其跳动次数，让Human提供GetHeartPumpCount()已不太合适，则可把心脏也作为一个Entity，作为人Entity的子Entity，同时心脏Entity有Heart这个Component，提供Heart.GetPumpCount()接口。但Unity的实现中，并不将此功能归于GameObject，而是归于Transform。这样子有其好处，即进行Transform世界空间坐标运算时，仅仅关心Transform这个组件本身就好了。但坏处是，为了表达父子层级关系，必须引入Transform、居然就被迫引入Position、Rotaiton、Scale这些可能没用的信息了。重要属性有一些重要的、通用的属性，也直接定义在Entity中，比如唯一ID。Unity的GameObject，还有供（物理、渲染）引擎内部使用的Layer属性，供Gameplay使用的Tag属性。Entity Component System以上，是典型的Object-Oriented EC。随着《守望先锋》的成功和他们在GDC分享《'Overwatch' Gameplay Architecture and Netcode》，Data-Oriented ECS成为了最近的话题焦点。它的特点是Component只有数据没有方法、System只有方法而没有数据（Component has no method, and System has no field）。数据和行为分离，更加解耦。同一种Component以Array的形式存储在一起。因为是struct-of-array，更加内存友好，性能效率会更快。特定System只关心特定某几种Component（Group，守望先锋称为“Tuple”）。比如Render System只关心Transform和Renderer这两种Component，仅当一个Entity#12实例同时有这两种Component的实例Transform#98和Renderer#37时，Transform#98和Renderer#37就置于一个Tuple里，然后Render System就针对这包含Transform和Renderer的Tuple所组成的数组进行foreach执行逻辑。System能以显式的配置按指定顺序执行，能更清晰地整理一帧内模块间的逻辑执行顺序，一般比较棘手的一帧Delay（one-frame-off）问题也就迎刃而解。从而，延迟处理（Deferment）也是ECS的特点，上游众多System可以随意高频地塞入CommandQueue，或者对某个状态进行预改变，然后在少数下游System对CommandQueue或改变的状态进行逻辑响应，能有效对逻辑响应进行统筹、过滤筛选，减少多余的逻辑响应。比如播放特效等。另外很重要地，基于以上，ECS更加容易做到粗粒度的JobSystem多线程编程。这一方面可另外参阅《Unite Europe 2017 - C# job system & compiler》既能解耦、又能简化复杂流程逻辑、也可能带来性能提升，这是Data-Oriented ECS最诱人之处。从上面的例子可以看出，ECS的功能是如此基础和重要，所以才说是Gameplay的必备要素。节点可视化编程（Node-based Visual Scripting）状态机（Finite State Machine）行为树（Behavior Tree）事件驱动可视化编程（Event Driven Visual Scripting）非线性编辑（Non-linear editing）上面提到的Gameplay框架及插件都有共同的一点：它们都可以以Node-based Visual Scripting的形式存在。Visual Scripting可能有人对Visual Scripting反感，直觉觉得它们的性能是低效的。Visual Scripting的Editor的UI复杂程度，是造成这种偏见的主要原因，但Editor的复杂度和它的Runtime运行性能完全不相关。理论上，一个语言的Front-end也可实现成Visual Scripting。比如，在《Game Programming Patterns》的Bytecode一章，如果为游戏开发一门语言，作者的确建议使用Visual Scripting作为Bytecode的一环，而并非使用文本文件，因为Visual Scripting中用户的每一个操作都是分开的，其机制忽略用户的每一个非法操作，但文本编程不同，用户是可以输入所有代码了之后才交给编译器编译，这将大幅提升实现编译器错误检测、错误提示的难度。Node-based至于Node-based，其思想就是封装和组合。我们可以合理地考虑重用性，将功能拆分为非常通用、非常细小的Node，作为一个又一个Node。但这样有可能会造成Node过多，造成浏览、编写时的麻烦。我们可以针对比较重要的一段逻辑进行归纳，将本由多个Node才能实现的重要逻辑，重新以1个Node的形式呈现。这事实上是个何时进行重构的问题，也是个提取共性、保留异性的思想。Blackboard各个Node是相对独立解耦的，但各个Node有是有可能需要数据交互的。往往通过在主体中添加一个Blackboard（黑板）和SharedValue，来让这些Node进行数据交互。利用Blackboard实现找寻Target、移动到Target、并进行Attack的行为树以上图行为树作为Blackboard的例子。它实现的需求是找寻玩家控制的Actor（FindLocalUserActor节点）移动到该Actor到足够近（ActorMoveToTargetUntilDistance节点）攻击（FunActorVKey节点）留意到，Blackboard定义了TargetTransform的一个ShanredValue。我们再观察FindLocalUserActor节点和ActorMoveToTargetUntilDistance节点：FindLocalUserActor节点定义了Transform这个SharedValue。FindLocalUserActor将找寻到的Transform通过Transform这个SharedValue设置给Blackboard的TargetTransformActorMoveToTargetUntilDistance节点定义了TargetTransform这个SharedValue（原谅命名和Blackboard的TargetTransform同名了，请读者留意），它的值在这棵行为树里绑定的Value是Blackboard中的TargetTransform从而，FindLocalUserActor节点找到的目标Transform，成功地通过Blackboard的TargetTransform，传递给了ActorMoveToTargetUntilDistance的TargetTransform，成功地通过Blackboard让两个相对解耦的节点又能合作起来。Blackboard和SharedValue往往通过Dictionary来实现。各个节点仅仅保存了SharedValue的Key的字符串，取值的时候，都是携带这个Key去Blackboard中查Dictionary对应Key的Value。总而言之，通过Node-based Visual Scripting，可以让程序、策划更加好地分工。程序通过实现代码实现各种通用的Node、封装各种常用的Node，策划通过这些Node，通过Visual Scrpting，在将这些Node“有机”地组合起来，即能实现各种不同的逻辑。虽然都是Node-based Visual Scripting，不同的Gameplay框架，有不同的具体机制和限制。下面将逐一介绍。状态机（Finite State Machine）PlayMaker状态机也是我们非常熟悉的概念。在Unity中，我们常通过Mecanim或PlayMaker接触到状态机。《Game Programming Patterns》的《State》一章，非常直观地概况了状态机的用处。其将以下响应玩家输入事件的混乱代码：void Heroine::handleInput(Input input){

if (input == PRESS_B){

if (!isJumping_ && !isDucking_){

// Jump...

}

}

else if (input == PRESS_DOWN){

if (!isJumping_){

isDucking_ = true;

setGraphics(IMAGE_DUCK);

}

else{

isJumping_ = false;

setGraphics(IMAGE_DIVE);

}

}

else if (input == RELEASE_DOWN{

if (isDucking_){

// Stand...

}

}

}重构为：这么简单直观的“一幅图”。状态机之所以能将其问题简化，是因为它框架符合需求地提供了（但也限定死了）以下基础功能：一个状态机内部的各个状态是互斥的，一个状态机一个时刻只处于一个特定状态（比如上图的“STANDING”、“JUMPING”等方框）（当然如果你坚持hardcode，你也可以把isJumping_、isDucking_这些独立的变量变为一个枚举变量State来表达互斥，这的确能大幅优化上面代码的繁乱程度）可以将不同的事件发送给状态机（比如上图的“PRESS↓”、“RELEASE ↓”等事件）如状态A能跳转到状态B，则它们俩间会有一个从A指向B的Transition，该Transition指定由什么事件触发，从而触发状态跳转（比如上图“JUMPING”状态到“DIVING”状态之间有一个Transition，其指定由“PRESS↓”事件触发）当状态机接受到新事件时，如该事件是局部事件，则只有当前所在状态有该事件对应的Transition时，才进行跳转（比如上图，假设状态机当前处于“JUMPING”状态，因其只包含一个响应“PRESS↓”事件的Transition，所以当状态机接受到“PRESS B”局部事件时，将不会进行跳转；当状态机接受到“PRESS↓”局部事件时，才会跳转到“DIVING”状态）全局事件不管当前处于什么状态，都可以立刻进行状态跳转（即类似于Mecanim中AnyState相连的Transition、或PlayMaker的Global Transition）A状态可以设置成能跳转到A状态自己，也可以设置成不可以状态有Enter()、Update()、Exit()三个阶段函数。（比如上图“JUMPING”状态跳转到“DRIVING”状态的过程中，将会依次调用到“JUMPING”这个状态对象的Exit()、“ DRIVING”这个状态对象的Enter()；如果会停留在“DRIVING”这个状态对象的话，将一直调用它的Update()）状态由用户自定义的脚本组成，分别都可以实现自己的Enter()、Update()、Exit()逻辑。脚本默认为串行执行，有些状态机也可以并行执行脚本。状态机提供Tick()函数以驱动当前状态的当前脚本的Update()函数状态机是张图可以有多个状态机同时并行运行从状态机的特点触发，它适用于简单的、需要全局事件跳转的、有状态的逻辑。但状态机不适用于复杂的逻辑，否则状态机即变成盘丝洞。使用状态机的具体举例有：技能的逻辑或表现、Buff的逻辑或表现、有明显步骤的动画表现（炉石传说主要用PlayMaker做表现动画）。通过多个状态机并行执行，可以把多种互不相关的状态结合起来实现一个复杂的角色动作逻辑。比如一个角色按身体姿态分有moveLayer={stand|run|crouch}，按动作分有actionLayer={idle|shoot|melee}，按状态分有statusLayer={normal|weak|speedup}。我们可以使用1个状态机去表达上述所有情况，这个状态机将包括：s0={stand&idle&normal}, s1={run&idle&normal}, s2={crouch&idle&normal}, s3={stand&shoot&normal} s4={run&shoot&normal}...等最大可能4*3*3=36种状态及其切换。我们也可将这3个相关性本就较小的状态用3个并行执行的状态机去表达，此时，我们只需要考虑4+3+3=10种状态切换就好。注意到，要成功这样做，需要依赖于底层服务提供者（如控制move的组件、控制action的组件、控制status的组件）本就能互不相关地被设置。行为树（Behavior Tree）Behavior Designer行为树是诞生于游戏行业的一种重要的执行模型。行为树的使用示例恰好在前面的Blackboard一节有提到，故不赘述。行为树因为是树状，所以比状态机能够更好地应付复杂的执行流程。通过不断地拆分子问题、重用行为树，来帮助设计者更轻松地、更少出现错误地解决复杂问题。虽然行为树也能和状态机一样响应外界事件、也能被外界事件中断某棵子树而跳到另一棵子树。但行为树常不这样做，常用于受外界事件突发事件影响较少的场合，而是通过行为树内部不断拉去游戏世界的信息，进行自发的流程控制。所以，行为树常用于AI设计、流程相对比较固定的关卡逻辑。其内部实现机制可概括为：行为树类似分层状态机（Hierarchical Finite State Machine, HFSM），注意和上面提到的多个并行状态机并不同。以树状的形式存在，状态被改叫为Task其每个Task可返回Success、Running、Failure的执行结果给父节点组合节点（Composite）是一种Task，其有1个或多个孩子Task。根据孩子Task返回的执行结果，不同的组合节点有不同的响应逻辑，从而不同地决定下一个节点是哪一个孩子并返回Running状态，或者不再执行孩子而返回Success或Failure节点修饰节点（Decorator）是一种Task，组合节点差不多，但其只能有1个孩子Task行为节点（Action）是一种Task，它对游戏世界信息进行读写操作，其必然是行为树的叶子节点，因为它并不能包含孩子节点。判断节点（Conditional）是一种Task，它和行为节点差不多，但我们口头约定好，判断节点只对游戏世界信息进行读操作来判断其执行结果、而不要对游戏世界信息进行写操作行为树提供Tick()函数，从而驱动当前待执行的或正在Running的节点的Update()函数。可以通过一个执行栈的列表来记录当前正在执行哪些节点。具体为：从Root点开始递归深度逐一遍历，将刚刚遍历到的新节点（包括Root自己）Push到执行栈栈顶；调用该节点的Update()；先假设该节点的Update()只返回Success或Failue状态，即代表其已经执行完毕，即可将其返回状态保存在自身、Pop出栈、并交由父节点对其孩子们进行状态判断，决定需否执行下一个子节点，如没，则父节点本身返回状态并Pop出栈如果期间没有并行节点、所有节点都返回Success或Failue状态，则这1个Tick()内都可以执行整棵行为树如果一个执行栈执行过程中出现节点返回Running状态，则这次Tick()不再执行这个执行栈。而是下一次Tick()再执行这个执行栈的栈顶元素如果遇到并行组合节点，则该并行组合节点为所有孩子节点都new一个新的执行栈来供孩子节点分别使用，从而实现并行执行。这个并行组合节点执行完毕时，可以销毁被它new出来的这些执行栈们所有执行栈可以保存在一个执行栈列表中，在Tick()内就这个执行栈列表进行遍历执行事件驱动可视化编程（Event Driven Visual Scripting）Flow Canvas在前一个项目中，我们采用行为树作为关卡逻辑编辑。在打算实现新项目关卡逻辑的时候，却发现有太多全局事件跳转，导致行为树出现各种interrupt节点，从这颗子树跳到另一棵毫不相干的子树，很是突兀和麻烦。才意识到之所以行为树能用于独立防线的关卡逻辑，是因为它的关卡逻辑需求是相对比较线性的，都是按照现行剧本去挨个发生的。这时我们也正常但不合理地联想到状态机也能响应全局事件，但由于状态机一次全局事件只能被一个状态捕获，所以是和我们的需求不一致的。于是参考兄弟项目组的经验，我们将目光转移到了Starcraft2的Galaxy Editor的关卡编辑器上：Starcraft2 Galaxy Editor - Trigger视频：Starcraft 2: Heart of the Swarm - Behind The Scenes - Galaxy Editor (HD)文档：Triggering for Dummies (the basics)从视频和上图可以看出，一个“Trigger”包括了EventLocal VariablesConditionsAction这个Trigger机制非常棒！某某Event在世界里发生了，策划配置好这个Event对应的Trigger们都会进行一系列Condition的判断，如果判断通过，则执行对应的一系列Action，过程中Trigger自己的局部状态通过Local Variables去记录，供Condition和Action读写。重点是在Local Variables和Conditions。从视频中你会发现，策划不已经是在编写逻辑了吗？只不过编写逻辑是通过UI来进行而已。但问题是，类似于Galaxy Editor中的Conditions的操作、UI，都显得比较繁琐不直观（比如上图中的一长串配置英文：“Number of Living units in (Any units in (Entire map) owned by player 1 matching Excluded: Structure, Missile, Dead, Hidden, with at most Any Amount) ==0”）。这时，我立刻联想到了Unreal4唯一押宝的Gameplay框架：Blueprints（前Unreal3 Kismet）。Unreal4 Blueprints Visual Scripting了解Blueprints后，发现Blueprints和Galaxy Editor的Trigger事实上都是属于Event-Driven。而且因为Blueprints是基于Visual Scripting的概念出发的，所以对于Variable、Condition的实现会显得更加灵活和强大。然后，恰好，在Unity Assets Store里，有不错的一些EDVS插件，包括uScript、FlowCanvas等。考虑到我们的关卡逻辑需要进行AssetBundle更新，所以将EDVS翻译成C#脚本的uScript并不适合，最后再通过各种使用和性能评估，我们选定了FlowCanvas。EDVS的特点是：基于Event触发，事件产生了之后push才触发逻辑。这点和状态机一样，比行为树轮询pull检查的性能较好默认一个Event发生后，对应的Flow都是同步执行完的。和状态机、行为树不同，默认未定义“状态”、“运行中”这些概念。你也可以实现自己的有“执行中”状态的节点，但需要自己定义同样的事件在这个状态下再发一次给你的这个节点，你的节点是什么行为提供更加类似于编程语言的变量和流程控制，比状态机行为树的粒度能做到更细我们当前正将EDVS应用于关卡逻辑配置上。非线性编辑（Non-linear editing）In-house Character Action Editor: FunAction editor什么是“ 非线性编辑（Non-linear editing，以下简称NLE）”？我们先通过图片搜索来找个直观感受。Image search of Non-linear editingNLE事实上就是老百姓口中的视频编辑，或者也可称为时间线（Timeline）编辑。注意到“非线性”这个字眼和时间线本身比较“线性”这个感觉，比较矛盾。这是因为历史原因导致的。在上个世纪90年代，线性编辑（Linear video editing）是主要的视频编辑方式，其弊端是，进行视频编辑的时候，源视频必须线性地进行访问（想象一下录像带），给编辑带来了极大不便。所以，非线性编辑的最大特点是视频编辑时，可以对源视频进行非破坏性的随机访问。所以，非线性编辑器和线性编辑器的差别并非我们当前游戏开发的重点——因为我们现在对外存、内存的访问都是非破坏性、可随机访问的。非线性编辑和线性编辑，都属于时间线编辑。在游戏中，NLE主要用在实时过场动画（Cut-scene）的制作。其核心概况是：多对象共存于时间线上，受NLE操作。NLE就好像导演，去控制摄影师、演员们、特效师们、音效师们什么时候该做什么事和Unity的Animation有相似性，都是基于时间线进行“某些东西”的编辑，但Animation中每一帧所编辑的东西非常固定：对象的属性或一些简单参数的事件，这远远不能满足于Cut-scene制作NLE在时间线的基础上，允许开发自定义各种行为节点，及对行为节点进行参数配置节点在时间线上有明确的开始点、结束点，即形象地以“条状”表达一段持续的“事件”。这样将[开始帧,结束帧)的帧范围（Frame Span）封装成一段范围事件的好处是：明确区分1个Track内的多个帧范围事件对象拼接组成，以帧范围事件对象为单位，单独配置、操作、执行。举例为：给帧范围单独设置角色动画，即可以不修改原有动画文件的情况下，单独配置角色所播动画的范围、播放速度给帧范围传入一组路径点数据，作为对象（角色、Camera等）的运动轨迹方便地单独调节一段事件的长短方便地修改交换A事件和B事件的发生次序NLE还可以用在角色动作编辑上。一般游戏类型的角色动作，我们完全可以使用上面提到的状态机或行为树来配置实现动作。Street Fighter 4: Hit and Hurt boxesStreet Fighter: frame by frame hurt boxes但在类似于FTG、ACT这些游戏类型，角色的动作精度要求极高，高到必须按帧进行单独配置（如上图Ryu的蓝色受击框是逐帧进行配置的）。所以我们也会把NLE的概念用于进行这种帧级别精度要求的角色配置上。本章开篇图为本人参考多款NLE编辑器所制作出来的FunAction动作编辑器。有Unity Flux插件经验的人会感觉其与Flux长得非常像，的确Editor方面FunAction是参考Flux的，但两者除了长得像之外，内在思路却完全不一样。FunAction的概况如下：最重要的，Action提供Tick()函数，从而一帧一帧地驱动执行任意角色模型可和任意Action运行时动态绑定。但一旦绑定，规定了1个角色对象有且只有1个Action，1个Action认定只操作1个角色对象事实上这对传统NLE多对象共存于时间线上来说，是一种退化。但这种退化是满足角色动作编辑的需求的，是合理的。未来如果有时间，在不能给编辑器带来额外操作复杂度的前提下，是可以实现成允许多对象同时编辑的，即一个既可编辑cutscene、也可编辑角色动作的NLE编辑器Action有多个Motion（动作，如idle、attack、hurt等），每个Motion有多个Track（轨道），每个Track和且只和一种BaseEvent的子类（事件类型，如PlayAniamation）绑定，Track可以出现其绑定的事件类型的任意个事件对象。BaseEvent可以让用户重载Enter()、Update(currentFrame)、Exit()等函数，从而实现各种千变万化的功能。BaseEvent的子类除了DurationEvent（样子为长条状）外，还有子类InstantEvent（箭头状）。DurationEvent类似于传统NLE的时间轴对象，有明确的StartFrame、EndFrame；InstantEvent类似，但规定StartFrame和EndFrame必须相同。这是因为在动作游戏中，有许多事件的持续帧数是只有1帧（比如攻击检测等）、或持续帧数是不用限定无法限定的（比如播放特效、播放音效等）Action提供SetMotion()函数，从而切换动作可自定义序列化、反序列化方式。默认为Protobuf-net，效率比Unity的各种XML、各种JSON序列化方式好多个数量级。开发使用的方式非常简单，以PlayAnimation为例，如下图每个自定义的Event都可方便地再自定义Inspector的逻辑和画法。示例如下图（留意到PlayAnimation的Inspector自定义实现了自动寻找动画属性的逻辑）每个自定义的Event都可方便地再自定义在Editor场景绘制额外元素。示例如下图，为ActorHurtBody的受击Capsule（可从AABB/Capsule/OBB间选择），和ActorHitTest的攻击OBB第三方Gameplay插件上面这些Gameplay框架的Runtime实现都并非困难。但实现起来，往往大量开发时间消耗在：提供功能齐全、人性化的Editor和Inspector实现性能高效、人性化的序列化反序列化一个好的游戏设计思路，是能让开发者可以重复造轮子、而不是让开发者必须重复造轮子。让开发者必须重复造轮子是简单粗暴欠妥的，让开发者既能选择重复造轮子、也能选择采用已有第三方插件，反而需要更多对基础框架扩展性的思考。在Unity Asset Store里有好一些比较不错的Gameplay框架具体实现插件。它们是：状态机：NodeCanvas、PlayMaker行为树：NodeCanvas、BehaviorDesigner事件驱动可视化编程：FlowCanvas非线性编辑：Unity Director Sequencer（尚未发布）、Slate、Flux（出名但不好）开发者不能有因使用第三方插件而感到“技术性羞耻自卑”的心态。相反，开发者应该发挥开发的能力去评估一款第三方插件是否优秀，评估的角度包括：是否满足基本需求是否开源（这很重要，因为代码即文档、文档不透彻更新不及时、二次修改的可能）运行性能、反序列化性能版本迭代、作者、社区是否活跃UI、操作、体验如果决定应用第三方插件，我们不应该轻易修改它，而是优先去扩展它。在Unity里，第三方插件（及其他项目无关的通用基础功能），建议都摆放在“Standard Assets”目录里，因其与其他文件夹的脚本是处于不同的两个dll，从而防止普通开发者错误地把具体项目业务逻辑感染进通用逻辑里。这样子，我们可以通过继承、或者partial、或者extend、或者static function等途径进行第三方插件的扩展。对于一些重要不紧急的插件修改，可以通过社区和作者进行交流，让其进行修改。比如本人就多次对FlowCanvas/NodeCanvas/BehaviorDesigner的作者交流讨论、提出多项建议（如1、2等），最后被采纳。如果有必要，我们决定修改第三方插件，我们需要承担从此不能再轻易更新这些插件的后果。如果我们已大幅修改第三方插件，此时我们可以反问自己：“这第三方插件是否已经太不满足需求了？我们是否应该开始重新造更适合我们的轮子了？”结语通过上述Gameplay框架的有机合理组合，能够实现丰富的Gameplay逻辑。Gameplay框架工具也远不只这些，地形编辑器、Starcraft2的Unit编辑器、技能编辑器，是更进一步、更具体细分的Gameplay编辑器。也能就上述Gameplay框架进行特例化修改，比如主要用于对话设计的Dialog tree是状态机的一种重要特例化应用。Utility AI是一种不错的AI思路。相比更“Rule-based”的FSM/BehaviorTree，Utility AI和GOAP相似，更有“Plan-based”的感觉。Utility AI的Apex实现如上图，程序写好评分的Node后，策略填填不同Node的分数（Score），就一个不同性格的AI就出来了。你是喜欢近战的路霸，就把“Proximity To Nearest Enemy”的Score调高，你是喜欢直线攻击的76，就把“Line Of Sight To Cloeset”的Score调高。应注意，没必要为了用工具而用工具，要看需求有否用到。但也要考虑，需求是易变的、市场是易变的、方向是易变的、玩家是不耐心的。要为Gameplay的通用性、扩展性做好准备。编辑于 2018-11-29 13:12Unity（游戏引擎）游戏开发开发工具​赞同 458​​27 条评论​分享​喜欢​收藏​申请转载​文章被以下专栏收录iS

探索Gameplay的无限可能 - 腾讯游戏学堂

探索Gameplay的无限可能 - 腾讯游戏学堂

首  页HOME

行业共建INDUSTRY

TGDC

GWB

开发者社区

高校合作U+UNIVERSITY

赛事活动

产学研成果

花火计划

精品课程OPEN COURSES

系列/专题

产品

技术

美术

市场

热门专栏FEATURES

问爆游戏人

很高兴你玩我的游戏

九号传送台

游戏人的一天

技术书籍

关于学堂ABOUT US

关于我们

学堂资讯

优秀游戏/作品展示

无障碍

默认配色

绿底白字

黑底黄字

咖啡底黄字

蓝底黄字

红底白字

黄底黑字

《天涯明月刀》研运历程分享

制作人

|

项目分享

2.5W人看过

搜索

学习打卡活动

策划

美术

服务器

登录

[退出]

中|英

首页

>

九号传送台

探索Gameplay的无限可能

Sniper 腾讯互娱游戏策划

▌当我们谈弱Gameplay时我们在谈什么？是什么？有什么？为什么？

 

Game、Gameplay这2个词随着时代的发展已经十分模糊化了，如果过分追求定义“什么是Game”、“什么是Gameplay”往往会陷入“蛋生鸡还是鸡生蛋”的死循环中，因为这2个词本身就是你中有我我中有你的关系，我们无法脱离Game的定义去谈Gameplay。

 

 

其次，如果我们真的按字面意思，或者接受度最高的解释“游戏性”去定义Gameplay，那么是否意味着“弱Gameplay的游戏玩起来没意思”？因为如果Gameplay=游戏性，那么弱Gameplay=弱游戏性=不好玩。

 

但显然事实并非如此，包括FGO、暖暖系列在内，很多弱Gameplay游戏一样取得了成功，说明这些游戏是好玩、有意思的，否则玩家不会留存、付费。

 

因此这里要给出我的一个观点——弱Gameplay并不是Gameplay弱，而是不强在传统Gameplay上。

 

传统Gameplay在玩什么？

 

 

最典型的枪车球、RPG、冒险、MOBA、格斗……

 

 

正是由于这些传统Gameplay有着十分明显的特点、玩法、乐趣，在过去我们会给这些传统Gameplay的游戏进行分类，明确它们的乐趣，而且往往这二者具有极强的对应关系。

 

 

但是，随着游戏的不断发展，这种“简单”的分类方式逐渐开始失效了。一方面游戏品类不断发生融合，出现X+Y型的游戏，例如FPS+RPG；另一方面在同一类型中，游戏厂商也不断挖掘游戏的“核心乐趣”，将某个品类的核心乐趣做拆解、细化，然后挑选其中的某一个“乐趣点”进行“精雕细琢”。

 

因此我们可以看到，目前我们更多地使用TAG而非分类的方式来对游戏进行描述，因为一个TAG其实代表了某一个“核心乐趣点”，而一个游戏可以有多个核心乐趣点。

 

传统的游戏分类方式将一系列乐趣点“打包”组合成了一个“类别”，例如JRPG=故事+角色成长+回合战斗+……，但将这些乐趣点拆分组合后形成的新游戏就无法用已有的“类别”去进行总结，只能将每个乐趣点通过TAG的形式贴在游戏上。

 

而在贴TAG的过程中，就出现了很多在以前看来很“不可思议的TAG”

 

 

这些TAG体现了一些传统Gameplay中没有包括，或占比较小的乐趣点，而正是这些“被忽视”的乐趣点构成了“弱Gameplay”的体验。

 

因为我们如果回顾市面上的“弱Gameplay”游戏，我们会发现虽然这些游戏中也包含很传统的Gameplay，例如回合战斗、QTE等等，但如果我们去找一个游戏的核心玩家问他“你玩这个游戏是在玩什么”，他的回答一定不会是这些传统Gameplay。真正让这些玩家能够留存、心甘情愿付钱的，并不是游戏中回合战斗、QTE的部分，而是人设、剧情、换装等。

 

 

所以这些“弱Gameplay”游戏并不是没有可玩性，它们的可玩性是十分高的，只是它们的可玩性与传统游戏相比较为独特，有自己的核心乐趣点和体验，且围绕自己的核心乐趣点进行了非常多的设计，并不低于传统游戏中对传统玩法的设计。

 

当然相对的，这些游戏在传统玩法上的设计就显得较为薄弱，给了我们“Gameplay很弱”的“错觉”。

 

因此，与其说这些游戏是“弱Gameplay”游戏，不如说他们是“弱交互”游戏，因为他们的核心乐趣点相比于传统Gameplay不需要那么强（数量多、频率高）的操作

 

 

这里就引出了本文的下一个内容，那这些“弱Gameplay”“弱交互”的游戏在玩什么？

 

---

 

▌“弱Gameplay”游戏在玩什么？玩什么？为什么？怎么做的？

 

如果问一个游戏在“玩什么”，对于传统Gameplay的游戏，我们有十分清晰的认识，例如射击、解密、动作杀怪、跳跃闯关等等。

 

但是对于“弱Gameplay”游戏，我们会感到难以说明他们到底在“玩什么”，似乎这些游戏玩的东西在传统玩家看来根本不算是“玩”。

 

 

因为如果以传统游戏玩家的眼光来看，这些游戏压根就“不像游戏”

 

最典型的例子是关于“文字冒险类游戏和Galgame算不算游戏”的争论，因为这类游戏绝大多数时候都是在“看剧情”，似乎根本和“玩”这个字没有关系，没有互动交互怎么能叫“玩”呢。

 

但是这样“反传统玩法”的游戏其实很多，他们有的交互很简单（Galgame），甚至有的压根没有交互（Steam四大名著之一的“山”），有的交互条件不可控（生命线），有的还想通过游戏来教给玩家一些知识（信任游戏）。

 

 

但是如果我们问玩这些游戏的玩家“游戏好玩么”，他们依然会说好玩（当然肯定也有更多的人觉得不好玩）。

 

 

为什么这些“不像游戏的游戏”也可以好玩？

 

个人认为，游戏是为了给玩家带来快乐，让玩家觉得好玩，这一点是毋庸置疑的。

 

但是快乐也分很多种类，一些快乐需要强Gameplay、强交互来获得，而游戏在实现这类快乐上有优势。例如驾驶的快乐显然需要强交互，需要人不断操作，但如果要在现实中体会这种快乐，需要很多钱、技术，同时也很危险。但在游戏里体会驾驶的快乐就很简单、便宜且没有危险，这就是游戏的优势。

 

但反过来，一些快乐不一定需要强Gameplay、强交互来获得，游戏在这些快乐上就没有优势了。例如看故事，虽然也可以通过游戏看，而过去在游戏中看故事的体验与看书、看电影相比并没有明显的优势，甚至在制作成本上还有劣势，因此这些快乐通过游戏来获得就不一定是一个好的方案。

 

 

但随着技术的发展，游戏能够承载的体验越来越丰富、交互方式越来越多样，因此游戏在体验快乐上逐渐开始获得优势，那些之前不常见于游戏的快乐逐渐变得适合通过游戏来获取，于是出现了叙事游戏、旅游游戏等等“弱Gameplay”“弱交互”游戏。

 

 

甚至随着技术、玩家需求的变化，原本的“强Gameplay”中的一部分也可以变“弱”来满足玩家的需求

 

例如阴阳师和明日方舟两款游戏，毫无疑问是成功的，但是虽然他们看上去有着十分“重Gameplay”的玩法（塔防、回合战斗），但玩家们都会调侃这2款游戏玩到中后期都是开自动战斗无脑刷刷刷的“播片”游戏，而绝大多数玩家在游戏中的目标也是为了能够培养出一个能够自动战斗的“播片”阵容，从而解放自己的双手无脑刷刷刷。

 

 

这在一些传统玩家看来似乎也不能理解，玩游戏玩到最后的目标是“不玩”而是干看着（还不能扫荡），这不有病么？

 

但事实上是，有相当多的玩家希望在每天看剧、看综艺的时候能够很轻度地点一下然后放着，通过低频的操作（弱交互）获得游戏中的成长。正是因为玩家有这样的需求，这类型的“播片”游戏才能够获得成功。

 

因此对于题目中“成功游戏是否必须围绕核心Gameplay设计才成立”的问题，我认为成功游戏可以不围绕“强Gameplay”设计，但需要围绕“核心Gameplay”设计。

 

“核心Gameplay”是游戏中占比最大的部分，它不一定是传统游戏中常见的玩法、体验，但应当是游戏的主要卖点、希望提供给玩家的主要体验、用于满足特定的玩家需求。

 

比如我们来看看FGO和暖暖是如何做的。

 

对FGO来说

• 核心卖点：TYPE-MOON、FATE的世界观、剧情和人设

• 面向对象：重度TYPE-MOON和FATE粉丝

• 满足需求：玩家想更多地了解TYPE-MOON、FATE世界的故事，接触自己喜欢的角色

• 游戏做法：FGO拥有目前手游中最大的剧情文本量，主线和活动中都有充足的剧情；不同角色有各种不同立绘、异装让玩家抽，角色的背景故事、语音也十分多

 

 

对暖暖来说，

• 核心卖点：换装玩法

• 面向对象：年轻女性

• 满足需求：希望获得、穿着、欣赏好看的衣服，向其他人展示自己的穿衣搭配

• 游戏做法：高品质、真实的服装建模，超多可穿着、定制的服装，多种用于展示、拍照、炫耀的表情、动作、互动方式甚至是舞曲

 

 

那么，在知道了目前成功的游戏是怎么做的之后，未来还有什么“弱Gameplay”“弱交互”游戏可能会出现呢？

 

---

 

▌未来还能玩些什么？玩什么？图什么？有什么问题？

 

我认为，要探究还有什么Gameplay可以被用在游戏中，前文中提到的3个点依然是关键和核心：

 

• “游戏，终究是为了满足玩家的需求、带来快乐”

• 有一些玩家的需求或快乐尚未被满足/存在不足

• 这些快乐随着技术的发展可以通过Gameplay（无论强弱）来满足或提升

 

即“有需求”、“有不足”和“游戏能行”，只要满足这3点，无论是强Gameplay还是弱Gameplay，都有打造成功游戏的潜力。

 

那么具体而言有哪些方向可以进行探索呢？

 

当然这里就是开脑洞的时候了，我个人想了3点：

 

首先说教育、学习。

 

人对教育和学习的需求是不言而喻的，这其中不仅有功利性的需求，例如中高考、考证，人类本身也有求知欲，在获得新知识后会感到满足和快乐。

 

但是学习需要极强的“延迟满足”能力，因为学习能够获得的快乐往往需要很长一段时间之后才能体现，绝大多数学习还需要在“无聊”的状态下坚持很久。很多人，尤其是儿童由于缺乏延迟满足的能力所以会“学不进去”、“厌学”。

 

另一方面学习的收获、成长感是很模糊的，例如背了几千个单词并不会让人立刻感受到自己的英语水平提升了，这进一步使得现实中的学习难以提供快乐。

 

不过上述2个问题确是游戏的强项，因为游戏中常用的目标、奖赏是削弱“延迟满足”的好手段，通过简单的“打卡签到”“每日任务”“成就奖励”等等元素能够让玩家获得满足感，从而在不需要较强的延迟满足能力的情况下也能长期坚持一件事情。另一方面，将能力数值化也是游戏里很常见的一种做法，能够更加直观地让玩家感受到自己的成长和目标。

 

但是将学习“游戏化”也是有难点的，首先就是如何将学习过程、学习内容与奖励反馈有机结合？

 

以背单词为例，现在有很多背单词APP，是不是在里面加上一个签到打卡、每日任务，就算将背单词给“游戏化”了？显然不是，因为这一功能与背单词的过程、收获是割裂的。背单词的痛点在于记住每个单词后，如果不是真正用到了，用户会感受不到满足与收获，因此如果要将背单词游戏化，应当是从这个问题下手，通过游戏的方式创造玩家使用单词获得奖励的机会，例如“单词战斗RPG”、“单词地牢”，让游戏中的胜利、奖励成为玩家记住单词的收获。

 

其次则是如何将学习进度真实有效地反馈成可视化结果？

 

人对知识的掌握情况其实是比较难以评估的，因此才有了各种考试来验证学习结果。但考试这一过程的体验之差大家都有所体会，如果要将学习游戏化，对玩家知识掌握情况的评估肯定不能仅仅靠考试来进行，而需要融入到每一个学习动作里，就像游戏中的天梯分系统一样，根据玩家学习中的点击速度、正确率等等因素来给玩家的学习效果进行打分。但如何保证这一打分结果能够准确反映玩家的学习情况，肯定是一件需要仔细设计和琢磨的事情。

 

 

第二个领域是倾听、倾诉等感情释放行为。

 

我认为目前的社会生活压力是比较高的，在这种高压生活下，人需要倾听和被倾听来进行感情释放，因此微博、公众号等领域产生了很多“树洞”服务来让人们能够匿名地进行倾诉、八卦别人的故事，当然也有更加专业的心理咨询服务。

 

但对大多数人来说，让他们面对真实人物去进行倾诉还是有顾虑的，哪怕是匿名，也很难保证对方能够像自己想的一样保密。此外一些较为内向的人也并不能接受直接描述的方式，面对诸如“你最近有什么不开心的事情？”的问题，他们会避而不谈。

 

但游戏最擅长的就是构建虚拟人物，并通过设计漂亮帅气性感的外形来拉近虚拟人物与玩家的距离，让玩家产生亲近感和占有欲。此外游戏中的交互方式也较为多样，例如可以有选项式的交互“你今天过得怎样？——挺好、一般、不太行”，根据玩家的选择，一步一步引导玩家进行倾诉（虽然没有进行过心理咨询，个人认为这种方式应该是专业心理咨询中更为常用的方式），或者通过类似“殴打假人”、“整蛊NPC”的方式来完成发泄。

 

但这其中显然涉及到一个较为明显的技术问题，就是如何让游戏中的虚拟NPC具有“交流”的能力。如果用传统的AI行为树、选项支的方式肯定无法实现预期的效果，这其中如何运用NLP（自然语言处理）技术来识别对话、生成回答是需要进行技术突破的。

 

 

最后一点则是弱社交。

 

其实人多多少少都是有社交需求的，即使是自称“死宅”、“内向”的人，其实也需要社交，只是如今他们可以使用一些“弱社交”的方式满足社交需求，例如视频弹幕、微博留言点赞等等。但这种程度的弱社交难以构建起稳定的线上关系，几乎不会有人会在看视频看直播时跟某个弹幕水友发生更深层次的关系，想通过微博留言来社交也十分不靠谱。

 

而对于不那么宅和内向的人来说，朋友之间更是需要一些深入交流的途径和由头来维持友谊、互通近况，例如著名友尽游戏“分手厨房”。但一旦涉及到线下、重度玩法，就一定会出现“众口难调”的问题，太忙导致时间难以统一，太穷导致一些桌游、密室玩法玩不起，线下更是让社交的成本显著提升，还有很多人接受不了重度的玩法（例如桌游、狼人杀）。

 

而游戏能比较好地解决上述问题，一方面游戏本身就是构建线上社交的常见手段，无论是游戏内置聊天、朋友圈、公会等社交功能，还是游戏本身提供的话题性，就足以支撑很多社交需求的实现。另一方面，游戏在弱玩法、长线养成上有得天独厚优势，因为社交并不一定需要通过短时间、重单局的重度玩法（例如桌游）来进行，轻度、养成感强的玩法一样能拉近人与人的距离，提供人与人之间交流的机会，例如支付宝种树。

 

不过，如何打造具有普适性的社交玩法、养成对象依然是一个需要琢磨的问题，因为传统的社交玩法在线下社交的过程中已经被探索得七七八八了，而线上社交随着网游的兴起也经历了多轮次的迭代，那么轻度玩法+社交要怎么做，必然是一个难题。而养成玩法更是随着数值养成类手游的流行被很多人玩腻了，谁能在“养什么”“怎么养”上给出一个新的答案，谁就能获得优势。例如前年旅行青蛙的火爆其实是打破了传统养成游戏中对被养成角色的强控制，改为玩家几乎无法控制青蛙，只能“随缘”。这一变化带来的新奇体验（随机、不确定）引发了火爆。

 

 

在最后，我想宽泛地谈谈我对“未来游戏还能怎么玩”、“弱Gameplay可以怎么做”的看法。

 

我认为“未来游戏还能怎么玩”其实更加取决于“未来设备、技术还能怎么发展”，设备、技术对玩法的影响是彻彻底底的“降维打击”或者应该叫“跨纬度打击”。

 

因为游戏“玩什么”其实取决于“有什么”，而“怎么玩”取决于“能用什么玩”，因此底层的硬件、技术一变，上层的游戏、玩法必然发生翻天覆地的变化。

 

如果想要长远地探索外来游戏还能怎么玩，那就必定需要在硬件、技术层面进行探索和储备，例如可穿戴智能设备、VR、AR等等。

 

而关于“弱Gameplay可以怎么做”，我认为“因为弱Gameplay火了所以做弱Gameplay就能成功”是肯定不对的。正如前面分析，弱Gameplay有他们强设计的部分，是针对了特定的受众、需求进行设计的结果。因此如果要做弱Gameplay游戏，那么明确受众、预期是第一步也是最重要的一步。

 

甚至如果跳出Game的束缚，弱Gameplay并不一定要通过Game实现，例如要做一个“养汪星人”的游戏，一定要做到手机上么？是否可以考虑做到电子宠物、玩具上？

阅读与本文标签相同的文章

第九区漫游

更多推荐

MMORPG手游天气系统的沉浸感设计

局部现场

105227人看过

《明日方舟》UI/UX 分析——藏在「好看」背后的先进性

他视角

101672人看过

“打得不错”：为什么《炉石》玩家可以默契地用礼貌词语进行嘲讽？

学术范儿

87966人看过

友情链接腾讯游戏腾讯学堂腾讯课堂TGideas

法律信息用户协议产权声明侵权投诉指引隐私协议

联系我们

微信在线反馈

微信在线反馈

Copyright © 1998 - 2023 Tencent. All Rights Reserved. 腾讯公司 版权所有. 粤B2-20090059-5

公众号

扫码访问公众号

视频号

视频号

B站

B站

微博

微博

Gameplay框架 | 虚幻引擎文档

Gameplay框架 | 虚幻引擎文档

Unreal Engine 4.26 Documentation

Unreal Engine 4.27 Documentation

Unreal Engine 5.0 Documentation

Unreal Engine 5.1 Documentation

Unreal Engine 5.2 Documentation

Unreal Engine 5.3 Documentation

> 创建交互体验

> Gameplay框架

Light Theme

Dark Theme

>

Gameplay框架

游戏规则、玩家输出与控制、相机和用户界面等核心系统。

Choose your operating system:

Windows

macOS

Linux

本页面的内容

基础框架元素

以下范例展示了游戏框架各部分联锁的方式。以一个简单的游戏情景为例：兔子与蜗牛赛跑。游戏框架的基础是GameMode。GameMode 设置的是游戏规则，如首个跨过终点线的玩家即是冠军。其同时可生成玩家。

在 PlayerController 中设置一名玩家，其同时会产生一个Pawn。Pawn 是玩家在游戏中的物理代表，控制器则拥有Pawn并设置其行为规则。本范例中共有2个Pawn，一个用于蜗牛而另一个用于兔子。兔子实际为 角色，是pawn的一个特殊子类，拥有跑跳等内置移动功能。另一方面，蜗牛拥有不同的移动风格，可从Pawn类处直接延展。

Pawn可包含自身的移动规则和其他游戏逻辑，但控制器也可拥有该功能。控制器可以是获取真人玩家输入的PlayerController或是电脑自动控制的AIController。在本范例中，玩家控制的是蜗牛，因此PlayerController拥有的是蜗牛Pawn。而AI则控制兔子，AIController则拥有兔子角色，其中已设有停止、冲刺或打盹等行为。相机提供的视角仅对真人玩家有效，因此PlayerCamera仅会使用蜗牛Pawn的其中一个CameraComponent。

进行游戏时，玩家的输出将使蜗牛在地图中四处移动，同时HUD将覆盖在相机提供的视角上，显示目前游戏中的第一名和已进行的游戏时间。查阅Gameplay框架快速参考，了解基础框架元素简介及其协同工作的方式。还可点击以下链接直接跳转至页面，浏览各个类的总览与在蓝图中设置/使用C++对其进行设置的方法。

基础框架元素

Gameplay框架快速参考

简要概述构成游戏框架的游戏规则、角色、控制器、用户界面等的类。

游戏流程总览

启动引擎，运行游戏或 play-in-editor 会话的过程。

Game Mode 和 Game State

关于 Game Mode 和 Game State 的概述

Pawn

Pawn是玩家在场景中的具化对象。

控制器

在玩家或AI实体情境中，控制器实质上是大脑。

摄像机

摄像机代表玩家的视角；玩家如何看世界。

用户界面和HUD

面向美术和程序员的关于创建用户界面（如菜单和HUD）的指南和信息。

标签

Gameplay Framework

欢迎帮助改进虚幻引擎文档！请告诉我们该如何更好地为您服务。

填写问卷调查

取消

Create Gameplay - Unity 手册

Create Gameplay - Unity 手册

手册

脚本 API

unity.cn

Version:

2021.3

2023.2

2023.1

2022.3

2022.2

2022.1

2021.3

2021.2

2021.1

2020.3

2020.2

2020.1

2019.4

2019.3

2019.2

2019.1

2018.4

2018.3

2018.2

2018.1

2017.4

2017.3

2017.2

2017.1

5.6

包含此页的版本：

不含此页的版本：

受支持

旧版

手册

脚本 API

语言:

中文

English

中文

日本語

한국어

手册

Version:

2021.3

2023.2

2023.1

2022.3

2022.2

2022.1

2021.3

2021.2

2021.1

2020.3

2020.2

2020.1

2019.4

2019.3

2019.2

2019.1

2018.4

2018.3

2018.2

2018.1

2017.4

2017.3

2017.2

2017.1

5.6

包含此页的版本：

不含此页的版本：

受支持

旧版

Unity User Manual 2021.3 (LTS)

在 Unity 中操作

Create Gameplay

Creating a 3D game

场景

Create Gameplay

You can use Unity to design and create games. There are some basic workflows and concepts in Unity that can help you use Unity.

There are some core concepts you need in order to create gameplay mechanics, and you might need to write scripts. For more information on how to create a work with scripts, see the Scripting section.

Topic

描述

Scenes

Understand scenes and how to create and work with scenes in Unity.

GameObjects

Understand GameObjects and how they work with components.

Prefabs

Learn how to create and work with Prefabs in Unity.

Layers

Understand and use layers and layermasks in Unity.

Constraints

Learn different types of constraint components that you can attach to GameObjects.

Rotation and orientation in Unity

Understand how Unity calculates and works with rotation and orientation.

Lights

Understand the effect of lights on a scene.

Cameras

Learn how you can use in your games.

Cross-Platform Considerations

Understand how different platforms can affect your games.

Publishing Builds

Understand how to publish your builds.

Troubleshooting

View solutions to some common problems that occur in Unity.

Additional Resources

For a tutorial on how to get started with Unity, see the Unity Essentials pathway on Unity Learn.

To see a list of templates you can use to create a game, see Templates.

Creating a 3D game

场景

Copyright © 2023 Unity Technologies 优美缔软件（上海）有限公司 版权所有 "Unity"、Unity 徽标及其他 Unity 商标是 Unity Technologies 或其附属机构在美国及其他地区的商标或注册商标。其他名称或品牌是其各自所有者的商标。 公安部备案号:31010902002961 法律条款 隐私政策 Cookies 沪ICP备13002771号-8

请大神具体一下什么是GamePlay程序员，今后又要如何发展？ - 知乎

请大神具体一下什么是GamePlay程序员，今后又要如何发展？ - 知乎首页知乎知学堂发现等你来答​切换模式登录/注册游戏设计程序员Unity（游戏引擎）C#请大神具体一下什么是GamePlay程序员，今后又要如何发展？大四就快毕业了，一心想来北京发展，虽然技术不够但是热爱游戏。终于一家公司愿意录用我，主程序人超级好，问了我好多问题，然后给我分配的职位叫做GamePl…显示全部 ​关注者25被浏览20,046关注问题​写回答​邀请回答​好问题​1 条评论​分享​2 个回答默认排序无名剑渲染沙琪玛，不专业不学无术​ 关注就是写各类游戏逻辑的程序员，包括但不限于，UI，周边，战斗……是每个游戏公司研发部门里头人数最多的码农工种。尽量找些能让别人觉得自己不一样的活去干，公司没有就自己学。比如学学渲染，学学网络同步，学学物理。如果有机会转管理，早日转管理。毕竟打工到30+如果没在好公司占好坑，基本都是颠沛流离发布于 2023-10-01 20:56​赞同 2​​添加评论​分享​收藏​喜欢收起​知乎用户蟹妖。GamePlay程序员，主要就是做游戏逻辑的。怎么算赢，怎么算输，赢了干什么，输了干什么……看具体游戏、项目，可能和界面程序员有重叠。玩家点了按钮，先做什么，再做什么，游戏内部怎么响应……简单的游戏里，也可能和AI程序员有重叠。玩家这么操作，N/PC就那么动一下……因为现在中间件比较好用，声音、输入应该不会有专门的程序员了，可能也会放到GamePlay这边做。图形、特效之类的应该会有专人做。不过什么时候触发，哪个地方显示哪个，可能和GamePlay有交集。网络、服务器应该也是专门的方向。有的项目会涉及到脚本，看策划能不能写啦；找GamePlay把策划案翻译成脚本也是可能的。国内常见的项目应该不太会用到物理仿真、图像处理之类的吧，就不多说了。这应该是游戏程序里的入门职位了，以后怎么发展还要看自己。可以朝某个方向专门深入下去，图形、网络之类的，应该都不错。可以各方面都接触一点，朝技术、项目管理方向发展，也挺好的。编辑于 2017-02-17 17:28​赞同 24​​5 条评论​分享​收藏​喜欢收起​​

Gameplay是什么意思_Gameplay的翻译_音标_读音_用法_例句_爱词霸在线词典

play是什么意思_Gameplay的翻译_音标_读音_用法_例句_爱词霸在线词典首页翻译背单词写作校对词霸下载用户反馈专栏平台登录Gameplay是什么意思_Gameplay用英语怎么说_Gameplay的翻译_Gameplay翻译成_Gameplay的中文意思_Gameplay怎么读,Gameplay的读音,Gameplay的用法,Gameplay的例句翻译人工翻译试试人工翻译翻译全文简明柯林斯牛津Gameplay美 [ˈɡeɪmpleɪ]释义（游戏用语）游戏可玩性。即游戏的玩法，是决定一个游戏有多好玩的重要因素。大小写变形:gameplay点击 人工翻译，了解更多 人工释义实用场景例句全部玩法On PC, the game had it all — imaginative storyline and characters, challenging gameplay, superb graphics.个人电脑里的游戏非常完美，从想象力丰富的故事情节及人物到富有挑战性的游戏设计和精美画面，应有尽有。柯林斯高阶英语词典Today we re adding two new articles to our Gameplay Section.今天我们在游戏介绍里添加了两篇新文章.期刊摘选Dark and Light offers a gameplay that adapts to each player.黑暗与光明提供了适合每个玩家的丰角色扮演.期刊摘选Will para gameplay be in 1.0?0中有伞兵地图 吗 ?期刊摘选Flip the phone on its side for Widescreen mode: bigger landscapes and enhanced gameplay.翻转手机来进行宽屏模式: 更大的屏幕和加强的游戏可玩性.期刊摘选We want the lore to drive gameplay. With certainty there will be quests related to lore.我们想用传说来引导游戏过程. 所以肯定会有和传说有关系的任务.期刊摘选IMPROVED GAMEPLAY : Passing and positioning have all been enhanced.改进的游戏性: 传球和站位都被更新了.期刊摘选What else should I know about with regard to Arena gameplay?关于竞技场比赛我还应该知道些甚么?期刊摘选Excellent graphics, easy gameplay makes this puzzle one of the most addictive games ever made!令人激动的图形, 简单的游戏玩法使得这款智力游戏成为最容易上瘾的游戏.期刊摘选We wanted to have nearly all of the gameplay play out onscreen in a visceral way.我们希望有几乎所有的游戏画面上发挥出了内脏的方式.期刊摘选The tactics and strategy involved in the gameplay are a combination of wargames, cardgames and chess.策略和战略涉及在玩游戏中是军事演习, 扑克牌戏和国际象棋的组合.期刊摘选When a realm reaches maximum player capacity , gameplay becomes adversely affected.当服务器里的宅人们太多的时候, 游戏过程将因此大受影响.期刊摘选Unparalleled Gameplay Variety You will never run out of new things to do!无与伦比的游戏方式你绝不会无事可做!期刊摘选Maya Bubbles Touch has the awesome gameplay as the most popular versions of Bubbles have!玛雅泡泡是现在最受欢迎的泡泡龙游戏,画面超精美!期刊摘选Enjoy 13 levels of gameplay as you follow the story of The Bourne Ultimatum.跟随谍影重重的故事,你将享受到13个难度水平!期刊摘选And gameplay is king , you've got to make sure that it comes across in every way.你知道,游戏可玩性永远是第一优先考虑的问题, 你得保证游戏的各个方面都不会拖后腿.期刊摘选Experience the atmosphere and excitement of International Cricket with impressive graphics and gripping gameplay.经验的气氛和激动的国际板球与令人印象深刻的图形和引人入胜的游戏.期刊摘选Land operations will cover vast areas, making reconnaissance an essential part of gameplay.陆上战争将覆盖很辽阔的区域, 这使得侦察成为游戏中一个必不可少的部分.期刊摘选Are there mercenaries that add a Party aspect to the gameplay?佣兵会给在游戏中添加小队作战的概念 么 ?期刊摘选The Bad: Incredibly short, featuring only four to six hours of gameplay; no new multiplayer content.缺点: 难以置信的短, 只有4到6小时的游戏容量; 没有新的多人游戏内容.期刊摘选Its been a while since I released my last blog on Gameplay innovation.从上次我在博客里写的有关游戏性革新的文章已经有一段时间了.期刊摘选DrunKMonkey: the gameplay is addictin but without MP no use.这游戏令人着迷,但没有多人模式,没意思.期刊摘选This game has endless tactical opportunities and the magnificent gameplay will never cease to enthral you.这款游戏有无尽的战术可能,宏大的场面会永远迷住你.期刊摘选The changes of the gameplay are noticeable, the game really got smoother and is more direct.游戏性的改变是明显的, 游戏真的变得更平滑而且更加直接.期刊摘选Great musical score, a great story driven action adventure, and a gameplay designed for mobile phones.伟大的音乐评分, 一个伟大的故事驱动的动作冒险, 以及游戏设计的手机.期刊摘选This is a new level of gameplay that simply cannot be compared to any other game.这将带来一个没有任何其他游戏能比拟的全新层次的游戏方式.期刊摘选The gameplay was developed, and also made a great leap forward.该游戏的开发, 同时也作出了巨大的飞跃.期刊摘选Scripting also can be an effective way to add a sense of ambience to gameplay.脚本也可以是增加游戏气氛的有效途径.期刊摘选On PC, the game had it all — imaginative storyline and characters, challenging gameplay, superb graphics.个人电脑里的游戏非常完美，从想象力丰富的故事情节及人物到富有挑战性的游戏设计和精美画面，应有尽有。柯林斯例句收起实用场景例句释义实用场

除了渲染，游戏客户端程序员还有哪些进阶方向？ - 知乎

除了渲染，游戏客户端程序员还有哪些进阶方向？ - 知乎首页知乎知学堂发现等你来答​切换模式登录/注册程序员游戏开发客户端开发Unity（游戏引擎）虚幻 4（游戏引擎）除了渲染，游戏客户端程序员还有哪些进阶方向？问不少同学的未来学习规划，大部分说想学渲染。 渲染确实重要，必须掌握，但肯定不是唯一的方向。 那么除了渲染，游戏客户端程序员还有哪些进阶方向？显示全部 ​关注者1,117被浏览532,241关注问题​写回答​邀请回答​好问题 110​添加评论​分享​45 个回答默认排序Jerish​ 关注补充：有朋友对3C不了解，这里补充一下，具体可以参加下面这篇文章。3C，即character camera control，其实这个概念在游戏设计里面使用的更多。character，一个或多个游戏角色，玩家可以扮演该角色也可以观察该角色。camera ， 一个或多个摄像机 辅助玩家观察游戏世界、增加玩家的体验感和沉浸感。control，表示控制或者交互的方式，可以抽象一个或多个控制器来使玩家控制对应的角色，游戏的基础是交互，我们要通过控制器来实现玩家对角色的控制。注：在虚幻引擎里面默认集成了一个成熟的Gameplay系统，你可以看到playercontroller、camera、character等等的C++类，其实与前面提到的3C是几乎相同的概念。可以看到，3C涉及游戏的核心系统，其内容与游戏玩法高度相关，所以不同的游戏的3C都有所不同。比如常见的ARPG，设计层面上要有一个完整的故事和一个个性鲜明的角色，而程序上我们需要实现一个可玩的有打击感的战斗系统（涉及到复杂的动画系统、特效系统、镜头处理、音效、震动反馈、后处理等）、角色成长系统(制作相应的配表工具)、移动系统（攀爬、游泳、飞行等）、定制的动画以及分镜系统等。而其他的游戏，还可能有迷雾系统（dota）、关卡生成系统（我的世界）、载具系统（极品飞车）、以及各种特殊的与游戏规则高度相关的定制系统（文明）。对于3C程序来说，可能有一些相对通用的技术与功能，比如Gameplay框架、状态机FSM/HFSM（如逻辑状态机用于衔接角色的行为表现），网络同步，动画系统，移动系统。而像一些其他技术如FOV分层渲染、描边、物理、音效、界面特效等（这些实现可能由渲染程序、音频、UI程序做），3C主要是负责整合到现有游戏的系统内。游戏涉及到的技术很杂，很多时候不那么好划分，有的时候你的项目就那么几个人，那什么系统你都要硬着头皮做，管他是渲染、物理、AI还是3C呢。原答案：游戏客户端程序一枚，或者也可以叫Gameplay程序。两年前曾经回答过一个类似的问题，不知道还有没有朋友记得。确实，我感觉游戏中的渲染就好比互联网的人工智能，门槛薪资都相对高一些。所以搞游戏的初学者程序都想搞渲染，包括我。但是我并不是执着于从事引擎渲染，有趣的技术还有很多，而且难度也不小。拿我的经历举例把，最近这两年的时间我都在专注于网络同步和3C。今年花了大半年的时间专攻网络同步技术，参考了网上200+的论文/视频/技术文章等资料，总结梳理出了《细谈网络同步在历史中的发展变化》这个系列的文章。一开始其实没想写这么多，但是随着学习和深入，我发现有很多问题没有理解或理解的不深刻，所以只能一遍遍的看论文和文章、尝试翻译和理解，同时结合自己的实践经验来巩固，最后整理完竟然有3万多字。网络同步发展了这么多年，网上依然鲜有文章或书籍详细的将相关的概念和知识进行系统的梳理（注意我是指网络同步，而不是游戏服务器架构），所以我发现即使我在2016年才入行，仍然能找到行业内某个特定领域的一点点空白（网络同步的发展历史）。目前我见到最好的系列文章是Glenn Fiedler的Introduction to Networked Physics | Gaffer On Games，书籍就是网络多人游戏架构与编程 (豆瓣)，如果你觉得有更好的欢迎推荐一下直到现在，还是有数不胜数的人（包括已经从事游戏行业很久的朋友）搞不清帧同步/快照同步/状态同步的区别，看了网上零碎分析对比博客更是无法理解“帧同步”一词为什么一直有争议。关于网络同步还可以提出很多问题：帧同步的帧是指什么？国外的Lockstep与帧同步有什么关系？lookahead cheat类型的外挂有哪些应对方案？帧同步中的逻辑与渲染分离是如何实现的？如何解决帧同步各个客户端之间互相等待的问题？客户端预先执行后出错如何回滚？快照同步和状态同步有什么区别？有哪些插值手段来解决同步的表现问题？延迟补偿是什么？是在客户端实现还是在服务器实现？延迟补偿适合所有游戏么？如今的状态同步到底是指什么？具体有哪些同步手段？物理同步是一种同步手段么？为什么实现起来很困难？在我刚开始接触网络同步时（其实已经有两年工作经验了），上面的问题我基本上都答不出来，最近我在按照历史发展梳理相关技术时这些问题才慢慢的被逐个解决。我理解了什么是帧同步？（国外称为Lockstep，国内一开始叫帧间同步，参考 “帧同步”一词在国内的发展历史）什么是快照同步？（其实就是同步整个游戏场景某一时刻的完整状态，GitHub上那些古董的游戏源码 id Software）什么是状态同步？（源自快照同步的思路，被TRIBES Engine优化成只同步那些产生变化的对象数据，使用虚幻引擎4年，我想再谈谈他的网络架构）理解了常见的各种同步的优化手段。比如逻辑与渲染分离（帧同步如何分离逻辑和渲染？），延迟补偿（Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization），客户端预测回滚（Client-Side Prediction and Server Reconciliation），插值技术（Entity Interpolation - Gabriel Gambetta），冗余数据，InputBuffer（【守望先锋GamePlay框架与网络同步(含字幕)】'Overwatch' Gameplay Architecture and Netcode bilibili）理解了帧同步与状态同步应用场景的差异（见下图）。理解了物理同步的难点在于跨平台的确定性问题以及网络误差容易被物理引擎放大（网络同步在游戏历史中的发展变化——五、物理同步）UE4的移动组件插值示意帧同步与状态同步对比有人可能说，这个技术不太像客户端的技术。但其实这就是一门客户端与服务器相结合的技术，做游戏确实不必那么拘泥某项技术，那些为了梦想奋斗的苦逼的独立游戏开发者真的就是要什么就学什么。你做不同的游戏类型，那技术的难点都是不同的，ACT/RPG（AI，3C，动画，无缝大场景）、格斗（动画）、FPS（网络同步，3C，音频）、MMO（服务器架构，同步，无缝大场景）、赛车（物理模拟，音频）其实有很大的差异。仔细想一想，人生这么多年，可以学的东西有很多。对于我而言，经过今年系统的学习和总结，在理论上我对网络同步技术的认识基本上已经处于一个新的阶段，除了工作上的实践加深理解外这一块我可以暂时放一放了（知乎上偶然你还会发现一些非常好的文章 比如Gordon：六：帧同步联机战斗（预测，快照，回滚） Frozen Claw：浅谈物理引擎的网络同步方案）。在2021我还是打算入门渲染，同时好好研究动画系统这一块（这篇动画技术总结可以帮助梳理一下：qingdong：游戏动画技术总结，打算看看Character Animation With Direct3D，以及虚幻引擎里面的相关技术）。说了这么多，也不是让各位去学习网络同步。而且觉得如今网络这么发达，学习资料这么多（我找资料的时候能通过Goggle发现几十年前的论文），如果你对某些技术感兴趣的话就可以去学。游戏编程精粹系列7，8本，每一本都500页往上，看哪个想学就可以挑一个方向去搞（建议有目的的去研究，否则一般人就是杂而不精了）。此外，游戏开发一样是计算机编程，除了这些令人眼花缭乱的技术外，不要忘了巩固你的计算机基础。C++、操作系统、计算机网络这些有空就巩固一下，常学常新，可能某一天你突然就理解了某些技术的本质与原理。最后，给个小建议，按照历史的发展去学习一门技术，个人觉得是系统学习的一个非常好的方式，唯一的缺点就是比较费时间。不过随着你的功底不断加深，你学习新技术的速度也会加快。编辑于 2021-03-22 17:51​赞同 767​​32 条评论​分享​收藏​喜欢收起​知乎用户做游戏的……额……其实我们做游戏动画和物理的也是很不错的方向，现在各种招不到人诶……动画层面：这篇survey里的各种方法，如果您能够有个大概的了解（也不要求全部吃透）这本书，如果您能够看完（也不要求吃透了）欢迎联系我……物理层面：如果这两套课程能够看完，吃透，也欢迎联系我至于在游戏引擎里的落地和运用，我可以手把手教（UE4和Unity我都行，现在主要是UE4）……我这边是天美广州（是的，广州），欢迎来撩：邮箱：noahzuo@tencent.com编辑于 2022-06-13 11:36​赞同 561​​77 条评论​分享​收藏​喜欢