UE4 TRPG制作日志七

一、Grid的创建与优化

在游戏中创建了绿白相间的棋盘地面，主要是源自：96朝日版游戏王

这部分的内容在UE4 C++基础回顾2 中有过实验

可以看到，棋盘上又有地形。

01、这种棋盘的制作就可以用static mesh提供的快速渲染多个实例来做，这样做性能好：SM_01和SM_02分别为绿、白两种颜色的plane，通过add instance 来添加实例。当然，需要创建一张绿白交替的棋盘，需要提供一个循环方式指定每次循环体内的add instance的location和创建的是哪一种颜色的plane。

逻辑结构： 

 

效果：

02、这个for循环怎么写，写在哪？之前用蓝图实现，感觉性能符合要求。如果用C++的话这个要怎么写？我想把东西都用C++整一下，缕清逻辑。（应该作为一个知识点）

已经完成用C++实现，需要每次创建时clear instance再add instance，然后把几个变量作为基础参数来控制棋盘网格的行列数，大小等即可。由于棋盘只在构造函数中创建一次，感觉不是很必要用C++去写。其次蓝图的Grid的可移植性更好一点。

03、之前还做了点击人物后，会在周围生成一些高亮网格，这个的思路就是把plane做成actor，这个actor会接收鼠标点击事件。当然人物会获取他当前基于绿白棋盘的位置（这个就是一个坐标系求值问题，初中数学搞定），当点击后,会在周围位置做一些linetrace，目的是判断棋盘上方是否已经有障碍物了，没有障碍物则会spawn出一个高亮的plane。

升级第一点，procedure mesh做成的actor比直接使用plane做成的actor性能好一丢丢。小地图的话无所谓。当然如果是使用蓝图写procedure mesh的话优势不大。用C++做各种基本形状的ProcedureMesh（YouTube上有一个UE4写我的世界，其中的方块就是使用C++ProceduralMesh做的基本actor，该actor可以被销毁）（应该作为一个知识点）。如果是要动态产生大量物体的话，蓝图的spawnactor就没有优势了。(又有一种叫做RuntimeMeshComponent的比proceduralMeshcomponent的性能还要好一些，RuntimeMesh在笔电上编译失败)。

升级第二点，复杂图案的话可以用一个mask，（有机会再演示），当然也衍生出的一种关于龙门骰篇的实现思路（游戏王DM版），可以指定六面体的展开形状，让人物在展开的高亮grid上行走。

二、Character的优化

之前是先创建了一个topdown的模板。再一点一点的添加功能，包括后面再添加GAS。不过也完成了GAS部分的测试，当时就觉得需要细分player和enemy。在之前的方式中其实并不能正常的创建子类（会崩溃）。这部分在TRPG 03\04有做点基础。

01、接下来会写成基类CharacterBase(C++），用于添加各种基础所需的接口，包括计算基于网格棋盘的修正位置。在没加回合制前，需要把玩家和敌人都设置为可选。派生出BP_CharacterBase，在这一层上放一个selectable接口(用于和鼠标交互),然后再派生出bp_playerbase和bp_enemybase。

02、需要添加转向，停止移动时，如果一定范围内有其他人，则自动转成面对面；在战斗过程中取消普通的移动。

03、把幸运值作为一种attribute作为考量，必要的话用代码模拟幸运值的影响。

04、完善人物受伤时的反应。（这个后面还要仔细考虑下）

05、添加各种各样的技能啦，balabala,这个就后面做了

三、掷骰子

最近和几个朋友聊，大致想了一种，当幸运值比较低时，采用第一种丢骰子的方式（直接松手的方式，非酋玩法），幸运值适中的时候（向上抛丢骰子），幸运值爆表，旋转丢骰子，旋转丢骰子把骰子的头尾基本确定好，（欧皇丢法）。这里面也涉及到一个模拟概率。（初中数学）。在TRPG 05有演示。

把这一块写好还要制作战斗的回合制。

没有想好流程中的移动形式和遇怪形式，大富翁形式？自由形式？根据丢骰子决定遇怪？明暗怪形式？

四、环境

可变环境，这里的可变是指类似于暗怪那种类型的，突然改变周围的地形。

五、简单化，更流畅的交互

追求简单稳定健壮的交互方式，基于此再考虑如何再简单的往上拓展（类似于音乐、语音、语音输入、手势、较复杂的行为树等）当然后面有时间的话就搞一个leapmotion丢骰子的小程序（这个谁有兴趣的话可以先搞一下，我应该放到很后面才会用到交互输入）。