你眼中的游戏中台产品是什么样子？

序言 - 产品的价值

在谈论游戏中间平台之前，我想与您谈论产品思维，从而扩展中间平台的思维。

无论自然，人类社会或广阔的宇宙如何，一切都朝着整个混乱方向发展，这就是熵的过程。

随着信息化的迅速发展和在流行病的影响下的“后遗症”，我们越来越清楚地认为，根据既定规则，社会似乎很难运作。熵增加的现象变得越来越明显，当前的业务重点逐渐从操作产品转移到运营用户。

过去，许多行业甚至一些传统行业一直在营销运营产品。简而言之，这是关于如何推广产品并将其出售给几个消费者。在运营用户将该产品出售给该客户之后，他可以反复购买几次。同时，他还可以驱使几个客户使这些客户反复购买……等等。

期望值的公式=概率x结果/益处

因此，预期值的大小取决于概率和回报范围的大​​小。所谓的找到最大期望是找到概率和回报之间的最佳组合和平衡，并以最大的期望值指导我们的行动。很明显，对产品运营的期望比运营用户的期望要小得多。

那么，如果我们可以在现有产品的前提下更好地管理用户怎么办？之前提到的是，该产品是基于一组既定规则的产品。因此，在这个熟悉的工作流程下，我们可以通过积累经验，发展过程的标准化和访问流程来提高工作效率，以更好地管理用户？

本文的主要内容是通过中间平台的概念而不是大规模运营用户来改善操作产品的观点。他们可能会在以后的文章中谈论它，因此请继续关注。回到游戏的中间平台，也许它的存在是我们正在寻找最佳平衡的解决方案。

1。在游戏中间平台上的想法

我相信每个人都已经知道了互联网中间平台的起源和发展的故事，我将不再引用详细信息。但是，游戏行业的中间平台很少提及。我想借此机会与您讨论。当然，毕竟，这只是我自己的看法，而且肯定会有一面。请理解。

返回中间平台的核心内容：简而言之，它是系统组件，避免重复创建车轮，提高开发工作效率，并降低或降低或降低人工和时间成本。从这个角度看，该论点可能有些模糊。实际上，中间平台的设计通常无法偏离业务，因此在摘要定义下无法阐明中间平台的边界。

俗话说kaiyun官方网站登录入口，风险和机会共存。中间平台的热门概念的背后，还有一个盲目的后续趋势。许多不应该属于中间平台字段的东西莫名其妙地积累到中间平台类别中，导致中间平台失去了其原始核心价值。并非所有公司或部门都需要“中级”，而中级化实际上是从“集中化”和“平台化”演变而来的。

随着公司规模的扩大和业务复杂性的提高，问题不断暴露，并且各个部门或项目组之间的协作要求将变得越来越高。如果存在一定的集中趋势和多个业务线路是平行的，则工具，内容，协作和其他模块继续抽象中心内容，但是每个模块都独立于每个平台存在，并且需要连接和组合一个中央模块，因此在此时建立一个中间平台是必要的。

2。游戏中间平台的组成

在中期部门的建设没有被认为是理所当然的。除了其强大的“内部力量”基础外，它还需要多功能的“外部力量”。因为中间平台的所有要求源自项目团队，因此它用于构建组件和功能，以满足项目团队的需求，而不是消除想象力。

此外，中端项目通常不会直接创造像项目这样的利润价值，因此在项目建立的早期阶段，从内而外会有许多阻力。当然，内容的这一部分与每个企业的战略规划有关。在项目管理中，启动过程中流程组的部门需要集中于分析和考虑，而该内容更多地是关于计划和执行过程阶段。

游戏中间平台系统由技术中间平台 +业务中间平台 +数据中间平台等组成。其中，业务中间平台可以分为中间平台，内容中间平台和中间平台。当然，每个企业都有中间平台的不同范围或名称，但它永远不会与根源分开。

其中，技术中间平台可以分为：发动机平台，工程平台，技术艺术平台，AI平台等。

操作中间平台可以扩展到：内容平台，营销平台，用户平台，工具资源平台（GM方向）。

以中间平台为例。使用多租户模型，我们通过操作中间平台为不同的游戏项目提供组织服务。在多个租户中实施中端组件共享，以提高重用效率并减少发展时间和人力的目的。

3。如何构建游戏中间平台1。选择许可管理模型

常见的包括ACL访问控制列表，DAC自主访问控制（ACL扩展），MAC强制访问控制，基于RBAC的基于RBAC的访问控制。可以搜索每个的优点和局限性，在这里不会描述。我个人使用RBAC模型来操作中间平台设计：

定义：

当满足A和B时，允许操作。

描述：RBAC的想法来自现实世界的企业结构。例如，销售角色有权查看客户信息。当销售人员小王加入公司时，他可以赋予小王的销售角色，然后王王有权查看客户。此方法避免了每次新手加入作业时，都需要在ACL模型下一一配置资源表。同样，许可更改变得非常方便。只需修改角色，您就可以实现多个用户的权限修改。

局限性：RABC并不总是满足所有权限。例如，我们无法自定义游戏操作角色。例如，游戏操作字符有权创建和删除。如果我们想从操作人员小李操作中删除删除许可。然后，我们必须创建另一个角色来满足需求。如果这种情况非常频繁，那么角色的统一将丢失，并且系统将减少。

2。操作中间平台

对于游戏操作中间平台，它必须是一个多租户模型。不同的游戏项目组共享相同的系统或程序组件，并且仍然可以确保用户之间的数据隔离。

为了响应不同游戏业务方提出的游戏操作和管理需求，建立了具有高凝聚力和低耦合级别的一般游戏操作和管理系统，以为解决方案提供业务多功能性，易于系统维护和高功能可伸缩性。

同时，为了满足每个游戏项目团队的应用程序管理需求，设计和开发了一般的游戏操作系统。基于一般服务器端接口级的功能响应，它可以打开与其他服务的数据交互，并提供支持多租户，自助服务访问的系统和服务，并且可以自由扩展。

3。营销中间车站

随着玩家数量的增加，用户和游戏内容等数据源已大大扩展，保持玩家的生命周期的困难以及运营计划的缓慢，并且出现了营销管理平台。基于迫切需要数据驱动的业务增长和精致的运营，玩家需要扩大自己的生命周期：

营销平台定位为建立行为分析产品系统kaiyun.ccm，整合各种运营策略和工具，开放了增长和精制运营的封闭环节，并旨在减少产品分析和运营的时间和人工成本，提高整体效率，并丰富和扩大产品的增长和扩展产品的增长和内容运营能力。

4。中间平台的特殊事件

主题事件的中间平台被认为是非必需的体系结构。是否要建立它取决于对业务对这种需求的依赖程度，并且在游戏行业中更为普遍。

首先，我们必须判断是否可以在以前的消费者/活动游戏活动或经常出现的活动场景中抽象共同的组件。例如，基本的规则要素，例如绘制电网，转盘，周期性的特殊节日和其他材料，高度高度可重复使用。

它可以理解为简单改变皮肤的活动，可以通过业务属性灵活地配置和结合。对于每日广告图片，框图片开元棋官方正版下载，背景图片或横幅，它们可以作为材料积累。尽管这些内容可能具有自己的强大自定义属性，但仍可以考虑材料的积累。例如，如果同一圣诞节主题的事件背景紧密，可以在其他项目中使用某些关键元素吗？

（1）提高活动重用率和再利用效率

（2）减少（避免）重复逻辑和接口开发

（3）标准化一般逻辑，例如用户信息验证和授予，并减少测试开发量

（4）准备与外部系统联系

（5）专注于改善页面效果和用户体验

4。中端产品的挑战1。沟通与协作的挑战

实际上，我一开始就在商业部门，而我面临的业务需求相对清晰，直接和相对放松。尽管它也面临多方项目团队，但它没有中端的概念，也不需要考虑重用思维，业务需求也很顺利。在业务量的持续扩展之前，越来越多的问题暴露出来。

以对接需求为例，愿意与不同规模和成熟度的项目组合作的意愿也不平衡。大规模或高利润的团队具有更清晰的业务和流程环境。一方面，我们需要能够在较短的时间内支持快速响应并迭代日常活动的启动。另一方面，他们不会积极考虑实施的复杂性，也不想干扰由于我们的发展进步而导致的日程安排进度，并且正在进行更加困难的沟通。

但是，也有类似且不是非常成熟的项目团队，他们希望我们描述要求，并且对要求的描述也不是非常准确的描述，而且他们并不特别关心最终功能的性能。有时，我们只是在考虑对它们的要求。因此，实际上，不同部门之间的沟通和协调会分散大量精力，并反复确认相同的需求，并且整个结果确定期将通过无效延长。

说话的艺术仍然需要一直学习。

2。逻辑抽象功能的挑战

如果将沟通和协作视为中端产品的软功率的实施例，那么逻辑抽象能力就是测试硬能力的体现。

因为中间平台必须面对的一系列解决方案可以为多个企业和多个项目组服务，因此该解决方案的设计不仅需要强大的逻辑思维能力，而且还需要抽象的扩展能力。在满足所有需求的同时，它还可以敏锐地检测到不同需求之间的共同特征，从而输出多租户产品解决方案。

例如，项目团队需要操作平台来支持白名单的功能，并且需要满足特定人群的特殊逻辑的实施。

这似乎是一个非常简单的需求功能点，但是对于中端产品，有必要在满足业务需求的前提下探索所有可以重复使用的场景，并在满足业务需求的前提下抽象公共逻辑。很明显，在以后的操作中需要重复使用这种需求，例如扩展到黑名单，活动用户，大R和其他用户组。然后，我们无需每次都重新创建轮子，并开发相同或相似的逻辑。

在实际的业务情况下，将有越来越复杂的事情要解决，这个例子也扮演着扔砖和吸引玉的角色。

产品方法论文章中还提到，某些要求实际上是伪必需的，您可以继续深入研究。白名单函数的抽象分解实际上是要滤除用户组并为该用户组实现特定功能。

这样，可以以这种方式完成此要求：原始的一次性白名单函数开发实际上可以转换为用户标签系统的开发。在基于操作平台的原始用户系统中，添加用户标签功能不仅可以满足原始的白名单功能，还可以扩展一系列潜在的用户需求。

3。其他挑战

从整个产品级别来看，中端产品的全面功能仍然很高。

一方面，我们需要具有强大的业务拆卸功能，具有抽象功能的逻辑思维能力和整体协调能力，清楚地清楚业务中的关键路径和业务流程，并能够控制整体系统迭代功能，并控制整个业务实施中系统完整功能的节奏。

另一方面，它需要全面的沟通和协作能力，这可以不断地稀释平台构建的成本共享能量，同时在多个业务线之间徘徊。同时，有必要满足良好的商业方的需求，并与整个系统的相关利益相关者合作，以完成整个中间平台的功能实现。

5。后记

自然定律从疾病到秩序变化，而产品的诞生实际上是该陈述的表现之一。我还曾说过，产品是一组标准规则。中间平台更像是整个系统的常规主体。随着整个系统的扩展，我们将更感谢中间平台系统的作用。