请问游戏编程中的精灵（sprite）是什么意思呢？有什么作用呢？老外命名它的意图又是什么呢？ 第1页

看了现有的一些回答，都遗漏了一个重要方面：游戏发展早期，C甚至汇编当道；复杂的游戏逻辑（玩家操作、攻击技能、伤害判定、各种特殊的技能/状态逻辑，等等等等）想要有条不紊的管理起来、随时间流逝均匀可控的运作、同时又要尽量优化性能（比如其它答案谈到的“图形显示优化”）……

这难度，飞上天了吧？

因此，就有了“精灵”抽象：游戏里一切能感知时间流逝、具有坐标位置的，都是精灵。

你看，一下子抓住了两个根本：一、有坐标信息；二、能感知时间流逝。

一旦抓住这两个根本，事情就容易起来了。

我们可以设计一个定时器，周期性的调用和精灵绑定的处理函数（相当于C++的虚函数，接受的传入参数是interval）——实际上，这个处理函数是一个dispatcher，它负责转调用我们写的一切动画以及碰撞判定等逻辑的处理函数。

所有这些函数都要接受interval参数，比如让精灵按贝塞尔曲线运动的函数就是用interval乘以运行速率、然后改写精灵的坐标信息；同样的，动画呢，就是按照interval的节律缩放扭曲图片或者改变它的颜色（或者基于interval把一组图片换来换去，从而实现走路、放大招等效果）。

注意精灵是可以没有对应的图片的，比如我们要在进门处放个陷阱，那就是一个和门口坐标重叠的、不可见的“触发器trigger”，当碰撞检测发现游戏物体和这个“触发器精灵”坐标重合时，就会调用对应的trigger。

换句话说，这是用C甚至汇编实现的一个原始而精巧的继承体系；它的根是“精灵”这个基类，提供坐标这个公开数据成员和dispatcher时钟信息的接口；然后是“支持碰撞检测以及提供接受碰撞事件并加以处理的接口”的继承类，和“支持动画”的继承类以及其它各种继承类。

至于为什么叫“精灵”，大概是因为它只是能“感知”有位置，却未必有实体吧——在西方传说里，“精灵sprite”本来就是有魔力的、介于虚实之间的幻想角色，如火之精灵、光之精灵之类。

一旦有了这个抽象，那么无论声音还是图像，无论是软件还是硬件优化，就都要以精灵为中心了：负责游戏性循着精灵这条线更改角色位置、检测碰撞、触发相关处理逻辑；负责画面的也循着精灵这条线，更新屏幕显示、优化图形性能；负责声音的呢，同样循着精灵这条线，根据距离画面焦点的远近改变不同声源的声音大小、以及考虑是否应该添加滤波/回音等效果；负责剧情的同样可以把文字/过场动画/事件触发等绑到精灵上，设定触发条件即可，等等等等。

总之，每个人只关注自己需要关注的那个侧面，完全可以忽视其它东西的存在。这样不管游戏多么复杂、世界多么宏大，一切都可以井井有条的解决。

注意这个先后顺序：程序员设计的东西，肯定是以便利程序员自己为最优先。

先有了一个最合理最高效的架构，然后一切就可以基于这个架构提供方便。

就好像是计算机3D图形先把3D真实感图形渲染以面片为中心、然后硬件设计（显卡/GPU）才提供了迎合这个抽象的渲染体系；并不是硬件先弄出来面片，然后程序员们一阵焦头烂额手忙脚乱的往面片迁移……肯定不是这个过程，对吧。

换句话说，硬件支持可以证明一种做法的流行——流行到通过硬件管线直接支持——却几乎不可能是这种做法的来源（都出硬件支持了，可想而知这种设计在硬件出来之前有多流行）。

另一个，因为大多数人只负责自己那一块，很容易局限于“在我的领域，XX事是怎么怎么来的”。这大概就是高票二位大佬掐架的原因。

但游戏开发是个很复杂的工作，不可能迁就于某个单一方面。

比如在3D游戏逻辑开发里就没有“面片”，那是建模和渲染玩的，不会“侵染”游戏逻辑开发过程，对吧。

同样的，2D游戏开发，精灵是从软件架构来的；但这个架构在设计时，一定综合考虑了图像渲染、游戏逻辑等诸多方面，最终才决定“同时向图像组和游戏逻辑组开放sprite这个概念”——也只有站在总体架构的角度，sprite这个术语才是贴切的：如果是图像处理方单独决定的，那他们肯定不会叫它sprite。这个词和他们做的事（合成活动图片到背景）有半点关系吗？

当然，因为语言层面没有面向对象的支持，这个设计只能通过以强制类型变换为核心的各种奇技淫巧实现。

到了面向对象时代后，这套体系就沿用下来了；后来大概是为了区分吧，2D游戏仍然沿用精灵这个术语；而3D游戏就改名叫GameObject，不再使用“精灵”这个说法（但一切GameObject仍然有坐标有transform，哪怕它只是个计分牌、只关心屏幕坐标）。

正因此，当年C++等面向对象语言火爆时，游戏界反而不怎么感冒。因为这些都已经在C语言里面有了完美的解决体系，面向对象语言搞的那么一堆private啦继承啦之类约束反而会打破这个体系，把既有体系推倒重来、然后再把附着于既有体系的无数现有逻辑重写一遍，这实在太麻烦了。所以……C++，从游戏行业滚开！
嗯，当然，说“C++滚开”是开玩笑。
上古时代的确只能用C或者汇编写游戏；但后来渐渐转向C写引擎、然后通过内嵌的脚本引擎或协作其它语言写游戏逻辑这类解决方案，以便提高生产效率。那么这些协作语言完全可以用各种面向对象的新秀。
只是当时的游戏引擎被锁定到C了，推倒重来代价太大；而把和引擎配合、写游戏逻辑的语言改成C++，一个是不能像脚本那样简化和加速游戏开发任务（用脚本就图它简便，换成一辈子精通不了的C++不是找不痛快吗），一个是游戏逻辑这块并没有太高的性能需求。这等于说换C++一点好处没有，反而带来很多麻烦。因此在相当长一段时间里，最面向对象的游戏业反而普遍不用C++。
直到多年以后、基于C++开发的新游戏引擎/框架越来越成熟、越来越强大，游戏业这才慢慢抛弃C，转而拥抱C++以及其它面向对象语言。
但由于学习门槛高，C/C++系还是只用在引擎内部，游戏逻辑部分还是会选用其它语言。