问适用于as3游戏和常规富媒体网站的依赖注入框架

EN

我使用RobotLegs做了一个游戏，它需要与几个不同的后端服务集成。一项服务为我提供了一个多玩家大堂区域，允许玩家相互挑战，一项服务在挑战后处理面对面的游戏，另一项服务允许玩家从他们的社交网络账户访问信息。

从一开始，我就像构建一个富互联网应用程序一样规划了游戏的架构。这个游戏本身是一个流行的基于回合的棋盘游戏的实现。思考如何运行本地游戏与网络游戏无疑帮助我保持了MVC框架开发游戏方法的轨道。有一大堆代码可以重用，解释本地玩家用鼠标点击和通过网络接收消息来指示远程玩家做了类似的事情之间的区别帮助我理解了根本不能与视图绑定的逻辑。我能够非常流畅地使用模型、命令和中介器，最后，当我将游戏代码交付给我的客户时，它使游戏的代码更易于维护和理解。

我认为大多数游戏都会有一个基本的模型来跟踪“棋盘”，无论是网格中的棋子还是太空中的敌舰和小行星。一旦您将模型视为独立于视图的实体，就更容易想象玩家如何通过鼠标和键盘交互来触发来自控制器的命令，从而对模型进行更改并将这些更改通知给视图。对于一些简单的游戏，这可能会有更多的工作要做。对于其他人，比如需要长期维护或需要多种输入法的人，它可以省去一些令人头疼的问题。

让我们考虑一下游戏中的不同视图。视图可以包括标题屏幕、设置/选项屏幕、多玩家大厅、高分/排行榜屏幕和主游戏本身(可能由许多较小的视图组成！)。许多这些视图可以有模型，如高分列表，各种设置(应该在选项屏幕和游戏视图之间共享)，等待游戏的玩家列表，以及游戏的当前状态等。顺便说一句，需要一种方法来保存游戏，以便玩家可以从他们离开的地方重新开始吗？当数据位于模型中而不是直接绑定到视图时，这样做要容易得多。

我认为，太多的Flash开发人员将游戏视为与富互联网应用程序截然不同的野兽。MVC框架可能适用于游戏，尤其适用于多玩家和您打算在较长时间内迭代以添加新内容和功能的游戏。最大的挑战是让自己记住这样一个事实，即在屏幕上跑来跑去的可爱的、毛绒绒的小动物只是数据的可视化，这些数据可能很容易使用DataGrid或图表以不同的方式显示。尽管用这种方式玩它们可能不是那么有趣！

RobotLegs是全新的，所以你很难找到很多在生产中使用过它的人。上周，他们终于从发布候选版本转移到了第一个稳定版本。然而，它是由一群非常受人尊敬的程序员创建的，如果你的项目是中长期的，你会看到在你的项目生命周期中RobotLegs的采用呈爆炸式增长。这将是所有酷孩子都在使用的！:)

(除了偶尔通过Twitter和整个博客圈与一些作者进行交流外，我没有其他利益。)

HTH

AS3目前不是我的事，但游戏框架是我的事。)所以，是的，也不是，MVC模式不是你的第一选择，因为你不需要创建太多的视图、控制器和模型。

你有一个更像接口的东西，一些处理游戏机制的通用“引擎”，以及一些数据库表。

我目前使用的是MVC的某些方面，但不是完整的模式--“仅仅是好处”。

编辑:你“不能说：”MVC不是设计用来在游戏(引擎)内部使用的，因为MVC模式只描述了一个逻辑，而不是一些预定义的东西，比如“代码总是要包含$x，并且必须以包含($y)开头”。它只是一种设计模式，并不直接影响代码的质量，而是影响游戏设计的进度和进行方式。