Android引擎e3roid学习笔记②AndEngine比较

还是利用e3roid的学习方法，再理过AndEngine；但有几点不同。首先AndEngine缺乏文档，所以方法不得已简化为源码+实例；其次，比较的目的依旧是e3roid的应用，所以从细致程度上不如前者。另外，由于AndEngineExample与e3roid不同，并不仅仅展示单一功能，而是较为复杂，其分类也就显得不那么清晰，因而遗漏问题可能较为严重，如有需要在真机到手之后会单独开文讲述。

AndEngine分为以下几个部分，即audio, engine, entity, input, opengl, ui, util。与e3roid相比，其中，engine大致与e3roid相当，entity大致与drawable相当，input大致与event相当，物理部分通过扩展包实现，同样是box2d。

但与形同虚设的e3roid相比，AndEngine显然提供了更为强大的audio支持，SoundFactory与MusicFactory令声音的控制更为自如。与此相关的官方实例有MusicExample, SoundExample等。

engine一项中也包含了比e3roid更多的内容，如camera（用以调节屏幕的显示区域，利用HUD类实际绘制游戏屏幕于手机之上），option（设置），handler（基本的碰撞检测，物理与时间等内容）以及其他特殊功能（如分屏等）。当然，也提供了如e3roid一般的fps限制以适应低端机型。与此相关的官方实例有BoundCameraExample, CollisionDetectionExample, TextrueOptionExample, DigitalOnScreenControlExample等。HUD为对于camera的继承，其下有control。此处架构有些混乱。

entity一项，除了在e3roid中我们已经见过的modifier, shape, scene, sprite等，AndEngine还增加了particle（用于粒子效应）, text与primitive（基本的线、面、矩形）。与此相关的官方实例有AnimatedSpritedsExample, AutoParallaxBackgroundExample, ChangeableTextExample, EntityModifierExample, EntityModifierregularExample, LineExample, ParticleSystemSimpleExample, ParticleSystemCoolExample, ParticleSystemNexusExample, PathModifierExamle, RectangleExample, SpriteBatchExample, SpriteExample, SpriteRemoveExample, TextExample, TickerTextExample, TMXTiledMapExample, MenuExample, SubMenuExample, TextMenuExample等。需要说明的是，MenuScene为对CameraScene的继承，而后者是对Scene的继承。与engine中的camera并不相同。

input是另一个AndEngine优于e3roid之处，被分为sensor（用于重力感应）与touch（用于触屏）两项。与此相关的官方实例有MultiTouchExample, TouchDragExample。

ui将可继承的activity进行分类，用于不同的目的，如LayoutGameActivity等；除此之外，还特别增加了Dialog。

opengl下有texture等内容。

physics下相关实例有PhysicsCollisionFilteringExample, PhysicsExample, PhysicsFixedStepExample, PhysicsJumpExample, PhysicsMouseJointExample, PhysicsRemoveExample, PhysicsRevoluteJointExample等。基本上把box2d的实例搬过来了。

从以上简单粗略的梳理可以看出，e3roid基本上是一个简化版的AndEngine。在一些基础功能上，AndEngine要优于e3roid，如input与audio。但同时AndEngine也存在封装过度的问题。可以说功能与复杂并行。进一步的研究有待后续进行。

Android引擎e3roid学习笔记①引擎架构

e3roid是一款为android平台提供的开源2d游戏引擎，其主页为http://www.e3roid.com/，在其主页业已包括的信息本文将不再赘述。关于android平台游戏引擎的不给力与各种介绍，cping1982前辈在其主页中已多有说明（http://blog.csdn.net/cping1982）。与相似引擎AndEngine相比，e3roid架构合理，并且有API说明（http://www.e3roid.com/doc/），免去仅凭阅读实例猜测用法的苦恼；反过来说，AndEnigne的实例也可作为e3roid的补充，盖其本身实例较前者匮乏，而作者本人也承认e3roid对于AndEngine的继承关系。本文仅就e3roid引擎资料缺乏的情况之下，提供个人的学习研究心得，更为重要的目的在于为应用作一些铺垫。研究方法十分朴素，即以源码+文档+实例，希望能够有所收获。当然，错误也在所难免，敬请谅解。
本文所用e3roid为1.2.11版本。
e3roid由以下package构成，即[e3roid][audio][drawable][event][lifecircle][opengl][physics][script][util][service][transport]，其中，[script]用于多种语言实现（目前支持Java, Javascript, Lua），[util]提供通用类，[service]与[transport]用于网络通信，亦即在通常情况下开发者只需专注于其他内容，而这一部分的内容由package的名称即很容易理解其内容。
下面将分述各包的内容与用法。

• [e3roid] 基础类

e3roid的基础类E3Activity, E3Engine, E3Scene出现于[e3roid]之中。作为一款面向android平台的游戏引擎，Activity类为必备要素。使用一个实例来描述基础类的运用十分必要。一个标准的e3roid应用，至少应对E3Activity进行如下继承。本例来自于HUDExample，除了本例之外，SceneUpdateExample也是E3Scene的重要实例。在大致像样的应用之中，依次调用onLoadEngine()->onLoadScene()->onLoadResource()之后，必须有一个Update()函数用以刷新。

 public class TestExample extends E3Activity{
     // The width and height for the scene.
     private final static int WIDTH  = 320;
     private final static int HEIGHT = 480;
     // Textures.
     private Texture robotTexture;
     private Texture hudTexture;
 
     
     @override 
     public E3Engine onLoadEngine(){
     // Initiating the engine.
     E3Engine engine = new E3Engine(this, WIDTH, HEIGHT);
     // Asking for the full screen request.
     engine.requestFullScreen();
     // Asking for the portrait request.
     engine.requestPortrait();
     return engine;
     }
 
     @override
     public E3Scene onLoadScene(){
     // Initiating the scene.
     E3Scene scene = new E3Scene();
     // Load the texture for hud.
     Sprite hud = new Sprite(hudTexture, centerX, centerY);
     scene.addHUD(hud);
     // Set the position.            
     centerX = (getWidth()  - robotTexture.getWidth())  / 2;
     centerY = (getHeight() - robotTexture.getHeight()) / 2;
     // Load the texture for backgroud.            
     Background background = new Background(
              new TiledTexture("background.png", getWidth(), getHeight(), this));
     scene.getTopLayer().setBackground(background);
     // Load the texture for robot.            
     Sprite robot = new Sprite(robotTexture, centerX, centerY);
     scene.getTopLayer().add(robot);
     return scene;
     }
 
     @verride
     public void onLoadResources(){
     robotTexture = new AssetTexture("robot.png", this);
     hudTexture  =  new AssetTexture("controller_base.png", this);
     }
 
 }

• [audio] 

[audio]包由AudioInputListener接口与AudioInputeService类组成。前者用于接收声音输入，后者用于提供声音输入录制服务；除了标准的lifecircle之外，AudioInputService提供了诸如run(), isRecording(), readAs16bitWave()等简单实用的函数。官方给出的example为AudioInputExample。初步鉴定e3droid中并未提供如AndEngine中的SoundFactory类，这多少为游戏声音编程带来一些麻烦，但依靠android自身提供的功能大可完成一般性质的任务。其实AndEngine之中也不过进一步封装而已。具体方法详见Beginning Android Game 2011一书。

• [drawable]

对于任何游戏编程来说，图形绘制都是极其重要的一部分。因此，可以说，[drawable]是e3roid的重中之重。事实上，从其所占的比重来看也是如此。首先来看drawable基础部分，除了Drawable接口之外，其下有类Background, Layer, Menu, Shape与Sprite，其中，Layer与Menu是单独的类，而其他三者则具有Backgroud->Sprite->Shape这样的继承关系，通过阅读文档可以发现，Sprite与Background较Shape变化甚微。官方给出的相关实例为BackgroudExample, ShapeExample与SpriteExample, SpriteDragExample, SpriteMoveExample, SpriteRemoveExample，内容与上面所举的例子大同小异，只是增添了rotate(), scale(), move()等函数的应用，但一些更有意思的方法并没有展示。
值得注意的是，当进行Shape(Background, Sprite)的清除工作时，需要重载父函数的onRemove(), onDispose()等方法，并且，被清除的对象不可再被调用，若只是想要隐藏，使用SetVisible()即可。
[drawable]其下还有[controls][modifier][texture][sprite][tmx]等子包，展示了其高级用法，下面就来进一步学习。
[controls]主要提供虚拟摇杆的支持，其下有StickController与DigitalController两个类，其中后者为对前者的继承。官方文档说明前者为analog on-screen control，而后者为digital on-screen control，但二者的区别我尚未明晰。官方实例提供DigitalControllerExample, AnalogControllerExamplem, MultiTouchControllerExample，为一个基本完整的模拟摇杆实例。目前感觉此包是专门的模拟控制，如需特别控制则以应用onSceneTouchEvent(), onTouchEvent()为佳。
[modifier]提供修改可绘制对象的接口，其中大多数类都可从名称中获取其含义。ShapeModifier是其抽象基类，其下派生出ParallelModifier, ProgressAware, ProgressModifier, SequenceModifier, SpanModifier，其中，ProgressAware, ProgressModifier用于控制进程，SequenceModifier提供设置循环方法，其他待考证。ProgressAware下派生出AlphaModifier, AxisModifier, ColorModifier, MoveModifier, RotateModifier, ScaleModifier等更为实用的具体类。官方提供的实例有AlphaModifierExample, AxisModifierExample, ColorModifierExample, MoveModifierExample, RotateAndScaleModifierExample。由以上实例可以看出，任何Modifier类均需要以ProgressModifier进行初始化，并且调用onModifierStart(), onModifierFinished()方法。进一步的研究将在真机到手之后跟进。
值得注意的是在[modifier]之下尚有被作者称为for easing actions的[function]包，其具体作用目前尚不清楚。
[sprite]提供sprite的特殊绘制方法，包括AnimatedSprite, TerminalSprite, TiledSprite, TextSprite，其意自明。官方提供的实例有AnimatedSpriteExample, TiledBackgroundExample, TiledSpriteExample。在具体实现上，则可在上面的例子中加入如下代码。AnimatedSprite.Frame是[sprite]下的一个数组，用以存放动画的帧。

         // Add animation frames from tile.
        ArrayList<AnimatedSprite.Frame> frames = new ArrayList<AnimatedSprite.Frame>();
        frames.add(new AnimatedSprite.Frame(0, 0));
        frames.add(new AnimatedSprite.Frame(1, 0));
        frames.add(new AnimatedSprite.Frame(2, 0));
        frames.add(new AnimatedSprite.Frame(3, 0));
                 
        // Start animation with 500msec, infinite loop.
        sprite = new AnimatedSprite(texture, centerX, centerY);
       sprite.animate(500, frames);

需要停止播放动画则可加入

         if (sprite.isAnimated()) sprite.stop();
非常方便。

TiledSprite目前不在本文关注范围之内。

• [event]

[event]是另一个重要内容，e3roid[event]具有如下接口，即AnimationEventListener, ControllerEventListener, FrameListener, ModifierEventListener, SceneEventListener, SceneOnKeyListener, SceneUpdateListener, ShapeEventListener, TextInputListener等。其中，SceneEventListener, SceneOnKeyListener, SceneUpdateListener较为重要，值得注意的是，一般的触摸事件由onSceneTouchEvent()接收，onTouchEvent()专门判定触摸某个Shape对象。官方并没有与此对应的专门实例。

• [lifecircle]

e3roid的[lifecircle]与一般的android应用并无明显的区别，在引擎架构之下，其实这一lifecircle并无太大的作用，除了提供E3LifeCircle的接口，还有E3Service类，但其下除了AudioInputService之外并无其他继承者。或者作者想向其中进一步添加其他子类也未可知。

• [opengl]
• [physics]

[physics]完全集成box2d，后者几乎成为2d引擎的标准配置。shape与world的基本概念也被完全移植过来，成为PhysicsShape与PhysicsWorld类，熟悉box2d的制作者可以很快上手。至于经常用到的碰撞检测则完全可以使用shape对象自身的函数完成。
以上基本理过e3roid的架构与实例。

游戏设计书籍评述

由于学习的需要，研读了部分市面上现存的游戏设计书籍。很早就想将其整理出来做一下备份。刚刚在豆瓣上搜索书籍时，发现此类书目有多了不少，翻译引进与国人自主撰写均有，质量究竟如何不得而知。但我的看法是尽管大多数内容未免重复，但是每一本书都有其独到之处。翻阅不需很长时间，略有收获便值得庆幸。如有机会，还是想将新出的书一一学习过。

此篇文章中所列书籍均为设计类，不涉及任何具体技术问题。排序不分先后。

 这是偶然在卓越搜索得到的书，但后来却证明是最为实用的书。实用，是对设计师而言。尤其对初心者。书中的一切均可实践，涉及的问题都是在设计过程中一定会遇到的问题。至少在我的阅读范围内，尚未见到过如此面向实用的书籍。若类比，本书可与编剧领域的《21天搞定电影剧本》相媲美。其他书籍或许同样实用，但前提是对于公司或工作室。本书却完全适用于个人创作或小型工作室。用作者的话说，他试图发现游戏领域的元素周期表。在设计书籍普遍语焉不详的现在，实为难得。总之，极力推荐。

作者为著有Game Design Bible的Christ Crawford，价值不容小觑。但本书与Bible不同，价值不在一般理论的介绍与阐释，而在于Crawford独家珍藏的各种游戏想法与点子，还有他制作的现在已经很难找到的游戏开发过程。阅读本书是一次真正的与大师对话。Crawford是一位特立独行的设计师，也是把游戏推向艺术高度的设计师之一。他的很多想法即使在今天看来仍不过时，读之很容易心有戚戚焉。另外，Crawford物理背景出身，编程能力极强，值得学习。本书中他讲述了不少Atari时代的故事，可以重新体味彼时的辉煌与教训。

本书是为数不多的类型游戏设计书籍。关注角色扮演游戏的设计师一定要读一下。很多一直在思索的问题都可以在其中找到答案。附录部分收录了rpg大作如辐射的策划文档，非常具有收藏价值。

本书极具学术气息，由黄石老师等的博士论文修改集结而成，与市面上大多数由游戏制作者撰写的书籍非常不同。不久前导师曾说，没有理论支撑，一个学科不可能站住脚。诚如斯言。所以在我看来，《数字游戏策划》一书意义重大。也希望今后能够出现更多此类书籍。

对增加游戏剧情和情感深度非常有帮助的一本书，而且非常实用。作者为好莱坞金牌编剧，但难得的是参与过数款游戏剧情工作，懂得游戏是怎么回事。通常的方法之外，他甚至提供了非线性叙事的一种方法。虽然在我看来不太实用。

如书名揭示的那样，这是一本关于游戏的基本介绍。初读可能会觉得很不起眼，但如果细读的话则能够发现许多老师独到的关注点。细读到什么程度呢？很多章节的来源我已了然在心。如果打算报考中国传媒大学游戏专业研究生的话，最好读一下。

与题目不同，这本书并不仅仅谈论产业。事实上，它基本没有提到产业。相反，这是一本介绍游戏制作全过程的设计全书。也可以说，是一本游戏设计的入门书籍。总体而言，本书适宜大型公司的游戏制作使用。内容非常全面，从预制作过程到原型设计，乃至预算都有涉及。有配套网站和相应的练习题，题目主要作用为检测读书效果，但也有一些面向实践的题目，能够达到锻炼思维的目的。

这本书的出版时间应该非常早，因为我是在中学时候就收藏了本书。应该说，《顶级游戏设计》一书还是需要一定基础与反复阅读才能够体会。本书同样涵盖了游戏制作的基本过程，但个中所述几乎完全来自实践，倘若有一定实践经历则能得益许多。每章附有制作人采访与作者个人建议，非常中肯实用。附录中则有推荐网站、工具与教育资源。总之全书相当具有收藏价值。

非常经典的关卡设计教材。由于同类书籍的缺乏而愈发显得弥足珍贵。理论介绍之后附有虚幻编辑器的使用方法。总之必读的一本书。

来自美国的游戏设计教程，由于是全彩印刷因而非常之贵。但读完之后却感觉相应收获并不如价钱那么引人注意。入门类书籍，涵盖内容全面，但独到之处较少。

本人最早阅读的一本游戏设计通论，由于当时读的是英文版，所以也不清楚这一版本翻译如何。内容还是非常详尽，对于入门帮助很大。同样附有制作人采访，内容也十分厚道和精彩。

Tales of Grace：传说初恋

Tales of Grace（圣恩传说，下文中简称TOG）是我接触到的第一款传说。可以认为，我并不是传说的目标受众。起初，日式漫画人设的3D化便使我难以接受。剧情过于低龄，让人提不起继续的兴致。战斗或许有趣——事实上，我也是由于战斗才被吸引尝试传说系列——但缺乏持久的游戏动力。以上是我对传说系列的初步认识。我的游戏经历并不丰富，对于日式rpg的大类也认识有限。在真正接触过TOG之后，传说系列在我眼中的形象大为改观，现在正不时抱着小三儿攻克Tales of Innocence。

在褒扬TOG之前，我仍然要先说明它显而易见的缺陷。虽然这种缺陷几乎是rpg或说日式rpg的通病。迷宫无聊而冗长，其中的谜题可看做对玩家智力的鄙视。或许是由于制作者将大部分的精力投入战斗系统而导致。至于人设与剧情，这是仁者见仁的问题，不难看出，本作面向青少年，那么如此做法不仅不能算作过错，反而是吸引玩家的手段了。

TOG解决的最大问题即是传统rpg战斗重复，并因此导致的无趣问题。解决这一问题的主要手段是战斗系统动作化。但并非简单的动作化，而是某种程度的格斗化。采用线性系统，既增加了跑位带来的变化，又去除了无关因素。动作化带来的显而易见的好处是战斗的变化，而试图掌握这种变化的玩家则需要练习，这种练习与练级非常好地重叠在一起，带来了传统rpg所不能提供的游戏体验。

除此之外，TOG还采用了很多辅助方法来改进战斗游戏体验。譬如特定条件下的各种奖励。这其实带有成就系统的概念。利用称号学习技能及附加值也是充满乐趣的。虽然与直接通过经验获取相比有一些随机性，而当称号条件苛刻的情况下尤为如此。

但是，相比其他的作品，如正在进行的TOI，家用机平台的TOG却并不够丰富。尽管有系列一贯性的料理系统，但优秀的战斗系统却缺乏更给力的任务让玩家体验。

我并不想对游戏剧情的具体内容作评价，虽说我很叹服传说的人物塑造，其丰富的细节令对我来说狗血的剧情都可以忍受。但是小对话系统的出现表明制作者有意于尝试“玩”剧情的概念。小对话本身作为收集元素体现的正是这一点。虽然这还远远不够，但我对这一趋势很是欣喜。

《座头市》：乱世清泉

相对于小武的其他影片，《座头市》显然具有很多现代元素。这一点主要表现在叙事上。剧情连贯，有戏剧性，多条线索交织。换句话说，我们能够看出小武希望讲个好故事的野心。但对于本片来说，好故事当然不只是全部。事实上，好故事只是为了更好地塑造座头市这个人物而存在。

蹊跷的是，座头市这个人有着极为薄弱的存在感。眼盲，安静，爱笑，但不习惯说话。仅有的台词只是为人熟知的日本人的敬语。对于他的过去我们一无所知，只从试图欺辱他却失败的路人口中得知他曾为一代宗师。甚至连座头市这一名字，都是在影片临近结束时才透露出来。更多的时候，座头市被称为按摩师，或盲人按摩师。

当然，座头市依然有自己的标签。譬如出奇的武艺高强。这一点如此引人注目，以至于其他的特点都被忽略不计。但是，座头市有盲人的敏感和乱世之中难得的善良。乱世难得善良，是因为恐惧高于一切。当半句话都没有说完就已经性命不保，善良几乎等同于愚蠢。座头市有善良的资本。但更为难得的是，座头市并不依仗自己的资本而善良。当他帮助梅夫人运菜的时候，他们的笑容会让人忘记黑道的盛行。帮助新吉赢得赌局，并且丝毫不妥协于赌局的黑幕。结尾，他的坦白（“即使睁开眼睛，我还是什么都看不见”）让人知道，有时他也不过硬撑而已。

对于座头市的全部刻画集中于对姐弟俩的帮助。从原本的怀疑，到独自一人追查姐弟俩都准备放过的老大。座头市如同乱世的一泉清水，涤荡了那个时代。跳出影片来看，恐怕唯一的缺点就是座头市过于完美，未免不符合现代审美的习惯。但结合时代定位，反而有古典小说的淋漓畅快。

叙事的缺陷在于推理过程的缺失。最后的老大人选除了让人感慨座头市的伟大，不能惊呼原来如此。原因即在于铺垫过少，除了将拐杖碰掉之外没有其他。
但小武的魅力恐怕还是那些静静书写的镜头。这一回，他不时采取蒙特奇快速切换来烘托一种氛围。譬如弟弟跳舞的镜头，又譬如结尾的大歌舞。无不具有非常的美感。这种独特的镜头语言成就了小武。

人物多而不重复，每个人物都有其存在的意义和价值。连疯跑的傻子都似乎暗示了这个时代的疯狂。

艰难的3D化之路——看3DS降价事件

3DS降价，里外不讨好。尽管赢得了一周20万台的出机量，但信誉大跌。本文不想从商业运作的角度批驳任天堂，因为不擅长，也因为笔者同样是为《时之笛》购入3DS的内心滴血的任饭。本文选择的角度是3D游戏的可能性。

任天堂的理念是利用过时的技术带来非凡的体验，NDS和Wii的大获成功是近年来极好的例子。NDS利用触控、录音和双屏增加了游戏体验，但真正令NDS大卖的是脑白金之类的休闲游戏。而Wii的体感虽然引来了大批体育游戏的模仿者，但最终却由于粗制滥造而不得人心，真正成功的仍旧是任天堂自家的作品Wii Fit及其Plus。过时的技术为什么能够带来非凡的体验？首先是由于任天堂别具匠心的角度。另一个方面，也是过时技术的易于驾驭。由任天堂抛出裸眼3D，这件事情令许多人自觉不可思议。笔者也是其中之一。据说，3DS是导致任天堂老将横井军平离开的主要原因。

裸眼3D能为游戏体验带来什么？在问这个问题之前，或许更应该思考，裸眼3D不能为游戏体验带来什么。在传统游戏占据大片江山的现在，游戏真的需要3D化吗？3D与高清不同，后者是所有受众都能享受，所有游戏都能采用的画面提升。撇开3D带来的身体不适不谈，传统游戏3D化的空间极小。从目前的实践来看，很多游戏被玩家抱怨，3D效果不明显，只能导致晕眩，不如关掉游戏。即便是任天堂自家的大作，复刻神作《时之笛》，虽然3D效果确实美轮美奂，但关闭并不影响游戏。对于高清，玩家不会要求带来游戏性上的改变。但3D显然不同。

高的开发成本使人不能抱怨游戏公司的不思进取。在转战其他掌机易如反掌的今天，有谁能为看不见的利润投入研发成本呢？3D游戏需要新的玩法，最可能的即是视觉谜题。这种类型的游戏能够被各大厂商瓜分，留下自己的立足之地吗？

从3D电影的萎靡不振也能看出端倪。电影的3D化较游戏要容易许多，但事实上，令人满意的3D电影作品并不多。即使像《变形金刚》这样的作品，也只是在某些场面能够见识3D的魅力。表现人类的谈话，很遗憾，并不需要3D的效果。至于《加勒比海盗》更是被人讥讽为除了字幕完全没有看出3D。电影尚且如此，游戏的3D化之路显然还很漫长。
反观3D的出现，其实是人类对于真实的视觉效果需要所激发。既然有这种需要，就说明3D有其市场。如何抓住这一市场，已经关系到3DS的生死存亡。

角色扮演游戏设计杂谈之③：练级，真的必要吗？

此前的文章谈到角色扮演游戏之中战斗系统至上的必然，此篇旨在论述以战斗为核心乐趣的战斗系统设计。

一般说来，游戏项目立项的时候需要写明这一项目的核心概念，此后的可玩性与关卡设计均由此而来。这一核心概念必须具有丰富的内涵以扩展后续内容，必须足够引人注目以得到项目支持资金以及潜在玩家的关注，诸如此类无需赘言。更重要的是，这一核心概念必须独特，即便是现有游戏的衍生产物，也必须有所发展。作为游戏子类的战斗系统是否也能够借助这样的核心概念以定义之？然而，从现有的游戏设计实践来看，在部分情况下，战斗系统的核心概念是被忽略的。事实却是，倘若战斗系统拥有其独特而可行的核心概念，无论设计者自身，抑或玩家体验，都会轻松愉快许多。传说系列的战斗系统LMBS(Linear Motion Battle System)一直为玩家所津津乐道，抛开其他因素不谈，我想这一战斗系统的核心概念即为“如何在角色扮演游戏中体验到格斗游戏般的快感”。而马里奥与路易RPG中则很好地运用了“跳跃”这一贯穿马里奥系列始终的概念，为角色扮演游戏带来全新的体验。The Last Story中，Gathering的概念不仅衍生出独特的战斗系统，更与世界观、剧情紧密地结合。无论如何，核心概念有助于战斗系统设计的规范与延伸，从而更好地与其他游戏系统结合，孕育更好的游戏体验。

当借助核心概念将战斗系统设计完成之后，该系统须须经过自生复杂性与延伸性两个指标的检验。

依据《全景探秘游戏设计艺术》，自生复杂性可由行为数目与行动结果数目之比得出。拥有较高的自生复杂性的游戏可被冠以“优雅”之名，最典型的例子是国际象棋。尽管该计算公式限定了行为动词自身的数目，但毫无疑问，增加行动结果数目的最简单的方法即为简单地增加动词。按照这一思路，许多相当复杂（但并不意味着具有高的自生复杂性）的游戏诞生，而将其推演至最高水平的即为策略角色扮演游戏。除了多样的职业之外，地形等元素也被加入其中。由此带来的好处是多样的游戏体验。不仅不同关卡可以尽其所能展现各自的特色，即使是同一关卡，也可有不同的对抗方法。然而，这也使得策略角色扮演游戏成为核心玩家的代名词，而且大大延长了非良性游戏时间。非策略性角色扮演游戏之中也常常可以见到运用这一方法的实例。以增加自生复杂性而非单纯复杂性为目的，除了确保游戏的优雅之外，对比核心概念，将目的集中起来也是一个不错的方法。

仅从战斗系统的角度来看，可供关卡设计应用的具有延伸性的元素有两类。在敌，有敌人的种类与数目；在我，有我方角色能力的增强。在现有游戏之中，未能很好地体现这两种延伸性元素的原因有难度设计不当，在敌我能力过于悬殊的情况下，很难体现双方各个角色的不同。而在 《改进回合制角色扮演游戏战斗系统的12种方法》一文中，作者明确地将体现敌我双方各个角色的差异作为方法之一提出。同样，相似的操作与效果也使得玩家不能由此看出游戏的进展。一切均以游戏体验为判断标准。若游戏体验相似乃至相同，角色扮演游戏即应当大幅度地减少杂兵战。若不能做到大幅度减少杂兵战，则至少使得这种战斗成为一种乐趣而不是相反。要做到这一点，首先这种战斗不能是强迫性战斗，其次仍然要突出各个角色，乃至各个技能的差别。《剑与电》作者认为，角色就是他能够做的事。这一观点在设计角色时非常有帮助。

另外，一些看似战斗系统之外的元素却真正地影响其所达到的成效。《圣恩传说》之中，某些战斗开始之前会给出一些挑战，譬如10连击消灭敌人，达成这些挑战将给予玩家额外的奖励。这种类似于迷你成就的奖励不仅有助于玩家燃起斗志，更重要的是向玩家揭示了这款游戏更多的隐藏的玩法与乐趣。这一点容易忽略，但非常重要。

最后，我想谈一下关于经验值与练级的问题。这是角色扮演游戏的原点，但也是遭人诟病最多之处。在次世代游戏之中，我们是否还需要如此简陋而无趣的概念？首先，这种概念的出现仅仅由于对于成长的模拟。亦即，倘若有其他方法代替这种概念，很好地模拟成长，那么自然无需囿于此。目前，其他方法有熟练度等。其次，能否由于这一概念的简陋可笑而放弃对于成长的模拟？事实上，其他类型游戏之中也必须解决这一问题，因为随着敌人逐渐强大，玩家角色亦必须变得强大才能应对。只不过，动作游戏之中采取的成长模拟并非与经验值挂钩而已。我认为采用其他方法是可以的，但具体仍需探讨。放弃模拟成长的可能性我却未能想出来。