对于分布式理解

分布的话, 我的理解分几点, 应该属于相当肤浅的, 记录一下, 大家不要笑.
1. 数据一致, 服务器上不保存任何值, 全部上数据库, 加上内存数据库, 比如redis, 目前数据库单库性能上线为10W QPS, 容量3T 大概这样, redis大概512g的样子
2. 服务器间通信, 自己写的话大概是集中到网关或者点对点互相连接两个套路, 转发速度目前云服务器内网都能达到万兆, 甚至3万兆
3. 万一还是有逻辑要世界唯一执行, 还得有个裁决者, 如果是网关集中转发可以在这块做文章, 或者独立建立主线逻辑服务器
4. 对于客户端连接服务器这块, 如果是tcp/udp或者http协议的话, 目前有很简洁的办法就能做到负载均衡, 性能上限大概连接数是100万, 轮询能到
如果要求的各项指标都在以上范围内, 整个分布式还是比较好弄的, 如果某些组建需要集群才能满足性能, 那就某一块还需要继续细分解决方案

[锤子][畅呼吸]车用空调滤芯长宽高

锤子的官网只有大概匹配车型, 对于有强迫症的我来说, 看不到具体数据实在不放心, 经过询问官网客服获得如下数据
产品型号 JAF5200055 产品尺寸 205*269*33mm
产品型号 JAF4200052 产品尺寸 225*234*30mm
产品型号 JAF4200048 产品尺寸 238*204*33.5mm
产品型号 JAF4200125 产品尺寸 529*237*29mm
产品型号 JAF5200067 产品尺寸 280*240*34mm
产品型号 JAF4200041 产品尺寸 193*214*30mm
产品型号 JAF6210066 产品尺寸 264*284*44mm
好吧, 我的是246x188x34, 我还是老老实实用博世的吧

无尽扫雷-从开发到挂起

0. 起止时间:

2017年11月11日 立项
2018年4月27日 挂起
游戏只上架成功了Google Play地址  国内下载地址
没有装google框架的话应该会显示游客登录, 也能试试.

1. 起因:

那是双十一很偶然的一天, 在youtube上看到一个视频. 说的是一款网页版本的扫雷游戏. 竟然是没有边界的, 可以让全球人一起玩的那种. http://mienfield.com/ ps: 这个网站差不多1月的时候也挂了.
现在还能看看视频

当时觉得这个创意好酷, 再到google play和app store上搜索了一下. 竟然没有任何一款无尽版本. ok! 立项!

2. 开发过程:

2.1 确定实现方式

选择go和cocos creator作为双端实现方案, 并初步学习差不多用了1个月.(2017年11月-12月).
一开始打算用熟悉的C++来做双端, 毕竟和之前挂机游戏一脉相承. 不过考虑想顺便学点新东西, 服务端采用了Golang实现的leaf框架制作, 客户端采用Creator的TS来写.

2.2 密集开发

密集开发游戏功能(2017年12月-2018年2月春节前夕)
实际做起来还是发现不少挺费事的地方, 但是担心如果大规模数据进来, 游戏服要能动态扩展. 就写成了无状态可分布式游戏服+redis缓存+mysql最终持久化.
而客户端也经历了好多次性能优化, 才打到了满意的效果. 毕竟同时加载近2000个节点. 还需要绘制小地图.
最终, 客户端代码+服务端代码一共差不多2W行的样子. 边陪闺女边做差不多3个月.

2.3 提交

对接与提审(2018年3月-4月底)
对接的时候Google的麻烦多, 调试起来必须非大陆账号才能正常内购, 最后还是买的礼品卡解决的真实环境测试.
提审的时候就是苹果的蛋疼了. 尝试了大半个月都被打回了. 最后两次一次判定
Guideline 4.3 - Design 说是spam经过解释后判定Guideline 4.1 - Design - Copycats
只能暂时搁置了.

3. 挂起

终归还是上线成功了google play, 还是凭借前些时阿里云的便宜服务器, 购买了3年的. 全部都部署好了. 如果你有兴趣可以来试试.

扫雷小地图优化之矩形合并

扫雷的小地图是一个动态的点阵图, 直接使用Graphics组件绘制在大屏幕绘制大概64x64空间时, 按每个数据点进行绘制时性能还算面前能够接受, 大概10几个毫秒
但是到了丧心病狂的滚动大地图时, 因为有256x256的数据, 这个数量级如果还是俺点绘制. 6万5的数据点, 每个点还都是矩形, 我的妈妈咪呀, 几十万的GL vert爽的不要不要的
所以我们要将相同的数据举行进行合并, 合并时算法还要带剪枝, 要不性能又都跑到脚本层消耗掉了.
一开始是两道循环, 用Map保存数据(是为了查找方便)
到最后是一道循环加内嵌的一道高度剪枝的循环, 数据全部用Array, 终于算是手机上效率可以接受了. 大概200毫秒左右, 90%多的性能消耗还是最后落在了Graphics的fillRect上面
用两张图简单表示一下大概意思, 黑灰的为正常显示, 彩色的是我将每个矩形都随机了RGB颜色, 希望能看明白.

CocosCreator多节点优化杂谈

无尽扫雷大多数功能都已做完，进行性能调优。本以为只要用了缓存池就不会存在过多问题，哪知道不卡只是桌面浏览器WebGL里的事情。
直接说结论，调试的血泪史就不扯淡了。

• 预制首先还是要全部由NodePool进行缓存，缓存在加载场景时逐步加载。
• 扫雷节点，替换资源时，直接用loadRes效率还是不足，把通用的spriteFrame缓存，改扫雷资源的时候直接等于上去会快很多
• 尽量避免大规模js与原生层通信频率，1200多个节点一起setPosition在move事件不可取。要直接移动他们的父节点
• 由于扫雷一共管理1200多个扫雷节点，如果只用NodePool还是有轻微卡顿，修改节点的parent还是需要一定时间的。如果能把要删除的节点直接改个资源换个坐标，效率比NodePool高。
• label的非fnt字体，描边，节点的mask都会打断渲染批次。能不用就不用，不过这个对于扫雷这种素材不多的游戏来说都还好。直接用碎图然后用自动图集就可以自动合并渲染批次。

好了，差不多就这么些。通过这些细节处理，基本达到了流畅扫雷目的。至少在骁龙626上是这样。

vscode去掉go语言绿色波浪

两个办法, 一个是还是用golint做提示, 屏蔽W,C

"go.lintTool": "golint",

"go.lintFlags" : [

"--disable=W,C"

],

另外一个是用megacheck做lint工具

"go.lintTool": "megacheck",

不过megacheck需要自己去go get一下, 不过话说这东西比golint卡一些

go get honnef.co/go/tools/cmd/megacheck

Hello World, again!

时隔数年, BaihowFF.com又重新回来了.
虽然blog越来越边缘化了, 还是以此blog记录一些所思所想