As3 OOP 游戏结构（类架构）答案

【问题标题】：As3 OOP game structure (class architecture)As3 OOP 游戏结构（类架构）
【发布时间】：2010-12-01 22:39:31
【问题描述】：

游戏说明：具有不同级别和每个级别的不同类型的视觉问题的测验。
到目前为止的 OOP：GameBoard（回答问题的地方）、Dialog、HighScore、Controller/LevelController？

我有一个名为 Controller 的文档类用于初始化游戏：

public function Controller() 
{
    initGame();
}    

function initGame() 
{
    xmlGameData = levels, questions xml
    highscore:HighScore = new HighScore();
    startGame();
}

function startGame() 
{
    levelController = new LevelController( this, xmlGameData );
}

然后我开始将“文档类/主时间线”的引用传递给我的不同对象，这些对象本身扩展了 MovieClip 或 Sprite。

public function LevelController(docClass, xml)
{
   mainTimeLine = docClass;
   xmlGameData = xml;

   loadGameBoard(); 
   nextLevel();
} 

function loadGameBoard()
{
   gameBoard = new GameBoard(mainTimeLine, this);
   mainTimeLine.addChild(gameBoard);
}

一段时间后，这变得非常混乱，我想知道更好的方法来控制不同的对象（如 GameBoard 和 HighScore）和状态（级别）和动作（AnswerQuestion、NextQuestion 等），也许是一个控制点。

【问题讨论】：

标签： flash actionscript-3 oop architecture

【解决方案1】：

Fire Crow 的想法是正确的。您要做的是将游戏中的哪些变化与游戏本身分开。因此，您的 Controller 对象将包含适用于所有关卡的游戏功能，例如分数、显示精灵、GUI 信息以及引用当前关卡的关卡数组。您的游戏由一系列关卡组成，因此它们自然应该由关卡对象表示。每个级别都知道如何绘制自己并处理来自玩家的输入。关卡对象可以在完成时通知Controller，然后Controller可以在数组中显示下一个关卡。

【讨论】：

【解决方案2】：

我是这样做的。

由于这是 Flash，我让我的游戏对设计师友好。这意味着我每帧实例化对象。我知道人们会否决我，但我知道很多设计师为此感谢我（他们在搞砸图形时不必修改任何代码）。

基本上，让每个可见对象（可以“蒙皮”）子类化一个 MovieClip。让它通过自定义事件与它通常所在的位置进行通信 - 例如“板”（也是一个电影剪辑）。

这是一个简单的单词搜索游戏的code example，它将帮助您更好地理解我在说什么。

【讨论】：

嘿。我无法打开 .fla（猜它是 CS4），所以我无法完全判断。在我看来，这是开发面向设计的游戏的一种非常务实和有效的方式。 OTOH，我认为这种方法不太适合大型/可扩展游戏，需要大量代码，而图形实际上只是资产。我看到的最大问题是，很大程度上取决于 .fla 中的内容，这是一种专有的二进制格式。不适合工具、版本控制、测试等。

【解决方案3】：

我为控制我的游戏的“UI”和“支持”功能（屏幕流、分数提交、关卡提升）所做的工作是将一系列静态函数放在一个主游戏控制器类中，该控制器处理显示/隐藏游戏屏幕的所有逻辑，通过 levelData 数组推进迭代器并处理从一个中心位置提交的所有服务器端。

它基本上是一个具有一系列静态函数的类，例如：

public static function LoadUserData() {}
public static function SaveUserData() {}
public static function PlayNextLevel() {}
public static function SubmitScore() {}
public static function ShowLevelPlayScreen() {}
public static function ShowLevelPauseScreen() {}
public static function ShowGameOverScreen() {}

等等……

这些控制器永远只有一个，因此封装在静态函数中就可以了，使其易于从代码中的任何位置访问，并且在语法上调用起来比将其放入 Singleton 中更简洁。

【讨论】：

这是一个经常犯的错误。没有冒犯，但是当谈到 OOP 时，这种方法违反了它的每一个原则。这是一篇关于这个主题的好帖子：tinyurl.com/256wxd。除此之外，请随意谷歌“单身人士是邪恶的”。并且使用类作为全局对象更糟糕，因为单例至少允许通过多态性进行重用。
back2dos - 我不同意那篇文章的一些观点。作为程序员，我们应该始终努力先做最简单的事情。如果某些东西可能永远不会被使用，为什么还要过度设计、创建接口、工厂等。
@back2dos
@JStriedl - 取决于客户。这可能是一个简单的 Flash 游戏，但随后客户想要更改，额外的功能。如果您的架构一开始就很差，那么您可以稍后在赛道上开枪打死自己。我不是设计模式的粉丝，但根据我的经验，坚持一些基本的 OOP 原则对我来说是必须的。同样在这种情况下，静态函数使调试变得更加困难，因为它们可以从任何地方调用。
@Allan - 当然。我并不是要暗示这一点，因为我使用了最简单的解决方案，即我的代码是草率的。我在项目之间重复使用大量自定义编写的类，并使应该可配置的项目......可配置。核心引擎是一个很好的候选者，可以包含一个简单的静态实用程序函数集合，因为在开发过程中它不太可能需要大幅改变用途，只要您的前期设计至少大部分都符合要求。

【解决方案4】：

嗯...我假设您的问题是 “有什么比我这里的管理游戏更好的结构？” 虽然没有明确说明这就是我会尝试回答的问题

我不认为多态性是您所做工作的最佳解决方案。 OOP 不仅仅是一系列对象。它将功能分组为有用的对象。

我建议将更多功能移到控制器中

1.) a main object with all the following functionality that will be present 
    throuhout the game
    a.) go to level (next/previous)
    b.) keep track of score
    c.) controll the state of the game
    d.) anything else that exists throughout the game

2.) level objects that handle level specific information
    a.) interactivity of the questions such as buttons etc.
    b.) managing the correct answer and the impact it has on the score in main

【讨论】：