文丨刘武锋
一百多行搞定一个游戏？这不是瞎扯蛋，吹牛逼吗？要不，就是这游戏非常简单！冷静一下，咱先看看游戏需求：
2.1游戏规定最大参与人数为21人。20位参赛选手和一个主持人。主持人只负责开始游戏辅助选出第一位擂主。
2.2游戏以房间赛制模式进行，即每个房间的比赛结果互不影响。以解决单次比赛中，出现分数重复的问题。房间内所有人要能实时看到正在比赛的选手的答题情况。
2.3游戏可以注册账号，游戏开始前需要参赛选手以自己真实姓名和店铺编号注册账号。并作为游戏排行数据显示。
2.4 主持人点击“开始游戏”，系统随机选出第一位擂主作为守擂者，随后由擂主自行选择自己的对手作为攻擂者并可以主动“开始”游戏。
2.5 擂主点击开始后，倒数计5秒进入答题界面。
2.6 答题界面分为两部分，攻擂者界面和守擂者界面。每个界面需要包括对应的名字、游戏、积分、店铺名称、和倒数计时。当选手答题时，对应的界面变亮并最高层显示。不答题者的界面则变灰并隐藏到下一层。
2.7 答题双方采用车轮战的方式轮流答题。答对加一积分，答错者淘汰。默认攻擂者首先答题。
2.8 每轮答题限时20秒，可以提前选择并确定。
2.9限时倒数计时为0时，系统自行根据操作内容判断对错。如果答题者没有操作，则被淘汰。
2.10 答题题目可以自行上传并且设置随机出题。
2.11 排行榜需要按照最后的擂主、单轮答题数、总答题数为数据。生成总冠军、mvp、得分王三个排行榜。排行榜之间可以相互切换查看。
三、游戏界面分为三个阶段，答题开始前，答题时和答题后3.1 答题前：首页、登陆界面，房间等待界面。
3.2 答题时：攻擂者答题界面和守擂者界面。
3.3 答题后：冠军显示界面、排行榜。
总结起来，这是一个实时多人互动游戏，而且是一个多状态切换的回合制游戏，还是一个不断换玩家的手动触发 定时触发游戏。
我们的老客户就这么果断地把这么一件重要活派给我们，还好，我们第六代的研发框架（代号“智元”）正在出笼。仔细分析，要完成这种互动游戏，还非得用它不可。
所谓的100多行代码实现，当然是要在使用我们自研框架的前提。
现在已经有那么多框架了，什么react，vue，angular……，前后端解决方案都有，我们为何闲着没事干，又重复发明一个轮子？
可能是我们觉得我们的轮子更圆一点，跑得更快一点。
现有实时多人互动游戏的开发方案存在问题：
1、组件不够灵活和标准，在不同项目中复用成本比较高。
2、整体架构过于复杂，普通工程师学习掌握成本高。
3、开发效率不够高，开发周期长，难以使用人工智能辅助。
4、业务逻辑调整困难，有可能需要同时升级客户端。
5、开发过程需要经常重启服务端6、前后端分别开发，需要有联调过程。
“智元”的优点和价值是：
1、自动创建游戏的基本框架，并预设一些基本功能，节约开发时间。
2、对程序员要求不高，只需要经过简单培训，学会几个函数的使用方法，就可以开发各种复杂的游戏。
3、统一规范的代码格式，创造性用表格化进行处理，更好地为人工智能开发提供高价值数据。
4、游戏业务逻辑集中在服务端处理，安全可控，并可套用常见状态机，所需代码极少。
5、可以在服务端实时变更游戏的规则，而不需要升级客户端。
6、客户端仅负责渲染和动画表现，无需处理任何业务逻辑，游戏性能容易优化。
“再好的框架，也不至于100多行吧？要不就是这种框架很不灵活，只能做非常有限的任务。”
“智元”的适应范围不光是多人实时互动类游戏类软件，目前一些应用类软件也可以了，而表现形式上也正在从H5，安卓原生，IOS原生，2D，扩展到3D，VR/AR等各种UI。
怎么才算一行代码？一个js文件有几千行代码通过压缩之后，只剩一行。好吧，给个形象一点的例子：
我们的代码长成这样，以上算三行。有没有意见？
实现以上需求，我们一共用了98行（我们正在调整一些还比较傻的做法，尽量往60行优化）。另外还有88个元件，部分元件上也附加有一些初始化的代码要人脑去考虑。总共不超过200行代码需要考虑。
时间有限，我们稍后再谈我们的第七代、第八代研发框架有哪些过人之处。我们也会陆续发布一些视频和介绍，让大家有更形象体验。
点击右上角：智子天姬，关注订阅查看更多人工智能知识
-END-
