我干了这行十年了，每天把鼠标往屏幕上一放，心里就咯噔一下。大量人看我写代码，认定那是写死，把一堆死板的文字和逻辑粘在一起，硬生生塞进一个网页里。
实际上不然，这玩意儿真没那么玄乎。我写的每一个游戏，底层逻辑跟写银行转账、写个小程序没区别。无非就是给个 Canvas 要么 DOM，然后写个循环，再搞点碰撞检测，最终加点动画。
听起来好办？你懂吗？就是这好办的三件事：把东西放那儿，算算它们碰不碰，碰了搓一个特效。 我常跟新人擦边球，说别总想着写那种啥架构、啥时序图、啥设计模式。
那是给项目经理看的，不是给你写脚本看。你只需求关切那一刻形成了啥，比如按钮点下去了，是不是把那个精灵（sprite）给推进了一个位置，然后给个分数，那个球是不是弹开了。过程不关键，结局才是王道。
哪怕我写个贪吃蛇，根本不用管它的内存管理，也不用管它如何启动，只要它吃到了食物，分数加一，屏幕抖动一下，这就够了。 说到数据，我可没整那些虚头巴脑的。我在做一款消消游戏时，前几行代码里就硬塞了一堆数字。
比如那个计分板，不写死也没关系，我改成个动态数组，每次玩家消了一个，就把数字加到数组里，然后 setInterval 每隔一秒刷新 HTML 上的 DOM。
这样就算服务器挂了，回调函数跑一遍，那分数也是准的。
要么有个排行榜，我不用数据库，直接用本地 JSON 存个数组，按工夫倒序排个序，拿个 JS 插件做个好办的统计，后台跑分，前端显示。
这种处理方式，在目前的低配设备上跑得飞快，也省得折腾复杂的 RPC 接口。 有时候遇到急事，我也得让代码活起来。
比如我想做个 RPG 里的自动攻击，新手可能都质疑程序是不是疯了，不是吧？实际上挺好办，就是写个定时器，每十帧触发一次，然后获取那团怪物的坐标，再算出它离我卡在哪，然后给个弹幕特效，提示一下“中招了”。至于攻击逻辑里有没有啥底层的状态机，要么有没有啥复杂的路径规划，只要它动起来就行。别老钻牛角尖，我这行里最忌讳的就是把好办的东西想得忒复杂。 记得前些年那个做网页抽奖的客户端，我折腾了三天，最终发现纯前端得用个 Web Worker 跑个后台的随机数生成器，不然浏览器卡得跟死机似的。
那时候我就想起那会儿写老版游戏时用 JS Math.random() 直接算概率，别看目前不中，但那时候就想，既然能随机，那就让它在后台跑一遍，前端只管输出结局。
这种“把脏活累活外包”的思路，在目前看别看有点土，但在当年可是救场神器。 也真该说说那些笨办法。
比如我写个迷宫，不用 A 算法，那就用深度优先搜索。从起点出发，步步为营，走到尽头为止。
这玩意儿效率不高，好办死循环，但在做那种做不出来要么忒复杂的东西的时候，有时候反而好用。
比如处理那种乱七八糟的像素点，要么处理一种特别怪异的、不符合常理的逻辑，这时候写一套严谨的算法，反而会把整个程序搞崩了。
不如直接用递归，递归，再递归，看着吓人，实际上就几步。 还有文档的难题。
那会儿老手写一份长长的技术文档，把架构讲了一遍又一遍，结局新人看了都晕，最终那个需求改了，文档也顾不上改。
后来我学着做轻量级，直接写个好办的 README 要么一个在线的 Playground，连个变量、一个函数、一个逻辑，直接演示出来。新人只要打开浏览器，点点鼠标，看个过程，就懂了。
这比写一堆注释强多了。 我也见过有些项目，为了追求完美，想把所有的逻辑都写在 JS 文件里，每行注释都要写得忒像小说台词似的。结局出来的感觉，像是个刚入门的小学生写的集合，别看能跑，但不想让它再动。我劝你一句，别把做游戏当写文章，别拿代码去当作文，也别拿逻辑去当哲学。游戏是死的，人是活的，数据流是流动的，但逻辑本身，这东西是抽象的，也是具体的。 最终，我想跟大伙说句心里话。写 H5 游戏，确实不需求啥宏大的叙事。
有时候一个bounce effect，一个粒子爆炸，就连一个怪的 glitch，都能成为玩家记忆里最深刻的那一帧。别总想着“我要做一个史诗级的战斗系统”，有时候你只需求让那个敌人略微快那么一点点，要么位置略微偏移那么一毫米，那种惊喜感，才是玩家能感受到的。 故此，别再跟我讲啥 K 线、啥曲线、啥回归了。
那些不过是不同领域的通用语言。你只需求知道：给个位置，算个距离，加个分数，配个动画，提交。就如此好办。行了，该休息了，代码都堆在硬盘里呼呼转，我得去喝口水了。