游戏设计入门——游戏程序框架设计

游戏开发这个世界太广阔了，这篇文章中，我只在程序实现的抽象逻辑上，开一个口子进行一些肤浅的阐述。

当我去设计一个游戏，一个玩法，包含规则，游戏对象等等一系列的游戏系统，用纸可以写下来，用嘴可以说出来，但是当我想要用程序去实现这一堆东西的时候，就有些无从下手。

比如我们大家都会下五子棋，它有一个明确的规则“一人一字交替放置棋子，率先5颗连成一线获胜”，在现实世界中，我们不用考虑五子棋的硬件配置，拿一张白纸，画上横纵格子，两人分别执笔就可以完成一场五子棋的游戏，或者是使用正规的五子棋盘和棋子。无论用什么玩，要实现“玩”是很简单的。

但是在做一个五子棋视频游戏的时候，那就需要把“棋子”“棋盘”这些东西用软件去实现，

进一步，作为抽象概念的“游戏规则”“胜负判断”也需要软件去实现，这就需要更多的“用计算机思维去思考”。

于是我花了一些时间，凭借有限的本科计算机基础以及一些自我东拼西凑的自学，总结了一下游戏框架的一个通用设计方案。

一.随便开个头

首先阐述一下大的抽象概念，这里也不用被“抽象”二字吓到了，什么是抽象，就是归纳总结出来的结论之类的东西，就像把自行车，飞机，汽车都抽象为“交通工具”一样，这里归纳总结一下这些玩意的共性，于是“交通工具”这一个抽象概念就诞生了。

视频游戏程序框架，我认为她（she）就是一个循环（Loop）过程性，“开始游戏——杀敌/解密/闯关/…——游戏胜利/游戏失败——开始游戏”，对吧，关键字，循环（Loop）的，过程的。

进一步对此概念进行细化，衍生出GameState（游戏状态）和GameController（游戏/规则控制器），至于为什么会有这两个概念？我是参考了UE4提供的GameState类和GameMode类，同时也参考了前辈们用Flash写的游戏逻辑，至此我总结为GS和GC两大块，至于更高级的学术阐述，受限于我学识水平目前还做不到。

 二.GameState

GameState就是对游戏状态的描述，最基本的两个，GamePlay（开始游戏）GameOver(游戏结束)，这里GameOver不能理解成玩家平时看见的GameOver，玩家平时看见的GameOver大多表示游戏失败，而在这里，这个概念只是表示游戏结束，因为无论你游戏胜利还是游戏失败，游戏都结束了（GameOver）。

在此之上，可以进行扩展，例如现在游戏都会有主菜单，也有暂停，或者有多人模式，游戏设置等等，于是我们可以在GameState中添加MainMenu，GamePause，MultiPlay，GameOption等等。

使用GameState进行游戏状态的管理有什么用？最重要的就是给你一个清晰的编程实现游戏的思路，或者说给你一个入手点，至于方便管理游戏进程，方便后续游戏程序功能性扩展，降低游戏程序各系统耦合性等等，实在太多了。

至于GameState如何使用？这东西就是用来切换的，作为标识游戏目前状态的一个Flag。

之前在阅读《游戏人工智能编程案例精粹》这本书中，其中详解了FSM（有限状态机）在游戏AI的应用和扩展，以此联想，对于GameState的处理使用FSM岂不是再合适不过了。《lua游戏开发实践指南》中提到“对于Singleton，无论什么情况下，只要它们提供方便就使用它们”，虽然这句话说的太满，不太符合中国人的思维，也不符合辩证法（笑），但也某种程度上表明Singleton的实用性和广泛性。所以更进一步，使用Singleton（单例模式）的FSM处理GameState，以我来看是极好的。

当然，以上是抽象概念的阐述，最终用到游戏程序设计上，还得按照一些编程语言的语法和特性来实现，这里，我也给出了一份Unity的C#的原型代码，可以当作伪代码吧。

Unity的C#的原型代码： 

publicclassS_GameState : MonoBehaviour {

   publicenum