我一开始根本没打算研究什么“弹一弹”这种小游戏。我一个搞了这么多年开发的老家伙，觉得这玩意儿就是给刚入门的新手练手用的。
1. 怎么就非得做这个“弹一弹”了？
我那侄子，上周末来我家玩。他抱着个平板，玩一个贼简单的碰撞游戏，就是用手指拨动屏幕上的小球，让它在屏幕里头弹来弹去，躲避障碍物。他玩得入迷了，非要拉着我给他讲。我当时正在旁边吹牛，说这玩意儿技术含量低得要命，我分分钟就能给他搞一个出来。
牛皮吹出去了，面子得兜住。等他妈带着他去睡觉了，我立马坐下来，心里合计，这个“弹”的物理过程到底是怎么实现的？不能只停留在嘴上。
我决定，这回实践必须用最简单的方式。不扯什么复杂的引擎，就用最基础的HTML5加Canvas来搞，直接开撸，看看到底要多久能跑起来。
2. 撸起袖子，我到底先干了什么？
我第一步就是把“场地”给搭起来。搞了个Canvas，设置了固定的宽高，比如800x600。这就是我的世界。
第二步，定义我的主角——那个小球。它不光有位置（x, y），还得有速度（vx, vy）。我随便给它初始化了一个中间位置，然后速度随便给了一点，比如(vx=3, vy=5)。
最关键的第三步就开始了，得让它动起来。这个得靠一个循环函数，不断地更新位置然后重绘。我设置了一个定时器（或者叫requestAnimationFrame），在每次刷新的时候：
- 把速度加到位置上：x = x + vx; y = y + vy;
- 然后把旧的球擦掉，在新的位置上再画一遍。
看着那个小球终于动了，我心里还挺得意。但是很快，小球跑出边界，没了。这可不行，得让它“弹”回来。
3. 核心步骤：让它弹回去，我掉进的坑
弹回来的逻辑，就是碰撞检测。我一开始想得太简单了。
我判断了一下：如果x大于屏幕宽度了，就让vx方向反转，乘以-1。如果x小于0了，也反转。
我跑了一下，发现球刚碰到边界，就有点“颤抖”，感觉像是卡住了，然后才反弹。我盯着代码看了半天，才发现我犯了个极度低级的错误！
我忘了考虑球的半径了！
我一直是用球的中心点(x, y)来判断是否越界的。但球是个圆形！当球心撞到边界时，一半的球体已经跑出去了。正确的判断应该是：
- 当球心X + 半径 >= 边界宽度时，才反转。
- 当球心X - 半径 <= 0 时，才反转。
改了这两行代码，球立刻丝滑了，一碰到墙壁，立刻以完美的角度弹回来。解决这个问题我浪费了半个小时，但这就是实践的乐趣，小细节搞不明白，全局都是错的。
4. 搞定收工，让它真能“弹”
解决了基础的物理循环，剩下的就是怎么实现“弹一弹”里那个“弹”的动作了。
原版游戏通常是用户用手一拨，小球获得一个瞬时加速度。我用鼠标模拟这个过程：
我设置了一个“拖拽”逻辑：鼠标按下，记录一个起始点；鼠标松开，记录一个结束点。这两个点的距离和方向，就是我要给小球的额外速度向量。
比如，如果我从左往右快速拖动，系统就计算出一个正向的大的VX和小的VY，直接加到小球当前的速度上。
这回我没自己从头写那个复杂的向量计算，直接参考了一个开源库里关于鼠标拖拽转化为向量的代码块。毕竟目的不是炫技，而是快速实现功能。
我花了大概两个多小时，把这个基础的“弹一弹”游戏功能完成了。第二天早上，我给侄子演示了一下，虽然界面简陋，就一个黑框框里一个红球，但他玩得可开心了。他说：“叔叔你真厉害！” 这比什么专业术语都有用。
这回实践告诉我，越是基础的东西，比如基础的物理循环和碰撞边界处理，越不能偷懒，必须自己手动敲一遍，才能发现自己以前偷懒跳过的那些小坑。