在我上学时，我的编程老师总是会告诉我们：“把你的代码当成可重用的库来思考。”我想你可以想象我在习惯这个原则之前，丢失了多少代码。我肯定每个人都有那一个常见的模板，你在不同的项目中经常重复使用。一个例子是时间跟踪。一个常数或参数来表示总时长，一个字段来跟踪已经过去的时间，一个if语句放在Update()中。当你看到它第100次的时候，你会停下来想：“我能不能停止重复这个？”我喜欢我的代码中的第二个原则是逻辑可读性。并且我在工作中思考这个问题的时间很多。它看起来在代码中更好，当你可以读取两个值之间的决策作为FlipCoin(true, false)而不是Random.Next(0, 1)。而且更好的地方是，当一个值类型本身告诉你它是一个概率，而不是仅仅是一个float。最近六个月，我一直在思考这些细节，工作在下一个版本的Vectro Blast上。它把我带回了这篇文章的开头。你不需要建立一个巨大的库来做所有的事情，最后什么都没做。但是这些看似无用的小块，却总是满足了代码中的清晰度的内心渴望。也许我自己太自责了，因为我写了所有我能写的东西。但是你有时不觉得，开源中缺少了这些小解决方案吗？通常只有解决了最大的问题的最终大解决方案。所以我写的解决方案很小，但我相信在某些地方它们是非常有用的。在与开源的关系上，我相信这个代码不仅会使我的工作更好，也会使他人的工作更容易或更好。最常见的问题，我说：“够了”，并且以更清晰的形式写了它们。无论是否有人会从这个仓库中受益，还是从中借鉴灵感，还是你只是想学习如何解决某些问题……那完全取决于你。我希望无论如何，文档不会让你失望，因为我尝试在这里解释包的基本原则。github.com/sagittaras/gamedev-kit你解决过的最小，但最有趣的问题是什么？