奇亿音乐全称【奇亿（北京）音乐有限公司】公司于2011年5月成立，前身为Channel Music Studio，是由一群屡获殊荣的声音设计师和作曲家组成，从事游戏音乐制作服务十年以上。公司提供：游戏音乐制作、游戏音效、游戏配音等资源制作，能满足各类型游戏对声音的要求，原创量身定制。现与国内外数百家游戏厂商达成长期合作，作品遍布全国各地及海外市场。


主营业务—配音

奇亿音乐录音棚及控制室房间均选取专用吸音，声学材料，精心设计棚内装饰，具备良好的录音声学条件基础。配音可远程或者现场监棚,实时互动，提高配音质量。

奇亿音乐可录制配音种类齐全，除了游戏中常见的英语，还可以录制阿语、日语、韩语、法语、西班牙语、德语、意大利语…….等几十种语言，还可录制各地方言。

声优可模仿国内知名演员声音，每位声优老师可以配音角色7-8种每个项目都配有语音导演监制！

主营业务—配乐

奇亿音乐拥有众多经验丰富的音乐制作人，至少3年以上原创声音设计经验，作品风格多样，有较强的游戏曲风写作能力，可为任何高端产品谱曲。

并且拥有有业内乐团，提供乐团演奏实录，满足任何产品对音乐不同标准的要求。


主营业务—音效
根据游戏作品需求自主完成拟音，真实还原声音现场
拥有独立正版音效库，积累不同类型的独立素材，音效创作没压力。
音效师工作经验平均3年以上，全部成手拒绝小白


代表作品：

《State OF Survival》、《崩坏3》、《逐光之旅》、《守望黎明》、《海航王：热血航线》、《斩妖行》、《Call Of Magic》、《Doomsday: Last Survivors》、《巨龙国度》、《苏丹的游戏》、《七号堡垒》、《俄罗斯方块环游记》、《太空杀》、《萌趣医院》、《剑与轮回》、《桃花源记》、《云上城之歌》、《魔神之战》、……等等。

合作客户：
Fun Plus、快手、IGG、B站、字节跳动、网易游戏、迪士尼、搜狐畅游、完美世界、米哈游、英雄互娱、咪咕、IM30、网龙科技、掌趣游戏、昆仑在线、梦加网络、吉比特、神奇时代等等。

作品试听：
官方网址：https://www.qiyiaudio.com/
音乐作品试听：https://www.qiyiaudio.com/music.html
音效作品试听：https://www.qiyiaudio.com/sfx.html
配音作品试听：https://www.qiyiaudio.com/voice.html

Wind是一款面向云的高性能、高效率以及高扩展性的大型分布式游戏服务器引擎。Wind利用Python语言的简洁语法以及丰富的生态库来提高游戏业务的开发效率，针对一些对性能有要求的游戏业务功能(如实时战斗功能)，Wind利用Golang的高并发特性来保证服务的高性能，同时Wind接入云的组件来保证游戏服务的动态扩展性，提高服务资源的利用率。

https://github.com/ferris1/wind

Wind是游戏服务器界首次结合go与python优点的服务器，如果Wind能解决你的问题的话，希望能帮Wind点个Star，如果不能解决大家的问题的话，也欢迎大家提Issue和Request，我会持续开发和完善Wind。

本文是Wind服务器引擎设计与实现系列的第一篇

1：Wind单服务引擎功能的设计与实现

2：Wind分布式集群功能的设计与实现(待更新)

3：Wind服务云部署功能的设计与实现(待更新)

Wind单机引擎功能的设计与实现

本篇文章主要介绍Wind的出现背景，Wind要解决什么问题，以及Wind的设计和服务器引擎实现方案。从游戏业务需求出发，介绍Wind拥有的特性以及引擎各个功能如何实现这些特性。

Wind出现背景

得益于云计算的低成本、按需灵活配置和高资源利用率的特性，大量的互联网应用已经在云上部署。但游戏服务上云的进度却很缓慢，这其中的原因跟游戏产品特性有关系。相对于互联网产品，游戏产品对延时更敏感，尤其是一些强竞技性游戏，如果将游戏服务部署上云的话，会有一些额外运算与路由导致延时增加，这也导致游戏服务上云进程比较缓慢。

虽然一些强竞技性游戏上云后可能影响游戏体验，但是对于一些休闲类、放置类、弱竞技类游戏来说，这些游戏对时延并不敏感，还是非常适合上云的。而且随着云游戏的发展和游戏产品的国际化，游戏上云是一个必然趋势。游戏上云可以很好运用云上资源，更灵活的配置服务资源以及更高效的管理服务，降低游戏服务的成本。

早前开源服务器更多关注的是单服务器内部的设计，如云风的Skynet，虽然单服务器性能很高，但没有提供一个很好的服务集群化方案，集群的配置、集群的监控管理以及集群间的通信交互都很麻烦，集群服务的动态扩展性也不强，导致搭建服务集群困难以及整体服务资源利用率低下。

因此Wind致力于解决上述问题，简化游戏服务集群方案，提高服务资源利用率，同时也保证游戏服务的开发效率以及运行性能。Wind是一款面向云的高性能、高效率以及高扩展性的大型分布式游戏服务器引擎。Wind利用Python语言的简洁语法以及丰富的生态库来提高游戏业务的开发效率，针对一些对性能有要求的游戏业务功能(如实时战斗功能)，Wind利用Golang的高并发特性来保证服务的高性能，同时Wind接入云的组件来保证游戏服务动态扩展性，提高服务资源的利用率。

游戏界有Unity和Unreal这样完善并且开箱即用的客户端引擎，这样的引擎大大缩短了游戏的开发周期，基本上一天就能做一个能跑的游戏。但是却并不存在一款大家熟知分布式服务器引擎，这样的服务器引擎可以快速上手并且能满足游戏各个阶段的开发需求。Wind致力于做一款易上手且完善的分布式服务器引擎，帮助独立游戏开发者或者中小企业快速搭建服务器框架并且快速开发游戏业务，降低游戏服务器开发难度与成本。

Wind特性

游戏产品生命周期通常会经历三个阶段，第一个阶段是开发阶段，第二阶段是上线阶段，第三个阶段是运营阶段，不同阶段面对场景与需求不一样，对服务器特性要求也不一样。产品前期更倾向于开发的高效率，后期更倾向于产品的质量与稳定，Wind针对三个阶段的需求有不同的设计。

开发阶段

开发阶段处在游戏产品快速试错与完善阶段，通常会有大量需求增加和变更，此时为了应对需求快速变更的情况，主要要求服务器具有便利性，便利性又可分为开发便利性与部署便利性。

• 开发便利性

开发便利性是指给定一个功能需求，服务器框架能否快速实现逻辑需求，能否降低项目组或者程序员的开发时间和开发难度。一个游戏服务器功能的开发便利性大体可以由两部分来保证，一部分是底层引擎功能的抽象复用，如网络通信、数据存储、并发模型、远程函数调用等，抽象是消除复杂的最好工具之一，抽象提供简洁明了的接口，降低程序员上手难度。开发便利性另一部分保证是游戏逻辑语言的选择，通常一个服务器大部分代码都是产品逻辑代码，如果选择一些非常底层的语言来写逻辑代码的话，那会非常痛苦，比如用汇编来编写UI交互逻辑，写出来的代码又臭又长，因此逻辑程序语言会选择一些高级语言来实现，Wind使用Python来编写游戏业务代码，主要利用Python简洁的语法以及丰富的库。Python对程序新手也更友好，可以更快的上手服务器开发。

• 部署便利性

游戏服务部署主要包括服务参数配置、服务环境安装以及针对不同类型服务部署在不同物理区域。一般游戏会有三套运行环境，一个是开发环境、一个是测试环境，一个是运营环境。比较传统的部署方式是直接在服务器操作系统中部署多个服务，这种部署方式有个缺点是如果服务环境升级的话，那各个环境也要手动更新，操作重复且容易出错。考虑到环境的问题，有些运营的比较久的游戏根本不敢轻易升级。所以现代部署基本上是容器部署，比如Docker容器，只需要写一个Dockerfile脚本便可以在各个环境使用最新配置运行，降低了不同职能的环境配置成本。

上线阶段

游戏产品上线阶段是最重要的时刻，游戏上线意味着产品投放外部玩家，开始接受外部玩家的考验。刚上线时是统一时间初次开放，大量玩家同时登陆游戏，这要求服务器需要由高并发能力，同时也要求服务器具有强大的可靠性和扩展性，保证大量玩家登录时能正常玩游戏和当人数超出预期时可自动伸缩服务来承载玩家游戏。

• 可靠性

服务的可靠性体现在预期负载和数据量下，服务器能否保持良好的性能运行。Wind的单服务性能主要由Golang语言来确保，一些调用频繁的功能以及对性能有要求的游戏功能(如网络通信功能、游戏战斗功能)由Golang这种静态语言编写，提升服务运行效率。同时Wind在Golang层采用多线程并发模型，为每一个客户端开一个线程处理网络包，提高单服务的并发性。Wind的多服务可靠性由专用的游戏负载均衡算法保证，负载均衡包含多种算法(比如最小分配、最大分配)，可根据游戏业务进行切换。同时Wind使用Python动态语言来编写逻辑，支持函数级别的热更且可以在不停服的情况下热更游戏资源。

• 扩展性

扩展可以分为功能扩展与资源扩展。游戏的功能扩展属于软件层面上的扩展，Wind使用插件模式来保证游戏功能高扩展性，每个功能以插件的形式加入引擎，如果你不想用原先的功能，你可以写一个新的插件替换掉原来的插件，插件模式可以很好扩展游戏组件。

资源扩展属于硬件扩展，硬件扩展又可分为纵向扩展和横向扩展，纵向扩展是将服务器换成性能更强大的服务器，这种方式扩展有限。现代分布式服务器下更常用的是横向扩展，也就是添加更多的机器。Wind使用服务发现和负载均衡来保证硬件的扩展性，每当新增服务时，原有的服务集群可以很快发现服务并调度服务，服务的横向扩展能力主要由服务发现的能力来决定。游戏服务上云后又可以让服务扩展性又进一步，服务上云后可利用云上公共资源，动态伸缩服务，提高服务的利用率，降低冗余，从而降低资源成本。

运营阶段

运营阶段处于游戏的稳定阶段，玩家数量会保持在一定数量上，服务器会长期的运行，此时稳定性是服务器最重要的一个特性。又因为运营阶段是长期的一个维护阶段，因此可维护性也是一个非常重要的特性。

• 可维护性

软件的大部分开销并不在最初的开发阶段，而是在持续的维护阶段，维护包括漏洞修复、保持系统正常运行、调查失效、适配新的平台、为新的场景进行修改、添加新的功能等等。不幸的是，大部分程序员都不喜欢维护所谓的遗留系统，可能因为涉及修复其他人的错误、和过时的平台打交道是份额外工作。服务的维护主要是服务监控，良好服务监控可以在一定程度上预防服务问题的大规模扩散。

Wind引擎实现

大型分布式服务器主要由早前单服务引擎发展而来，早前服务器服务玩家数量较少，基本上单进程服务器便能服务玩家。但由于互联网技术的发展，玩家越来越多，单进程服务器服务不了更多的玩家，因此发展分布式服务器来服务更多的玩家。得益于云的发展，游戏服务上云提高了资源利用率，降低了服务维护成本。Wind分布式引擎主要由这三个部分组成，第一部分是单服务器引擎，第二部分是分布式集群，第三部分是服务云部署。

• 单服务引擎：

单服务引擎包含一个服务器能运转的所有功能，游戏客户端发送请求给单服务引擎，单服务引擎处理请求后并回包给客户端。单服务器引擎主要包括程序语言、网络通信、并发模型、远程函数调用这些主要功能。

• 分布式集群：

分布式集群由每个运行的单服务引擎组成，分布式集群主要是为了解决单服务器引擎只能服务少量玩家的问题，通过横向扩展服务器来解决单服务器压力过大的问题，分布式集群功能主要包含服务发现、负载均衡、消息队列和数据存储等功能。

• 服务云部署：

对于一些只有几十个人的游戏，你可能就只需要起一个服务就行了，但是对于上百万玩家的游戏，这时就需要起上千或者上万个服，而且针对不同地区有不同的部署方案，面对这么庞大的部署，如果纯手动管理，那会非常耗时耗力，这时就需要一些云部署工具来支持。云部署主要包含容器部署、K8S编排、服务治理与监控。

单服务器引擎

单服务引擎包含一个服务器运行的所有功能，能单独运行并服务一部分玩家。单服务引擎运行后，客户端通过网络通信将请求发送到服务器中，服务器通过并发模型将请求交给逻辑模块处理，逻辑模块通过序列化解码参数数据并将请求数据交给服务注册的RPC函数处理。

程序语言

目前游戏服务器开发语言使用比较广泛的组合是C/C++和Lua。C/C++属于静态语言，拥有很高的运行性能，但因为C/C++语法更倾向于计算机的理解方式，对程序员编写业务逻辑并不够友好，降低了产品的开发效率，而且C/C++热更方法比较有限，线上出问题时不能快速且方便的修复，可能要时不时的停服关机修复，比较影响游戏体验，因此引入语法更简洁、更方便而且支持打补丁的高级动态解释语言Lua。引入Lua后，C/C++的分工有了变化，一些要求高性能的服务器模块用C/C++编写，比如网络库、数学计算库以及局内实时战斗逻辑等，Lua负责一些对性能要求不高的模块，但业务逻辑量比较大的模块，这样的模块其实占游戏业务的很大一部分，比如游戏的一些外围系统：等级系统，背包系统，聊天系统等等。相比于Lua，其实个人更喜欢Python，Python比Lua拥有更简洁的语法、更高的容错以及更完善的函数库，在开发产品业务时，拥有更高的开发效率，所以Wind的游戏业务逻辑语言使用Python开发。

使用C/C++编写一些模块，可以很好解决服务运行效率问题，但C/C++没有自动内存管理，写逻辑时很容易发生内存泄漏，而且C/C++语法复杂，程序员上手难度较高，开发成本大，因此引入Golang语言。Golang以高并发著称，拥有比C++更简明的语法特性，可提升开发效率，同时Golang提供自动内存管理机制，极大的简化了程序员开发的难度。因此Wind使用Golang来开发一些对效率有要求的模块，目前Wind的网络库是Golang写的。一些对性能要求高的游戏业务你也可以使用Golang来开发，比如战斗功能。

Python与Golang的交互

Wind的网络库由Golang编写，目前支持TCP，之后会支持KCP、Udp和Quic这些协议。每个客户端连接过来后，Golang会开一个线程去处理网络数据，有数据发过来后，Golang会将数据交给Python逻辑端处理，这里有个问题，就是Python线程和Golang线程是怎么进行交互的？Wind服务器引擎的主线程是在Python端，在起服务器时加载Golang编写的网络动态库(so文件或者DLL文件)并且开启网络线程处理客户端数据，目前Python与Golang的数据交互使用Socket通信交互，Python端启用一个TCP端口，Golang连接这个端口并且将数据传送给Python端。当然你也可以换Python与Golang的交互方式，比如换成ZMQ的zmq_inproc通信，使用zmq_inproc通信时，线程间共享一个ZMQ Context，可以通过共享内存来传递数据，不需要使用I/O线程，可以加快Python和Golang的交互。

并发模型

游戏客户端所做的工作基本上是将数据按一定逻辑显示在屏幕上，单个客户端并不需要与太多的服务器进行交互，多的也就两三个左右，所以客户端基本上对并发没有太多的要求。但是服务器就不一样了，同一个服务器要服务的客户端可能是上千个，甚至可能是上万个，这时候就需要并发模型来合理分配服务器的计算资源并正确的为客户端服务。

为了最大化利用物理机的多核资源，一般会有两种并发模型，一种是单进程多线程模型，这种模型通常是单个进程中存在多个游戏服务，每个服务分配一个核进行计算。游戏界应用这种并发模型比较成熟的是云风的Skynet，Skynet启用多个工作线程来处理服务的事件，各个线程间基于消息传递来通信。这种单进程多服务的缺点是，服务之间的隔离比较弱，服务之间共用了进程的数据，单个服务发生问题时可能影响其他服务，这样的设计也并不适合云部署，云部署所满足的一个基本要求就是服务间相互独立，每个服务是云调度的基本单位，每个服务可自由的被调度，因此更适合云部署的是多进程单线程模型，每个进程是一个服务，同一台机器可以起多个进程来利用多核优势，同时单线程中使用异步来处理数据I/O，提高服务器的并发。

那么Wind使用的是哪个模型了？ Wind使用是的混合模型，Wind是单进程单服务，网络库利用Golang的高并发特性，每个客户端连接启用一个线程来读取数据，同时为了减低业务逻辑编写难度，避免多线程锁问题，Python使用单线程异步协程来编写业务逻辑。网络层的多线程消息数据会通过一个队列来发给Python协程(asyncio)。

Python协程

Python协程本质上是异步，只不过这个协程是语言层面上的支持，编写游戏业务时更清晰、更简单。Python启动线程时，会启动一个事件循环，这个循环会一直检测是否有事件可以处理，如果某个任务要进行I/O(磁盘I/O或者网络I/O)，那么这个任务会被挂起，直到对应数据到来时，这个任务又会被事件循环处理。

import asyncio

async def main():
    print('Hello ...')
    await asyncio.sleep(1)
    print('... World!')

loop = asyncio.get_event_loop()
loop.create_task(main())
loop.run_forever()

使用异步协程编写游戏业务逻辑时，同一个时刻只能有一个客户端请求被处理，降低了开发难度，与协程搭配使用的是各个模块的单例化。

网络通信

实现游戏服务器时，主要会接触到的是传输层以上的一些网络协议，传输层协议包括UDP协议和TCP协议。UDP是一种无连接的协议，没有可靠性保证、顺序保证以及流量控制，但正是因为控制项比较少，UDP在数据传输过程中延迟小，速率高。游戏中一些对可靠性要求不高，但要求高速率的业务可以使用UDP传输，比如游戏语音服务。

TCP是面向连接的、可靠的、基于字节流的传输层通信协议，TCP通过序号确认机制、超时重传机制、重复累计确认机制和检验和机制来实现可靠性传输，同时提供流量控制和拥塞控制来控制源端的发送速率，以确保对端能正确接收。相对于UDP啥都没做来说，TCP什么事都做了，导致TCP传输速率低，延迟大。游戏是实时性应用，游戏的一些外围功能(背包功能、个人信息)时延要求不高，TCP够用了，但是对于游戏战斗这类高实时性功能，TCP的延迟太大了，会导致游戏战斗时体验会非常差。

为了解决TCP传输延时大的问题，游戏界通常会在UDP之上实现一个延时更低的可靠性传输协议，比如KCP，Enet。KCP能以比TCP浪费10%-20%的带宽的代价、换取平均延迟降低30%-40%，且最大延迟降低三倍的传输效果。ENet是专门为多人第一人称射击游戏Cube开发的可靠性传输协议，Enet提供连接管理，Enet最大的特点是提供多通道机制，每个通道包传送独立，单个通道会确保前一个序号消息到达才会发送下一个序号消息，以保证可靠性。

通常游戏会集成好几个传输协议到网络层，以便在不同需求场景下切换，比如集成UDP、KCP和TCP到网络传输层。Wind的网络层也会集成多个网络协议，以便在不同游戏场景中进行切换。

远程函数调用(RPC)

在单机游戏中，如果你要实现某个游戏效果，你可以通过函数名字直接调用对应函数来实现效果，但在网络游戏中，有些游戏效果需要向远端的服务器请求计算或者数据(比如匹配，背包)来实现，这时就会需要远程函数调用。远程函数调用通常发生在同一个共享网络下的不同地址空间中，比如不同物理机。远程函数调用通常采用Request-Response通信模式，每个远程函数名字以Request/Response(也可以用其他结尾，比如Packet)结尾，以此来区分本地函数。

封装好远程函数调用库后，写代码时就像写本地函数调用一样，程序员并不需要关心与远端的交互细节。但与本地函数调用不同的是，远程函数调用需要经过网络传输，网络传输增加了调用的时延与不确定性，为了防止主线程逻辑卡死，远程函数调用一般设计成异步调用，Request包发出后，不会等待包的返回，而是Response包返回后在处理之前的逻辑。

实现远程函数调用需要两个功能支持，一个是序列化功能，一个是协议工厂功能。

序列化

序列化是一个将数据结构和对象信息转化成可以存储和传输形式的过程。我们在写代码时通常以对象的形式读取数据，因为对象更符合人类思维习惯，我们能更快编写程序代码。但是对象信息数据通常是不连续的内存，不能直接进行存储或者传输，所以序列化需要将对象数据转化成二进制或者连续的字符串。序列化技术有很多种，比较常见的是Json、Xml、Protobuf等。Json是直接将对象转化成字符串，拥有很强的可读性，但缺点也很明显，那就是序列化后的数据太大了，导致需要的网络带宽也会加大，而且Json不安全，没有错误处理机制，你可以将同一个字段值转化成其他类型的数据。现在比较大型的游戏通常采用的序列化是Protobuf，Protobuf是协议定义型的，在使用时你需要定义你的数据类型，而且因为Protobuf在序列化时是用ID作为标识符，而不是字段名来标识，所以序列化后的Protobuf数据很小。对于游戏来说，Protobuf支持函数引用定义，解决了函数重复定义的问题。使用Protobuf后也可以用协议定义文件来生成MD5，以次来标识不同游戏版本的网络协议接口，以防老版本的客户端连接新版本的服务器，造成数据错误。

协议工厂

Json序列化时可以将函数名序列化进去，数据包到达服务器后，服务器根据函数名调用注册的RPC函数，但Protobuf序列化时并不会将函数名的信息带进去，Protobuf只会序列化协议参数数据，所以要使用Protobuf进行服务器序列化时，还需要一个新字段来标识这些数据是来自哪个协议的数据。通常是用一个ID来表示协议函数，那么哪个协议ID代表哪个函数了？这时候就会需要协议工厂功能。定义好协议文件后，将协议文件转化成代码文件时，通常会给每个协议一个ID，然后生成一个协议工厂代码文件，这个工厂代码就是根据ID来调用对应函数。

服务继承

Wind整个项目的核心代码是Engine目录下的SrvEngine.py 其他所有代码都是以组件的形式附加到这个文件下。Engine拥有一款引擎的所有功能，但并不作具体的逻辑服务使用，具体的逻辑服务需要继承Engine，然后添加各个逻辑服务的一些特定功能，具体服务在service 目录下，目前有Gateway服务和Game服务。各个服的具体设计可以参考这边文章

       游戏做到了商店这一步，我突然有点迷惑，按理来说我的角色是整个殖民地的开拓者，管理者，所有者，所有在殖民地建造的内容应该为我所有，所以压根就不应该出现我去商店购买物品还要付钱的情况，除非我是租赁给别人店面。可是这样一来商店就变成了了外贸中心，只能赚游客的钱，而我游戏里也没有关于这一点的设计。

     所以还是得走资本主义的道路，我可以建造商店，可以招募商人入住，然后呢，可以购买商店里面的物品，殖民地的物品也可以贩卖给商店，这样商品有变现的途径，但是呢，为了做一些限制，我给这个商店加入现金限制，这样不至于一个商店就可以买断殖民地全部商品，钱多的花不完。这样的好处是可以让玩家建造更多商店或者找更多变现途径。商店里的商品还可以随时间进行刷新和随机。

       游戏做到了商店这一步，我突然有点迷惑，按理来说我的角色是整个殖民地的开拓者，管理者，所有者，所有在殖民地建造的内容应该为我所有，所以压根就不应该出现我去商店购买物品还要付钱的情况，除非我是租赁给别人店面。可是这样一来商店就变成了了外贸中心，只能赚游客的钱，而我游戏里也没有关于这一点的设计。

     所以还是得走资本主义的道路，我可以建造商店，可以招募商人入住，然后呢，可以购买商店里面的物品，殖民地的物品也可以贩卖给商店，这样商品有变现的途径，但是呢，为了做一些限制，我给这个商店加入现金限制，这样不至于一个商店就可以买断殖民地全部商品，钱多的花不完。这样的好处是可以让玩家建造更多商店或者找更多变现途径。商店里的商品还可以随时间进行刷新和随机。

目前有业余策划一名 职业数值一名 策划案进度60%左右 

线上合作 欢迎有兴趣的程序和美术朋友的加入 

hello，我们是苏州的一个小组，目前在开发一个西幻背景的挂机类游戏，诚寻UI设计和原画，需要游戏里的物品图标、怪物原画、技能图标以及整个游戏的UI设计等。

有偿，价格好谈，坐标苏州可线下交流的优先，有意加QQ：76271950

目前工作室这边就我一个人兼职策划+程序，游戏设计已初步完成，程序框架搭建完毕，本人专职游戏行业资深开发人员。真切希望并欢迎靠谱想追求自己梦想一起做独立游戏的美术。项目虽然我主导设计，但是毕竟是属于大家一起的，因此所有人都可以参与讨论并提出自己的想法和建议，可以远程办公也可以北京驻场。当然也非常欢迎各路朋友加我联系方式全当交个朋友（QQ：930859714）

哈喽，我们正在寻找优秀的游戏文案创作者进行外包合作，有兴趣的作者大大欢迎来liao~

引言

唤境引擎，是2D游戏制作工具，纯中文，免费用。支持在Windows（64位）和Mac上运行。

版权归游戏开发者，支持输出多平台：Windows、Android、IOS、H5、Mac、小程序等。

官网：https://www.evkworld.cn/

为了扶持独立开发游戏的制作者们，唤境官方开办了激励计划活动，对优秀的游戏作品提供高达3w的奖金。
目前活动已经成功开展了五期，第六期激励计划于2021年7月30日启动！制作游戏demo就能参与，不限题材，期待你的投稿！

往期获奖作品

《末代侠客》、《只兔：不灭的勇者》、《文字饥荒》……近百款游戏都是咱们激励计划的优秀开发者！

第五期：http://ld.act.evkworld.com/jljh5hz/index.html?

第四期：http://ld.act.evkworld.com/jljh4m/?game_id=jljh4m

第三期：http://ld.act.evkworld.cn/jljh3q/index.html?

第二期：http://ld.koolu.cn/jljh3/index.html?type=preview 

第一期：http://ld.act.evkworld.cn/jljhzj/index.html?

唤境激励计划

【投稿方式】
 投稿邮箱：huanjingserv@xingfeiinc.com    
邮件里的内容为游戏名字、H5试玩链接、您的联系QQ。
活动详细规则见：https://bbs.evkworld.cn/topic/1084/  

引言

唤境引擎，是一款中文游戏制作工具。可实现较为全面的2D游戏类型，例如：视觉小说、塔防、俯视角射击、平台跳跃、角色扮演。

引擎特性

简易上手，口语化编辑，内置素材库，拖拽即可使用！

安装系统配置

唤境Evkworld可以运行在Windows和Mac上，是跨平台的编辑器。

• 最低系统需求：windows7 （64位）
• 推荐系统需求：windows10 （64位）
• 顶级系统需求：windows10 （64位）

推荐使用Chrome或Firefox。

游戏案例

官方taptap主页：https://www.taptap.com/developer/84855

引擎使用

下图展示了唤境Evkworld的主界面，并使用数字标识了其中的关键部分。详细使用说明可查看官方文档：https://www.evkworld.cn/learn/381

请注意，当您打开编辑器时，只能看到欢迎页；只有在新建或打开某个项目后，才能看到编辑器的主界面。

1. 主菜单:点击该按钮可以打开主菜单。主菜单提供了很多基本功能的控制，诸如新建、打开、保存、预览项目，进行项目设置，查看帮助文档等。
2. 组件添加栏：可以添加在游戏中使用的诸如图片、文字、按钮、对话框等一系列组件。
3. 位置调整栏：包含用于位置调整的按钮和调整舞台尺寸的选项菜单。
4. 预览功能栏：左边的两个按钮分别为“移动端扫码项目预览”与“移动端扫码单幕预览”；右边的两个按钮分别为“PC端项目预览”与“PC端单幕预览”。
5. 资源功能栏：可以跳转到教程、开发者论坛、素材库的快捷按钮。
6. 项目库：在项目库区域，您可以放置各个库，最多不超过三个，每个库之间可以拖拽调整位置，也可以收到右边侧栏里。
7. 场景库： 这里可以查看游戏里所有的场景，通过点击加号添加，或者选中场景右键新建克隆灯草走，双击某场景，还可进入该场景的图层组页面。
8. 对象库：在对象库区域，您可以看到所有在项目中所创建的对象，包括精灵、文字、按钮等等。
9. 侧边栏：这里可以收置所有库：全局变量、全局事件表、同类组、资源库等。
10. 舞台：舞台区域是对可视对象，进行编辑和展示的区域。游戏中所有关于美术、界面、文字等可视部分的编辑，都可以在舞台上完成。
11. 事件表：事件表区域是用来查看、编写游戏逻辑的区域。游戏中所有数值计算、场景跳转、逻辑判断等，都需要通过事件表进行控制。只在舞台上布置了素材的游戏是完全静态的，只有结合事件表进行控制，游戏才能动态运行。当点击 +事件 ，或点击现有的某条事件时，您就进入了事件表编辑模式；此时右侧的属性面板，会显示条件动作库。
12. 属性面板：选中某个场景、图层组、对象后，您可以在属性面板区域查看或修改它的属性。根据不同的选中对象，属性面板会显示不同的内容。

游戏发布

打包游戏后，可以自行发布到其他平台。目前自动打包功能已支持H5、安卓、Windows平台的打包，联系官方可以打包其他格式。

广告支持

我们提供了广告组件，支持接入汇量、穿山甲广告，收益归制作者。

相关资源

• 官网：https://www.evkworld.cn
• 学习视频：https://space.bilibili.com/401512283/video
• 官方Q群：640215025

欢迎下载体验唤境：https://www.evkworld.cn

我们是一个美术小团队，有3-5名美术人员，有2d原画 3D，动作 UI 特效。目前我们团队专门给独立开发者或者开发团队定制美术风格或者输出美术资源，我们的合作模式更偏向美术外包，不管能否促成合作，也愿意结识各位游戏爱好者或者开发者大大，有意向的朋友加qq：362862631,

假如你有团队或者好的想法，而且目前是缺美术这块，可以联系我，我这边有3-5个美术人员，2D和3D模块基本没问题，动作特效也有。我个人是全职，假如你希望我们只是产出，我们可以提供产出，若你想让我们也提一些对项目本身的建议和想法 我们也可以提供，但还是以你为主导，我这边可以远程办公，也可以驻场（上海），只要对项目本身有益的地方，我这边可以尽量满足。我们不是外包，但合作模式偏外包，其实就是一个共享移动美术，愿意结交一些志同道合的朋友，有需要可以留言 qq：362862631

落地开发了个独游制作导航站web，包含了程序/美术/音乐等国内外的素材站点。

http://game.yixin.im/static-web/hd/game-base/#/guide

建了个QQ群：875583576，欢迎入群与群内独游小伙伴组队，交流游戏制作技术和游戏资讯等。

项目描述：

横板剧情解谜游戏《挣脱》（具体可以看我们的开发日志及游戏页面）

职位描述：

* 游戏主要策划人

岗位职责：

* 负责游戏主要内容的设计（关卡设计、核心机制、设计主要心流体验）
* 负责跟进游戏的制作进程
* 整理游戏相关文档

任职资格：

* 有独立的思想，热爱独立游戏
* 能够思路清晰的进行剧情解谜类游戏关卡设计
* 能对游戏提出新的设计及融合团队的想法
* 熟练掌握各种基础办公软件，有一定的整理能力

* 理解SCP基金会世界观及新怪谈/旧怪谈风格（重要）

加分项：

* 精通 SCP基金会世界观 及 新怪谈/旧怪谈风格 者绝对优先（重要）

* 具有一定编剧能力者优先
* 剧情类及解谜类游戏经验丰富且有着独到理解者优先

我们是迷物组，一家坐落在成都的独立游戏团队，目前DEMO的开发已经完成，因为开发方向及团队需求问题，目前需要再找一位策划小伙伴对整个游戏的GAMEPLAY部分进行整体的设计。我们有信心以我们的美术去支撑您的想法。

团队秉承创造为上的理念，团队内部气氛和谐。

有想法随时可以提出，如果有点子能让所有人感兴趣，我们愿意为这个点子新开一个项目并全力做出来。我们相信，创造性本身就是具有极高价值的，而能和大家一起提出点子的人更是我们最需要的。欢迎详细和我们聊一聊。

工资：

面议

联系方式：

QQ：88349625

微信/电话：18981157592

《挣脱》DEMO实机画面

大家好，我是来自网易易信游戏团队的.

目前我们正在规划一个孵化助力独立游戏的行动，前期在调研大家在独立制作中遇到的问题.

感兴趣的朋友可以戳问卷反馈问题：

https://survey.163.com/htmls/indiegame/paper.html

填写问卷的伙伴将加入我们的共建团，成为首批助力对象～

团队成立5年（同时具备2D、3D产品的开发能力），经历过高低起伏，现已处于稳定态势，为了寻求突破和发展，近2年成立休闲产品的项目组，也在其中寻找到该团队合适的出路，今年想重新整合了资源，想成立一个中度游戏的开发，寻求新一轮的春天，急需一位制作人\主策划！

我的联系方式——VX：Taki-C 电话：13641737211

工作职责：

     1，制定产品研发立项提案、核心玩法、研发方向和目，并保证最终产品和这个目标相符合；

     2，负责策划游戏主体架构，游戏主体逻辑规则，以及各大主系统功能策划；

     3，参与具体游戏数值设计、系统设计、关卡设计等

     4，与全体开发团队一同制作完善的项目计划，并保证项目计划的时间、质量和成本控制在有效的范围以内；

     5、根据项目决策，合理计划、分配项目内部策划资源；

     6、把握项目设计和发展方向，发现并及时解决问题。

任职要求：

     1，热爱游戏制作，做为制作人主导过至少一款成功上线的游戏产品并且是休闲类产品。 

     2，熟悉手游，对海外移动游戏市场有深入的了解和独到的见解，特别是欧美市场。 

     3，深入理解游戏的体验、交互、生命力、用户周期。并且了解游戏产品的运营机制，有成功休闲游戏开发经验者优先；

     4，有志于并有信心创建一流的手游产品，有强烈的责任心、务实的作风、忘我的热情及创业的精神，能够承受高强度的工作压力。

     5，有想象力、有创意，能拿出不一样得东西。

     6，熟练掌握游戏开发及运营流程，对策划、程序、美术、测试、营销的工作有深刻理解； 

     7，精通把握市场及玩家动态， 合理制定产品规划 ； 

     8， 创新思维，成就导向，产品导向。极其热爱游戏事业，具备创业激情；

 工作地点：上海

这是一本我非常喜欢且觉得质量很高又足够别致的游戏开发书籍：

    入门导向，侧重原型，自学亲和，传达观念，注重内容结构全面性的同时又不失对技巧和方法论的提炼

这篇原本是在17年国庆节假期时打算发出来的书籍推荐，其草稿的完善工作一直被延时到两年后的今天早上。

不过说来有趣，这一两年间，各处偶尔可见的书籍推荐中，这本书似乎还是很少会被提及，极少，暂时印象中好像唯独的一回，是去年曾在这儿见网友Esther9在她的入门推荐中似乎提过这书一次。倒是对入门和信息组织上有些并不够友好的南梦宫的那本《Unity游戏设计与实现》，反而常常在一些时候被作为亲和的入门书而推荐。

由此感觉，这本书的特点和价值，似乎还并没有得到相对应的关注，进而，可能也不大容易会被需要的人及时发现，这一点，也是我想做此推荐的主要动机之一。不过最重要的，还是我很喜欢这本书，觉得它写的足够好，翻译的也足够漂亮，值得我那些正计划切入游戏开发的学习，但还没找到合适的书籍层面辅助的朋友们发现它。

延时至今，是因为有几个章节我一直没能吸收利索，总等着。但仔细想来，毕竟不是写读书笔记，择其特色与重点简要呈现出来，可能才是关键，所以这里应该不会选择按照全局咀嚼再复述的方式提供，关键还是回归主题，重在推荐，兼顾表达喜欢。

那么书归正题，关于这本书，其中总体被划分为了三部分

    正如书籍标题《Introduction to Game Design, Prototyping, and Development.....》这三部分也大概的呼应了书名中的三个要素：第一部分对应[Game Design] ，第二部分和第三部分其实可以整合来看作一体，共同指向于[Development] & [Prototyping]

个人觉得，其特色重点集中体现在其分列于[首] [尾]的那两部分

[中]

    先由相对其他两部分稍显短小的第二部分引入（p166-p320)，作为仅占全书约23%的页数（不算同样很有内容的附录），算是一个乘上启下功能的部分，这里的重点是引出了编程项目时需要具备的相关思维模式：

• 比如对复杂命令的分解拆分的思维
• 强调了代码库的概念和意义，提及了本书中对代码库思维的运用
• 必要的命名规范知识
• 基础的Debug知识
• 对竟态条件(Race Conditions)可能导致的问题的强调提示
• 提示了他为什么认为C#对比Processing、UnityScript更适合作为入门编程语言，强类型语言对型成良好编码习惯等方面的好处。
• 也包含面向对象思维，以及敏捷开发思维和Scrum(迭代式增量开发）这些重要的部分，同时也强调通过找到合适的工具来利用他们保持在开发中的激情和创造力
• 强调了本书的工程适合作为之后进一步开发的起点这件事。

总体结构可具体见目录，其中可见有若干节C#方面的，对于开发原型需要的那部分基本符合20/80法则的那部分知识，以及Unity部分的常用知识点。这些内容整体应该是可以配合如《C#图解教程》这类比较经典的C#基础书来进行食用的，相对这种书则提炼的更精要，更结合Unity开发的语境。

这些或许也可以理解为，对在接下来要提及的本书第一部分内所隐含的同主题阅读的思维的一种延伸...

[首]

    然后说回第一部分[Game Design]，这其实是我个人感觉本书比较有特点也有意思，令我喜欢的部分。

用译者在前言中的描述“提供理论框架”、用序的书写者的话是"对游戏设计方法的广泛深刻的分析，以及从设计经验中总结出的心得体会”，正如第一部分第一章章标题所言的“像设计师一样思考"

如果你读过《游戏设计艺术》，开篇你便会因作者对Jesse Schell在《游戏设计艺术》中那句经典的“我是一名游戏设计师”的引入而感到熟悉而亲切的感觉，而这种熟悉的感觉，也会在接下来以不同方式，不同角度，重新以相似的形式出现。

因为后面，从对经典纸牌游戏Bartok的规则变化以影响游戏的设计气质的呈现为例开始，作者不忘从【游戏的定义】开始，逐步的列举并梳理，归类，分析现有的说法：

    这部分从比较老的 1974年的MaryMidgley对动机的强调，1978年的Bernard Suit偏重日常生活游戏的言论，到现在的席德梅尔的“系列..有趣选择”观点，还会看到如Fullerton的《游戏设计梦工厂》和上文提及的Jesse的《游戏设计艺术》中的定义引入和并列对比，分析

也是通过这部分对各家定义的对比剖解和展开，延展出了后面第七章要探讨的如作为设计师的设计目标的初步阐述（游戏性态度、体验理解....）更紧随其后的，作者也将MDA框架，与上文提及的两本书中所包含的设计框架进行再一次的并置：

• MDA：Mechanics Dynamics Aesthetics(玩家由Dynamics，唤起的情感反应，这里更接近于体验的意思)，以及它强调的设计师应首先以美学眼光看待游戏（自顶向下），及玩家与设计师看待游戏视角和目的往往不同这点。
• 《游戏设计梦工厂》中的FDD（Formal 形式，Dramatic 戏剧，Dynamic elements动态元素），对提供分析工具对游戏设计进行细分的专注和对叙事对玩家体验的重要性的强调。
• 《游戏设计艺术》的四元法 Elemental tetrad(机制、美学、剧情、技术)(这里的美学主要指开发者制作的艺术和声音)，的游戏开发者视角出发点。

进而，在此基础上进行了结合与拓展，基于Jesse的四元法的四种元素的结构，但划分到了三个层次来起到设定情境的情况进行分层表达：

• 前两层结合Fullerton的形式和动态元素，分别为【内嵌层】【动态层】
• 第三层将游戏和文化相连，由玩家掌控的部分纳入，为【文化层】

因此，举例来说，同样是四元素中的【机制】

• 在内嵌层中主要为“定义玩家和游戏互动的系统，包括规则和Fullerton书中的大部分形式元素（基本近似于Jesse书里对机制的定义）
• 而形式元素中没被包括其中的[步骤]与[结果]，因为它们由玩家参与控制，所以被归类到动态层
• 机制在该层主要包括玩家如何于内在元素互动，还包括如策略、涌现、有意义的玩法（《Rules of Play》中有定义)
• 最后，在文化层，机制指玩家掌控了游戏机制的情形，如游戏mod(玩家直接改变游戏机制)，关卡自定义等，同时包含游戏即时行为对社会的影响。

此后，第一部分便开始对开头引出的设计师的设计目标清单展开探讨，同时也不忘记覆盖像是纸面原型、游戏测试、基础的数学与平衡这些主题，也有精彩的如单独一章对谜题设计的讨论（在《游戏设计艺术》中，谜题作为一项高级机制也被单独进行介绍）、对玩家指引引导、对数字游戏产业进行概述分析，并提供入行看法的章节。

进而，综合这些部分，如果刚好阅读过其中引述并进行并列分析的那些著作，第一部分的前半段内容，一定程度上能够帮你以一种近似于同主题阅读的形式，提供一个重新审视，整合，并提炼反思的机会————而这，大概也就是我特别喜欢它的第一部分的一个很重要的原因吧

一定程度上，这第一部分就算被单独剪下来，或许也基本已经能自成一体的，作为一个较有紧凑感和信息密度的设计入门书籍来被使用了

[尾]

    最后，说说第三部分，也是这本书关于Development的部分，也是这本书注重实践的集中体现的部分，由若干个数字原型工程的逐步搭建的娓娓道来而展现的部分。为什么要做原型作者也讲的很清晰了：

• 快速试验、否定或修改游戏机制
• 探索游戏的动态行为（Dynamic)，理解可能由规则自然产生的可能结果（涌现）
• 确保规则和游戏元素易于被玩家理解
• 了解玩家对游戏的情绪反应（体验）

仅简要提炼下部分原型大概涉及到的知识点来以供参考判断吧：由简到复杂：

• Project1-左右移框接下落炸弹类原型  ：（ Time.deltaTime, 属性（property),Random,InvokeRepeating(),Destory，基础的GUI，PlayerPrefs,物理层）
• Project2-愤怒小鸟Like弹弓弹射类原型： （更多的摄像机知识，强调迭代积累脚本，更多组件的理解，一些基本的物理控制，实例化，LineRender,视差滚动模拟，游戏状态管理，鼠标input)
• Project3-小蜜蜂like的太空打飞机原型： （ 类继承，enum,static,单例，input输入管理器，代码库概念的加深，递归使用，重载，迭代代码开发的再强调，字典，委托（delegate)，再提竟态条件，贝塞尔曲线）
• .....

这一部分中，讲述与拆解的细致程度，开发知识的信息量，选题的全面，以及本部分对实践驱动的突出体现，这些已经足够标定该部分的特色。

缺点：

    如果非鸡蛋里挑骨头一点的说，可能主要来自的是，后面的第二第三部分，暂时没有看到和第一部分的设计知识进行更多关联和呼应的意图。

不过这也可以理解，毕竟后半部分重点落于开发原型的讲解，且原型作为教学入门之用，从设计复杂度的定位上来看，毕竟上还太过初步，强行呼应也并无必要，适于进行大层级上的设计分析之处可能在这个等级的原型中也并不多

关于作者

作者的经历与USC，Jesse Schell这两个关键词有较多联系，前者是作者曾经任教的地方，后者则曾是作者的老师。

本书的序言也是由USC的教授Richard Lemarchand书写，大概描述了他与作者Jeremy相识与之后在课堂上建立师生关系的过程。另外一点趣闻是，在讲解游戏测试的章节中谈及寻找值得信赖的朋友进行测试，引入【纸巾测试者】这个概念时（p102），作者提及了陈星汉在制作《风之旅人》时曾和他是室友，他让作者等到开发一年多了以后才让他试玩的这件事。

[最后，关于这本书其他值得知道的]

1.这部书的附录里的内容也很系统化，不要漏掉

    你在第三部分的各色原型中看到的各色知识点，如章节中未具体展开，则大部分都在这里有额外的拓展,如: 协程知识，上文提及的如委托(delegate)，接口，一些基础的设计模式，作用域的知识，还有很有趣和较详细的谈插值的例子

2.这本书当前已经更新了第二版

详情可参见本书的网站：http://book.prototools.net/

根据网站透露的信息第二版重点对于上面的[第三部分]有了很大的扩充调整（作者说在这件事儿上他花了1000+小时！）

新书增长了80页的同时，也包括对国内主要在售的第一版所基于的unity版本在当下已略有些过时的现象的调整————更新到了2017版本（进而一些代码也发生了轻度的变化）

这些变化也更多体现在对第三部分中包含的若干原型的进一步调整，甚至是替换：如第一版中的Project7- Quick Snap 这个第一人称着重光影烘培的例子 与 Project8 - Omega Mage 这个庞大的地牢游戏原型，在第二版中应该会被一个叫做Dungeon Delver的同样是类似original Legend of Zelda 的游戏代替。

因此在决定选择这本书的时候，适当考虑直接获取第二版进行学习可能是一个不错的选择。

大概要说的就是这些，希望能起到点作用

最后，感谢译者们，尤其是译者刘思嘉，多次在不错的游戏设计书籍的译者名单中见到他的名字，超级酷，译者序也写得很精彩，感觉这样的翻译者，值得更多

---

2020/12/27:

今天注意到这本书的第二版的中译版已经出了

我们是迷物组，坐标成都。

一家刚成立不久的独立游戏工作室。

团队经过两年的打磨，也决定要正式推出我们第一个项目了。

之前有发寻找程序合作的信息，多谢各位的支持我们已经寻找到了合适我们团队的程序小哥了，在此封贴。谢谢

一站式服务！在这里，所有问题将不是问题！

1、需求不明确怎么办？-----帮助整理并明确需求，免费测试定风格！

2、预算不够怎么办？-----提供多种方案，让您得到低价高质的美术作品。

3、项目完结发现需要调整怎么办？----免费调整优化，直至上线！

联系人：月月
QQ：407020775
Tell：18713132592
E-mail：xiawan_yueyue@163.com

私聊查看更多作品