阅读完本指南，你将能够： ✔ 知道 Demo 到底该做什么、不该做什么 ✔ 知道 Demo 应该多长、多少内容、深度到哪里 ✔ 理解如何让 Demo 强势拉升 Steam 愿望单 ✔ 可以按步骤从 0

这是基于过去十年数千个 Steam 独立游戏案例、发行商反馈、开发者后记、社群调查、SteamSpy 数据和上架作品回溯整理而成的最实用避坑清单。 内容 真实

这是一份 「个人独立游戏开发者从 0 到上线的完整实战流程指南」。 结构非常清晰、可落地，不废话，不空谈，适用于： ✔ 中国大陆个人开发者 ✔ 预算有限（0

这是一份 可直接用于现实项目 的“财务结构蓝图”，从 收入来源 → 各平台结算 → 多币种体系 → 税务结构 → 资金流动 → 成本结构 → 利润归集 全流程覆盖。 这部分建

这是一份 《香港公司开户 + Steam 收款操作指南（实战版）》，这是专门为 中国大陆独立开发者 准备的极简 + 可执行 + 可落地的完整流程。 内容覆盖从 注册香港公司

下面是一份 专为中国大陆独立开发者 编写的独立游戏海外发行的合规与税务风险清单（完整版）。 内容基于真实行业惯例、各国税务规则、平台（Steam/

引言 在 PC 游戏数字发行领域，Steam 长期占据主导地位，而 Epic 在近几年以较激进的策略介入竞争。本文将从市场规模、用户与活跃度、游戏库与上架策略、

一、单人团队的路线选择与立项尺度 单人团队最大的敌人是“范围失控”。因此路线必须以“可在 6–9 个月内可发布”为硬约束，功能遵循“可玩核心 + 最小

前言：一场不同规则的创作战争 在现代游戏产业中，“独立开发者”（Indie Developer）不再是一个边缘群体，而是一个不断壮大的创造力量。

对于独立游戏开发者而言，选择做移动端游戏还是 Steam 平台的 PC 游戏，是一个直接影响项目成败与团队发展的关键决策。两者在市场生态、玩家群体、收入结构、

一、引言（Introduction） 在 Steam 发行领域，游戏质量 ≠ 成功保证。 事实上，绝大多数销量不佳的独立游戏，并非因为不好玩，而是没人知道它存在

一、引言（Introduction） 在 Steam 平台上，首发只是起点，不是终点。 游戏真正的商业价值，往往体现在持续运营与长尾收益阶段。 许多成功的独立

一、总览（Overview） 本篇是上一篇《独立游戏开发者在stream平台上的机会》的延伸内容，旨在为开发者提供一份可落地的发行操作指南。 从

一、引言（Introduction） 过去十年间，Steam 已成为全球最大的 PC 游戏发行平台之一。对于独立开发者而言，它既是梦想的舞台，也是竞争

1. ARPU —— Average Revenue Per User（每用户平均收入） 定义 ARPU 表示：在一定周期内，每个活跃用户（Active User）平均产生的收入。 它反映了用户的付费深度

0. 制作人的核心定位与职责 0.1 制作人的角色定义 游戏项目的“创意总监 + 制作管理者 + 商业统筹者”； 职责三要素： 方向控制：产品愿景与风格； 资源整合：团

0. 专家级学习目标与核心能力 在专家阶段，目标不再是“构建一个能运行的游戏服务端”， 而是“设计一个能自我演化、自我修复、跨地域自治运行的游戏生态

0. 全局概览与学习目标 高级阶段的核心目标，是从“能跑一个游戏服”到“能稳定支撑百万在线”。 本阶段知识覆盖游戏服务端的高性能架构、分布式一致性、

0. 全局鸟瞰 计算机基础：网络（TCP/UDP、HTTP/WS/QUIC）、操作系统（进程/线程/协程、内存管理、锁/无锁）、数据结构与算法、编

第一章：引言 —— 从 10 万并发到“可信可扩展通信体系”的挑战 在当代大型网络游戏架构中，网关层与世界层之间的通信， 是整个分布式架构中最关键、最复杂

目录 引言：从“谁来决定胜负”谈起 客户端与服务器的职责边界 权威模型（Authoritative Model）与可信执行的演化 客户端主导的战斗计算

在前几章中，我们确立了“游戏世界是一个状态流（State Stream）”的理念。 但是，如果这个世界被拆散到成百上千个节点上运行，那么问题来了

目录 引言：从状态到流的哲学转变 数据流思想的起源与计算模型演化 游戏服务器中的“流”与“存”之争 状态即流（State-as-Stream）模型定

目录 引言：当“状态管理”成为智能体的任务 AI 与传统状态管理的根本区别 游戏状态的五维特征与可学习空间 智能状态压缩（AI-based State Compre

目录 云原生游戏服务的兴起与挑战 Serverless 架构的哲学：瞬时存在的计算 游戏状态的再定义：中心化 vs 分布式 云原生状态管理：K8s、Redis、CRD 与 Actor 模型

目录 Go 与游戏服务端架构的天然契合点 有状态的实现基础：Goroutine、Channel 与内存状态管理 Actor 模型在 Go 环境中的实现方式 状态存储层设计

目录 引言：从“Hello World”到百万并发的演进 第一章：什么是状态（State）？从哲学到计算机的定义 第二章：状态与游戏世界的本质联系 第

一、消息分发的总体架构 在典型的游戏服务器中，消息经过如下路径： flowchart LR A[Socket 收包] --> B[解包 / Header 解析] B --> C[CmdID 查表] C --> D[Dispatcher 分发] D --> E1[LoginHandler] D --> E2[PlayerHandler] D --> E3[BattleHandler] 流程

一、TCP 是“流”，不是“包” 很多初学者容易犯的错误是把 TCP 当作“包”协议使用。 实际上： TCP 是**面向字节流（stream-based）**的协

一、消息的层级结构概念 在网络通信中，一条消息一般由两部分组成： ┌──────────────────────────────────────

一、测试设计与评估目标 1.1 测试目的 游戏服务器的通信层常在高并发场景下运行， 每个包的序列化性能对整体吞吐率（QPS/TPS）有直接影响。 目标： 比

一、序列化的多样化背景 游戏服务器不仅在实时战斗中传输高频数据，还涉及： 登录认证（跨语言接口） Web 管理 / GM 工具（HTTP 接口） AI 模块（Pytho

一、序列化的意义：从内存结构到可传输字节 在网络通信中，我们需要把“内存对象”转换为“字节流”： graph LR A[结构体 / 对象] -->|序列化| B

一、引言：网络不稳定的必然性 无论游戏服务器多强大、协议多先进， 只要玩家使用移动网络或 Wi-Fi，就无法避免以下问题： 问题 表现 原因 延迟高 技能释

一、引言：为什么游戏必须要“心跳” 网络连接就像一条“虚拟电缆”，但它并不是永远稳定的。 在游戏运行中，你可能遇到： 玩家在地铁、Wi-Fi 与 4G 之

一、引言：游戏通信的本质是“实时性 + 一致性”的平衡 在游戏开发中，通信协议决定了“游戏世界如何同步”。 它不仅仅是“传输数据”，而是塑造了整个游

一、引言：Rust 的异步哲学 Rust 在系统层面提供了三件武器： 零成本抽象（Zero Cost Abstraction） 所有权系统（Ownership & Bor

一、引言：为什么 Skynet 能成为游戏后端事实标准 在中国游戏行业，Skynet 被广泛应用于： MMO / SLG / 卡牌游戏； 即时战斗 / 聊天 / 世界服； 自研分布式框架的

一、引言：从异步回调到同步语义 在 Java/Netty 世界，开发者必须处理： Selector； Pipeline； Future； Callback。 这让程序高度异步

一、引言：Netty 的定位与价值 Netty 是一个基于 Java NIO 的高性能网络通信框架，最早由 JBoss 社区在 2008 年推出，目前由 Netty 项目组维护（io.netty）。 它的目

一、引言：为什么需要线程池？ 在多线程或协程系统中，创建线程的成本极高： 操作系统线程的创建需要： 分配内核栈； 注册到调度器； 上下文切换； TLB flu

一、引言：从共享内存到共享通信 在传统多线程模型中，线程通过共享内存通信，需要锁来保护数据。 然而锁带来了复杂性、死锁、饥饿与调试困难。 C.A.R. Hoare 在 1978

一、引言：为什么我们需要 Actor 模型？ 在上一节我们学习了多线程与协程的差异。 线程和协程虽然解决了“并发执行”的问题，但它们都无法直接解决另一个根本

一、引言：从线程到协程的时代转折 在计算机的早期时代，程序通常是顺序执行的：一条指令执行完才开始下一条。 当网络 I/O、磁盘读写、数据库访问等耗

一、引言：从 I/O 到事件的必然演化 在上一节我们学习了阻塞与非阻塞 I/O 模型： 阻塞模型简单，但每个连接需要独立线程； 非阻塞模型高效，但需要手动轮询，代

一、引言：I/O 模型是服务端的灵魂 在游戏服务器、即时通信系统或高并发 API 网关中，开发者最常听到的词之一就是“I/O 模型（Input/Outpu

一、概述：架构的演化即“世界复杂度的增长” 在游戏技术体系中，架构不是一次性设计，而是一个随规模、并发量与功能复杂度演化的过程。 早期游戏服务器

一、通信的本质：游戏世界的“血液循环” 通信系统是游戏服务端架构中最底层但最关键的一层。 如果说： 世界服是“大脑”； 战斗服是“心脏”； 那么通信层

一、概述：游戏世界的“生老病死” 一个游戏服务器，不只是一个常驻进程，它更像一个世界的宿主。 它的生命周期可以分为三个阶段： 阶段 含义 关键操作 启动

一、概述：游戏世界的“服务解剖图” 在前几章中我们从「架构形态」的角度认识了 MMO、SLG、MOBA、FPS 的差异与统一。 而当我们进入具体工程

一、前言：架构的多样性与统一性 过去二十年，游戏服务端经历了从单服 → 分布式 → 微服务 → 云原生 → 世界一体化的五次演进。 每一次演进都围绕着同一个目标

一、实时游戏的工程定义 1.1 “实时性”意味着什么？ 在游戏网络架构领域，实时性（Real-Time） 不等于“零延迟”， 而是指系统具备在严格时间约束

一、SLG 的本质与技术特征 1.1 什么是 SLG SLG（Simulation Game / Strategy Game），即“策略模拟类游戏”， 是以 资源规划、领地扩张、部队调度、长

一、MMO 的定义与特征 1.1 什么是 MMO MMO（Massively Multiplayer Online Game） 指 “支持数千至数十万名玩家在同一虚拟世界中实时交互的在线游戏”。 与单

一、概述：从“单机”到“在线”的技术演进之路 在游戏发展的半个世纪中，游戏架构 的核心变化可用一句话概括： “从单机的孤立逻辑，到局域网的共享状态

一、前言：分层协作是现代游戏架构的根基 在网络游戏中，客户端与服务端共同构成了一个“分布式系统”。 两者之间通过协议进行通信，承担不同职责： 客户

一、引言：谁在决定游戏的“真相”？ 在多人游戏中，所有玩家都在体验同一个“虚拟世界”。 然而，这个世界到底以谁为准？ 如果每个客户端都自认为正确 →

一、引言：从单机到网络化的必然演进 在计算机游戏发展早期，所有游戏都是“单机游戏”。 玩家的输入、逻辑运算、渲染、存档，全都发生在同一台计算机上

1.2.1 游戏类型与实时性需求 本节目标： 从玩法特征出发，系统分析不同类型游戏的实时性与架构差异； 结合 Java 与 Go 两种后端工程实践视角，阐述服务器设计模式；

第 1 章 游戏服务器的本质 1.1 游戏服务器的定义与职责 本节目标： 让读者系统理解游戏服务器在整个游戏生态中的定位、职责与作用，为后续架构学习奠定基础。

《游戏服务端编程实践》——章节大纲文档 第一篇 基础与准备篇：从 0 到 1 认识游戏服务端 第 1 章 游戏服务器的本质 1.1 游戏服务器的定义与职责 1.1.1 为什么需要服

在 SLG（Simulation & Strategy Game，模拟策略类）游戏的开发中，如果目标是可复用的通用模块设计，那么就要抽象出不依赖具体玩法逻辑、可在

下面是针对《三国志战略版》风格 SLG 游戏中塔防战斗玩法的「客户端消息分发与状态同步模块」的详细设计。该模块负责： 接收服务端推送的战斗状态更新（如

下面是一个专为SLG 游戏中塔防玩法设计的战斗通信协议与功能设计方案，适用于使用 TCP + Protobuf / WebSocket 的通信模式，具备实时性、扩展性和跨平台兼容性。该设计

下面是一份针对“类似《三国志·战略版》的 SLG 游戏”，并融合了“模拟经营 + 塔防元素”的完整产品架构与功能模块设计。该设计适用于中重度策略手游（支

下面是一个针对类似于《三国志·战略版》这类 SLG（Simulation & Strategy）游戏的产品级架构及功能模块设计，涵盖玩家体验、业务

以下是基于真实头部 SLG 手游（如《三国志·战略版》）的前端架构与功能模块，结合 Unity/WebGL 偏向战略类游戏的特点整理而成，完整、可行且贴近实际项目落地。 一、

下面是基于公开资料和真实实践经验整理的完整、可靠的《三国志·战略版》类 SLG 游戏的后端架构与功能模块设计，适用于百万级 DAU、大地图、多人互交的

为复杂的 SLG（Simulation & Strategy）游戏服务器设计一个完整可信的后端分层架构，需要满足高并发、高一致性、长生命周期状态管

对于复杂的 SLG（Simulation / Strategy）游戏服务器，Java 不一定总是比 Golang 或 Python 更好，但确实在某些方面具备更强的优势。要判断

模块介绍 🎮 游戏服务器模块职责划分与语言选型建议表 模块名称 职责描述 推荐语言/框架 选型理由 🌀 网关服务（Gateway） 接收客户端请求，负责协议编

以下是一个详细的游戏服务端学习计划，涵盖从入门到进阶的学习过程和具体知识点，并附上真实有效的文章、视频和网址资源。 1. 入门阶段：基础知识与工具

以下是一个详细的游戏客户端学习计划，涵盖从入门到进阶的学习过程和具体知识点，并附上真实有效的文章、视频和网址资源。 1. 入门阶段：基础知识与工具

Unreal Engine（虚幻引擎）简介 Unreal Engine是由Epic Games开发的一款功能强大的游戏引擎，最初于1998年发布，用于开发其内部游戏。随

在 Defold 引擎中使用 Lua 语言编写游戏逻辑具有一系列优势和一些局限性。 优势： 轻量级和快速：Lua 是一种轻量级的语言，易于嵌入，适合快速开发和迭代，这与

Defold 游戏引擎主要使用 Lua 语言来编写游戏逻辑。Lua 是一种轻量级的脚本语言，与 Python 有许多相似之处，但它们是两种不同的语言。Defold 的设计初衷是利