额，搜到了这个问题，我就随便答一下吧，下面都是我的猜测，正确与否自行判断。&br&&br&&b&一、用的什么引擎？&/b&&br&不知道，推测可能是cocos-2d或者他们自己写的一个框架。&br&&br&&ul&&li&Don't Starve 用&a href=&///?target=http%3A//www.fmod.org/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&FMOD&i class=&icon-external&&&/i&&/a&来处理声音，在data\sound\目录下的文件可以用fmod_eventplayer.exe这个程序来编辑。&/li&&li&Don't Starve 的图片好像是用类似PVR格式的纹理加载的。数据目录下面所有后缀是*.tex的就是纹理文件。每一个纹理还有一个同名的xml文件来描述资源。这些纹理可以用Don't Starve 的TEXTools程序查看，用&a href=&///?target=https%3A///nsimplex/ktools& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&nsimplex/ktools · GitHub&i class=&icon-external&&&/i&&/a&和png格式的图片相互转换。&/li&&li&Don't Starve 的动画文件用&a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Spriter 2D sprite animation character creation software.&i class=&icon-external&&&/i&&/a&制作。可以用Don't Starve Mod Tools 工具将Spriter的动画文件弄成Don't Starve 能载入的动画文件。Don't Starve 的动画文件本质上包括三部分，一个anim.bin的二进制文件用来描述动画，多个atlas-xxx.tex的纹理文件用来放置动画需要的文件，bulid.bin承担描述纹理文件的作用。之后将这些文件压缩成zip文件，主要提高加载速度。用上面提到的ktools可以将饥荒的动画文件转换成Spriter能编辑的格式。不过anim.bin，bulid.bin，atlas-xxx.tex，这些文件不一定每个动画文件都有，比如那些角色共用一套anim.bin动画文件，每个角色只是纹理换了一下。所以用ktools转换不成功时，注意分析这些动画的依赖关系，把对应的打包成zip，就行了。&/li&&/ul&因为上面所说的都在cocos-2d里面都有用到，所以我才推测它是cocos-2d的。 &br&--------------------------------------------------------------&br&&b&二、怎么组织的游戏世界？&/b&&br&我几个月前翻译过国外的一篇介绍游戏世界的生成方式的文章，在这里&a href=&///?target=http%3A//blog.csdn.net/czfblog/article/details/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&【饥荒】关于随机地图生成的方式&i class=&icon-external&&&/i&&/a&。BTW，这个博客里还有几篇关于饥荒的，有兴趣可以看一下。&br&&br&&ul&&li&Don't Starve使用&a href=&///?target=http%3A//www.mapeditor.org/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Tiled Map Editor&i class=&icon-external&&&/i&&/a& 来编辑地图块，Tiled是开源的哟。Don't Starve的地图是随机生成的，但是也有一些内在联系，比如pigking只会出现在森林边上，而且每一个pigking周围都有四个sanityrock（好像是叫这个？），这些东东的位置就是用Tiled编辑出来的，此外还有一大堆，在Static Layouts目录下。&br&&/li&&li&一个Room有多个Static Layouts&/li&&li&一个Task有多个Room，还有几个key，lock。&/li&&li&生成地图就把对应的key和lock拼接起来，可以保证地图的连贯性。&/li&&/ul&-------------------------------------------------------------------------&br&&br&&b&三、&/b&&b&反正就是&/b&&b&详细一点的吧。&/b&&br&要详细的话我就随便写写，想到那写那。&br&&br&&b&1.面向对象&/b&&br&Don't Starve 主要用Lua脚本实现游戏逻辑，大体上，饥荒的Lua部分采用面向对象的编程范式，在class.lua文件里用lua metatable实现了一套面向对象的系统，可实现类的继承。&br&在饥荒里基本上每一个类都由一个独立的脚本文件定义，这些个脚本文件大体结构如下：&br&&div class=&highlight&&&pre&&code class=&language-lua&&&span class=&nb&&require&/span& &span class=&s2&&&&/span&&span class=&s&&class&&/span& &span class=&c1&&--载入class文件&/span&
&span class=&kd&&local&/span& &span class=&n&&baseclass&/span&&span class=&o&&=&/span&&span class=&nb&&require&/span& &span class=&s2&&&&/span&&span class=&s&&baseclass&&/span&
&span class=&c1&&--基类，有时没有&/span&
&span class=&c1&&--这里可以载入其他的东东&/span&
&span class=&c1&&--创建继承基类的子类&/span&
&span class=&c1&&--为了不污染全局变量域，使用local关键字&/span&
&span class=&c1&&--没有基类时，这样写：&/span&
&span class=&c1&&--~local childclass=Class(function (self,...)&/span&
&span class=&kd&&local&/span& &span class=&n&&childclass&/span&&span class=&o&&=&/span&&span class=&n&&Class&/span&&span class=&p&&(&/span&&span class=&n&&baseclass&/span&&span class=&p&&,&/span&&span class=&k&&function&/span& &span class=&p&&(&/span&&span class=&n&&self&/span&&span class=&p&&,&/span&&span class=&o&&...&/span&&span class=&p&&)&/span&
&span class=&n&&self&/span&&span class=&p&&.&/span&&span class=&n&&value&/span&&span class=&o&&=&/span&&span class=&mi&&0&/span&
&span class=&c1&&--属性&/span&
&span class=&c1&&--初始化函数内容&/span&
&span class=&k&&end&/span&&span class=&p&&)&/span&
&span class=&c1&&--方法&/span&
&span class=&k&&function&/span& &span class=&nf&&childclass&/span&&span class=&p&&:&/span&&span class=&n&&fn&/span&&span class=&p&&(&/span&&span class=&o&&...&/span&&span class=&p&&)&/span&
&span class=&k&&end&/span&
&span class=&c1&&--因为使用了local，所以要返回，其他文件才能接收到&/span&
&span class=&k&&return&/span& &span class=&n&&childclass&/span&
&/code&&/pre&&/div&如果你了解了饥荒时如何实现面向对象的，看饥荒的源码就可以很快速的理解了。&br&&br&&b&2.代码与资源分布&/b&&br&下面列出了饥荒中各个文件或文件夹的作用：&br&（以*结尾的，该文件夹里就是一堆上面所说的类）&br&&div class=&highlight&&&pre&&code class=&language-bash&&├─bin
二进制程序文件
├─data 数据目录
├─bigportraits
人物肖像纹理
好像是用来放置于天气相关纹理的
├─images
主要纹理放置目录
├─levels
放置地皮纹理
├─minimap
├─models
未知，猜测与洞穴有关
├─scriptlibs
一些用lua实现的库，用来网络通信与json字符串处理
├─scripts
主要的lua脚本目录
├─behaviours
├─brains
├─cameras
相机，用来控制玩家所能看到的视野*
├─components
组件，一组通用的，用来描述物品的代码*
├─languages
语言文件，国际化用的
地图相关代码*
├─levels
世界模式，有生存，冒险，洞穴等等
├─static_layouts
Tasks，上面那些具体去看博客
卖萌用的，直接在命令行运行，有只会动的大象^.^
├─prefabs
定义世界里所有的物品
├─scenarios
场景，也就是贴吧所说的彩蛋
├─screens
├─stategraphs
状态机或状态图，用来和AI一起控制动物（和植物？）的运动
└─widgets
界面小部件（按钮，文本框etc.）*
├─shaders
└─mods 插件放置目录
&/code&&/pre&&/div&此外，data文件里还有DLC0001目录，这个目录来放置DLC版本的文件，结构和data目录一样。&br&&br&&br&&br&&br&&br&下面就一大堆网址：&br&&a href=&///?target=https%3A///kleientertainment/ds_mod_tools& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&kleientertainment/ds_mod_tools · GitHub&i class=&icon-external&&&/i&&/a& 游戏官方发布的mod工具，拿来自动转换纹理和动画，在win和ubuntu下编译成功。&br&&a href=&///?target=https%3A///nsimplex/ktools& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&nsimplex/ktools · GitHub&i class=&icon-external&&&/i&&/a& Ktools 工具，可以把tex纹理和png图片相互转换。还可以转换动画文件。&br&&a href=&///?target=https%3A///nsimplex/wicker& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&nsimplex/wicker · GitHub&i class=&icon-external&&&/i&&/a& 一个饥荒Mod框架。&br&&a href=&///?target=https%3A///debugman18/UpAndAway& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&debugman18/UpAndAway · GitHub&i class=&icon-external&&&/i&&/a& 一个大型饥荒Mod《天堂》，利用上面的wicker写的。&br&&a href=&///?target=https%3A///jkolokotronis/dsmods& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&jkolokotronis/dsmods · GitHub&i class=&icon-external&&&/i&&/a&
还是一个大型mod《黑夜英雄》，不过真的有点大，400多M，翻下墙再去克隆。
额，搜到了这个问题，我就随便答一下吧，下面都是我的猜测，正确与否自行判断。 一、用的什么引擎？ 不知道，推测可能是cocos-2d或者他们自己写的一个框架。 Don't Starve 用来处理声音，在data\sound\目录下的文件可以用fmod_eventplayer.exe这个程序…
&img src=&/50/v2-bdfc_b.jpg& data-rawwidth=&800& data-rawheight=&450& class=&origin_image zh-lightbox-thumb& width=&800& data-original=&/50/v2-bdfc_r.jpg&&&b&会做游戏的公司“应该”是什么样的公司？&/b&&blockquote&作者丨&a href=&/people/b65ec66e94eb5c& data-hash=&b65ec66e94eb5c& class=&member_mention& data-editable=&true& data-title=&@氪老师& data-hovercard=&p$b$b65ec66e94eb5c&&@氪老师&/a&&/blockquote&&br&&h3&&strong&&strong&丨　“我们制作游戏的模式存在设计问题。&/strong&&strong&”&/strong&&/strong&&/h3&&p&不记得什么时候，我产生了这个想法。&/p&&p&入行的前几年，见证了一些项目和公司的失败，当时的我把原因归结于“这个人是外行”“高层的决策失误”“策划水平不行”。后来看到更多的失败，令我咋舌的是这些惨败的案例竟然惊人的相似。很明显这已经不是个别人的能力问题了，就好比一个BOSS，一个玩家卡住还能说是他手残，多数玩家全卡住就是设计问题了。&/p&&p&目前国产游戏行业的现状，除了少数人以外，几乎所有人都不是很满意。很多玩家觉得国产游戏普遍都是垃圾，只会氪金坑钱，满街的游戏没几个好玩的；很多制作人员每天都在加班，“996”“997”成为常态，透支着健康和游戏梦想；很多有想法的设计者无法说服老板和资方，只能闷头根据上级指示做山寨和换皮，有条件的人纷纷出国学习游戏设计，然而学成以后在国外就业困难，回国又发现很多路被现状和政策堵死了；很多投资游戏的人则纷纷表示做游戏的风险实在太大，投几十个公司也不一定能成一个，几乎完全等同于赌命。&/p&&p&那么问题出在哪呢？&/p&&p&我个人觉得主要原因有两个：&/p&&p&&strong&其一是游戏天生不适合&/strong&&strong&“&/strong&&strong&卖公司&/strong&&strong&”&/strong&&strong&的套现模式。&/strong&&/p&&p&&strong&其二是风险分配不均以及诚信机制的缺失。&/strong&&/p&&br&&br&&h3&&strong&&strong&丨　“&/strong&&strong&卖公司&/strong&&strong&”的套现模式&/strong&&/strong&&/h3&&p&前几年如雨后春笋般出现的大量游戏公司，多数是风投和天使投的。&strong&这些投资机构是通过&/strong&&strong&“&/strong&&strong&卖公司&/strong&&strong&”&/strong&&strong&来实现套现盈利的。&/strong&比如风投投了一个手游小团队，他们的产品上线以后最好马上获得超高的流水，按照盈利能力给公司做比较高的估值，要么直接上市，要么能吸引到后续的投资，或者干脆被收购，风投就可以退出盈利了，公司的联合创始人也可以通过股权套现实现财务自由。这个过程的时间越短越好。这就是风投通过投资游戏公司获利的本质。&/p&&p&&img src=&/v2-53d44aa1baed3dad13e07_b.jpg& data-rawwidth=&640& data-rawheight=&370& class=&origin_image zh-lightbox-thumb& width=&640& data-original=&/v2-53d44aa1baed3dad13e07_r.jpg&&&i&争相上市的中国游戏公司&/i&&/p&&p&有人会说，这个模式不是挺好吗？硅谷的很多公司不也是这么运作的吗？是的，而且有很多开发者也这么想，如果一切顺利的话，&strong&奋斗个两三年就可以实现财务自由&/strong&，谁跟钱过不去呢？&/p&&p&那么，究竟有什么问题呢？&/p&&p&首先，游戏公司做估值上市的难度越来越大，相关部门对游戏公司上市及并购的监管越来越严。也就是说这种通过上市、收购或吸引下轮投资实现变现的方式将变得&strong&越来越困难&/strong&。&/p&&p&其次游戏并&strong&不适合投资方快速提高估值变现的需求&/strong&。很多类型的游戏都是慢热型，需要一段时间积累用户，而且后续的收益有明显的长尾效应。假如以短期收益最大化为目标，往往会对游戏性以及可能的收益造成损失。&/p&&p&游戏的设计，技术和美术方面的人才都&strong&需要时间培养&/strong&。很多优秀的游戏公司都是开发了几个项目之后才开始找到感觉，才能做出成功的产品。要求一个游戏开发团队第一个产品必须大卖，否则就得死，这样的做法成功率太低了。&/p&&p&哪怕第一款产品运气好成功了，&strong&多数游戏公司普遍不具备持续盈利的能力&/strong&。目前能破解“第二款诅咒”（指做出一个爆款之后就再也做不出第二个）的创业公司少之又少。那么根据第一个产品的盈利规模（甚至有的还有水分）进行的估值就有虚高的嫌疑。&/p&&p&最后，我认为，哪怕作为一种长期的投资行为，&strong&“&/strong&&strong&游戏公司&/strong&&strong&”&/strong&&strong&本身也不是一种很好的投资对象。&/strong&&/p&&p&为什么这么说呢？因为大多数游戏公司，尤其是手游公司，&strong&最有价值的资产是那几个核心的开发人员。&/strong&要想制作成功的游戏产品，靠人海战术是没有用的。往往最成功的游戏产品一开始都是由小团队开发出来的，最典型的例子就是Supercell，他们的团队都很小。很多游戏公司做成了一个产品后疯狂扩张，结果发现还是最初的那个产品最赚钱，就是这个道理。&/p&&p&投资者可以把整个公司都买下来，但是资方无法控制那些核心开发人员。人家把股权变现离职，你拦得住吗？他们重新拉投资另立山头，你有什么办法？资方花重金只获得了一个空壳，又有什么意义呢？谁也不是傻瓜，估值虚高的游戏公司不会一直有人买单。&/p&&p&有人可能会说，人走了没关系，只要IP留下就可以了。一个游戏哪怕再成功，&strong&它的&/strong&&strong&IP也&/strong&&strong&没有想象中那么有价值&/strong&，比较典型的例子就是EA的《荣誉勋章》系列，核心人员出走以后，后续产品的口碑迅速下降，反倒是那几个核心开发人员另起炉灶再造一个新IP《现代战争》一样大卖。小岛秀夫走了，下一代《合金装备》是否还能卖得那么好呢？&/p&&p&&img src=&/v2-2d712ad0a3062daf65f66ffd_b.jpg& data-rawwidth=&640& data-rawheight=&329& class=&origin_image zh-lightbox-thumb& width=&640& data-original=&/v2-2d712ad0a3062daf65f66ffd_r.jpg&&&i&小岛秀夫出走后的《合金装备》新作，甫一公开就恶评如潮&/i&&/p&&p&我们换一个角度想，游戏和动画、电影很像，都是创意产业，动画和电影为何没有大规模采用这种“投公司做市值然后卖公司”的模式呢？你听说过有人觉得京阿尼动画做的不错，想着要收购他们然后做市值上市卖掉赚钱吗？你听说过有人觉得某个电影不错然后把剧组人员都招进一个公司，不停地拍电影续集做大公司估值然后套现吗？&/p&&p&这种“卖公司”的模式对制作人员也造成了一定负面影响。&/p&&p&从开发者的角度讲，第一个问题就是投入和回报不成正比。根据上述模式投资模式进行开发的游戏，收入的大头是资方，其次是公司的股东，员工其实根本分不到什么。很多人996了一两年，游戏做出来月流水过千万，他们以为终于熬出了头，结果却发现薪水并没有增加多少，加班情况也没有改善。面对这种情况，所有人的想法出奇的一致，都想着做出一点成绩就赶紧跳槽或者自己单干。因为所有通过游戏发家致富的例子都是通过“做公司市值”的方式取得成功的，因此假如自己没有股份，就很难获得令人满意的收入。&/p&&p&游戏的制作者们发现，仅仅是“做好自己分内的工作”，根本挣不到什么钱。因此所有人都想着拉投资、创业，哪怕目前仍然处于打工的状态，很多人也仅仅是把目前的工作当做跳板。这样一来，整个行业就变得非常浮躁，很多人整天想的不是怎么提高自己的业务水平，而是时刻准备逃走。&/p&&p&然而拉投资不是那么简单，开公司也绝非那么容易。有的人可以设计出好玩的游戏，有人可以写出优雅的代码，有人擅长画出美丽的画面，如果一个行业要求技术人员都得把脑袋别在裤腰带上，玩命去创业才能过上正常的生活，我认为是一种超级不正常的现象。&/p&&br&&br&&h3&&strong&丨　风险分配不均以及诚信机制的缺失&/strong&&/h3&&p&在制作游戏的过程中，投资方几乎承担了全部的风险，而制作人员除了时间和精力外，风险几乎为0。项目挂了，策划程序美术拍拍屁股再找工作就好了，这年头项目成功率这么低，一两个失败项目的经历并不会对职业生涯产生很大的影响，大不了在简历里不提这段就好了，但是投资方的真金白金可就回不来了。&/p&&p&在一种关系中，风险过大的一方一定会采取一定措施进行弥补。举个例子，比如一个地方，相关部门要求餐馆的顾客可以无条件免单，那么餐馆老板就很有可能要使用劣质的食材，雇佣廉价的非法劳工，把菜单的价格抬高，通过这些手段才能抹平免单带来的损失。&/p&&p&同理，由于制作人员承担的风险很小，资方就会采用各种手段来弥补。担心开发者不好好工作？那就加班吧，“996”甚至“997”。项目成功率太低？那就快速赌一把，不成赶紧撤。策划有自己的想法？按你说的做万一不成你拍拍屁股走人了，肯定不能听你的啊！没有持续盈利能力？赶紧把公司卖掉就好了。员工拿着高工资旱涝保收？真的做成了，没有股份的就不分钱！&/p&&p&那么其他类似的创意产业是否也存在这些问题呢？他们又是如何解决的呢？&/p&&br&&br&&h3&&strong&丨　日本动画的例子&/strong&&/h3&&p&我想到了日本动画的制作委员会制度。&/p&&p&首先简短的科普一下日本动画的制作委员会制度，这套制作动画的方法，大体思路就是由几家不同的金主提供资金支持，制作公司负责制作动画，组成一个动画制作委员会。动画版权共享，挣了钱大家利益均分。&/p&&p&这个模式的主要目的是“均摊风险”。3之前，由于制作的成本太高，很多动画制作公司都游走在死亡边缘，有一部作品没做好，就有破产的风险。通过制作委员会制度提供的资金支持，动画制作公司可以把精力专注在产品层面。&/p&&p&另一方面，多个投资方一起参与项目，对于资方来说也分散了投资风险。单个作品投资的减少意味着可以参与更多的项目。&/p&&p&&img src=&/v2-528ddb56b64f2dc54efe2b5a05dc7be9_b.jpg& data-rawwidth=&640& data-rawheight=&400& class=&origin_image zh-lightbox-thumb& width=&640& data-original=&/v2-528ddb56b64f2dc54efe2b5a05dc7be9_r.jpg&&&i&《新世纪福音战士》的成功，让动画制作委员会制度得到广泛推广&/i&&br&&/p&&p&那么诚信方面的问题是怎么解决的呢？&/p&&p&资方把钱给了出去，怎么保证制作公司会尽心尽力的做好动画？动画质量这种东西又不能量化的评估，怎么确保他们不会乱搞一通然后跑路呢？制作公司担心金主会不会中途变卦尾款不给了？会不会以资方的优势压低成本或者承诺好的分红不给我？&/p&&p&日本人解决这个问题的方法也很独特：&strong&业内熟人关系和行业自律&/strong&。记得很多文章都讲过，日本动画业界是一个高度封闭的系统，制作人员最看重的是自己的信誉，至于合同什么的根本就不当一回事。金主们相信的是那些能挑大梁的制作人，而制作人赌上了自己的业内声誉，他也更倾向于找那些知根知底的合作伙伴一起工作。一个人如果不好好干活名声臭了，会被整个业界排挤根本找不到活干。这样就形成了一种信任链。&/p&&p&制作委员会制度就是这样一定程度上解决了“风险”和“诚信”两个问题。&/p&&br&&br&&h3&&strong&丨　好莱坞的情况&/strong&&/h3&&p&正如大家所知，好莱坞电影采用的都是剧组制，资方搞定钱的问题后，由制作人牵头，寻找合适的导演、编剧、剧组人员和演员。这个临时组建的团队根据预算制定拍摄计划，拍摄完成后制作人员领取报酬，剧组解散，大家各奔东西承接下一个项目。也有些人合作的比较顺利，组成固定的合作伙伴。&/p&&p&&img src=&/v2-26ccfd28efd640a28ae0_b.jpg& data-rawwidth=&640& data-rawheight=&219& class=&origin_image zh-lightbox-thumb& width=&640& data-original=&/v2-26ccfd28efd640a28ae0_r.jpg&&&i&体系成熟的好莱坞电影产业&/i&&br&&/p&&p&很多人可能不知道的是，在熟人关系和行业自律外，欧美还有IMDb这个辅助工具。在很多人眼中IMDb就是一个电影的评分网站。但其实IMDb还有一种收费服务，他们会收集每个电影的所有演职员信息，不光是重要岗位（导演、编剧、演员），还包括了所有专业性非常强的工种（比如剧务、道具、灯光、舞美、特效师等等等等）。形成一个非常专业的影视人才数据库。当一个新剧组成立，某一个岗位缺人的时候，他们就会使用IMDb的专业版付费服务，在这个数据库中联系合适的人，同时IMDb还会对制作人员提供的信息进行核实，以确保人员信息真实可靠，一个人参与过哪些片子，那些片子的盈利情况如何，都可以很快的查出来。IMDb这个第三方网站实际上提供了一种诚信辅助机制，降低了整个电影业界的运行成本，这套机制相比日本那边完全靠人脉关系的方式就更科学一些。&/p&&p&&img src=&/v2-3f973c99ee8f61b4e4d14e4_b.jpg& data-rawwidth=&640& data-rawheight=&505& class=&origin_image zh-lightbox-thumb& width=&640& data-original=&/v2-3f973c99ee8f61b4e4d14e4_r.jpg&&&i&IMDb并不只是“豆瓣”或“时光网”&/i&&/p&&p&我们可以看到，无论是日本动画还是好莱坞电影，核心思路都是通过“做产品”获得收入，而不是通过“卖公司”的方式。&/p&&br&&br&&h3&&strong&丨　会做游戏的公司“应该”是什么样的公司？&/strong&&/h3&&p&那么游戏行业是否也可以采用类似的运作方式呢？&/p&&p&写到这里，我们不妨做一种“假想实验”。如果我们采用“动画制作委员会”或者“剧组”的方式来制作游戏，是否可行呢？如果要做，会是一种怎样的规则呢？&/p&&p&我们现在设计一个在现实中不存在的A公司。这个A公司是这样一种运作模式：&/p&&p&&strong&A&/strong&&strong&公司第一种主要业务是，定期召开&/strong&&strong&“&/strong&&strong&游戏制作展会&/strong&&strong&”&/strong&&strong&。&/strong&&/p&&p&A公司认识很多开发组，这些开发组有技术、有创意、有设计方案和研发计划，但是没有钱。A公司也认识很多投资方，这些投资方别的没有，就是有钱，对投资游戏感兴趣，因为游戏做好了可以赚钱。&/p&&p&那么A公司会定期把他们召集起来，为双方提供一个交流的机会和一套合理的游戏规则，也就是这个“游戏制作展会”。&/p&&p&在展会中，每个开发组的领头人有20分钟的演讲机会，向投资方展示他们想要开发的游戏，包括游戏的设计理念、盈利模式、开发计划、宣传预算等等。领头人要回答投资方提出的各种问题，并且提出大体的预算计划，预算计划中包含项目周期和预算上下限。&/p&&p&预算下限的意思是，如果筹集到的金额不足下限，视为项目启动失败，开发者或许应该修改自己的项目方案；预算上限的意思是，出于对投资者的保护，一个项目不应该获得太多的研发资金，以免浪费或出现腐败现象，因此超过预算上限的资金会按比例返还给投资者。&/p&&p&投资方听完了所有开发组的展示后，可以在会议结束后自行决定投资哪些项目，投多少金额。在开发者进行展示时只能提问题（开发者可以选择不回答），而且在展示设计案时投资者不能公开表示是否愿意投资，这一点与拍卖会不同，是为了防止“托儿”的出现。&/p&&p&如果一个项目的投资数额超过了预算的下限，则融资成功，这个项目的“研发委员会”开始组建。A公司收到投资者的钱以后，不会马上全额交给开发组，而是按照之前商定好的研发计划，研发组每完成一个里程碑，就支付一部分研发费用，原则上保证研发的需要，也不会给某些无良开发人员拿到钱就跑路的机会。同时这里也对A公司提出了要求，他们并不能拿着项目资金到处乱花。&/p&&p&项目完成后，所产生的收益分为三部分，很小一部分（比如5%）要分成给A公司。一部分（比如45%）分给开发组，一部分（比如50%）分给投资方，投资方按照当初自己投资在总预算中的占比获得收入。&/p&&p&&img src=&/v2-e452eccda30ef06e7c252de13ec11b8b_b.jpg& data-rawwidth=&640& data-rawheight=&426& class=&origin_image zh-lightbox-thumb& width=&640& data-original=&/v2-e452eccda30ef06e7c252de13ec11b8b_r.jpg&&&i&“游戏制作展会”的感觉类似这样&/i&&/p&&p&单机游戏与电影、动画有点类似，在项目完成后只要不出大的Bug，做完基本上可以不管了。如果收益比较好可以再次开始DLC或者下一作。由于原作的IP所属会有一点法律问题（比如谁有权利做续作的问题），这方面需要参考它们的经验。&/p&&p&网游的情况就比较复杂，游戏做完了还有后续的维护和更新的问题。这个不妨考虑在一开始立项定计划时，就把上线后半年内的维护更新成本做进预算里，上线半年后如果收益还OK，后续的投入当做新项目启动继续融资。&/p&&p&这种运营模式确实还存在很多需要细化的部分和设计，本文就不再继续开脑洞了。&/p&&p&&strong&A&/strong&&strong&公司的第二项业务，是建立像&/strong&&strong&IMDb&/strong&&strong&那样的行业数据库。&/strong&&/p&&p&对于投资者来说，A公司需要提供尽可能详尽的开发者数据。&/p&&p&台上做展示的制作人参与过哪些项目？这些项目的盈利情况如何？开发组的主要成员都有谁？他们有着怎样的项目经验？他们提供的工作经验是否真实？是否有过什么不良记录？这些信息都是投资者是否要投资一个游戏项目的参考。&/p&&p&所以一个像IMDb那样的开发者数据库就是必要的。&/p&&p&对于开发者来说，这样的数据库一方面可以帮助他们组建合适的团队，另一方面，也是一种无形的行业自律机制，一定程度上可以规避一小部分水平低下，项目做一个挂一个，光靠嘴忽悠，拿了投资者的钱就跑路的人。&/p&&p&最后我们不妨分析一下A公司存在的可能性。&/p&&br&&blockquote&A公司提供的是平台和信息服务，从根本上来说是一个小公司，没有什么重资产，运营成本也不高，并不需要很大的投入；&p&A公司的主要收入来自成功项目的分成和类IMDb数据库的付费服务，这两项都不是短期内可以实现大量盈利的业务，需要很长时间的发展积累；&/p&&p&A公司有点像淘宝平台，现金流会比较健康，最重要的是自身的诚信，游戏开发动辄就是上百万的资金交付，诚信方面不能出问题。&/p&&/blockquote&&br&&p&有人可能会问这个模式和众筹有什么区别。我觉得主要有这么几条：&/p&&br&&blockquote&1. 在筹款数额上比众筹要高很多；&p&2. 对于投资者有门槛，投一两百块是没有意义的，可能基础投资单位要求在10万以上；&/p&&p&3. 对于开发的监管要比众筹严格，筹到钱乱搞的后果也比较严重。&/p&&/blockquote&&p&最适合干这个活的或许是……阿里巴巴？&/p&&br&&br&&h3&&strong&丨　结语&/strong&&/h3&&p&游戏行业不是“零和博弈”，只靠《阴阳师》《剑与家园》无法养活这么多从业人员，也不是所有人都想进腾讯、网易。希望有一天，投资者都能赚到钱，开发者都能实现自己的梦想，玩家不会再抱怨国产游戏都是垃圾。&/p&&p&这个世界需要更多的好游戏，做游戏的方式并非一成不变……&/p&&p&&img src=&/v2-e026fc1514fa3eff_b.jpg& data-rawwidth=&640& data-rawheight=&362& class=&origin_image zh-lightbox-thumb& width=&640& data-original=&/v2-e026fc1514fa3eff_r.jpg&&——————————&/p&&p&欢迎关注我们的微信公众号“触乐”（chuappgame）。每天会精选一些文章定时推送，也欢迎来我们的&a href=&/?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&网站&i class=&icon-external&&&/i&&/a&看看。&/p&
会做游戏的公司“应该”是什么样的公司？作者丨 丨 “我们制作游戏的模式存在设计问题。”不记得什么时候，我产生了这个想法。入行的前几年，见证了一些项目和公司的失败，当时的我把原因归结于“这个人是外行”“高层的决策失误”“策划水平不行”…
&img src=&/50/476e10e27c74b9e291c82bf510fdedbd_b.png& data-rawwidth=&1295& data-rawheight=&744& class=&origin_image zh-lightbox-thumb& width=&1295& data-original=&/50/476e10e27c74b9e291c82bf510fdedbd_r.png&&&b&在接触到虚拟现实的那一刻，我就意识到，也许这是我应该走的道路。&/b&&p&&b&常常在想，这样的现实是否值得我去奋斗？&/b&&/p&&p&&b&因为那些看起来美好的未来也许只是虚幻的遐想罢了。&/b&&/p&&p&&b&镜匙网络科技
MirrorKeyVR&/b&&/p&&p&&b&微信公众：MirrorKeyVR&/b&&/p&&br&&br&&p&总有人私信问我一大堆关于VR的问题，虽然尽力解答了，但是我觉得一两句话对这些开始关注VR的朋友们并没有太大的帮助，&b&既然知乎给我开了专栏&/b&，我也不能总闲着，所以今天开始随便介绍一些我开始接触VR后学到的小知识，主要希望能给对VR原创内容开发感兴趣的朋友们一些小帮助，&b&不定时更新，请勿转载！&/b&&/p&&br&&p&下面介绍我们的一款VR游戏&b&《MirroringRUN镜像酷跑》&/b&是怎么制作出来的，其中主要介绍一些比较独特的&b&游戏设计思路&/b&，相较于传统3D游戏，更多的&b&是针对于当前阶段，对VR游戏的思考与探索。&/b&&/p&&p&我打算主要从以下几个方面来讲述一下，都是自己的个人看法与经验，希望获得专业人士的指导与点评。&/p&&br&&p&&b&第一部分
VR如何才能不“晕车”？（本章）&/b&&/p&&p&&b&第二部分
VR应该用来玩什么？&/b&&/p&&p&&b&第三部分
VR与未来？&/b&&/p&&br&&br&&p&&b&第一部分&/b&&/p&&br&&p&&b&VR如何才能不“晕车”？&/b&&/p&&p&你第一次体验VR的时候，是不是在一辆飞奔的过山车上呢？&/p&&p&旁边的工作人员一脸坏笑（当然你带着眼镜根本看不到）的告诉你：“一会儿你会感到一种强烈的冲击感，可能会觉得头晕、恶心，但是不要担心，这就是过山车本来就应该有的感觉！”&/p&&img src=&/c0fbbc8afe9ddc77ca17db_b.jpg& data-rawwidth=&580& data-rawheight=&326& class=&origin_image zh-lightbox-thumb& width=&580& data-original=&/c0fbbc8afe9ddc77ca17db_r.jpg&&&p&于是你傻乎乎的开始了，“旋转！跳跃！我闭着眼！”从高处的轨道突然加速下降的时候，一股难受的感觉从后脑袭来，&b&“想吐！”&/b&&/p&&p&玩完之后，总觉得自己像是晕车了一样，久久不能恢复，想想曾经自己做过山车时的感觉，那种爽快刺激，心脏血液快速涌出的快感，&b&似乎有什么不同。&/b&&/p&&img src=&/71e89075fbd5addf86e80cba_b.jpg& data-rawwidth=&550& data-rawheight=&379& class=&origin_image zh-lightbox-thumb& width=&550& data-original=&/71e89075fbd5addf86e80cba_r.jpg&&&p&&b&因为，这根本就不是同一种感觉！&/b&&/p&&p&传统过山车会感觉到头晕是因为大脑暂时性缺血及平衡感失调，而VR过山车头晕的原因则是因为晕动症的发生。&a href=&/?target=http%3A///link%3Furl%3Dy2w69p7mNrMs0GRMXQ-fjOQBgM8MHSR3DXln5dxC8o6cSI9gijQzW6mQcjbHfYyc& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&晕动症_百度百科&i class=&icon-external&&&/i&&/a&&/p&&p&简单说来，晕动症发生的原因是由于&b&你的眼睛不能够明确同一个对照物的运动和身体运动在内耳形成平衡的机制&/b&(之间的关系)。&/p&&p&中枢神经系统对这种压力产生的应答是&b&大脑中的恶心中枢&/b&活动，所以你想吐。。。&/p&&p&因为我们都是坐着或站着玩VR游戏的，所以，凡是带有运动机制的VR游戏均符合晕动症发生的条件，这也就是为什么很多场景体验式的VR游戏不会让人感觉到头晕了。（场景体验式的VR游戏一般不会运动）&/p&&p&相当多的人都认为：VR游戏感到的眩晕、恶心感是由于画面的刷新频率不够。然而这并不是最根本的原因，根本原因在于&b&当画面刷新率不够的时候，画面的变化速度与身体感受到的加速度（力）不一致，即触发了晕动症。&/b&&/p&&p&所以，我们明确了&b&VR会使人头晕的根本原因：即人体视觉与体感的不协调。&/b&&/p&&p&这也就意味着，如果你想要做一款不会使玩家头晕恶心的VR游戏，以下三点是绝对不能出现在游戏中的：&/p&&p&&b&（1）不要试图通过鼠标或者手柄控制玩家所面对的方向。&/b&（简单的说就是不能用鼠标或者手柄来代替玩家的脖子来进行转头这一动作！至少不是频繁的利用这些操作，参考案例：MirroringRUN）&/p&&p&&b&（2）不要让游戏内玩家视角的坐标运动加速度过大。&/b&（也就是说，在玩家所处位置的每个方向上都不能有瞬间的加速或减速运动！至少不能让玩家察觉到，参考案例：ShowDownVRdemo）&/p&&p&&b&（3）不要试图营造那些本来在现实生活中就容易导致头晕的场景。&/b&（摇摇晃晃的小船和加速翻转的过山车，呵呵。）&/p&&br&&br&&p&有了以上三个绝对不能靠近的雷区，我们在设计的过程中不得不放弃成堆好玩的想法，整个过程就像这个游戏一样。&/p&&p&&img src=&/1bfc3da2f63f2_b.jpg& data-rawwidth=&556& data-rawheight=&445& class=&origin_image zh-lightbox-thumb& width=&556& data-original=&/1bfc3da2f63f2_r.jpg&&真的很没劲吖！&/p&&p&按照以上三点得出的游戏会变得很奇怪，下面是成果&/p&&p&&b&MirroringRUN镜像酷跑（这名字真二~）&/b&&/p&&p&这是一款运动竞速类VR游戏，玩家通过转动头部即可完成方向的变换，你需要尽全力躲避一路上的所有障碍，这个过程当中得分越高越好！&/p&&p&后续的多人竞技模式则更加有趣。&/p&&img src=&/eadd8a9d987da29936ead30_b.png& data-rawwidth=&1920& data-rawheight=&1048& class=&origin_image zh-lightbox-thumb& width=&1920& data-original=&/eadd8a9d987da29936ead30_r.png&&&p&不瞎扯了，说关键的，&b&我们试图将这个游戏做的完全不会使人头晕恶心！&/b&&/p&&p&&b&（1）整个游戏完全通过头瞄作为唯一输入。&/b&&/p&&p&游戏中，玩家无法控制自己的前进与后退，因为我们让玩家只能够向前，玩家唯一能够控制的就是自己转弯方向，&b&面朝哪个方向，就会前往哪个方向。&/b&&/p&&p&除此之外，在游戏的控制等方面上，我们均&b&只采用头瞄选择&/b&的方式，避免了戴上头盔找不到鼠标键盘的尴尬，同时也是为了移动端能够有更方便游戏操作。&/p&&p&&img src=&/5c241f7374ddd7dd85db3ebc54986d02_b.png& data-rawwidth=&1920& data-rawheight=&1040& class=&origin_image zh-lightbox-thumb& width=&1920& data-original=&/5c241f7374ddd7dd85db3ebc54986d02_r.png&&（玩家只需对准特定的按钮，就会有液体逐渐填满这个按钮，填满之后即为确认选择，具体操作见游戏试玩视频）&/p&&p&&b&（2）加速机制采用匀加速，即游戏内玩家运动时的加速度极低。&/b&&/p&&p&游戏中玩家前进的&b&速度会不断增加&/b&，游戏开始，玩家在选择难度后，会有不同程度的初始加速过程，我们在这一过程中提供&b&一个极少参照物的环境&/b&，让玩家几乎无法通过对比周围环境来得知自己的速度在增加。&/p&&p&与此同时在后续的游戏中，玩家的速度仍然会不断增加，但是我们让这一加速过程变得异常缓慢，其&b&加速度大约是初始加速度的1/50&/b&，同样会让玩家无法察觉到加度的感觉。&/p&&p&&b&（3）模拟人开车而不是坐车的运动方式。&/b&&br&&/p&&p&在玩家的视野中，我们添加了一架悬浮的飞行器作为载具，玩家&b&始终可以看到自己视野中有一架飞行器在下方&/b&，并且会随着自己的转动而改变前进方向。这个物件存在的主要目的不是为了符合游戏逻辑，而是为了&b&始终提供给玩家一个视觉参照物&/b&，这相当于我们在现实生活中视野里始终存在的，&b&鼻子。&/b&&/p&&p&这一点很重要，尽管你会认为自己平时根本看不到鼻子，但事实上你的一生都在用余光注视着你的鼻尖与鼻梁。所以在VR世界中提供&b&一个跟随头部转动的物件&/b&是解决晕动症非常重要的一环。&/p&&p&&b&通过测试，95%人在游戏过程中不会感到头晕，在连续5次及更多次游戏的情况下仍然如此，所以严格意义上讲，这款游戏基本避免了VR可能产生的晕动症现象。&/b&&/p&&p&试玩视频如下：&b&建议选择1080P观看&/b&，视频压缩的有些模糊了，见谅！&/p&&p&&b&&a href=&/?target=http%3A///page/s/d/r/s0175qx0tdr.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&MirroringRUN镜像酷跑 单人试玩视频 镜子科技&i class=&icon-external&&&/i&&/a&单人全过程试玩&/b&&/p&&p&&b&&a href=&/?target=http%3A///page/q/8/z/q01753yg68z.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&MirroringRUN镜像酷跑游戏试玩视频&i class=&icon-external&&&/i&&/a&游戏测试集合&/b&&/p&&p&有些人可能会觉得看视频都晕了，玩起来怎么可能不晕？&/p&&p&&b&但事实上确实不晕，哈哈！&/b&&/p&&p&&b&除此之外，别看玩的人看起来很淡定，其实玩起来的时候非常紧张，玩家玩到最高速度后已经彻底进入那个高速跑道了，每次躲避障碍的惊险情况下都会不由自主的大叫，因为叫的实在难听，所以就没有放出来。&/b&&/p&&p&&b&（我自己玩到后半段时已经觉得心跳快的不行了，大口吸气也缓解不了紧张的感觉，直到撑不住撞死之后才发现手脚都在发麻，这是很神奇的一点，也不知道是为什么？有懂生物的朋友希望能够给我解答一下。。。）&/b&&/p&&br&&br&&p&虽然这样的小游戏只能打个酱油，但是我希望它能带给我们一个思路，VR游戏与传统游戏是不一样的，它的设计需要全新的思路与方法。&/p&&br&&p&&b&下一部分讲营造VR的气氛，以及VR跑酷的关卡设计中如何与美术、程序之间协调。&/b&&/p&&br&&p&日奉上&/p&&p&镜匙娱乐，专注VR原创内容开发。&/p&
在接触到虚拟现实的那一刻，我就意识到，也许这是我应该走的道路。常常在想，这样的现实是否值得我去奋斗？因为那些看起来美好的未来也许只是虚幻的遐想罢了。镜匙网络科技 MirrorKeyVR微信公众：MirrorKeyVR 总有人私信问我一大堆关于VR的问题，虽然尽力解…
&p&内存泄露是开发人员在项目研发过程中最常见也最不愿遇到的问题。就目前来看，大家对于判断项目是否存在内存泄露仍然存在一些误区：&/p&&blockquote&&ul&&li&误区一&br&我的项目进出场景前后内存回落不一致，比如进入场景后，内存增加40MB，出来后下降30MB，仍有10MB内存没有返回给系统，即说明内存存在泄露情况。&/li&&li&误区二&br&我的项目在进出场景前后，Unity Profiler中内存回落正常，但Android的PSS数值并没有完全回落（出场景后的PSS值高于进场景前的PSS值），即说明内存存在泄露情况。&/li&&/ul&&/blockquote&&p&以上是我们遇到的开发团队反馈给我们的典型问题。相信大多数开发团队都会遇到类似的情况。&strong&在此有必要说明一下，以上两种情况均不能表明内存存在泄漏问题。&/strong&即便内存在一段时间始终保持增长的趋势，也不能简单地判定其存在内存泄露。因为造成内存不能完全回落的情况有很多，&strong&比如资源加载后常驻内存以备后续使用、Mono堆内存的只升不降等等，这些均可造成内存无法完全回落&/strong&。一般来说，我们推荐的判断内存是否泄漏的方法如下：&/p&&br&一、检查资源的使用情况，特别是纹理、网格等资源的使用&br&在我们进行过的项目深度优化过程中，资源泄漏是内存泄露的主要表现形式，其具体原因是用户对加载后的资源进行了储存（比如放到Container中），但在场景切换时并没有将其Remove或Clear，从而无论是引擎本身还是手动调用Resources.UnloadUnusedAssets等相关API均无法对其进行卸载，进而造成了资源泄露。对于这种情况的排查相当困难，这是因为项目中的资源量过于巨大，泄露资源往往很难定位。因此，我们在UWA测评报告中对项目中的每个资源都进行了详细的监控，并通过“生命周期”这一衡量指标让大家可以清楚地了解到每个资源在项目运行过程中的使用范围。&br&&img src=&/6a9438b25aca3c8cd8a2_b.jpg& data-rawwidth=&1914& data-rawheight=&1291& class=&origin_image zh-lightbox-thumb& width=&1914& data-original=&/6a9438b25aca3c8cd8a2_r.jpg&&&br&&p&这样，大家可以通过资源的“&strong&生命周期&/strong&”属性来快速查看有哪些资源是“常驻”内存的，并且判断该资源是“预加载”资源还是“泄露”资源。&/p&&p&同时，项目中所使用的总资源数量往往是成百上千的，让大家逐个资源检查过来是一件很费力的事情。&strong&所以，我们推出了资源的“场景比较”功能。建议大家通过以下两种方式进行资源比较，以便更快地找到存在“泄露”问题的资源&/strong&：&/p&&br&&blockquote&&ul&&li&同种类型场景或同一场景进行比较&/li&&/ul&&p&一般来说，同种场景或同一场景的资源使用应该是较为固定的，比如游戏项目中的主城场景或主界面场景。通过比较不同时刻同一场景的资源信息，可以快速帮你找到其资源使用的差异情况。这样，你只需判断这些“差异”资源的存在是否合理，即可快速判定是否存在资源泄露，已经具体的泄露资源。&/p&&/blockquote&&br&&blockquote&&ul&&li&不同类型场景进行比较&/li&&/ul&&p&除一些常驻资源外，不同类型的场景，其资源使用是完全不同的。比如，游戏中主城和战斗副本的资源，除少部分常驻内存的资源外，二者使用的绝大部分资源应该是不一致的。所以，通过比较两种不同类型的场景，你可以直接查看比较结果中的“共同资源”，并判断其是否确实为预先设定好的常驻资源。如果不是，则它很可能是“泄露”资源，需要你进一步查看项目的资源管理是否存在漏洞。&/p&&/blockquote&&br&二、通过Profiler来检测WebStream或SerializedFile的使用情况&p&AssetBundle的管理不当也会造成一定的内存泄露，即上一场景中使用的AssetBundle在场景切换时没有被卸载掉，而被带入到了下一场场景中。对于这种情况，建议直接通过Profiler Memory中的Take Sample来对其进行检测，通过直接查看WebStream或SerializedFile中的AssetBundle名称，即可判断是否存在“泄露”情况。&/p&&br&三、通过Android PSS/iOS Instrument反馈的App线程内存来查看&p&承接上述“误区二”中的说法，“Unity Profiler中内存回落正常，但Android的PSS数值并没有完全回落”是有可能的，这是因为Unity Profiler反馈的是引擎的真实分配的物理内存，而PSS中记录的则包括系统的部分缓存。一般情况下，Android或iOS并不会及时将所有App卸载数据进行清理，为了保证下次使用时的流畅性，OS会将部分数据放入到缓存，待自身内存不足时，OS Kernel会启动类似LowMemoryKiller的机制来查询缓存甚至杀死一些进程来释放内存。因此，并不能通过一两次的PSS内存没有完全回落来说明内存泄露问题。&/p&&p&我们推荐的测试方式是在两个场景之间来回不停切换，比如主城和战斗副本间。理论上来说，多次切换同样的场景，如果Profiler中显示的Unity内存回落正常，那么其PSS/Instrument的内存数值波动范围也是趋于稳定的，但如果出现了PSS/Instrument内存持续增长的情况，则需要大家注意了。这可能有两种可能：&/p&&blockquote&&ul&&li&&p&&strong&Unity引擎自身的内存泄露问题&/strong&。这种概率很小，之前仅在少数版本中出现过。&/p&&/li&&li&&p&&strong&第三方插件在使用时出现了内存泄露&/strong&。这种概率较大，因为Profiler仅能对Unity自身的内存进行监控，而无法检测到第三方库的内存分配情况。因此，在出现上述内存问题时，建议大家先对自身使用的第三方库进行排查。&/p&&/li&&/ul&&/blockquote&&br&关于Unity内存方面的问题，建议通过查看UWA Blog的两篇内存优化文章，基本上目前研发团队遇到的95%的内存问题，通过这两篇文章都可以找到相应的办法来进行解答。&br&&a href=&///?target=http%3A///archives/optimzation_memory_1.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&性能优化，进无止境&i class=&icon-external&&&/i&&/a&&br&&a href=&///?target=http%3A///archives/optimzation_memory_2.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&性能优化，进无止境---内存篇（下）&i class=&icon-external&&&/i&&/a&
内存泄露是开发人员在项目研发过程中最常见也最不愿遇到的问题。就目前来看，大家对于判断项目是否存在内存泄露仍然存在一些误区：误区一 我的项目进出场景前后内存回落不一致，比如进入场景后，内存增加40MB，出来后下降30MB，仍有10MB内存没有返回给系统…
谢邀。&br&&br&问题描述中红丸的出招指令是错的这个事我就不细说了，反正也不是重点。&br&&br&先谈谈你的设计思路。&br&&br&&b&能不能行？能行。&/b&&br&&b&有没有缺点？有。&/b&&br&&br&第一，&b&没有人规定出招必须要使用「方向键以外的按钮」触发&/b&。拿KOF举个例子，→·→是跑动，↓·↗是大跳；MD幽游白书中甚至有纯方向指令的必杀技，如飞影的残像、阵的空中浮游。这些指令用你的系统是判断不出来的。&br&第二，你用一个所谓缓冲区去存所有的指令，触发某个技能的时候清空对吧？那我问你，&b&Super Cancel&/b&这种功能你如何实现？比如说波动拳（取消）真空波动拳，实际指令简化是↓↘→P↓↘→P，但是按你的设计，波动拳触发的时候就把前面的↓↘→给清掉了，然后自然就放不出真空。&br&&br&&br&&br&我说说真正是怎么实现的。&br&&br&&br&你可以用状态机的概念来理解，但是注意：出招检测主要使用的并不是角色的状态，而是&b&每个技能有一套自己的状态，或者说指令阶段&/b&。&br&&br&拿波动拳来说，指令是↓，↘，→，P。&br&一开始是等待输入↓。当系统检测到↓被输入的时候，就进入等待↘的状态，检测到↘时则继续进入下一个状态，等待输入→。&br&关于输入时间限制，通常有这么几种方案：&br&&ul&&li&一段式：接收到第一个指令输入后开始计时，所有的摇杆、按键序列必须在X帧内完成。&br&&/li&&li&两段式：接收到第一个指令输入后开始计时，所有的摇杆序列输入必须在X帧内完成，然后重置计时器进入按键犹豫期，按键必须在Y帧内完成。&br&&/li&&li&多段式：接收到第一个指令输入后开始计时，下一个指令必须在X1帧内完成，然后重置计时器，再下一个指令必须在X2帧内完成……&br&&/li&&/ul&&br&例如HyperSFII采用的是多段式，也就是↓（犹豫期X1）↘（犹豫期X2）→（犹豫期Y）P。同一个必杀技中方向指令之间的犹豫期是一样长的，最后的按键分轻中重有差异，你可以看做是不同的技能。像PPP同按这种必杀技必须同时输入。&br&（日本玩家实测数据：&a href=&///?target=http%3A//www8.plala.or.jp/ichirou/hypersf2/input.htm& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&www8.plala.or.jp/ichiro&/span&&span class=&invisible&&u/hypersf2/input.htm&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&）&br&&br&&br&&br&&b&系统按帧扫描摇杆/按键输入，并且遍历出招表。每一个符合条件的技能都会被更新状态。&/b&&br&&br&你可以简单想象成类似这样的结构：&br&&div class=&highlight&&&pre&&code class=&language-text&&角色
防御耐久值
可行动/浮空/倒地……（这里可以用一个属性标记，也可以用多个属性）
（其它属性略）
出招状态表（集合&技能状态&）
技能指令（集合&指令&）
（动画，判定等属性略）
当前指令阶段
当前计时器
&/code&&/pre&&/div&&br&&b&确定角色、对局初始化的时候，先利用角色固有的出招表创建出招状态表。&/b&&br&&br&到实际游戏中，每帧再像下面这样处理。我这里为了方便你理解，使用的是类似OO的伪代码。实际老一点的街机游戏都是在算法中直接写死内存地址和偏移量的。&br&&br&&div class=&highlight&&&pre&&code class=&language-text&&foreach (var 技能状态 in 角色.出招状态表)
if (技能状态.当前计时器 &= 0)
var 技能 = 技能状态.技能;
var 所需指令 = 技能.技能指令[技能状态.当前指令阶段];
if (当前按键输入.Matches(所需指令.按键)) //实现略
if (所需指令.IsLast) //可以用指令数量判断
if (CanCast(角色, 技能)) //实现略
角色.Cast(技能); //出招
技能状态.当前指令阶段 = 0;
技能状态.当前计时器 = 0;
技能状态.当前指令阶段++;
技能状态.当前计时器 = 所需指令.犹豫期;
技能状态.当前计时器--;
技能状态.当前指令阶段 = 0;
技能状态.当前计时器 = 0;
&/code&&/pre&&/div&&br&注意，我再强调一遍，&b&每一个技能都会独立参与计算&/b&。简单示意如下：&br&&br&（技能/状态/计时器）&br&波动拳：0，0&br&升龙拳：0，0&br&旋风脚：0，0&br&（假设这三个技能的摇杆犹豫期都是固定6帧、按键犹豫期10帧）&br&&br&第1帧输入↓，&br&升龙拳：0，0&br&波动拳：1，6（激活）&br&旋风脚：1，6（激活）&br&&br&第2帧不变，&br&升龙拳：0，0&br&波动拳：1，5（激活）&br&旋风脚：1，5（倒计时）&br&&br&第4帧输入↘，&br&升龙拳：0，0&br&波动拳：2，6（进入下一状态）&br&旋风脚：1，3（继续倒计时）&br&&br&第7帧输入→，&br&升龙拳：1，6（激活）&br&波动拳：3，10（进入下一状态）&br&旋风脚：1，0（时间到，下一帧复位）&br&&br&第11帧输入P，&br&升龙拳：1，2（倒计时）&br&波动拳：4，0（触发）&br&旋风脚：0，0&br&&br&大概就是这样的感觉。我上面示意的算法还模拟了&a href=&///?target=http%3A//games.t-akiba.net/sf2/theo_sys.html& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&games.t-akiba.net/sf2/t&/span&&span class=&invisible&&heo_sys.html&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&中提到的「入力再開１フレーム」现象，例如摇杆拉住→（经过X帧后）↓↘+P，如果输入↓的时候正好是升龙计时归零的那一帧，那么之前输入的→并不被承认，于是也就发不出升龙拳。再晚一帧的话，由于归零后重新接受了→，指令就是有效的了。&br&拿上面的例子说，如果你没有输入↘，而是在第8帧（复位）时才输入，那么之前的↓相当于被抹掉了，最后是发不出波动的。&br&&br&&br&蓄力系指令有单独的蓄力计时器，这里不赘述，作为程序员你应该有能力类推出来怎么实现。&br&Match按键输入和指令的具体实现我也没有提，这对于游戏手感其实是有很大影响的——&b&能接受什么样的简化指令？&/b&&b&如果最后同时满足了多个技能的指令序列，具体执行哪一个？不同作品的处理方式不同，造成的效果也不同。&/b&&br&&br&举个例子，街霸中按键和抬键都算作输入。&br&像前面说的波动取消真空波动，↓↘→P（按住）↓↘→P（抬起）也能承认。要实现这一点，在处理按键的时候就不能只拿按键当前状态，而是要考虑把「按键状态变化」当成事件。设置一个极小的缓冲区就可以解决。&br&&br&再例如KOF中的←↙↓↘→P这一招，&br&在KOF96中是必须每个方向都摇到位才可以。&br&KOF97就不同了：实际指令变成了←↓→P，而↙在KOF97中视为同时输入了←和↓，因此只输入↙（两帧以上）→P就可以摇出来。同理，←↘→P也是可以的。&br&但是←↘P就不行，因为它最后一个方向要求严格匹配，必须要单独输入→才可以。输入→之后可以随便输入其它方向，例如←↓→↘P也可以。像跳跃中↓↘→K这种必杀技，可以在地面上直接输入↓↘→↗K（也就是所谓低空凤凰脚）。KOF97中，大部分必杀技只要是犹豫期内完成输入，最后按键的时候摇杆在哪个方向都无所谓，换句话说↓↘→↖K可以后跳低空凤凰脚。KOF99就不行，↓↘→↗的技术还存在，但是↓↘→↖是不接受的，含有←要素的方向会强制取消掉↓↘→系的指令。&br&&br&更多系统实测可以参见&a href=&///?target=http%3A///motdouga/kof-top.html& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&/motdouga/kof&/span&&span class=&invisible&&-top.html&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&。&br&&br&&br&看到这你应该差不多基本明白指令扫描是怎么回事了。顺带着应该也能明白模拟器上的简化出招作弊的几种原理（其实都是改内存）：&br&&ol&&li&延长技能设定的指令窗口（犹豫期），本来是6帧，延长到10帧，相当于速度慢点系统也接受，就会更容易摇出技能。&/li&&li&缩短蓄力技的蓄力时间设定，本来要蓄70帧，改成1帧，不用蓄也能阿里斯古了。&/li&&li&改变技能的状态，把当前指令阶段锁定到最后一段，系统认为你前面的已经摇过了，像↓↘→+P只输入最后的→+P就可以了。有点一键出招的感觉。&/li&&/ol&&br&&br&&b&以上，禁转。&/b&
谢邀。 问题描述中红丸的出招指令是错的这个事我就不细说了，反正也不是重点。 先谈谈你的设计思路。 能不能行？能行。 有没有缺点？有。 第一，没有人规定出招必须要使用「方向键以外的按钮」触发。拿KOF举个例子，→·→是跑动，↓·↗是大跳；MD幽游白书…
分享一些具体的gc alloc产生的隐患和解决方案。&br&&br&&br&1 Delegate&br&&br&1.1 Delegate的赋值（=）操作&br&&br&Delegate是我们的好伙伴，日常开发中，都离不开它。但是，不真正了解Delegate而胡乱使用可能会带来巨大的性能问题&br&&br&下面的代码中，声明了一个委托和一个委托类型的成员变量del，然后在Update的时候赋值，将Start赋值给del。&br&&br&
public delegate void DelegateMethod();&br&
public DelegateM&br&
void Start () {&br&
void Update () {&br&
del = S&br&
} &br&&br&这段代码是有性能问题的。在Unity的profiler可以看到有104B的gc。&br&&br&&br&为什么呢？因为C#中对委托的“=”操作，其实是等价于new。上面的Update中的实现，在编译器看，其实等价于&br&&br&
del = new DelegateMethod (Start);&br& 在编程时，我们要牢记这点，切忌对委托对象进行频繁的赋值操作，避免导致不必要的性能消耗。&br&&br&1.2 Delgate 的 “+/-”操作。&br&&br&Delgate还可以进行“+/-”操作，实现多委托。&br&&br&
public delegate void DelegateMethod();&br&
public DelegateMethod single_&br&
public DelegateMethod multi_&br&
void Start () {&br&
single_del = S&br&
multi_del = single_&br&
void Update () {&br&
multi_del += single_&br&
multi_del -= single_&br&
}&br&&br& profiler的结果，每帧312B的gc&br&&br&&br&因为在Start函数中，有一次对multi_del的赋值，multi_del此时已经是一个SimpleDelgate了，但Update时，先有一个&+&操作，c#就讲multi_del改为了MultiDelgate。MultiDelgate的添加和删除元素，都会有Clone操作，如上图中红框所示。&br&&br&并且，multi_del越长，这个Clone操作的次数就越多。比如这种情况：&br&&br&
public delegate void DelegateMethod();&br&
public DelegateMethod single_&br&
public DelegateMethod multi_&br&
void Start () {&br&
single_del = S&br&
multi_del = single_&br&
multi_del += single_&br&
multi_del += single_&br&
multi_del += single_&br&
void Update () {&br&
multi_del += single_&br&
multi_del -= single_&br&
}&br&&br&&br&&br&会造成每次调用高达0.9kb的gc。&br&&br&1.3 EventDispatcher的最佳实现。&br&&br&因为1.1和1.2，我们推荐用List&Delegate&数据结构来实现常用的事件系统。下面是一份best praticle&br&&br&&br&public class EventDispather : MonoBehaviour {&br&
public delegate void EventHandler();&br&
public List&EventHandler& _handlers =new List&EventHandler&();&br&
void AddHandler(EventHandler handler){&br&
if (!_handlers.Contains (handler)) {&br&
_handlers.Add (handler);&br&
void RemoveHandler(EventHandler handler)&br&
if (_handlers.Contains (handler)) {&br&
_handlers.Remove (handler);&br&
class Example&br&
EventD&br&
EventHandler _Example_H&br&
public Example()&br&
dispatcher = new EventDispather();&br&
_Example_Handler = Example_H //缓存函数代理的引用&br&
public void Update()&br&
dispatcher.AddHandler (Example_Handler);//gc warning！！&br&
dispatcher.RemoveHandler (Example_Handler);//gc warnning！！&br&&br&
dispatcher.AddHandler (_Example_Handler);&br&
dispatcher.RemoveHandler (_Example_Handler);&br&
public void Example_Handler()&br&
}&br&&br&2 String字符串&br&2.1 String.concat&br&&br&&br&运行下面的测试代码：&br&&br&
public string a_str = &1&;&br&
public string b_str = &2&;&br&
// Update is called once per frame&br&
void Update () {&br&
void A(){&br&
a_str = &1& + &2&;&br&
void B()&br&
a_str = a_str + b_&br&
void C()&br&
a_str = a_str + b_str + a_&br&
}&br&&br&&br&&br&&br&我们发现，String.Concat内部在每次调用时会创建一个新的字符串对象。所以String.Concat字数越多，gc alloc就越多(StringTest.C()&StringTest.B()).&br&&br&值得一提的是，A（）函数的实现没有gc，因为编译器会将这种常量字符串的拼接在编译期优化掉。）。&br&&br&一种优化办法是，使用StringBuilder或String.Format（内部实现也是stringbuilder）来减少创建新字符串对象的次数，但需要在创建StringBuilder&br&&br&2.2 Int.ToString&br&&br&&br&游戏开发中，经常会遇到将游戏中的数值显示到ui上的需求，比如：&br&&br&
public int gold = 1;&br&
void Update () {&br&
gold++;&br&
uiGold.text = gold.ToString ();&br&
}&br&&br&&br&&br&对于数字文本，有一种优化方法是预生成游戏中所有可能用到的所有数字文本，从而避免了运行时ToString的消耗。假设游戏中的数字不会超过20480,加血和扣血不会超过10240.
private static string[] int_str_dict=&br&
private static string[] plus_int_str_dict=&br&
private static string[] del_int_str_dict=&br&&br&
//游戏加载阶段调用。&br&
public static void Init()&br&
if (int_str_dict == null) {&br&
int_str_dict = new string[20480];&br&
plus_int_str_dict = new string[10240];&br&
del_int_str_dict = new string[10240];&br&
for (int i = 0; i & int_str_dict.L i++) {&br&
int_str_dict [i] = i.ToString ();&br&
for (int i = 0; i & plus_int_str_dict.L i++) {&br&
plus_int_str_dict [i] = &+& + i.ToString ();&br&
for (int i = 0; i & del_int_str_dict.L i++) {&br&
del_int_str_dict [i] = &-& + i.ToString ();&br&
public static string ToPlusIntString(this int value){&br&
if (value & plus_int_str_dict.Length && value &= 0)&br&
return plus_int_str_dict [value];&br&
return &+&+plus_int_str_dict.ToString ();&br&
public static string ToDelIntString(this int value){&br&
if (value & del_int_str_dict.Length && value &= 0)&br&
return del_int_str_dict [value];&br&
return &-& + value.ToString ();&br&
}&br&&br&三个数组的总内存占用为&br&&br&&br&相比运行时的那些gc，这187kb的预分配其实性价比很高，所以代码优化为。&br&&br&&br&
public int gold = 1;&br&
void Update () {&br&
gold++;&br&
uiGold.text = gold.ToIntString ();&br&
}&br&&br&3 用枚举作key的Dictionary&br&游戏中经常会用枚举，但用枚举做字典的key就会有性能隐患。&br&&br&
public enum EnmKey&br&
public Dictionary&EnmKey,int& enm_dict = new Dictionary&EnmKey, int&();&br&&br&
// Update is called once per frame&br&
void Update () {&br&
int a = 0;&br&
enm_dict.TryGetValue (EnmKey.a,out a);&br&
}&br&&br&&br&为什么呢。因为在Dictionary内部实现中，会调用接口&br&&br&object.Equals(object a);&br& 来判断两个元素是否相等。但枚举为值类型，object是引用类型。将值类型的数据转换为引用类型，就会产生一次装箱和拆箱操作（详细细节可以百度），从而导致gc alloc。&br&&br&实际上：&br&&br&List of Struct&br&枚举为key的Dictionary&br&Struct为key的Dictionary&br&在查询时，都会有装箱带来的消耗。&br&&br&解决办法是：&br&&br&确保你的struct实现了 IEquatable& T &&br&确保你的structoverride Equals() and GetHashCode()&br&为枚举为key的字典创建一个Custom Comparer&br&&br&
public enum EnmKey:int&br&
public class EnmKeyTypeCompare : IEqualityComparer&EnmKey&&br&
public bool Equals (EnmKey x, EnmKey y)&br&
return x ==&br&
public int GetHashCode (EnmKey obj)&br&
return (int)&br&
public Dictionary&EnmKey,int& enm_dict = new Dictionary&EnmKey, int&(new EnmKeyTypeCompare());&br&&br&
void Update () {&br&
int a = 0;&br&
enm_dict.TryGetValue (EnmKey.a,out a);&br&
}&br&&br&&br&4
其他小tips&br&&br&永远不要遍历Dictionary，除非你能保证只需遍历有限的几次。&br&元素个数较少（小于10）List的查询速度其实不比Dictionary慢。&br&对于可变长度的List，Dictionary，最好能预估一下容量，避免运行时扩容带来的性能消耗。&br&性能敏感地带，不要使用List.Find，List.FIndIndex，List.FindAll 等接口，原因和1.1中所 说一样，每次会有一次对象创建，从而产生gc alloc。&br&uGUI的Image.set_fillAmout有gc alloc消耗，即使你设置的值是相同的。建议赋值之前做一次是否改变的判断。&br&UnityEvent.Invoke性能很差，不推荐使用。对于有回调需求的还是建议使用Delegate，如本文第一节所述。&br&优化性能时一定要杜绝每帧都有gc alloc的实现。即使每帧50b，一秒就是3kb！（60fps的话）
分享一些具体的gc alloc产生的隐患和解决方案。 1 Delegate 1.1 Delegate的赋值（=）操作 Delegate是我们的好伙伴，日常开发中，都离不开它。但是，不真正了解Delegate而胡乱使用可能会带来巨大的性能问题 下面的代码中，声明了一个委托和一个委托类型的成…
我觉得首先要对“物价”定义，这个物价是指游戏中的虚拟货币或一般等价物，还是折算为现实中的实际货币或等价物（如点卡兑换或人民币线下交易）？&br&&br&前者，我认为有可能，但不太可能普遍和更慢&br&后者，我认为有可能，可能相对普遍和更快&br&&br&其次很显然，题主的游戏环境应该是一个允许泛交易的游戏环境（显然不允许的环境下不存在p2p交易，也就没有什么价格变化的问题了）&br&&br&根据我的粗浅经验，最有可能的情况是：物品价格随游戏进程而有明显变化（通常为下滑，但这往往是通胀及稀有度变化的效应），在足够未定的环境中&b&持续一段时间&/b&，会自然稳定&br&&br&我认为如果&b&快速进入&/b&“价格稳定”的经济环境，一般说明如下几点：&br&&b&1，游戏自然进入经济稳定环境而得出合理的价格，这个期间低于原预期&/b&&br&&b&2，目的性更强和更有经验的玩家将上述经验带入了新的游戏环境&/b&&br&&b&3，有付费要素调节乃至决定了经济体系的兑换比例&/b&&br&&br&&br&下面简单试阐述几点：&br&1，通常的泛交易游戏环境必然出现稳定态&br&2，稳定态的内外部决定因素&br&3，人工加速稳定态的必然性&br&&br&用通俗的理论来理解，价格控制由供求决定：以游戏的基本经济体制套用货币理论和最基础的新凯恩斯理论的角度解读，是基本适用于游戏中的虚拟环境的，其共同规律如下：&br&1.1绝大多数（不可排除有少量例外，下同）虚拟资源和一般等价物，货币，均由玩家控制的角色劳动产出，即劳动力转换为价值&br&1.2绝大多数游戏运营方不会频繁粗暴直接干涉游戏内的经济体系，因此在大多数情况下，游戏内经济体系呈现完全竞争市场状况而非“政府”干涉状况&br&&br&2.1服务器开放瞬间，社会总产能，总资源，总货币价值均为零&br&2.2随游戏进程，劳动力总量，总质（单位时间劳动收益）会有上升故而社会总产能，总资源，总价值呈必然上升趋势&br&2.3因为2.2，故而会产生通货产量提升，进而带来通胀效应&br&2.4游戏和现实最大的不同之一即货币的直接回收系统，通常设计良好的系统会保证总体系内的货币直接消失换取玩家需要的服务或其他资源，以总量维持稳定而非无限通胀&br&2.5假设在某个游戏进程点之后（短期内没有大的更新，游戏生态相对稳定的期间内），供求可能达到准一般均衡态或非瓦尔拉斯均衡态（存在普遍的，大量的生产过剩）&br&2.6此时的货币和价格环境趋于稳定，每一样物品的价值均基于其实际价值（通常为其养成向核心数值价值）决定&br&&br&3.1玩家环境总体会趋于帕累托最优，而且游戏进程通常保证这个趋向不可逆&br&3.2如果游戏不允许付费购买玩家的核心追求，则该趋势随游戏设计的核心数值获取难度而变化，通常为趋缓&br&3.3如果游戏允许付费购买玩家的核心追求（以下解释为核心数据），则该趋势随平均付费度而变化，通常为趋缓（即付费效率趋低），且受到3.2的影响&br&3.4基于2.4 2.5 3.1 3.2 3.3，可知正常情况下，即&b&游戏总内容，进行时间，总玩家数量三个有限条件&/b&下，在&b&某个时间节点以后，游戏社会整体经济状况一定会达到稳定&/b&&br&3.5例外：在未达到足够稳定的情况下受到上层干预，使得整个社会经济体系发生变化（通常原因为大型的更新，如新的版本，影响大的数值调整，增添删改已有内容等）&br&&br&&b&4.1该游戏若有额外付费购买核心数据的直接或间接方式，则其平均折换值（可以将所有购买/折换行为），将成为系统内认可的“定价”&/b&&br&&b&4.2该游戏若无额外付费购买核心数据的直接或间接方式，则达到或接近均衡态时的平均货币价值和物品价值，将成为系统内认可的“定价”&/b&&br&4.3该游戏若有付费购买和核心数据无关的付费方式，则其对社会经济状况无直接影响&br&（例如土豪购买十万小喇叭辱骂敌对公会为“无影响”‘；但充值排行榜第一的土豪得到了一把毁天灭地刀为“有影响”）&br&&br&5.1除非出现断裂式的，或跨平台，跨地区跨语言的玩家隔离，否则游戏内的经验将由玩家进行完整记录和传承&br&5.2绝大多数开放新服务器的游戏环境和老服务器的环境接近或相同&br&5.3基于5.1，新环境中的玩家的总体行为将呈现更有效率，即更快趋向于平衡点的特征&br&5.4新环境中的玩家中，完全经济人大于完全自然人，即打金工作室和商人的购买力和生产力比例超过玩家比例时，游戏将加快趋近平衡&br&&br&综上：可得最上面黑字部分结论&br&&br&&br&update：我阅读了&a data-hash=&642e40fd8c4dcac56f20b& href=&///people/642e40fd8c4dcac56f20b& class=&member_mention& data-editable=&true& data-title=&@孙志超& data-tip=&p$b$642e40fd8c4dcac56f20b& data-hovercard=&p$b$642e40fd8c4dcac56f20b&&@孙志超&/a&的答案，认为其中有合理的地方，我归纳他的结论是：&br&商人和打金工作室具有凌驾于游戏本身经济体系以上的调节力，驱动了市场达到平衡&br&&br&我认为这是一个明显的干扰因素，也认为是一个明显的因素，当“所有商人和工作室的产能和购买力“已经达到和超过了该社会经济体系中其他所有玩家之和时，这个因素就成为主要原因，否则为次要原因，但仍然是最直接的促进游戏经济体系达到平衡的重要因素。&br&&br&但也提出一些不同意见：关于网络游戏环境是否理想博弈环境或经济实体这点之中，”完全信息“一条是显而易见的错误：&br&在游戏环境中的用户，对于某一资源（在一个服务器内）的具体情况，包含但不限于：资源总量，产出效率，单位成本，持有量，流动量，平均成交量，交易方，价格走势——都&b&不可能&/b&拥有完全信息，他们仅可能拥有少得可怜的有限信息，即可察范围内有限的样本&br&甚至于除非对所有和交易有关的行为和信息均进行记录的情况下，游戏运营方都不可能拥有完全信息，所以对于多数玩家而言经济体系的表征更类似于黑盒而非玻璃盒&br&&br&例即玩家大多数情况下不可能获知：“因近期大量打钱（非打装）工作室入驻因而本服呈现通胀状态”推知“未来一段时间内我的实际购买力降低”进而做出“我要不赶紧把手头的金币都买东西，要不准备用人民币从工作室买金币”或者类似的决策，我想这一点无需证明。&br&&br&我们认为多数玩家在游戏内消耗金钱和时间是为了让自己的角色的核心数值得到成长，但显而易见，这并非玩家的唯一目的和绝对行动模式，大量休闲型玩家的存在，和游戏内利他行为的存在可以证明这一点。&br&&br&基于三个完全——完全理性，完全信息，完全自利的理想模型分析并不适用于分析网络游戏内经济环境，这点是容易证明甚至无需证明的。
我觉得首先要对“物价”定义，这个物价是指游戏中的虚拟货币或一般等价物，还是折算为现实中的实际货币或等价物（如点卡兑换或人民币线下交易）？ 前者，我认为有可能，但不太可能普遍和更慢 后者，我认为有可能，可能相对普遍和更快 其次很显然，题主的游…
如何创建更具引诱性的游戏奖励框架？&br&&br&曾经有人问我，决定一款游戏循环可玩性价值的是高难度还是深入人心的奖励机制?我当时思虑了许久，发现这个问题比较难以回答。固然，高难度的游戏挑战可以形成一个较长周期的玩家目标，但优秀的奖励机制也是形成玩家黏合度的关键要素。事实上不管是硬核，重度还是轻度游戏都或多或少存在基于累积资源层面的玩法设计，而这种资源累积的主要获取渠道就是奖励机制。纵然是一款轻度游戏，其奖励机制大多数也都具有繁复而庞大的特性。玩家可以体验到各个大小环节汇聚累加而成的各种奖励，从而使玩家具有了该游戏所赋予的倾向性理解。&strong&大多数游戏设计师会将这种结果理解成是这款游戏的灵魂级奖励成功地向玩家完成了释放&/strong&（让玩家感受到了游戏理念）。&br&随着对游戏设计研究的深入化与游戏产业的壮大，奖励机制正在逐步提升它所处在游戏之中的权重值。从简单的点击操作到复杂的策略挑战，都密集地分布着各种各样的奖励，奖励类型多种多样，包括了数据型、体验型、资源型、道具型等形式，以阶梯式布置的方式让不同属性的玩家均能获得不错的成长体验。游戏奖励的双刃剑效应看过我往期文章的读者应该知道我在研究游戏设计的时候时常会提到心理学的一些概念，其实这并非是一种巧合与题外延展。产品与用户的关系其实说白了就是一种心理学验证过程，只有透彻化面向用户的心理，才能设计出真正符合需求与定位的优秀产品，奖励机制的设计也不例外。但奖励机制的心理层面却又比较特殊，它具有着非常明显的两面性形成双刃剑效应。&strong&正刃效应：斯金纳箱实验运用&/strong&大部分人都清楚的知道奖励机制对于一款游戏的留存性至关重要，但不知大家是否有想过他重要的原因是什么呢？它为何会形成这种不可或缺的需求效应？为了解答这个问题，我们不妨回顾一下哈佛大学著名的“斯金纳箱”实验。这是一个科学家们为了研究操作性条件反射而设计的实验，简单的来说就是通过一些利于目标的诱导条件使目标更快速的学习设计者所设置模块的使用方法。在这个实验中，科学家们将一只老鼠放在箱子里，箱子内部有一个拉杆。科学家们将实验分为三组，第一组，什么都没有，第二组，如果老鼠拉动箱子里的杠杆会获得一些食物，第三组，如果老鼠拉动箱子里的杠杆会有一定的概率获得一些食物。科学家们通过三组实验对比研究怎样的条件能让老鼠更频繁地拉动杠杆。实验结果发现，第三组的老鼠学习行为最快，拉动杠杆的频繁度最高。&br&从中，我们可以清晰的看到奖励安排与行为诱发之间的关系。&strong&在任何一次特定的行为回报当中，最有效的奖励安排是通过随机性插值法所设计出的变化性比例奖励&/strong&，它会使目标始终获得一个平均的回报，而不会让目标过快过慢地获得回报，从而丧失或削弱行为动力。这一点运用到游戏中有着更加直观的体现。例如在《魔兽世界》中，一个任务道具或高等装备需要玩家挑战一个副本BOSS，但挑战完成后并不是100%的概率获得这些物品，因此诱使玩家反复的进行挑战。这也为“当奖励只是一种机会而不是必然性的时候，玩家更乐意频繁地去执行一个行为”的观点提供了论证依据。&br&不过需要注意的是，此方法虽然是一种核心的设计方法，但同时也具有较为苛刻的设计要求。设计师必须遵循用户心理极值，合理设定奖励的获得比例，过高过低都会导致玩家产生厌倦感（由于程序算法中一般采用伪随机分布式方法，所以必须人为的控制，使每个玩家的概率具有全局效应的50%而不是真正的50%）。至于持反对意见所提出的游戏内容欺骗说（该说法认为将奖励概率化以实现延长玩家体验游戏内容的时间属于欺骗行为，玩家始终在玩同样的游戏内容，却花费了更多的时间。），我个人并不赞同。因为固有化的奖励获取本来就是一种数学理想模型，不单单是不利于游戏生命力，也不符合现实世界的自然逻辑。&br&&strong&反刃效应：激励性目标偏转&/strong&20世纪末，有一位心理学家曾与当地幼儿园合作做过一次有趣的实验，这个实验的目的是研究行为目的是否会受奖励成分的影响。他将幼儿园喜欢绘画的孩童分为两组进行绘画游戏，他告诉第一组的孩童如果完成好的绘画将会得到奖励，而并没有与第二组的孩童声明什么，只让他们自由绘画。随后，两组的孩童完成了近乎相同数量的绘画作品。于是他发起第二次绘画活动，这一次，他不再给第一组的孩童发放绘画奖励，结果第一组的孩童在绘画数量上出现了大幅度的下降，而第二组则几乎没有任何影响。于是该心理学家作出结论，由于他给第一组的孩童赋予了一个额外的目标（物品奖励），不知不觉中，该组孩童的动机就从喜欢绘画转变成为了奖励而绘画，因此在第二次没有奖励的绘画中，就有不少人不再绘画了。这便是典型的激励性目标偏转，通过一种外在利益关系使得用户对一种行为的心理价值产生了变化，而且往往这种变化是弊性的。在游戏中，这种错误的方向不但经常被设计师们忽视，甚至反而成为一种设计方法参考进行推广使用。为了深化这种概念的理解，我们需要一个游戏体验实例来进行进一步的剖析。作为一款重度游戏的爱好者，呈现出更加复杂而完善的操作体验是我追求一款动作游戏的核心要求。而《龙之谷》是目前MMO类游戏中最符合我心中想法的产品。最开始我只是单纯地被这款游戏的动作性所吸引并乐此不疲，不过随着等级的提升，属性的增强，对游戏运作模式的了解加深，不知不觉我的游戏目标从动作性战斗体验变成了高等装备的制作与人物数据的跳跃上。于是我努力的研究各种怪物数据与生存的手法以完成这款游戏中最困难的副本获得最好的装备。很快，在我的努力下，这个目标被实现了。那一刻我如释重负，退出了游戏，在那之后较长一段时间里我都处于冷谷期状态，完全不想再上游戏。这时我才发现我的游戏动机从对动作性战斗的喜爱变成了传统的装备数据追求，由于我实现了这一点，所以那一段时间完全失去了游戏动机。从以上案例不难看出，《龙之谷》在不知不觉之中为我植入了一个硬性目标，并逐渐破坏了我玩这款游戏的初衷。虽然从宏观角度来说似乎没有什么改变，我始终都是为了一个动机在进行游戏，但其本质却显得畸形了许多。&strong&激励性目标偏转在充分向世人展示出奖励的强大蛊惑性的同时，也暴露出了其极度容易伤害到产品自身的缺陷&/strong&。奖励效能与风险平衡如果奖励机制的设计如此复杂，我们究竟应该如何妥善地处理这种两面性，设计出优秀的奖励机制呢？其实我认为最关键的要素在于奖励效能与风险平衡之上。&strong&分清主次：严谨地设计奖励效能&/strong&奖励效能，顾名思义就是奖励机制在游戏中所造成的影响力大小。游戏设计师必须明确自己的游戏目标究竟是什么，不能被短期的利益与玩家的愉悦心理所迷惑。因为说到底，奖励机制最终是要围绕游戏进程而服务的。《龙之谷》就存在奖励效能过大，导致游戏动机被破坏的问题。但是过低的奖励效能又会使玩家难以进入专注的挑战状态。所以优秀的奖励机制必须合理把握奖励效能的度，在不影响游戏主要特性的前提下，营造出能成功引诱玩家去挑战的价值。当然，最理想的形态是当奖励刚好和玩家当时的需求相衔接。&br&不过现在市场上最流行的是基于F2P方式的游戏运营模式，这种盈利模式下的游戏在奖励效能方面需要考虑的问题比内容与时间型付费的游戏要更加复杂，因为它需要建立一个更加细分化的奖励体系。首先游戏内直接获得的奖励要进行合理的控制，以确保商城的奖励足够具有吸引力，但同时要建立一个付费奖励系数阀值，使其不会形成非付费玩家无法逾越的沟壑。而对于直接获得奖励，可以适当的缩放价值比例，但可以增加同一个时间周期内获得的次数。因为获得的满足感是玩家的一种基础情绪，如此一来玩家的良性情绪很容易被游戏放大，就算奖励不高，但如果次数足够多，玩家在心态上也是欢迎的。&br&&strong&数据模型：符合玩家投入的风险平衡&/strong&在游戏领域尚在启蒙的时代，一名知名的游戏设计师和一位心理学家合作研究后发现，游戏中的奖励存在变量随机因素的设定会大大提升这款游戏给玩家造成的牵制力与留存率。而如果游戏奖励是固定的或这个奖励的吸引力较低的话，则对玩家所形成的牵制力就会弱化很多，因此优秀的奖励机制离不开合理的风险设计。一个合理的风险设计不但能使奖励更加具有引诱性还能提供很多额外的游戏价值。古人云：“富贵险中求”。风险与奖励同是共生而存的，而且越大的风险获得越好的奖励也是一种真实存在的自然法则，所以这也是游戏奖励设计中的基本原则。优秀的游戏设计师总是擅长于塑造让玩家进退两难的困境。在面对奖励与风险相当的局面之时，让玩家自己权衡利弊，判断每一步行动可能产生的风险或者回报。给玩家一个选择的机会，你是选择较少的奖励与安全的处境还是丰厚的奖励与危缘绝地（或者较低概率的奖励），这是进一步提升游戏刺激性的巧妙方式。&strong&优秀案例：浅析巫师3的奖励机制&/strong&作为一款敢于使用直接免费上市，喜欢的话再付费购买这种匪夷所思的运营手段的巫师3来说，不是开发商太过于愚蠢，就是的确有超然的过人之处。事实证明，巫师3是后者。巫师3的优秀不仅仅是玩法与剧情的体现上，在奖励机制的设计上也具有相当的代表性。在这款游戏中，宝箱奖励与任务奖励的设计上与《上古卷轴》类似，具有等级挂钩，少量区域固定化等特征。也就是说宝箱开出的物品与玩家的人物当前水平相匹配，不会获得过于超越当前水平或者过于鸡肋的装备物品，从而使得奖励效能得到了有效地控制。更加有趣的是，这款游戏还具有独特的物品属性动态变化的机制。当玩家成功击杀几个敌人以后，每次拾取物品，剩余未拾取的物品会根据一定的机率产生品质变化。也就是说原本A身上留下的战利品是传奇品质的武器，当玩家拾取了B身上的战利品以后，A身上的战利品有几率改变为低级品质的武器。如此一来，看似固有化的奖励拾取也具有了不可预料的变数。大大提高了玩家所面临的风险系数。奖励机制的本质是什么牛津大学的一名哲学家最近在利物浦游戏开发者大会上就奖励机制的上瘾问题做出了一定的看法，他认为让玩家上瘾是游戏设计师的主要目标。虽然我并不赞同这个观点，但这种说法形成的原因却也可以理解。就拿F2P游戏中常见的“外观性氪箱”为例，玩家们做出此行为的动机就是为了获得更好的外观奖励，但往往真正获得了奖励以后便不再对此感兴趣，似乎只是一种纯粹追求自己所没有的物品的欲望，这种欲望放大以后的确就是一种瘾因子的体现。但是若以此现象对游戏奖励机制进行套用未免有点强行理解。因为&strong&游戏奖励机制的本质是为了更好的引诱玩家接触游戏，深入游戏，是一种将玩家从游戏低压抑系数向高压抑系数转变的催化剂&/strong&。因此，更好地诠释乐趣才是奖励机制的本质。那么问题出在哪呢？是F2P的错吗？还是在这个浮躁的年代，很多游戏设计师忘记了产品理念，本末倒置？最后的问题，你到底要做毒品还是游戏？&br&对游戏相关感兴趣的朋友，欢迎关注我们的微信公众号。&p&&a href=&///?target=http%3A///r/5UTN1QvEGFZnrU_29xH3& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&/r/5UTN1Qv&/span&&span class=&invisible&&EGFZnrU_29xH3&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a& (二维码自动识别)&/p&
如何创建更具引诱性的游戏奖励框架？ 曾经有人问我，决定一款游戏循环可玩性价值的是高难度还是深入人心的奖励机制?我当时思虑了许久，发现这个问题比较难以回答。固然，高难度的游戏挑战可以形成一个较长周期的玩家目标，但优秀的奖励机制也是形成玩家黏合…
&img src=&/958741fbf14e84bf4a186d96_b.png& data-rawwidth=&725& data-rawheight=&133& class=&origin_image zh-lightbox-thumb& width=&725& data-original=&/958741fbf14e84bf4a186d96_r.png&&这样高精度多细节的界面设计的开山鼻祖是暗黑3的设计，国内很多游戏都效仿其风格来做。写实绘制型风格的设计，主要材质多采用石头，金属的搭配结合。&br&&br&《暗黑三》界面标头与主功能条&br&&img src=&/2f86cb4d51e3552ccd3496_b.png& data-rawwidth=&596& data-rawheight=&202& class=&origin_image zh-lightbox-thumb& width=&596& data-origin}