之前Github放了一个例子，版本很老，是0.9.8的，后面1.x时代有一天突发奇想又去升级了一下，升级到了1.5.6。

今天突然有人又问到这个了，就顺手升级到1.9.5。测试了一下桌面环境是工作的，不过android环境不太想测试了，就寻思着集成一下Travis来测试一下，因为项目本身没有单元测试，所以测试的要求也不高，一是能编译通过，生成apk包，二是能够apk能够安装。

Travis是自带了android支持的，不过还是beta版，说实话beta版果然坑多。

首先来个简单的.travis.yml 文件

language: android

android:
  components:
    - build-tools-23.0.1
    - android-24

然后报错说找不到android-24。马上检查了一下本地的android sdk，有这个版本号。

然后网上找了一下方案，原来默认最高支持就到23，要支持高版本需要这样

language: android

android:
  components:
    - tools
    - tools
    - build-tools-23.0.1
    - android-24

这个的tools必须重复两遍，一次拉取最新的xml，一次才是真正的安装。

这样之后可以生成apk了，再来试试安装apk吧。

思路很简单：创建一个模拟器，然后启动，最后安装即可。Travis自带了一个命令android-wait-for-emulator 来等待模拟器启动。

在components里面声明– sys-img-armeabi-v7a-android-24 然后添加

after_script:
    - 

…

内存编辑器如字面意义是可以修改内存的工具。可以很简单的使用于游戏破解。

比如游戏中有金币这个概念，那么用户是可以看到金币数的，那么在内存编辑器中搜索这个数值，然后在游戏中做出一些操作使金币数量发生变化，然后再搜索新的值，直到搜索出来的结果数量只有一个或者几个，然后使用内存编辑器修改这个数值，回到游戏中金币数就会变成修改过后的值。…

Gdx-ai提供了常见的AI算法，当然也包括寻路算法，比如常用的A*。

Gdx-ai自身的API抽象也很易懂，也方便自定义寻路。

首先由Graph和Connection提供图中的连通性和对应连接的开销。 简单一点直接用DefaultConnection，它提供的默认开销为1。

而PathFinder就是具体执行寻路的类，而返回的结果是GraphPath，它包含了路的结果，对应的连接还有其他一些数据。

这是Meritxell Calvo Palanques画的示意图

 

另外就是Heuristic，它并不是必须的，但是一个有效的Heuristic函数可以加快搜索，不过不方便提供，或者不想提供，最坏的结果无非就是退化为Dijkstra。（我提供的例子会直接返回一个错误的启发函数，不过依然可以获得结果）。

例子就简单一点吧，一般地图的数据是从Tiled地图或者其他格式的文件中获得的，这里我直接用硬编码来。

这个图只有四个点，其中点1,2,3相互连接，点3连接点4，我们要寻找从点1到点4的路径。

首先表示这个图

IndexedGraph<Node> graph = new IndexedGraph<Node>() {
            @Override
            public Array<Connection<Node>> getConnections(Node fromNode) {
                Array<Connection<Node>> connections = new Array<Connection<Node>>();
                switch (fromNode.getId()) {
                    case 1:
                        connections.add(new DefaultConnection<Node>(n1, n2));
                        connections.add(new DefaultConnection<Node>(n1, 

…

LIbgdx旗下的gdx-ai库提供了大量使用的AI算法，其中包括了最常见的有限状态机FSM。

gdx-ai是一个普通的java库，并不存在平台相关依赖，所以直接在core中引入就可。

dependencies {
        compile "com.badlogicgames.gdx:gdx-ai:1.7.0"
    }

StateMachine是有限状态机的接口，对应的实现目前有两个DefaultStateMachine和StackStateMachine。

StackStateMachine以栈的形式保存状态，所以可以提供了方法获取上一个状态，一般使用DefaultStateMachine就行了。

FSM的例子很多，我们直接来一个简单的。

首先主体对象是人，而人只有两个状态，一个走路，一个打伞。

状态切换的条件是时间，也就是假定下雨的时间符合一定的条件。

首先创建一个Person类

public class Person extends Image {
    private TextureRegion walk;
    private TextureRegion rain;
    private StateMachine<Person, PersonState> stateMachine;
    private float time;

    public Person(final TextureRegion walk, final TextureRegion rain) {
        

…

Libgdx对于资源管理提供了AssetManager来做资源的管理，如果你需要使用它那么你就不得不使用这样的代码

manager.load("data/mytexture.png", Texture.class);
manager.load("data/myfont.fnt", BitmapFont.class);
manager.load("data/mymusic.ogg", Music.class);

其中的文件路径是字符串。然后在你使用的地方

Texture tex = manager.get("data/mytexture.png", Texture.class);
BitmapFont font = manager.get("data/myfont.fnt", BitmapFont.class);

这样使用其实蛮不方便的，如果你把文件路径作为一个全局变量的话，其实很多代码是重复的。

而AnnotationAssetManager提供了反射的方法来完成这个工作

package com.huangyunkun.hundred;

import com.badlogic.gdx.graphics.Texture;
import net.dermetfan.gdx.assets.AnnotationAssetManager;

public class Assets {
    @AnnotationAssetManager.Asset(Texture.class)
    public static final String ball = "ball.png";
}

比如有一个球的图片，那么只需要声明一个字符串。然后加载的时候直接传入这个类本身，由加载器自己去寻找所有需要加载的资源即可。…

测试驱动开发（TDD）逐渐成为越来越流行的实践，它提升了代码的易用性和独立性，也增强了开发信心。

TDD作为一种实践自然不存在不适用的领域，但是在一些领域它是具有挑战性的，比如游戏开发。

知你所愿

测试驱动开发在游戏开发中应用的最大挑战并不是来自UI。
其核心问题是你通常并不清楚你的UI是什么样的。UI是你必须面对的东西，而和它的交互更多时候是一个深层次的东西。

游戏的本质是状态机，而获得某种状态或者到达某种状态有时候需要付出相当大的代价。

测试这些东西是困难而且浪费的。

Uncle Bob曾说过：‘不要TDD UI’。

对于UI做纯粹的TDD是困难的，但是对于部分做TDD确实可能的。

比如游戏中的算法，状态机本身的变化等等。

对于UI它的确不合适，但是对于其他部分，TDD是一个不错的选择。

单一责任原则

遵循SRP原则是一个很好的补充。

将你的代码分离出来，从某种意义来看这样是为了测试而改变，但是从长远来看，也是一种很好的维护方法。

有很多事情是可以做到的，比如将可以测试的算法部分从UI中剥离，分离一些不同原因而存在的代码。

有一点是需要牢记的，有些代码第一次看的时候很难测试，但并不意味着第二次的时候仍然很复杂。

在流程上的妥协并不是什么大问题，首先使用你喜欢的方法写出代码，然后编写测试。

你需要预防的只有一次性写完整个游戏再进行测试的冲动。

在事后写测试的问题在于代码耦合，进而难以测试那些重要而有用的类。如果你发现你写的代码难以测试，请尽量遵循依赖倒置原则和开闭原则。

这样才能保证代码解耦足够支撑你事后测试。

实体系统

将代码分离，说着很容易，操作起来确实困难的。

如果分离？依照何种标准归类？

Entity System本身就是一种分离规则，将整个游戏分离成组件、实体和系统。

Libgdx有Ashley支持，它是一个轻量级的实体系统。

一旦整个项目跟随这个规则来拆分，大部分代码都是可以测试的。

游戏的核心部分将归入系统之中，而系统本身和绘制，即UI是可以分离的，这样游戏中的各种状态和情况都可以很快速的测试出来。

BDD合适吗？

BDD本身是一种设计方式，换一种方法思考本身并不能改变什么。

从本质上讲，二者也不是一种东西。

参考资料

IEEE:TDD
BDD
Game engine 101…