杂谈

2023-04-04

不懂为啥现在的游戏公司都把精力放在提高画面建模上面，而不是提高游戏性?答：就像网红餐厅, 先不管好不好吃，至少拍出来的照要好看，才能勾引你去呀。货物可能不是很好，但包装要够上档次，这样收礼人就不会认为是差东西。好看->细节到位->制作精良->好东西，虽然这个过程不是绝对成立。在你还未去了解该游戏更多的内容前，你对它的第一观感（即美术效果），再加前面的惯性联想，省去你去判断这是不是个好游戏，成功吸引你的注意。

2022-10-22

主程应是布道者

• 以初学者的角度思考问题，回归本源，返璞归真
• 不要过分指责复杂任务的错误。因为任谁去做都大概率出现问题
• 分散工作量，集中式决策

返工是对项目的极大损害

• 项目开过程应该避免任务返工。
• 量化可推进项目进度的内容。

2022-10-01 发觉很多人在讨论同步算法时，及及讨论坐标的同步上，而忽略核心玩法同步，或者说坐标同步仅是同步算法一部分

同步是为了展现效果的一致，而核心战斗玩法就是要表现的效果。优秀的同步算法就是解决核心战斗的业务问题。那么任何影响坐标和角度的行为都应被考虑进同步算法。比如技能会击飞目标，要如何表达击飞过程？按照同步位置和角度可以解决一切问题的思路，击飞过程同步坐标和角度就好要·

在编程领域里，研究算法时，必定同时讨论数据结构。对应到同步算法中，会是坐标、角度和各式各样的玩法数据。理论任何增加在核心玩法的内容，都可能会影响数据结构&算法。

2022-08-27

网络重连后是否需要数据包重发？有此疑问是因为，看到同事非常坚持认为非战斗系统要在网络不稳定时支持数据包重发，甚至拿出例证说腾讯某某游戏也是这么做。分析了我们的游戏项目的实际情况后，非战斗游戏系统不存在让数据包重发的条件，完成可以通过其它方法做到腾讯某某游戏重连的表现。比如1. 要求有数据包返回才加载界面 2. 重连成功后，重载当前场景，场景本身的业务逻辑会触发新一次数据请求。 数据包重发，实际就是不断地向服务端发包，潜在着对服务端的安全问题。另外，重发数据包无法解决一个非技术难题。一个合理的现象是，当玩家遇到反馈延时，极可能再次/多次点击。这个反馈延时其中就有可能网络不稳定，导致数据包回包慢导致。问题的严重性在于，如果这个点击是一个是消耗类操作！！！重发数据包，意味着再次请求消耗！！！而玩家的期望其实只想1次。。。所以这种情况下，是否重发数据，可能需要做过滤或交由业务自己解决。

2021-12-03

多年前呆过的一个项目，其版本开发总是延期，抛开中途需求变更、开发流程/管理不完善、老板强势介入或不可抗力等原因，仅从技术开发自身角度考虑未能如期交付的原因包括：1.过于自信报的工期很短 2.随意评估工期 3.开发中发有现技术难点 4.以为工期有空余，工作慢慢做 5.接手他人代码做的需求，改之前可能需要先熟悉需求/代码 6.没有看清楚文档，漏了要做的功能 6.没能察觉需求出有坑！需求描述不够充分/仅口头描述，但实际暗藏着额外工作量。 归结起来就是没有理清楚需求就写代码。行业一个解决办法写【设计文档】，但管理者认为它不是（也不可能是）应用程序里要展现的内容，做的话反而拉长了版本开发时间。执行者认为这是一个额外工作内容，变相压缩了开发工期，被迫加班赶进度。 我是主张将【设计文档】纳入开发流程，并给予额外的工期。【设计文档】不仅仅是画画流程图，它的意义为了驱动执行者理清/提问需求、思考代码流程/数据结构、结合自己的技术熟练程度评估工期。它是执行者与管理者之间的“开发契约”，管理者可以观察是否严重夸大工期，执行者可以拒绝超出“契约”外的需求。

• 需求工作量一次给太大，评估的工期也会很长。容易给执行者“时间很多”的错觉，导致前期慢慢做，后期赶成狗！
• 需求的各要点工期不宜太紧凑，否则工作节奏会很压迫，一旦中途出现意义就必然延期了。所以适当将评估工期比实际大那么一点来应对开发风险。但夸大了的工期会在“开发契约”被发现。

2021-12-02

选择哪个开发节奏？1.边写代码边调试，2.写完所有代码再调试。【方式1】的缺点是频繁切换调试端与代码编辑器，调试端每次都可能都要耗时去启动-加载，而大多数情况只是为了解决当前可见的一个问题，效率比太低。【方式2】是1次切换，尽可能多的发现问题。放在最后调试，难道就不怕，当代码写错要重新设计工期却不足了？这是有前提的，接到需求不要急于写代码，先做需求分析，尽可能穷尽所有问题，提出疑问，此时大概能思索出代码的框架，基本可以保证不会有大错，出现重新设计的概率极低。然而也有使用【方式1】的情况，就是工作量很大，预估要几周才能完成，开始只对问题作了关键点分析，没有展开细节，所以会先写完大部分关键点代码用简单数据模拟调试，之后每填充完一定量的细节代码就进行局部调试。另外按工作经验来看，需求越复杂预估工期与实际浮动越大，万一工期预估少了！边写边调的方式下，在早期完成关键点后，还能有机会重新审视工期。

2021-12-01

最近在想，编程技术成长过程，什么是重要的能力？1.把玩工具/插件？如折腾插件将编辑弄得那么“独一无二”，我觉得无所谓，弄得表面上看得那么的科技感，不见得个人很有技术含量。除非你的领域是写插件/工具/开发流程辅助。想了解领域的最新工具，毫不费力地去讨论/技术群看一眼就够了，基本都是“月经”内容。2.收集各种技术资源/文章/代码？对内容/方案最好要有自己的看法。3.热衷业务框架/设计模式？解决问题不应该先想着要套用哪个设计模式，这个思维（技术驱动需求）彻底的错。正确地是理清需求需求需求TMD还是需求！！只要解决好当前问题，并抽象了其中有相同规则的需求。最终不知不觉可能就是某个设计模式。 总结来说，个人认为： 1.资源检索。当考虑问题时，能快速地知道在哪里能找到提示。所以平时就应该要有技术积累。比如笔记、哪本书、哪个网站讨论/发贴、或者知道哪个网友/同事做过等 2.技术知识。技术的广度/深度，影响着解决方案的技术落地，技术越好落地方案就越好。这也是为什么在应用开发中，做操作系统与业务之间业务框架工作的技术人员，一定要具备扎实的技术知识，否则肯定做不好。 3.问题分析&解决。这是跟技术知识无关的思维方式。日常开发就是一个很好的提升思维能力的训练机会。不要先急于写代码，学会需求分析，理清需求/提出疑问/流程顺序/需求关系/冲突点/代码结构. 4.团队沟通/技术共识。工程开发不是单打独斗，个人冲动行为，可能将导致团队陷入被动。1.务必让与你任务有交集的人员完全了解对接内容。2. 修改别人的代码，必先与对方沟通，再动手修改。3.当修改框架代码，务必先做好设计/收集建议再作修改。4.日常多关心下同事的开发内容。5.组织日/周例会，纠正使用规范/收集问题等等。

2020-5-6

技术积累要回归起点。举两个曾经的疑问，1.常用内存字节长度有1、2、4和8，为什么跳过3、5、6和7？2. 为什有引用类型的语言不能/不建议操作地址？被外行问过，1.写完代不是就能运行了吗，为什么还要编译？

这些都是小问题大学问。激发/思考/回归这类问题，当然自己可以去翻书，但更高的回归效率应该是回答外行/新手“来自最原始的疑问”。还有就是行内多技术交流。

如果是想研究技术，就不要厌烦外行/新手的问题，不要担心因为回答不上问题而感到羞耻/或暴露了不能外见的私密似的/或爱面子怕被怼。

我一向认为技术交流，就像学术辩论一样，讨论的话题只有技术，末了的积极态度是赞赏和倾慕！

2020-2-18

Lua是用C实现的，可以说它先天就拥有操作系统级别的性能优势（当然最终要看Lua的实现效率），我甚至怀疑这种性能优势是Lua被广泛用于游戏开发的一个重要原因。Lua是我目前使用过最易用的编程语言，可能是考虑跨平台运行（ANSI C）的原因，它内置没有高级API，比如没有多线程、Socket api等。我特别喜欢Lua的安全模式(或称沙盒模式，pcall和xpcall)，有别于大多语言的异常捕捉，pcall(xpcall)通过返回错误码和定义错误处理函数的做法，令代码更加优雅。

Lua的简单易用，也必定让它走向另一个极端。变量赋值不需要类型一致（赋值只是让变量指向另一个lua对象），所以除非有清晰的定义规范和充分的注释，否则阅读代码时层层追溯一个lua对象的定义简直就是恶梦。跨平台的原因，Lua精简内置的功能，提供的接口很少，所以很多问题需要开发者自己解决，比如不要惊讶你的项目居然还要为lua封装一系列字符串操作接口。Lua用8字节来统一表示整数和浮点，你无法像其它编程语那样，为了精打细算内存去定义一个2字节整形或者4字节浮点数。一个“不适当”的赋值，Lua在你毫不知情下，暗暗地将table从线性转成哈希结构（或者哈希转线性结结构），这一方面无法确切地掌控内存，令程序容易踩入性能问题。

2019-12-10

C/C++不应该有垃圾回收。只要C/C++还是操作系统的主要实现语言，C/C++就不会有内置垃圾回收机制。这是近日看了《垃圾回收的算法与实现》前几章后有感。书中没谈该到观点。只是明白了书中要表达到的意思后，回想起常有人抱怨C/C++没有垃圾回收，固有此想。

看了前面几章，主要介绍了几个GC算法：位图标记，复制gc，引用计数和分代gc。尽管这么多算法，但每种算法都解决同一个问题，对象什么时候被释放才是效率最大。因为频繁使用的对象就算没被引用，在空间和性能允许的条件下也应该被继续保留，而不是立即清除。保留多久的问题上就是各个GC实现细节差异。引用计数认为当计数小于等于0时就要释放对象，而分代认为最后创建的对象会被优先考虑GC。而算法在性能和空间的微小取舍上派生子版本。如标记GC算法，扩展出了复制标记和压缩标记算法。

各个垃圾回收算法各有特点，不存在一个通吃所有情况的GC算法。 C/C++的一大特性是“靠近”操作系统，为了更好性能，操作系统的核心部分是用C/C++和汇编语言写的，这里不是业务层，无法知首具体要处理的问题，如果是C/C++语言的设计者，使用哪个作为内置GC算法？答案是不解决这个问题。由业务层框架解决垃圾回收算法问题，根据使用场景特性选择适当的回收方案。

恐怕C/C++的完美之一是没有垃圾回收！

2019-12-8

个人认为单例模式是经常被玩坏了的设计模式。常看到业务框架中出现一大坨单例，究竟是需要单例还是用全局对象呢？频繁地敲打字符“GetInstance()”令我感到厌倦。回顾一下单例模式的需求特性：1. 类型不能实例化多次，否则内部会产生逻辑冲突。2.业务范围内不能获取到实例。然而我所遇到过大多数的单例都不满足条件1，可以很轻松实例化多次。而条件2是大家都喜欢使用它的原因，全局访问特性，能快速将功能“拼凑起来”。但它代价是放弃了进一步思考框架的解耦和内聚性。大多数情况下，我个人偏向用全局对象来替代单例，如果app是程序入口的全局对象，app.audio则是声音控制的管理对象。

2019-10-21

开源代码的功能要简洁。或者说刚好满足需求就好。功能越丰富，框架设计会考虑更多、更复杂、代码量更大。当增删改代码时，最终额外增加与需求不相关的人力成本。

原文:
https://lizijie.github.io/2019/10/21/%E6%9D%82%E8%B0%88.html
作者github:
https://github.com/lizijie