可靠 UDP 传输
这篇关于可靠 UDP 传输的文章，作者从对 TCP over UDP 的审慎态度出发，深入探讨了其可能的应用场景与实现路径。 作者首先指出，强行在 UDP 上复制一个完整可靠的传输协议往往得不偿失。其优势通常只在特定条件下显现，例如游戏状态同步等对包序不敏感、或采用一问一答请求模式的场景——这类小数据量交互正是 TCP 建立/拆除连接开销的短板所在。 核心方案上，作者认为一个可行的“可靠 UDP”模块，应专注于解决“如何利用不可靠传输实现可靠协议”这一逻辑问题，而非直接绑定 UDP 收发。他提出的 API 设计，将可靠化逻辑封装为独立层，业务层仅需调用发送与接收接口，而由底层的 `rudp_update` 函数处理数据包组序、重传请求与心跳维持。 作者分享了一个轻量级的 C 语言实现（约 500 行），采用了请求重发机制、16bit 包序号、以及可配置的发送延迟与超时策略。他强调，其实用性在于简化逻辑，并通过超时而非复杂确认来清理过期数据，为特定低延迟需求提供了一个灵活且易于修改的参考起点。
用 2d 缩放及斜切变换模拟斜视角下的旋转
这篇讲的是作者从一次游戏体验出发，发现游戏《Invisible Inc》在低配电脑上依然流畅运行等距视角（isometric）下的旋转动画，并由此推敲其图形实现原理的过程。 通过分析游戏资源文件，作者发现场景物件（如门和墙）仅有一到两张正面图片，并非预渲染多角度素材。其核心思路是：游戏引擎以2D方式运行，利用仿射变换模拟了3D的斜视角旋转。具体做法是先对图片进行X轴缩放，再施加一个特定的斜切变换，最终通过一个整合后的矩阵（如文章中推导的[cos(x), sin(x)/2, 0, 1, 0, 0]）在实时运算中变形图片，制造出透视错觉。作者还通过一段CSS代码直观演示了这一变换效果。 文章末尾，作者分享了为该游戏制作中文汉化Mod时遇到的两个实际问题及其解决方法，这些关于游戏文本排版引擎和本地化字符串格式化的经验，对同类型工作也有参考价值。整体上，文章从现象剖析到原理推导，再到工程实践，是一次有趣的技术探索。
skynet 里的 coroutine
这篇讲的是 Skynet 框架如何利用 Lua 协程，将基于回调的消息处理模型，巧妙地转换为开发者更熟悉的阻塞式 RPC 调用风格。 Skynet 本身是一个消息分发器，每个服务通过一个统一的回调函数处理消息。这种异步模型虽然高效，但写起来可能不够直观。文章深入剖析了框架内部的核心技巧：为每条进入的消息创建一个协程，并让消息处理函数运行在其中。当遇到如网络请求等需要阻塞的操作时，处理函数会通过 coroutine.yield 将控制权交还框架，并附带操作类型（如“CALL”）和会话ID。框架挂起该协程，等待结果消息到达后，再根据会话ID找到并恢复对应的协程继续执行。 文章还进一步探讨了更高级的场景：如果开发者想在消息处理中自己使用协程怎么办？此时，用户协程的 yield 会被自己的 resume 捕获，导致 Skynet 的阻塞 API 失效。为此，框架提供了 skynet.coroutine 库。它在用户 yield 的类型前加上一个“USER”标记，从而与框架的内部 yield 区分开来，确保两者能协同工作而不冲突。 作者最后分享了使用协程作为迭代器的实际案例：处理一个巨大的内存操作日志文件时，通过协程实现了流式读取和转换，避免了内存溢出，展示了这一机制在实际工程中的实用价值。
资源包的设计
这篇讲的是游戏资源包设计中的工程实践与权衡。作者从“如何把资源打包并高效更新”这一核心问题出发，指出了当前直接使用通用压缩格式（如zip）的普遍做法，以及为应对资源引用关系、大量文件检索等需求而采用自定义格式（如MPQ、AssetBundle）的趋势，其中对文件名进行hash索引是关键一步。 然而，文章敏锐地指出，hash冲突是这类设计中不容回避的问题，并以Unity的AssetBundle在冲突时直接放弃打包为例，说明了现有方案的缺陷。作者随后提出了一种简单有效的“加盐二次hash”方案：在打包时若发现hash冲突，便引入一个可确定的salt值重新计算，从而在运行时能唯一区分原文件，且强调了正确加盐（如将salt作为hash seed或循环XOR）的重要性，避免了简单拼接导致的二次冲突。 此外，文章还涵盖了资源包间的引用需依赖间接索引而非单纯hash值，以及patch更新可设计为保留完整索引的增量包、并定期生成基准全量包的策略。最后，作者将打包工具类比为git，需要实现初始化、文件追踪、版本打包与diff生成等版本管理功能。整体方案兼顾了理论基础与工程落地，对处理游戏资源管理的复杂性提供了清晰的思路。
说说 XcodeGhost 这个事
这篇文章围绕曾经引起广泛关注的“XcodeGhost”事件展开。作者并非单纯复述事件经过，而是从一个技术观察者的视角，深入剖析了这场安全风波背后的技术逻辑与行业生态。 文章指出，被植入木马的Xcode确实导致了大量国产App被污染，但其实际危害程度需要理性评估。作者核心观点在于，iOS系统自身的安全设计（例如iCloud密码的高优先级保护、沙盒机制）构筑了多道防线，有效限制了恶意代码所能造成的最坏后果。他详细解释了为何直接窃取iCloud密码极其困难，并指出了用户可识别的钓鱼特征，如对话框反常地要求输入完整的Apple ID。 更重要的是，作者将此事与国内开发者普遍集成不明第三方SDK的风气进行了对比，认为后者对App信任链的破坏远超XcodeGhost。他借此批评了行业安全意识的薄弱，并呼吁用户（尤其是国产安卓用户）加强基本防护，如开启二步验证、谨慎对待系统弹窗。文章最后回归到技术本质，强调了操作系统层面安全机制的关键作用，为读者提供了在恐慌情绪之外更为冷静和深入的安全思考。
对象到数字 ID 的映射
这篇讲的是如何用一个高效的数据结构，为对象分配并管理短生命周期的数字 ID。 在像 skynet 这样的并行系统中，直接使用 C 指针来标识服务对象是危险的，容易引发悬垂指针、误释放等问题。因此，通常会用数字 ID 来间接引用。作者提出了一个具体的需求：既要快速映射，又希望尽量不复用已释放的 ID（避免误用），这与操作系统常见的文件句柄复用策略不同。 为了满足这个需求，核心方案是设计一张专门的哈希表。每次分配新 ID 时，在上次值的基础上递增，并检查哈希表中对应位置是否冲突，若冲突则继续递增。这保证了 key 永不冲突，让查询速度最快，且实现相对简洁。 更进一步，作者将这部分实现从 skynet 中抽离出来，做成了一个独立的开源库。文章详细介绍了其提供的 5 个 API（创建、销毁、分配、抓取、释放），并重点说明了为实现线程安全而采用的读写锁策略：对表的修改加写锁，而对 ID 的抓取和释放操作则加读锁，允许并发。这份实现还适配了 Windows 的原子操作。 整体上，这是一个解决特定工程问题的精巧数据结构，其实现思路（如不复用 ID 的哈希策略、引用计数与读写锁结合）对需要管理对象生命周期的系统设计很有参考价值。
为什么 skynet 提供的包协议只用 2 个字节表示包长度
这篇讲的是 skynet 框架中一个经典设计决策：为什么它的 netpack 库坚持使用 2 字节（最大 64KB）来表示 TCP 数据包长度，而不是更“灵活”的 4 字节。 作者从游戏客户端网络通信的实际场景出发，解释了这并非简单的技术限制，而是一种有意的引导。核心原因在于，在单个 TCP 连接中允许过大的数据包（比如 100KB）是一个糟糕的设计。这会在弱网环境下长时间阻塞整个通信信道，连带心跳包等需要及时响应的小数据包也被延迟，严重影响实时性。更进一步，4 字节的长度头还存在被恶意攻击耗尽服务器内存的安全风险。 因此，作者主张正确的做法不是放宽包长度限制，而是在“长度+内容”协议之上增加一层，将大数据块分片传输。这个设计看似“绕”，但它强制开发者去思考和解决数据传输的阻塞问题，最终能实现单个 TCP 连接承载多个逻辑信道的能力，比如区分高优先级的心跳/关键指令和低优先级的聊天信息或大文件分片。 所以，skynet 这个看似限制性的选择，其实是在用简洁的接口引导使用者构建更健壮、响应更及时的网络架构。
如何让玩家相信游戏是公平的
这篇文章从经典赌场骰子游戏的公平性争议出发，探讨了将游戏搬到线上后，如何用技术手段建立玩家信任。作者指出，许多争议源于游戏实现者的贪心而非规则缺陷，并由此引出一个关键问题：如何证明骰子结果在下注前就已确定，而非根据玩家行为动态调整？ 文章提出了一套基于MD5哈希的简易验证方案。核心思路是：系统在每局开始前，先生成三个包含随机骰子数字的字符串，计算并公开其MD5值；玩家下注后，系统再公布原文，玩家可自行校验MD5是否匹配。由于MD5的不可逆性，这能在逻辑上保证结果未被篡改。文中进一步探讨了MD5碰撞攻击的可行性，指出单区块碰撞的计算复杂度（约2^50次运算）远超普通设备能力，并建议通过链入上局数据来进一步增强安全性。 整体而言，文章用通俗的案例引出了一个实用的工程信任构建方案，说明即使是复杂的公平性问题，也能通过巧妙、透明的技术设计来赢得用户认可。
字体勾边渲染的简单方法
这篇讲的是游戏开发中字体勾边渲染的优化方案。作者从手游和端游的大量实际需求出发，希望能直接利用系统字体动态生成勾边，而避免耗时的离线预处理打包。文章先梳理了传统“多遍绘制”方法效率低，以及流行的SDF方法需要离线生成字模数据的局限，也提到了苹果平台API生成的带勾边字模信息存储困难——轮廓与字体主体信息混合，难以用单通道记录。 作者的核心创新在于，提出了一种巧妙的单通道编码方案来解决这个存储矛盾。他观察到，勾黑边后的白字，其alpha值小于1.0的像素必然都是纯黑色的。利用这一特性，他将alpha通道信息与灰度信息映射到同一个通道的不同数值区间：将alpha为1.0的像素的灰度值映射到0.5至1.0区间，而将alpha小于1.0部分的像素值映射到0至0.5区间。这样仅损失1bit精度，就在一张单通道贴图中完整保存了轮廓和填充信息。 最终还原时，通过一个极其简单的shader（Alpha := clamp(G * 2.0, 0, 1.0); Color := clamp((G-0.5) * 2.0, 0, 1.0)）即可从灰度图G中解码出原始的颜色与透明度。这个方案规避了双通道贴图的硬件兼容性问题，在保证渲染效果均匀平滑的同时，显著降低了实现复杂度和资源占用，为动态字体勾边提供了一个轻量级的实用解法。
回调还是消息队列
这篇文章从作者封装Hive socket库时遇到的一个具体问题切入：如何处理底层`poll` API产生的事件。直接注入回调函数虽然直接，但容易引发异常、重入等不可控问题，且会加剧C/Lua边界的性能负担。 作者提出的方案是将事件及数据一次性返回给Lua层处理。为优化此方案可能带来的GC压力，他采用了一个预先传入的消息队列（一个空的Lua table）作为接收结构。在C层，通过高效的`rawseti`操作将消息逐条写入这个结构，并巧妙地利用一个缓存池来复用存储每条消息参数的小table，从而在系统稳定后避免了临时构建大型Lua表。 文章最后，作者还附上了一段极简的Lua消息队列实现代码，展示了其优雅的实现思路。整体而言，文章分享了一个从具体问题出发，在性能与可控性间权衡并最终优化实现的技术决策过程。
Objective-C 的对象模型
作者从自己的C++开发经验出发，对Objective-C的对象模型进行了梳理和对比。文章指出，Objective-C的消息传递语法（如`[obj message:param]`）比C++的函数调用更强调可读性，参数名称与方法名融为一体，减少了参数写错或遗漏的风险。 在类与对象的设计上，两者差异显著。Objective-C通过`@property`简化实现，并支持运行时动态绑定，使用`id`类型可以向任何对象发送消息。而C++的RTTI则更偏向静态的类型识别。作者特别提到了Objective-C独有的Category机制，它允许在不改变类内存布局的前提下，将方法拆分到不同模块中，这比C++的友元（friend）机制使用起来更为优雅。此外，协议（`@protocol`）类似于接口，但支持`@optional`方法，提供了更灵活的契约检查。 文章认为，Objective-C在基础库整合和语言扩展方式（利用`@`符号）上比C++更为简洁一致，其动态模型带来的灵活性，如今已能通过先进的编译技术弥补性能损耗。整体来看，Objective-C牺牲了部分静态确定性，换来了运行时的动态能力，试图在性能与灵活性之间找到独特平衡点。
模糊逻辑在 AI 中的应用
这篇文章从作者阅读游戏编程书籍中有关模糊逻辑的章节出发，用了一个生动的例子来阐释：在游戏中，一个NPC决定是否追击玩家，可能同时受到“距离出生点远近”和“自身血量多少”等多个条件的约束。传统的精确逻辑设置一个硬性阈值（如超过40米就放弃），会导致在边界点上决策发生突变，不够智能和平滑。 作者随即引出模糊逻辑如何解决这一问题。它不再使用非此即彼的分界，而是将“远近”、“血量多少”这样的输入，通过定义“近、中等、远”等模糊集合进行软化。然后，基于一组人类经验式的模糊规则（例如“如果距离远且血量少，就非常不想追击”），经过模糊推理和最后的去模糊化计算，能输出一个确定的、但连续平滑的决策倾向值。 文章进一步指出，当决策条件增多、规则发生组合爆炸时，可以使用Combs方法将复合规则拆解为一维的独立规则来简化设计。虽然可能导致少量矛盾，但实践证明其结果与完整规则组合非常接近。整体上，这篇文章通过一个具体的游戏AI场景，将模糊逻辑从概念到实现的关键步骤进行了清晰拆解，说明了它如何让AI的决策行为更接近人类的柔性判断。
内存异常排查
这是一篇典型的故障排查与技术思考文章。作者参与排查一个C++程序的崩溃问题：一个包含百余个对象指针的vector，在对象析构时发现第95个指针异常，偏移了1-3字节，导致程序崩溃。 文章的核心在于作者层层递进的推断逻辑。从对象声明为const、仅读取的特性，排除了人为改写和常见的内存越界写入可能。指针地址非对齐（变为奇数）且仅此一处异常，让作者将怀疑重点转向了更隐蔽的“悬空指针”问题。他推断，可能是某个已被引用计数机制正确析构释放的对象，其内存被新对象复用后，残留的旧指针在析构链中被意外调用，其减引用操作误将后来对象的数据当作计数值进行递减，最终导致了这起离奇的崩溃。 作者最终给出的排查建议也极具针对性：为所有涉及引用计数的操作（包括标准库智能指针）添加断言，确保引用值在合理范围内，以防悬空指针的二次破坏。文章结尾，作者还延伸吐槽了C++生态中项目对高性能内存分配器的强依赖，并反思了语言“信任程序员”背后可能引致的工程混乱问题。
房租分配问题
这篇讲的是合租时如何公平分摊房租。作者从常见的“大家商量一下”的中式做法说起，认为往往碍于面子不够彻底。接着引出一个两人合租的精巧方案：双方各自秘密写下对主卧、次卧的心理价格，总额必须等于总房租。然后公开报价，价高者得到对应房间，但实际支付的租金却是双方报价的平均值。这样每个人最终都住进了自己认可的房间，且支付价格低于预期。 作者的核心观察是，这个方案的经济学原理在于，让双方都觉得最终结果对自己有利。基于这个基础，他进一步思考，如何将这个看似只适用于两人的方案推广到三人甚至更多人合租的场景。 他提出的三人方案是：三人各自写下想住的房间和出价。根据选择情况分类处理：若三人竞价同一房间，则出价最低者退出，转入后续两人分配；若两人竞争，则价高者按两人均价入住；若三人各选不同房间，则先去掉最低报价，将剩余两人的出价总和推算出对第三人房间的“集体估值”，再与第三人的报价取平均值，以此确定该房间租金。剩下的两人再按经典方案分配。 文章还讨论了当所有人的报价总和低于总房租时，系统仍会执行，这使得报价最低者可能支付更高比例的费用。作者认为这是合理的，因为选择低价本身就意味着承担相应风险，恶意压价伤害的是自己。
Pixel light 中的场景管理
这篇文章从Pixel Light引擎的源码出发，聚焦其场景管理模块的设计。作者指出，Pixel Light将场景元素（如Mesh、Light）设计为场景节点的继承类而非附加组件，这意味着所有实际渲染对象都位于叶节点，而容器节点仅用于组织和查询。 其场景管理的核心精巧之处在于“场景查询”机制。为实现高效的空间剔除与交互，引擎为每个容器引入独立的“场景层级”（如K-D树），并通过SQ系列查询类（如视锥剔除）遍历并激活可见节点。这与直觉相反——容器内的对象不强调严格的空间从属关系（例如摄像机与角色位于同一容器），而是通过“场景节点修改器”来动态建立关联，如使用SNMAnchor实现摄像机跟随或武器绑定。这种设计解耦了组织结构与行为逻辑，依赖简洁的事件机制驱动，避免了复杂的循环引用。 总体来看，Pixel Light的场景管理架构清晰地区分了静态空间组织与动态行为控制，其模块化与解耦的思路为理解3D引擎设计提供了有价值的参考。
一个 Lua 内存泄露检查工具
这篇讲的是作者团队遇到服务器内存一夜暴增8G的紧急情况，通过快速自制的Lua内存快照工具定位泄露的故事。 问题出在一张地图的Lua State中，有对象持续生成却未释放引用。作者懒得搜索现有工具，自己用半天时间写了一个名为“snapshot”的开源库。它的巧妙之处在于：不对整个Lua State序列化，而是只记录table、thread等复杂对象间的引用关系，并且用C直接调用API遍历，避免了用Lua实现时“观察即改变”的干扰。 核心方法是对比两个时间点的快照，新增的内存和其引用链一目了然。工具返回的虽然是一堆指针和字符串，但足够定位到具体是哪行代码的哪个变量导致了泄露，比如示例中清晰地指向了dump.lua第7行的tmp和S1变量。 这个临时工具已经成功帮他们快速锁定了故障点，展示了在紧急问题下“轮子虽小但能快速解决问题”的实用主义思路。
一个登陆认证系统
从代理项目《狂刃》的登录认证需求出发，作者描述了一个在时间压力下临时设计的简化认证协议。该协议基于HTTP，旨在为非Web应用在不安全信道上建立认证流程。核心设计包含游戏服务器（G）、认证平台（E）和客户端（C）三方交互：G生成一次性盐值（salt），C用用户密码对盐值进行加密签名后发送给E验证；E验证通过后，用相同算法生成发给G的认证令牌，最终由C转发给G完成双向确认。这种设计让G和E无需保持通信，只需预共享密码，降低了服务器状态管理的复杂度。 文章的重点落在实际部署中的一次“拍脑袋”引发的事故。合作方在未通知的情况下，使用作者用Lua快速编写的调试用认证服务器，对600人进行了压力测试。初期认证大面积失败，排查发现根因在于服务器的网络配置：该服务器配有电信和网通双线IP，而作者最初将服务绑定地址（bind address）默认设为127.0.0.1，合作方在部署时仅将其改为了服务器的其中一个IP，导致部分客户端无法连接。最终将绑定地址改为0.0.0.0才解决了问题。这个意外插曲揭示了一个常见陷阱：内部开发用的快速工具一旦被外部环境直接使用，其默认配置或简化实现可能成为隐形炸弹，即使核心逻辑（如作者后续补上的并发处理）经受住了压力，但外围配置的疏漏同样会导致生产事故。
星际争霸2编辑器的初接触
这篇讲的是团队如何用星际争霸2的编辑器来解决怪物AI配置的老问题。传统做法是策划写需求文档，再交给程序去改代码，流程长还容易出错。作者接手这个模块后，发现编辑器自带的触发器系统其实是个现成的解决方案——它支持用“如果-那么”的逻辑来定义行为，并且所有参数都能在界面里直接修改。 通过搭建一套基于触发器的AI框架，策划可以直接在编辑器里调整怪物的巡逻路线、攻击逻辑和技能释放条件，改完就能实时看到效果，不用再走提需求、等排期、测版本的漫长循环。这相当于把原本硬编码在程序里的行为“翻译”成了策划能看懂、能操作的数据配置。 这种做法的核心是把编辑器从单纯的关卡工具，变成了支持数据驱动的AI开发平台。虽然最初只是为了解决沟通效率问题，但最终让团队获得了快速迭代AI设计的能力——策划可以当场尝试不同的行为组合，测试反馈的周期从几天缩短到了几分钟。对于同样受困于工具链割裂的团队来说，这种“用现有工具挖掘隐藏功能”的思路，或许比从头自研一套编辑器更有实操参考价值。
位置同步策略
这篇文章记录了一位技术团队成员在团队扩张期的真实工作状态与思考。作者正面临一个常见的挑战：当新同事陆续加入，团队需要进入协作磨合阶段时，个人的技术节奏该如何调整？ 他没有选择继续深入某个技术细节，而是将重心转向了维护已有模块，以及将之前的代码成果清晰地交接给新同事。这背后是一种务实的协作优先策略：在人力尚未齐备、团队需要建立共同认知的阶段，保证现有系统的稳定运行和知识的顺利传递，比个人攻克一个新问题更具价值。 作者的选择揭示了技术工作中一个常被忽视的维度：个人的技术产出需要与团队的实时节奏相协同。他为我们提供了一个视角——在项目或团队的成长期，适时从“个人沉浸模式”切换到“团队支持模式”，本身就是一种重要的技术判断力。这对于同样面临团队协作与个人技术成长平衡的读者，或许能带来一些具体的启发。
AOI 服务的设计与实现
这篇讲的是团队如何将一个 AOI（自动光学检测）服务从规划落到实现。作者从一次例会后的实际工作计划切入，点明了 AOI 模块开发的起点。 文章核心围绕“如何设计并实现一个可用的 AOI 服务”展开。它没有停留在概念，而是深入到了方案选型的思考：比如，面对具体的检测需求，应该选择何种图像处理与算法模型？系统架构上如何分层，以确保服务的稳定性、可维护性以及未来扩展性？作者分享了在平衡检测精度、实时性与计算成本时的关键决策，这些细节让设计过程显得非常真实。 在实现层面，文章提到了将设计落地为代码时遇到的具体挑战与解决方案。比如，如何处理来自产线的高并发图像数据流，如何设计模块以适配不同的硬件设备。这些内容使得整个设计不只是纸上蓝图，而是一个经过工程化考量的完整故事。 从规划到落地，这篇文章提供了一个工业视觉服务从 0 到 1 的实践参考，对有类似系统建设需求的团队来说，其中的技术权衡和实现路径值得借鉴。