回忆宫殿

0/前言 工作中遇到了要更改配色方案的需求,然而目前的项目所有的配色是写在一个xml表里面的,大致结构是这样的: ID IsFillPart1 IsAddColorFirst1 ColorAddFirst1 HOffset1 SOffset1 VOffset1 IsFillPart2 IsAddColorFirst2 ColorAddFirst2 HOffset2 SOffset2 VOffset2 IsFillPart3 IsAddColorFirst3 ColorAddFirst3 HOffset3 SOffset3 VOffset3 IsFillPart4 IsAddColorFirst4 ColorAddFirst4 HOffset4 SOffset4 VOffset4 IsFillPart5 IsAddColorFirst5 ColorAddFirst5 HOffset5 SOffset5 VOffset5 1601 False False 0,0,0,0 0.56 0.35 0.24 False False 0,0,0,0 0.57 0.2 0.26 Fal ...

0/前言 可能这就是报应吧，刚开始工作的时候没好好学Lua，平常就是把它当成了python这样的其他脚本语言来用，一直没太仔细研究。到现在要做一些比较复杂的逻辑如果还是用之前那种面向过程的思想就会很受罪，所以这篇post来记录下Lua中如何实现面向对象 1/面向对象的基础概念 学过面向对象语言的肯定都很清楚，面向对象语言有以下几大概念： 对象(Object) 类(Class) 封装(Encapsulation) 继承(Inheritance) 多态(Polymorphism) 虽然lua本身没有这样的概念，但是好在它的特性比较好用且自由，我们就利用这些特性来实现 1.1/对象(Object) 众所周知Lua的数据结构基本上就只有表(table)，在实际使用体验上来说，这是一把双刃剑 坏处是涉及到一些比较复杂的数据结构，要手搓的东西就比较多 好处是简单易用，基础的数据结构本质上都大差不差，直接拉一个{}出来就都能搞定。得益于表里面几乎什么东西都能放的特性，我们对表的扩展可做的事情就太多了 对象包含属性与方法 那么来到Lua，用表的话与之对应的就是键值对和作为表的函 ...

统一规定的标准符号，不能乱用，不然就不好理解了。 循环的标准结构 注解符号的使用 基本结构: 顺序型 选择型 先判定（while）循环 后判定（util）循环 case选择

0/什么是UML? UML——Unified modeling language UML(统一建模语言)，是一种用于软件系统分析和设计的语言工具，它用于帮助软件开发人员进行思考和记录思路的结果. UML本身是一套符号的规定，就像数学符号和化学符号一样，这些符号用于描述软件模型中的各个元素和他们之间的关系，比如类、接口、实现、泛化、依赖、组合、聚合等 1/UML的分类 1.1/UML图 UML图本质上是将你的想法转述给别人,所以主要分为以下几类: 用例图 静态结构图:类图、对象图、包图、组件图、部署图 动态行为图:交互图（时序图与协作图）、状态图、活动图 类图是用来描述类与类之间的关系的，所以是UML图中最核心的。 1.2/UML类图 类图用于描述系统中的类（对象）本身的组成和类（对象）之间的各种静态关系,类之间的关系有： 依赖 泛化（继承） 实现 关联 聚合与组合 所以类图可以用以下例子来解释 123456789101112public class Person { private Integer id; private String name; p ...

1/索引与缓冲区对象 在上一章的实例中,引擎主循环每执行一次,就要上传顶点数据到GPU来实现渲染.对于简单的图形来说,这是可以接受的.但是实际项目中动辄几W的顶点数量不可能也使用这种方法来处理顶点,不然每一帧都要把所有顶点上传一次,那主循环不用干别的事了. 所以要优化这种情况,有两种方式: 减少数据上传量 在GPU上缓存数据 OpenGL对应的提供了两种方法来实现,分别是顶点索引和缓冲区对象. 1.1/顶点数组对象 而且各位不要忘了,OpenGL是一个典型的C/S架构,也就是说CPU在OpenGL里面扮演的是客户端的角色,而GPU在OpenGL里面扮演的是服务端的角色. 这就会产生一个问题:CPU在通知GPU执行一个API之后,必须等待GPU返回一个结果之后才能继续执行下一个API.换句话说,要调用的OpenGL API越多,性能就越差(要等待很多次返回结果) 那么有没有一种方法,把数个命令的结果保存在GPU上面,CPU只需要调用一个API就可以完成执行数个命令的结果呢? 答案是顶点数组对象 1.1.1/何为顶点索引 回顾之前画矩形的时候,我们上传了6个顶点,但是实际上只有4个顶点 ...

0/前言 从开始工作到现在对于游戏中的"随机"也接触了不少,这篇文章就来整理一下目前我对游戏中如何控制"随机"的看法 1/从最基础的开始 现在让我们来设计一个玩法 这是一个回合制RPG游戏,现在有10层地图,每层地图都有一些随时刷新的游荡小怪,击败这些小怪就可以获得某种的材料 这样一个简单的玩法,我们有以下几种设计方法 1.1/依据层数的随机 顾名思义,地图层数越高,材料的产出概率越高,同时材料的获取效率也会变高 这样设计的好处是玩家的产出与实例相绑定,驱动玩家去推进地图进度. 当然这种设计方式也有一些问题,例如 材料不能与地图进度绑定(提交材料进入下层地图) 每层材料的产出需要经过调整(如果你打到最高层,每次打怪的最高产出还是和第一层一样,那就没有意思了) 1.2/依据次数的随机 这种方式将产出与地图分离开来,具体的做法是设定每日前XX次是一个概率,之后XXX次是一个概率,XXX次之后是固定概率 这样做的好处是可以控制玩家每日产出的大体上限,如下表所示 次数 不掉 掉1个 掉2个 掉5个 产出期望(E) 打满可得 1-10 ...

从最简单的回合制逻辑开始

或许这一次能够真真正正的做到最后

在上一章,我们已经完成了博客的搭建,这一章就是博客的日常操作

0/碎碎念 由于目前的项目采用的战利品掉落被我设计成每个地图都不一样,之前的功能已经做了每个地图对应的战利品表了,处于方便维护的考虑,这次新增的战利品表也要每个地图都做一个.但是每个表涉及的战利品都非常的多,所以我就想先把所有的表用字符串输出出来再手动复制过去,毕竟这些表只有概率字段是会变的. 1/第一次尝试 所以我就写了下面这个代码来生成每层的表 123456789101112131415161718192021222324252627282930313233343536local format = [[ [3] = { {ItemKey="nil", Num = 1, Bind = 1, Rand={BASE}}, {ItemKey="物品1", Num = 1, Bind = 1, Rand={RAND1}}, {ItemKey="物品2", Num = 1, Bind = 1, ...