boxworld开发日记2019-6-8
打算做一个类似RimWorld的游戏，这里记录一下历程。首先，简单回顾一下。
2018年12月23日 场景管理，打算使用四叉树，后来发现四叉树在空间组织和内存占用方面并不占优势，之后计划使用地图分块。
2018年12月23日 那几天主要琢磨AI寻路，网上找了几份代码，总结归纳，写了一个雏形。
2019年05月08日 之前很多东西没有记录，之间一直在造各种轮子。这次是个地图砖块的插值
还有一个带碰撞的爆炸模拟
2019年05月27 走迷宫的小猫娘
实际应用中，发现自己写的A星寻路，性能是个问题，当然现在也没解决，100个单位同时寻路，会卡一秒。
A星寻路应用到场景的例子
测试了一下极限，128x128的图，4万个对象，运行不到10秒崩掉。5万个启动不了，直接内存报错。想当年我用双核u，集成显卡玩星际争霸2，一秒一帧但不崩，佩服暴雪程序的稳定。
2019-05-31 这些天一直在修正A星算法，优化了内存分配，修正了寻路估值算法，下面是两个效果对比图。
修正前，使用曼哈顿算法，特点是快，但只会走直线。
修正后，直接使用开方算法，视觉上路径比较真实一点
2019-6-8 总结一下这几天的作业。首先，更新了一下自己写的基于tile的轻型2D物理引擎，但还是有一些问题未解决，比如刚体卡在角落里面不动。
这里说一下为什么不使用box2D之类的比较出名的物理引擎，因为我要做的目标是上面的那种大规模的场景，而box2D、Chipmunk我都测试过了，两者性能至少目前都差不多，两个字：太慢！这类物理引擎，为了真实性，计算比较精确，每条边都进行计算，至于场景分割，不知道他们用什么算法。box2D刚体在500个左右的时候，已经卡成幻灯片了，像上面那种动辄几百几千单位的，实在没法用。我的游戏还要进行AI计算、寻路、事件处理，不只运行一个物理引擎。这几天一直在完善这个小物理引擎，卡到角落里面的原因，可能是刚体移动的时候，检测砖块发生冲突，导致力抵消，但没有好办法解决。这个引擎只是基于tile地图的简单物理性质模拟，速度非常快，不加刚体互斥运行一两万个没啥问题，加上刚体互斥，4、5000个也没有压力。
这是加了刚体互斥，用GDI渲染的效果图，不足的地方，就是角落里面总是卡着几个刚体，这让人很不爽！
应用到场景中的效果：有没有一点星际争霸2框着一屏幕单位的感觉？
同时，根据物理引擎特性，将单位汇聚一点之后，单位会随着时间自己慢慢散开
先记录到这吧，希望大家支持！
最新文章
- em与px换算关系以及常用列表
- centos7.0 下安装git（http方式）
- python的函数调用和参数传递
- HDU 4045 Machine scheduling （组合数学-斯特林数,组合数学-排列组合）
- Source Tree for MAC1.6
- tcp 服务端如何判断客户端断开连接
- Good Bye 2015 A. New Year and Days 签到
- 函数与关系实例，函数运算与SQL，试验与关系元组
- 通过js引入当前所需要的js，css等
- yield 学习笔记
- Javascript数据类型共有六种
- Hive笔记——技术点汇总
- R语言︱ 数据库SQL-R连接与SQL语句执行（RODBC、sqldf包）
- 移动端解决单机事件延迟fastclick
- 常用的消息队列中间件mq对比
- 1030 Travel Plan Dijkstra+dfs
- Android 2019最新面试实战总结
- 解决：error LNK2026: 模块对于 SAFESEH 映像是不安全的
- Python基础-入门之路PYTHON-包 相对导入&绝对导入
- 10 windows server 2012R2 发布MVC框架网站注意事项