本文并非介绍框架设计。只是想通过这个案例，单地表述解决本文问题思路。 基于上一篇《生成赛事对阵图-排序》，得到小区归总有序的前16名信息 [TOC] 问题 让前4名有机会同时出现在冠军赛和季军赛 其它情况随机分组 已知 保证集合有序,且长度>=16 解决 借鉴Knuth-Durstenfeld Shuffle的算法思路，本算法特别之处在于保打乱局部范围的元素，最终令相邻的元素在一个分组。决定打乱哪些元素由外层指定，如打乱奇数位的元素，则传入{1,3,5,7,9,11,13,15} 1. 满足需求1和2 1.1 第2名交换到索引9的位置，即第5组 1.2 第3名交换到索引5的位置，即第3组 1.3 第4名交换到索引13的位置，即第7...

本文并非介绍框架设计。只是想通过这个案例，单地表述解决本文问题思路。 [TOC] 问题 有一个大区（跨服）玩法，各小区积分归总后的前16名可以参加后续的淘汰赛。 #已知 各个小区榜均已排序 归总后的数据长度>=16 解决 借鉴选择排序的思路，但由于各个集合本身有序，所以无需遍历各个集合求最大值。另外只需要归总后最高的16名，所以不需要对所有集合排序。 每次从N个有序集中，选出一个最大值 由于是有序集，后面的元素不可能比之前的大，所以已被选取的索引，之后不需要再被遍历，tOffsetMap记录各个集合最后的索引位置 Lua代码 math.randomseed(os.time()) local function sortset(s, n) ...

[TOC] 新人容易忘记要先设计GameView分辨率大小再开发界面。 从技术层面，我想一个解决办法是，分辨率默在配置表中定义，当首次打开Unity工程时，GameView默认使用这个分辨率。 翻了UnityEditor源码，发现其并不开放设置GameView窗口的接口。于是写了以下代码，尝试通过修改其配置文件GameView.asset,window下文件大概在C:/Users/YOUR_USER_NAME/AppData/Roaming/Unity/Editor-5.x/Preferences。同时Unity也不开放其内部YAML的序列化接口，于使用了AssetStore的第三库YamlDotNet。但YamlDotNet的输出内容，Unity原生的YAML格式，有一下差...

[TOC] 思考问题要从问题的原点出发，套用某个方案是解决问题的错误思路。我写这个主题，是因为大多数人（包括我也是），在解决问题时，常常不经过具体的分析/验证，就贸然使用那些被“吹得牛B哄哄”的解决方案，如程序滥用插件和第三方库，策划抄需求。 按《金字塔原理 》书中的理论，解决目标问题Root，其实是自上而下解决N个子问题（树的深度）的决策树，其特点是重权越大的子问题越在高位，即被优先考虑/解决。 对比套用方案的思路，无疑是一个逆过程，即自下而上，重要的子问题没被优先考虑。最终可能导致目标Root妥协，迎合不是最优的解决方案，令目标Root偏离最初的原意。 不做分析的原因可能有以下几种： 项目进度紧张，没时间做。 对复杂问题。可能是知识/技能不足以分析/解决子问题（...

[TOC] 吐槽别人代码乱，在程序里多见不怪。细心就会发现这些吐槽行为并不是单向，被吐槽者往往也能收集到足够的“证据”/“建议”吐槽别人的代码很烂。 吐槽经常是发生在接手（离职/休假）代码时，这不是（离职/休假）时情绪亢奋写的代码龙飞凤舞。我认为烂代码是演变而来的，非一蹴而就（后面说明）。如果问题是普遍存在的，那么问题就不是个意外或特例。至于不将烂代码说出来无非是”有技术涵养”和“彼此理解”。而说出来则是可能因为经历太少人少轻狂、或是甩锅或是恶意攻击…. 问题规模小，可能需要少量或不根本不需要程序设计，大家一看代码就轻松明白，这种代码很难被定义为烂代码。然而需求的增加和叠加各种非技术问题，好代码就会大概率演变为烂代码。 常说“下层解决上层建筑“”。烂框架就会生出烂代码。好的...

[TOC] 2019年10月开始玩塞尔达荒野之息，觉得游戏里面有种感觉非常有意思。我不知道该用什么专业的词语来概括它。但我很容易在游戏里感觉它。 在荒野之息游戏里这么大的地图空间，并且又没有指引的情况下，为什么我在游戏过程并不觉得自己在胡乱的瞎逛呢？自己行走路线都很有规则，比如为了看清周围地域（找神庙），我总会朝着高处走。看到异样的建筑/地形/植物/怪物（如平原里有座小山），总感觉那些地方会有事情发生，而吸引着我过去，常常会有克洛洛和宝箱在那。又比如看到矿石会忍不住过去敲。 玩荒野之息玩到不知天时（连续几个小时），回头想来好像就是这个感觉，一直在让我乐此不疲地从一个地方到另一地方（进行游戏内容） 直到最近，听一些游戏介绍视频，无意地知道原来这感觉叫作【引力】。何物？吸引玩家...

[TOC] 几个月前接手了项目客户端网络层模块，要求分析数据包GC大小并优化。基于不可抗拒的原因，这个项目没有使用流行的通信协议，如google protobuffer和风云大大的sproto等，而是自研的key-value协议。经过一系列优化，最终将代码的GC减少了约50%，并且优化以来运行良好。由于不能将项目的具体代码逻辑贴出来，同时为了更好地理解本文主旨，下文使用伪代码来表达主体逻辑，请放心这不会影响你对要点的理解。 也许阅读的过程你会嘲笑和惊讶部分代码为何“如些地烂”。遗憾的是已无法对这些“上古的遗迹”细细地追溯过去，只能战战兢兢地修改下去罢了~~!! 修改前的代码 主要有两个对象NetPackage和NetWork NetPackage 数据包实例。负责储存着字段列...