编程与软件工程higherorderfun.com
实现 2D 平台游戏指南
A guide to implementing 2D platformers
2015 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是一篇 2012 年的经典教程，系统讲解了实现 2D 平台跳跃游戏的几种主流方案：基于图块的、基于像素（位掩码）的、以及基于多边形/向量的碰撞检测，并深入讨论了移动平台、梯子、斜坡等常见难点的处理方式。作者还分享了角色手感方面的经验，比如跳跃等动作应立即响应、动画只做装饰。
为什么经久不衰：它把 2D 平台游戏的碰撞检测与手感设计讲得清晰透彻，十多年后仍是独立游戏开发者绕不开的入门参考。
HN 评论精选
向量式碰撞检测并不难，比像素方案更干净健壮，值得推荐
说没有物理引擎就很难正确实现基于多边形的碰撞检测，这有点不厚道。这类碰撞检测代码用不了一千行就能写完（如果全是 OBB 还会更少），加上圆弧甚至贝塞尔曲线支持也容易得多。我用过像素方案，但做过向量方案后不会再回头——它更干净、更健壮、更易扩展。碰撞和物理代码根本不该知道像素的存在，只有渲染器需要。当然这要求更强的数学背景，但也不会比做游戏其他部分要求高多少。
yoklov查看英文原文
It's fairly disingenuous to say that implementing polygon-based (the article calls it "vectorial") collision detection on platforms is "very difficult to implement properly" without a physics engine. The collision detection code for this can be done in probably less than a thousand lines (probably less if everything is OBBs). Adding support for arcs, and even bezier curves becomes much, much easier as well (for both, probably another thousand lines, at most). It is also easier to add support for continuous collision detection this way, should that be something you want (although this would increase the amount of code a fair amount). FWIW, I used to go the pixel-based route, but after having done it this way I'm not sure I would do it again. It ends up being much cleaner, more robust, and easier to extend. I'd go as far as to say that your collision detection and physics code shouldn't have any knowledge of pixels, only your renderer (and maybe the gameplay code, if you insist) should have an idea about these. I will say that it requires a stronger math background, however, but in all honesty, probably not that much stronger than is required to make the rest of a game.
推荐 Towerfall 开发者的补充方案：整数坐标 + 逐像素步进
《Towerfall》的开发者 Matt Thorson 也写过实现健壮平台物理的笔记：使用整数像素坐标（避免浮点误差累积），并且物理按每次一像素逐步推进（避免高速物体穿透环境）。
panic查看英文原文
Matt Thorson, the developer of Towerfall, also has some notes on implementing robust platformer physics: http://mattmakesgames.tumblr.com/post/127890619821/towerfall-physics. The overall idea is to use integer pixel coordinates (to avoid floating point error accumulation) and to step all physics by one pixel at a time (to avoid fast-moving objects passing through the environment).
用"平台引用+专用规则"处理移动平台，比像素检测更简单可靠
我们做移动平台时，用了文章里梯子的那条规则：站在平台上时忽略常规碰撞系统，改用一套专门规则。给实体加一个"在某个平台上"的标志并保存平台引用，碰撞检测发现下落穿过平台时截断下落并固定到平台上；平台也记录身上的实体，移动时同步更新它们，销毁时解除引用。效果很好，像素检测那套反而很麻烦。
deathanatos查看英文原文
> Before anything on the scene is stepped, determine whether the character is standing on a moving platform. This can be done by checking, for example, whether his center-bottom pixel is just one pixel above the surface of the platform. If it is, store a handle to the platform and its current position inside the character. I implemented a 2D platformer with moving platforms once; we solved this simply by using another rule in the article — the one for ladders: > when you’re in a ladder, you ignore most of the standard collision system, and replace it with a new set of rules. There was a special flag on the entity for "is on a platform" (and which platform, too); thus, you trivially knew if something was on the platform. During normal collision detection, if you found yourself falling through a platform, your fall was truncated, and you were affixed to the platform. (An entity's platform variable became, essentially, Some(a_ref_to_the_platform).) The affixing was two-way, IIRC: the platform knew about you, mainly s.t. when it moved, it could update linked entities. And if it was destroyed — which could happen — then it could unref itself from whatever was on it; really, one had a weakref to the other, but I was not that good a programmer then, so it was more manually implemented. It worked quite well. We tried the whole pixel business, but it was troublesome; the game engine itself needed to deal with characters falling >1px per game state step, so it already knew "you are falling into a platform" bit.
现代平台游戏手感标配：coyote time 和跳跃缓冲
到 2022 年，有些机制是让游戏手感好的必备项，虽然因游戏而异，但大多数游戏都会需要 coyote time（土狼时间）和跳跃缓冲。
henning查看英文原文
In 2022, there are mechanics people will want for your game to feel good. This will vary from game to game, but I think most games will want coyote time and jump buffering. https://twitter.com/maddythorson/status/1238338574220546049
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选