如何在技术上为传统游戏开发者创造更好的环境？自上一轮周期中Axie和StepN横空出世以来，Gamefi和全链游戏始终是区块链行业的热点之一，这一全新的游戏模式在区块链技术之上，在玩家资产所有权、价值转移与游戏内经济体系、规则透明化及社区治理方面，带来了传统游戏平台从未实现的独特体验。这些愿景听起来虽然美好，但却面临着一个始终没有解决的问题：
链游的可玩性普遍不高，趣味性不足，更偏向于金融投机，在投机回报下降后，用户规模会迅速萎缩。
显然这与传统游戏的发展模式背道而驰。传统游戏的顺利发展，往往是靠着游戏机制的趣味性，能吸引到大量用户，同时游戏的开发者可以建立起良好的盈利路径，还可能因自身的影响力拓展出一系列的周边与IP。可以说，那些成功运营下来的传统游戏，其整个系统是正循环的，玩家可以体验到游戏的乐趣，往往也可以在游戏内和游戏外获得一定的经济利益。
相比之下，目前的链游更多是靠着单纯的回报率来吸引玩家。除了可玩性弱以外，Web3游戏还面临着使用门槛高、交互流程繁琐等老生常谈的问题。
这一切的根源是什么？不同的人有不同的看法。TabiChain团队认为，影响Web3游戏的一个重要因素，是优秀的传统游戏开发者因为技术和学习成本问题，难以进入Web3生态。对于那些不了解游戏或软件开发的人来说，从Web2到Web3只是换了一种叙事和环境而已，但实际情况远比想象中恶劣的多。
那么我们该如何通过技术实现，为传统的游戏开发者或相关厂商，缔造一种更友好的环境？下文中，我们将从多个方面，对Web3游戏面临的问题，及对应的解决方案进行全面解析，为大家阐述未来的Web3游戏业该如何在技术上更适配传统游戏从业者。
阻碍传统游戏开发者进入Web3生态的技术原因
在前文中，我们曾简单提到，技术不友好以及学习成本的高昂，是阻碍传统游戏从业者进入web3生态的核心因素，所谓的技术不友好和学习成本高昂，可以展开为以下几点：
1.web3应用与传统软件结构的不同
区块链和其上的应用（dApps）与传统软件架构有着本质不同，要求开发者具备全新的知识体系，如区块链的工作原理、共识协议、智能合约编程模型等。传统的游戏开发者需要花费大量时间来学习Solidity或其他智能合约语言，需要理解EVM的工作方式。
而且，传统的游戏逻辑通常在中心化的服务器上执行，可以灵活处理复杂的游戏状态和高频交互。在区块链上运行游戏逻辑则需要高度简化或重构，因为每个操作都要发布到分布式网络中执行，然后再上链，这受到区块链性能和成本的严重限制。
2.智能合约的设计限制
EVM虽然满足图灵完备，理论上可以表达任意逻辑，但其特性非常不利于游戏开发，例如：
缺乏定时器。以太坊链上的所有操作，必须由EOA账户手动触发。为了实现类似于定时器的效果，开发者需要额外部署一个服务，维护一个EOA账户以及事件列表，来手动触发定时任务。由于上链的延时问题，这些定时任务还不能保证按时完成。
没有回调等机制，不支持多线程和异步。由于Solidity是为以太坊智能合约开发而设计的，它的执行环境与传统的运行时环境有显著的不同。EVM的操作是事务性的，每次函数调用都需在一个事务中完全执行，而不存在传统意义上的异步概念。这意味着在Solidity中一次函数调用开始直到结束，都是原子性的，不能被其他事务中断。
没有引用外部数据的能力。虽然有类似Chainlink这种预言机，但不论是从集成角度还是数据调用角度看，其易用性与直接通过https请求来获取数据调用有天壤之别，并且这又让开发者增加了额外的集成负担和依赖。
扩展性和性能限制。游戏逻辑必须被简化或分解成多个简单的交易，以避免单一交易的gas费变得过高或超出最大限制，这限制了复杂交互和功能的实现。
3.数据存储与调用的限制
智能合约的存储空间昂贵且设计有限，不适合存储大量游戏数据。
可能需要用事件日志来间接跟踪游戏状态，而事件的抓取可能并不稳定。诸如何时刷新游戏状态等问题，常常需要玩家或者游戏运营方手动触发。
EVM采用的账户数据结构，导致其数据索引能力很差。当你查询某个账户的数据时，你只能了解其ETH或链原生Token的余额，但其拥有哪些ERC-20资产、每种资产的余额是多少，无法直接获知。对于NFT也是一样的道理。这些信息都封装在每种资产的专属合约中，而不是在用户自己的账户下存储。
我们能够从Etherscan等工具中看到某个地址具有何种token及其余额等信息，这些都是由区块链浏览器等周边工具索引而来，而后者要建立专属的庞大数据库，完整爬取所有的区块数据或监听链上事件，才能将链上的全部数据汇总归集。
Web3开发者通常要集成类似Etherscan，NFTscan，The Graph等第三方数据提供方，甚至要为其API KEY付费。此外，这些第三方服务本质都是链下的数据库，可能出现迟滞、出错、超过调用限制、服务不可用等故障。
我们来对比一下，大多数游戏自身的数据库形态与区块链中数据存储方式的差异，两者的不同是显而易见的。大多数游戏的数据结构完全由自己定制，有良好的表达和索引能力，不需要依赖任何第三方服务。
4.与现有游戏资产集成的困难
现有的游戏资产（比如道具和角色）通常不是在区块链上创建和管理的。将这些资产迁移到区块链上，通常要将通用但长尾的数据类型转换成标准的NFT或Token，这涉及到复杂的迁移和集成工作，会影响到现有的游戏经济系统。
5.升级、补丁与防灾
在以太坊上，智能合约一旦部署后，代码就是不可变的，这使得升级和修补程序比传统软件更为复杂。开发者经常使用代理合约或版本化模式来绕开这一限制，但这增加了整体结构的复杂度，代理合约在使用时需要格外小心，以免存储槽冲突导致数据损坏。另外，管理权限泄露风险也很严峻。
传统游戏的代码升级在技术构造上没这么复杂，唯一可能需要约束的是中心化的升级权限，这可以通过DAO等方式实现而非依赖于智能合约。
并且，传统游戏时常会进行数据库的快照或备份。这在平常可能不是很重要，但若遇到升级有重大 bug 时，可以迅速回滚数据，而这在区块链上基本是天方夜谭。即使通过重建合约的方式来对某些游戏的数据进行回滚，如何把旧合约的数据和状态迁移到新合约，仍然很复杂。
6.生态割裂与用户体验问题
不同的公链和VM，其智能合约语言、架构、数据结构等是迥异的。在Web2中，游戏开发者会选择Unity等跨平台的前端引擎，可以做到一套代码稍加适配运行在iPhone、Android、桌面端等不同环境；后端由于不运行在用户终端上，所以不存在跨平台问题。
而在Web3中这基本是奢望，迁移至一个不同的链或VM，意味着项目整体的重构，要付出巨大成本，更何况初入Web3的开发者完全没有经验去选择适合自己的生态，不论是从技术角度还是生态角度。
而在用户体验层面，区块链交互及其复杂，此前盛极一时的账户抽象概念，正是为了解决web3用户体验问题而涌现，在此不做过多赘述。
罗列完上述6大论点，我们总结一下：web2 to web3的开发者面临着巨大的适应门槛，如果他们是web2中的顶尖开发者，完全没必要抛弃web2中的事业不做，去web3这么一个陌生的环境里拓展一些不知道能不能成功的业务。
可以说，顶尖的游戏开发者大多没有进入Web3，某种程度上，这使得Web3游戏大多偏向金融投机，而不具备特别高的可玩性和乐趣。
用户侧也存在同样性质的障碍，Web3游戏一系列阻碍用户转化率的操作步骤，导致Web2巨大的用户群体没有意愿体验甚至完全不知道Web3游戏的存在。
有没有一种infra级别的项目能够解决上述问题呢？Tabi Chain可能是非常接近Web3游戏终极解决方案之一的项目，其核心概念是全能执行层（Omni Execution Layer）：开发者无需再关心各种VM或运行环境的区别，直接使用自己熟悉的、甚至是可以自定义的运行环境，直接开发或者移植的游戏。
除此以外，Tabi Chain还拥有模块化的共识、安全层等特性，一切都是模块化和可定制化的，以满足不同游戏和应用的需求。
全能执行层：按照开发者需求来选择执行环境
我们来回忆一下，区块链的本质是什么。有人可能会说是去中心化的不可篡改的账本。但如果更接近技术本质来说，应该说是：状态机在分布式网络中的可验证的永久状态同步。
也即，区块链实际在维护一个全网公认的状态机和其运转的状态：
每一次输入都是确定的，被记录在每个区块中；
状态转换函数是确定的，具体表现为区块链客户端中的VM或运行时；
状态的输出也是确定的，也被记录在每个区块中；
因此，一个链的共识体系中，并不一定只能存在一种执行层（如只有EVM），不论多寡，只要这条链能验证其上多个执行层的状态，让每个游戏都运行在自己的环境中，就可以解决我们上面说的种种问题。
在Tabi中，每个游戏或dApp可以构建自己独立的一个Service。所有Service将各自产生的区块提交至链的共识系统内；Supervisor Nodes中包含了所有Service中的运行时/VM，来校验service区块的状态。
在Tabi的全能执行层的核心可以看做一个具有多态能力的VM，因此叫做Polymorphism VM。
对于已有的区块链VM而言，Polymorphism VM需要将该VM囊括入自身的运行环境中，并提供相应的接口调用方法。囊括这个概念在这里有两种具体的实现：
共享世界状态：类似Ethermint，在Cosmos上提供了对EVM的支持。但EVM仅仅是一个表层，专注于用户交互、合约操作等，让所有的用户侧的操作看起来是在EVM上实现的。但这些操作最终的结果和数据，还是会存储在其他Cosmos模块中。所以这种EVM兼容性其本质是最底层数据的映射。
因此这种映射关系，也可以拓展到其他VM上，比如Ethermint可以再加一层SVM的模块，这层SVM和EVM其实对应的都是一份底层数据。
这就类似于在PC上使用VMWare来启动一台Windows虚拟机，VMWare不仅可以访问虚拟机内部的虚拟硬盘，也可以访问物理电脑的硬盘。如果此时再启动一台Mac的虚拟机，它也可以用同样的方式来挂载物理磁盘中的数据。这样其实就实现了多台虚拟机对同一个世界的资源与状态的共享。
Tabi Chain的Main Service的将采用这种世界状态共享的形式。因此只要有对相应VM的适配，基于该VM开发的dApp可以选择直接部署在Main Service上而非另起一个service。
独立世界状态：由于不同应用和游戏的需求迥异，有些游戏有自定义的运行时，将所有VM大一统地通过共享世界状态的方式囊括进Polymorphism VM中并不适合所有情形。因此独立的世界状态也是需要的，这种实现方式相对简单，对数据完全对立的Service而言也是最契合的。
但不论采用何种形式，都必须能被Supervisor Nodes进行验证，也即Polymorphism VM中包含了所有实现方式的VM或Runtime。
Web2游戏移植案例
Polymorphism VM具有高度的可定制性，特别是对于Web2开发者来说，他们可以使用自己熟悉的语言和框架，将任何业务逻辑移植到Polymorphism VM上。
假设Minecraft现在想要移植到Tabi，大致的流程为：
略微修改Minecraft服务端代码（Java，其他语言同理），将需要上链的数据移动到一个数据库（或一组）中，并将所有可能导致该DB发生变化的函数（也即状态转换函数）也挑选出来。
将该数据库和这些函数，打包为一个JAR包，可以理解为Java的一种可执行程序。最后再加上JRE也即Java的运行环境。这一整体加载入Polymorphism VM中，最终其所有数据都会上链。
将其他与上链无关的后端逻辑（如组队、聊天等）将运行在链下服务器中。
在Tabi Chain中启动一个Service，并通知Supervisor Nodes中的Polymorphism VM加载相同的JRE。
至此所有的流程就结束了。
对开发者而言这些改动是在原有的Java语言和框架下完成的。对于任何其他开发方式的游戏也是同样的道理。对用户而言游戏的交互也没有明显的改变。显然，这种移植Web2游戏的方式非常迅速和高效，有可能成为Web3游戏mass adoption的基础范式。