BCG Labs 的愿景是实验在去中心化的场景下如何设计并制作游戏，无论是传统的游戏还是 web3 游戏。

在我们看来，当前优先要解决的不是玩家的资产问题，而是创作者的协同和利益分配问题。

单纯从协同的角度来讲，github 是一个不错的解决方案，它可以很好的管理代码，还能做一些基本的进度跟踪和任务分配，为全世界大部分的开源项目，也包括以太坊在内的区块链项目提供了协作的解决方案。

不过，github 的目的和初衷是为了开源协作，其结构并不能满足去中心化场景下的利益分配需求，参与者是否能获得奖励需要依靠外部协商以及项目方的商业信誉。

从利益分配角度出发，当前也有不少外包或任务分发平台，但是参与其中的创作者仅是作为接单人而存在，项目的成败与其没有一点关系，这大大的限制了创作者的主观能动性以及创作行为的多样性，只有机械化的，可直接量化结果的任务可被分发。

BCG Labs 希望从立项到开发到运营，都可以通过去中心化的方式实现。

若这一模式实现，其势必可以真正改变当前的协作形态，让分布在世界各地的创作者可以真正的深入参与到项目开发中。

这一模式在当前的意义还不算重大，分布式协作的沟通效率远远低于办公室集群办公的沟通效率，但若未来脑机接口能真正实现，人与人之间的信息交流将由文字语言提升至思维层级，其带来的沟通效率将高于现在的百倍千倍，然而思维的碰撞比语言和文字要直接得多，现有的组织结构不可能接受这样的直接，不论是传递消息之前的反复斟酌，还是权力的层层审核，都将严重阻碍思维的传输效率。

去中心化的分布式协作可更好的适应这一未来，协作的创作者之间无需过于顾虑人情世故，无需考虑超过2级以上的审核，创作者以完成项目为目的聚合，也在项目成功获取收益后各自奔向下一个自己心仪的项目。

当然，这一未来也少不了AI的发展成熟，在所有可被培训的能力都由AI替代后，产品的瓶颈仅在于创作者的想象力，届时，一部分创作者们进行头脑风暴，形成产品创意，一部分创作者专职项目管理，进行任务拆分与跟进，一部分创作者操作AI，输出结果。

在这个过程中，创意者的贡献问题，执行者的完成验收问题，都将有别于现有的模式。

当前并没有任何合适的工具能起到这样的作用，我们也不能寄希望于别人造出这样的工具之后，再开展相应的工作，而且每个项目都具有自己的独特性，在这个过程中，还具有巨大的探索空间。

BCG Labs 自身的运作模式也将有别于现有的组织，不仅在产品的开发和运营上要尝试去中心化的模式，在整个组织的运作上，包括资金的获取和支出，利润的分配，也想要尝试是否可用去中心化的模式实现。

这一过程无法一蹴而就，就目前而言，我们期望先实现单个项目的任务建立、拆解和发布，将其过程实时的记录在区块链上并展示在我们的网站前端，以供任何人参看和参与。

若这一步可完成，则至少确认了单个产品的开发过程可被感知，它不仅可让创作者能获知产品状态，并选择擅长的部分参与，也可让产品的目标用户获知产品的情况并提前给出建议和反馈，还能让产品的投资者了解自己的资金具体是如何被使用的。

单个项目完善后，即可开始尝试多项目的开发，并邀请更多的创作者参与。

这一过程也许需要花费数年，也许更短或更长，广大的 web3 创作者，不管最终是谁到达了目的地，当下，我们都在前进……

这是 BCG Labs 的基础建设项目，它用于满足团队的日常工作管理，任务的拆分、发布、跟踪、解决以及相关的酬劳结算，需要可视化和透明化，并确保已完成的结果可随时查询且不可篡改，因此需要前端和合约密切配合。

以智能合约的形式管理任务的发起和完成，项目发起者通过网站创建任务，创作者提交任务内容，经由发起者确认后可领取报酬。

一般一个任务具有以下属性：

去中心化的任务发布和验收有两个关键问题需要解决：

一是如何做到信任最小化，即如何保证发布者在获得创作者提交的内容后，不转交给自己或相关方的账户再提交一次，从而将奖励回收。

二是如何做到无许可进入，即如何保证任何人在任务发布后都可参与完成任务，最终由完成的最好的人获得奖励。

这一议题暂时尚无完美的解答方案，它需要从文档、美术、代码等多个层面进行整合，目前 github 似乎可以解决一部分代码层面的判断问题，美术产出的争议则大概率只能通过治理投票判断，文档产出则更为复杂，其设计的合理性和逻辑性对判断者的专业要求较高，也更容易通过更改内容规避相似性问题，因此需要根据实际的研发过程和创作者的反馈，逐渐的完善和修正。

项目发起人需要自己或寻找其他专业的进度管理人员，将产品的迭代版本拆分为大的功能项，并设定功能与可交付版本的依赖关系，以及任务和功能的从属关系。

一般来讲，进度管理人员需要确保某个功能拆分的所有任务完成后，该功能即算完成，某个版本拆分的所有功能完成后，该版本即算完成，进入可发布状态。

该部分功能主要用于团队成员或其他利益相关方能够实时清晰的获知当前项目的状态。

在版本>功能>任务拆分完成后，进度追踪系统将自动追踪其完成状态和百分比，若某项功能的任务全部完成后，该功能并未完成，那说明功能的评估和任务拆分人员发生了错误，该情况目前需要团队自行解决，尚未无法通过合约的形式处理。

当某个可执行的版本内容完成后，将进入发布流程。

版本发布板块主要是作为迭代记录而存在，展示该项目完成了哪些可交付的内容，任何人都可在已发布的版本记录里获取对应的可执行版本，根据需求使用或验证其完成程度。

项目需要在创建初期将准备投入的资金以合约账户的形式呈现给所有投资者和创作者。

每一个任务花费的资金都将从该合约账户中支出，创作者和投资人均可以评估某个任务占据整个项目支出的合理性，以决定是否要参与或提出异议。

同时，已创建任务的资金将进入质押合约，任务发布者无法单方面取回资金，以确保资金提供者将合约账户内的资金提走时，影响创作者已经投入精力的任务。

BCG Labs 的愿景是实验在去中心化的场景下如何设计并制作游戏，无论是传统的游戏还是 web3 游戏。

在我们看来，当前优先要解决的不是玩家的资产问题，而是创作者的协同和利益分配问题。

单纯从协同的角度来讲，github 是一个不错的解决方案，它可以很好的管理代码，还能做一些基本的进度跟踪和任务分配，为全世界大部分的开源项目，也包括以太坊在内的区块链项目提供了协作的解决方案。

不过，github 的目的和初衷是为了开源协作，其结构并不能满足去中心化场景下的利益分配需求，参与者是否能获得奖励需要依靠外部协商以及项目方的商业信誉。

从利益分配角度出发，当前也有不少外包或任务分发平台，但是参与其中的创作者仅是作为接单人而存在，项目的成败与其没有一点关系，这大大的限制了创作者的主观能动性以及创作行为的多样性，只有机械化的，可直接量化结果的任务可被分发。

BCG Labs 希望从立项到开发到运营，都可以通过去中心化的方式实现。

若这一模式实现，其势必可以真正改变当前的协作形态，让分布在世界各地的创作者可以真正的深入参与到项目开发中。

这一模式在当前的意义还不算重大，分布式协作的沟通效率远远低于办公室集群办公的沟通效率，但若未来脑机接口能真正实现，人与人之间的信息交流将由文字语言提升至思维层级，其带来的沟通效率将高于现在的百倍千倍，然而思维的碰撞比语言和文字要直接得多，现有的组织结构不可能接受这样的直接，不论是传递消息之前的反复斟酌，还是权力的层层审核，都将严重阻碍思维的传输效率。

去中心化的分布式协作可更好的适应这一未来，协作的创作者之间无需过于顾虑人情世故，无需考虑超过2级以上的审核，创作者以完成项目为目的聚合，也在项目成功获取收益后各自奔向下一个自己心仪的项目。

当然，这一未来也少不了AI的发展成熟，在所有可被培训的能力都由AI替代后，产品的瓶颈仅在于创作者的想象力，届时，一部分创作者们进行头脑风暴，形成产品创意，一部分创作者专职项目管理，进行任务拆分与跟进，一部分创作者操作AI，输出结果。

在这个过程中，创意者的贡献问题，执行者的完成验收问题，都将有别于现有的模式。

当前并没有任何合适的工具能起到这样的作用，我们也不能寄希望于别人造出这样的工具之后，再开展相应的工作，而且每个项目都具有自己的独特性，在这个过程中，还具有巨大的探索空间。

BCG Labs 自身的运作模式也将有别于现有的组织，不仅在产品的开发和运营上要尝试去中心化的模式，在整个组织的运作上，包括资金的获取和支出，利润的分配，也想要尝试是否可用去中心化的模式实现。

这一过程无法一蹴而就，就目前而言，我们期望先实现单个项目的任务建立、拆解和发布，将其过程实时的记录在区块链上并展示在我们的网站前端，以供任何人参看和参与。

若这一步可完成，则至少确认了单个产品的开发过程可被感知，它不仅可让创作者能获知产品状态，并选择擅长的部分参与，也可让产品的目标用户获知产品的情况并提前给出建议和反馈，还能让产品的投资者了解自己的资金具体是如何被使用的。

单个项目完善后，即可开始尝试多项目的开发，并邀请更多的创作者参与。

这一过程也许需要花费数年，也许更短或更长，广大的 web3 创作者，不管最终是谁到达了目的地，当下，我们都在前进……

这是 BCG Labs 的基础建设项目，它用于满足团队的日常工作管理，任务的拆分、发布、跟踪、解决以及相关的酬劳结算，需要可视化和透明化，并确保已完成的结果可随时查询且不可篡改，因此需要前端和合约密切配合。

以智能合约的形式管理任务的发起和完成，项目发起者通过网站创建任务，创作者提交任务内容，经由发起者确认后可领取报酬。

一般一个任务具有以下属性：

去中心化的任务发布和验收有两个关键问题需要解决：

一是如何做到信任最小化，即如何保证发布者在获得创作者提交的内容后，不转交给自己或相关方的账户再提交一次，从而将奖励回收。

二是如何做到无许可进入，即如何保证任何人在任务发布后都可参与完成任务，最终由完成的最好的人获得奖励。

这一议题暂时尚无完美的解答方案，它需要从文档、美术、代码等多个层面进行整合，目前 github 似乎可以解决一部分代码层面的判断问题，美术产出的争议则大概率只能通过治理投票判断，文档产出则更为复杂，其设计的合理性和逻辑性对判断者的专业要求较高，也更容易通过更改内容规避相似性问题，因此需要根据实际的研发过程和创作者的反馈，逐渐的完善和修正。

项目发起人需要自己或寻找其他专业的进度管理人员，将产品的迭代版本拆分为大的功能项，并设定功能与可交付版本的依赖关系，以及任务和功能的从属关系。

一般来讲，进度管理人员需要确保某个功能拆分的所有任务完成后，该功能即算完成，某个版本拆分的所有功能完成后，该版本即算完成，进入可发布状态。

该部分功能主要用于团队成员或其他利益相关方能够实时清晰的获知当前项目的状态。

在版本>功能>任务拆分完成后，进度追踪系统将自动追踪其完成状态和百分比，若某项功能的任务全部完成后，该功能并未完成，那说明功能的评估和任务拆分人员发生了错误，该情况目前需要团队自行解决，尚未无法通过合约的形式处理。

当某个可执行的版本内容完成后，将进入发布流程。

版本发布板块主要是作为迭代记录而存在，展示该项目完成了哪些可交付的内容，任何人都可在已发布的版本记录里获取对应的可执行版本，根据需求使用或验证其完成程度。

项目需要在创建初期将准备投入的资金以合约账户的形式呈现给所有投资者和创作者。

每一个任务花费的资金都将从该合约账户中支出，创作者和投资人均可以评估某个任务占据整个项目支出的合理性，以决定是否要参与或提出异议。

同时，已创建任务的资金将进入质押合约，任务发布者无法单方面取回资金，以确保资金提供者将合约账户内的资金提走时，影响创作者已经投入精力的任务。