从0到1再到正无穷，我们来聊聊游戏编程

knismooth

    正好今天事情比较少，就跟大家聊聊游戏编程方面的事情，然后再请有兴趣的人跟我一起做点程序员的“零活”。当然，主题是游戏编程，那么跟游戏无关的一切都将被抛除，或者是“封装”。我不会讲计算机组原，算法或者编译原理上的任何东西，也没有打算把这些大学四年学的快吐得东西再搬出来，只是很简单的以游戏为线索聊一下如果我们要做一个游戏，将要走过什么样的技术道路。
当你有以下知识的时候将使你能更容易理解后面我在说什么，当然就算没有这些知识也不妨碍你继续阅读下面的内容，只不过你需要以另一种方式来去理解，因为我只是利用这些知识带来的思想去说明一些问题：
—计算机语言层级结构
—计算机图形学
—有限状态自动机原理（确定/非确定）
—掌握一门编程语言（编译）
—掌握另一门编程语言（解释）
    首先，为了不让大家产生误解，我要先解释一下软件编程和反汇编的关系。本来这不是个问题，但是就我所知很多从事过IT行业的人也会将这二者搞混。软件编程，说正规一些叫做软件工程，通俗的讲就是按照一定流程，使用某种编程语言实现某些功能；而反汇编，则是对已经编译好的软件进行逆向工程以破解，还原源码。举个例子，比如我们有一套房子，想把它从居室改成一个花园，但是过程中不能破坏房子的整体结构。如果是软件工程师（既房子的设计者），他们可以拿出房子的蓝图，寻找合适的地方进行修改，然后请施工队施工（其实就是他们自己）；如果是逆向工程师，他们需要亲自到房子里观察、勘测，找出房子的承重在哪里，哪堵墙是什么材料适合什么样的改造技术，最后再施工。对于这两种情况，第一种就是软件工程，第二种就是破解工程。虽然工程面向的对象都是那座房子，但是需要的知识，技术手段都是完全不一样的，工程师不需要知道敲什么样的砖会发出什么样的声音，逆向工程师也不需要知道盖房子时究竟先放的哪块砖。回到程序员的身上就是，软件工程师不一定会反汇编，而反汇编工程师也不一定知道怎么编程。所以，当你在网上看到一个汉化组需要“程序”的时候，他们多数是在找一个反汇编人员；而游戏制作组需要一个“程序”的时候，他们多数是在找一个编程人员。当然，这些都不是绝对的。
    前提说完，我们开始进入正题——游戏编程。
    首先我们要完成一个从0到1的认识，究竟计算机是怎么构造出一个游戏来的。一般理论将计算机游戏分为4个层次，硬件（语言）→图形引擎→游戏框架→脚本实现。这是一个中规中矩的划分，根据实际情况不同这里的层次可以更少，也可以更多。个人认为这个划分能很有力的说明计算机游戏的结构，所以后面将以此为基础进行说明，而对于一些中间或者过度层次，将放在最后进行阐述。
    第一层，硬件。这里的硬件并不是指你用了某某场的某某芯片，而是指硬件语言和硬件驱动。用一片海滩来比喻的话，它就像沙子下的岩石，是一切的地基，以后我们还会用到这个比喻。对于这一层，我们只需要了解就足够了，一般的编程是不会涉及到这一层的，因为对硬件的直接操作虽然高效敏捷，但是却异常的繁琐和复杂。对于这一层最直观地认识，就是你有一台显示器和一块显示器驱动芯片。这块芯片事先固化了一些逻辑，使它可以控制显示器上的每一个像素，并调节颜色与亮度。这些就是硬件语言，它们就像物理定律一样为你提供真理来构筑整个世界。但是这对于编程人员来说实在是太麻烦了，谁也不想在编程的时候还要去数屏幕上的像素点是在第几行第几列。因此对应的我们将显示器抽象到二维平面，用一组数学公式去表示他的像素位置以及亮度颜色，这一部分多用软件实现，也就是驱动程序。当然，这都是原始到不能再原始的原理，换到现在的场景下，驱动芯片被我们现在的显卡所取代，驱动程序也不仅仅是提供一些简单的显示功能，一部分物理效果演算也是在这一层进行的。而对于其他硬件的操作，也是同样的原理。
    对于第二层——图形引擎，比起硬件层来说要更为有血有肉。它的主要目的是为我们提供一套函数和框架来构筑一个计算机图形解决方案。好吧这么说有些太官话了，继续沿用沙滩的例子，图形引擎就像是那层沙子，他在空无一物的岩石上为我们提供一些可塑材料，从而使我们能雕琢出我们的作品。当我们要在屏幕上画一条直线，画一个圆的时候怎么办？我想所有人的反应都是去找个API然后去调用它的函数，没人会傻到翻出显卡驱动然后找怎么去点亮屏幕上的一串点。这些函数便是那些沙子，通过对它们的不断调用便可以组合出我们想要的图形（载入并显示已有的图像也属于这一层的功能）。这一系列函数的集合便是一个图形引擎，它们内部都通过依照图形学原理调用底层驱动来完成一些列绘图工作，这样我们只需要给出数学定义便可以轻松绘制出图形。D3D，OpenGL这些便是这样的东西，如果划分的严格一些SDL和ORG也算图形引擎，当然你够牛逼的话OpenCV也算。它们提供从坐标系到光照到投影到差值补正等等一些列的图形学运算功能函数，让我们实现各种视觉效果。当然绘制和显示只是一部分功能，图形处理和刷新管理等等也都包含在图形引擎的管理范围内。对于简单的游戏，到这一层就已经足够了，有了沙子加点水就能垒一个沙堡了不是？事实上对于简单的需求，这种原始的引擎也是最佳选择。我想谁也不想用虚幻3写个贪吃蛇出来对吧。可是，当我们有了一片沙滩的时候谁也不想只糊个沙堡就了事了对吧？难道你想一台8核16G内存的计算机只跑一个贪吃蛇？
    当我们要在沙滩上大展身手的时候还会遇到另一个问题——随着项目的扩大，代码行数，逻辑交互等等会渐渐超出我们的管理能力，从而导致程序越来越混乱，臃肿而难以控制。也许有的团队可以通过高度的纪律级出众的个人能力解决这种问题，但是相对的代价依然显得相当沉重，并且太不效率了。为了解决这个问题，便引入了一个工程化的概念——游戏框架。游戏框架简单的说就是一个模块化封装了图形、音效、逻辑、通信等功能的有限自动机。游戏框架通常会对图形引擎进行进一步的封装，使他的函数应用起来更为简单、高效，并且实现一些动画及特效。同时还会用同样的手法封装音效，逻辑，通信，UI交互等等模块。就像我们把沙滩上的沙子炼化并用它浇注出来了一个高楼的支撑结构一样，为后面高楼具体的结构划分，装饰打下基础和标准。当然对于这个概念可能还是不是很好理解，特别是在存在“游戏引擎”这样一个概念的情况下。拿falcom的轨迹系列来说，我们会发现从空轨到零轨到闪轨只有游戏内容变了，他的系统，操作方式都没有特别大的变化。这里所说的这个“系统”便是一个游戏框架，当falcom要出一款新游戏的时候，只需要按照事先定义好的标准建立模型，书写剧情脚本就可以了。我想应该有不少人接触过RPG制作大师这种东西，这便是一个低级封装的游戏框架（低级封装可以使上层更为灵活多变），你只需要告诉他用哪张图片代表什么，在什么地方触发什么样的剧情它就可以为你制作出一个RPG游戏。至于为什么说游戏框架是一个有限自动机，这个概念需要和脚本实现一起解释。
    有限状态自动机是一个数学上的抽象概念，他能根据输入或者不根据输入让自己在有限个状态上不断移动从而解决一系列问题。当我们写一个程序，程序会根据输入内容走入不同的逻辑，比如播放某段音乐、显示某张图像，这样的程序便是一个有限自动机。对于游戏框架，输入并不是指玩家的键盘鼠标操作，而是脚本。前面已经提到了，游戏剧情的替换是通过修改剧情脚本实现的。这个脚本里书写了在什么地方显示哪一张图像（比如主角的样子，背景的切换），还会写在什么情况下出现触发特殊场景（比如从对话场景切换到战斗场景），以及根据逻辑在脚本间进行跳转。这些综合起来便是游戏的脚本实现。在执行的过程中，游戏框架就根据这些脚本的指示，在特定的时机下载入某段音乐，显示某张图像，或者是转换到一些特殊场景下。这为游戏带来了极大地灵活性，增删新剧情的时候只要修改脚本就好，而不需要对核心进行修改，一些计算公式，AI逻辑也可以放在脚本中执行，当然这些东西自定义的脚本已经无法胜任，多使用perl或者lua这样的脚本语言嵌入C/C++这样的编译语言中实现。
    以上者四层概念便是一个游戏从0到1的实现过程。但是现实与想象总是有一些出入。对于商业开发来说，如果直接使用图形引擎，开发过程会显得非常漫长，不能迅速形成生产力，而如果使用游戏框架的话会因为封装过高而碍手碍脚的，更何况也没有公司愿意拿自己的游戏框架卖给别人。应对这种情况，游戏引擎便应运而生。游戏引擎的封装比图形引擎更高，但是又没有游戏框架那么封闭。游戏引擎公司通过下放一部分游戏框架的功能——图形音效等功能模块，脚本处理接口等构造出一个解决方案，这样购买游戏引擎的游戏公司只需要根据需要定义出自己的有限状态机，什么时候播放音乐，什么时候显示图像就可以了而不需要理会究竟怎么实现那些模块。通过游戏引擎构造游戏框架成本低廉而且快速，虽然还没到能让三岁小孩都写游戏的程度，但是已经大大简化了开发流程。对于世界上的游戏走势也能看出大型游戏已经全部向着使用商业引擎发展。
    说道最后，便是前面提到的所谓“零工”，也是一个从0到1的工程。我想这里有不少人都有过做自己的游戏的想法，但是苦于能力不足，精力不足无法完成。我的想法便是在此通过松散式合作的方式构建出一个简单游戏框架，以供大家使用，算是自娱自乐的一个小玩具。
    第一步的想法便是使用XNA引擎构建出一个AVG游戏框架，因为这是最简单的。只需要少数状态便可以满足大多数需求。
    如果你有兴趣，可以了解一下XNA引擎，并思考一些这个游戏框架所需要的一些功能函数及模块，需要哪些状态，并贴上来告诉我。如果你有兴趣编码，可以深入了解一下XNA并学习C#，编写一些功能函数交给我。一切交流在这个帖子中进行便可。不需要额外的通讯方式。
    关于XNA可以在网上找《学习XNA》这本书进行学习，而C#，在网上搜索一下“C#教材”便可以。
    关于编程的其他问题也欢迎讨论。

                                                                ——以上——

八云碧

技术宅好评，不过本人高三狗文科生，怕是没时间研究这个了呢...话说其实我最在意的是标题呢，由0到1....

Niren

Talk is cheap. Show me the code.

SaRroW

刚开始游戏专业的弱逼先顶再看

drzzm32

正在制作的路过

larrymario

受教了，谢谢楼主。
刚写完计划准备制作第一个游戏（弹幕游戏，但是还没那能力做成东方同人……），引擎也是边做边学中，只有大概的方向……
现在能想到的问题之一就是游戏数据的储存怎么办比较好，肯定不可能全部写到代码里，总归要搞个单独的文件来储存弹幕信息。计划是用xml弄成配置文件，但感觉这样做太二了
楼主接受提问么？我想问一下主流的，或者说大家比较常用的数据储存方法是什么？（如果这问题很白痴的话请无视……）

udumbara

大学时的“游戏编程”课其实就是计算机图形学应用呢……
因为计算机图形学也是另一门课……

十二

虽说我们站在巨人的肩膀上，但真正的结果还是取决于我们的认知。

漆黑之翼

上班狗表示想写点自己的东西都没什么时间啦

嘛……LZ有想法的话可以去Github上搞个开源项目嘛

逆雨

原本想自己制作AVG的，但是总腾不出时间，如今想来就是爱不够啊……