As3 OOP game structure (class architecture)

Question

Game description: A quiz with different levels and different types of visual questions for each level.
OOP so far: GameBoard (where one answers questions), Dialog, HighScore, Controller/LevelController?

I have a document class called Controller which initializes the game:

public function Controller() 
{
    initGame();
}    

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

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

Then I'm starting to pass around a reference to the "Document class / main timeline" to my different object which in themselves extends MovieClip or Sprite.

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

   loadGameBoard(); 
   nextLevel();
} 

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

This gets pretty messy after some time and I'd like to know better ways of controlling the different objects (like GameBoard and HighScore) and states (Levels) and actions (AnswerQuestion, NextQuestion etc.) from, maybe, a single point of control.

Answer 1

umm... I'm assuming your question is "What is a better structure for managing a game than what I have here" Though that's not explicitly stated that's what I'll try to answer

I don't think polymorphism is the best solution for what your doing. OOP is more than just a series of objects. It's grouping the functionality into useful objects.

I would suggust moving more functionality into the Controller

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

Answer 2

What I've taken to doing for controlling the 'UI' and 'Support' functions of my games (screen flow, score submission, level advancement) is to place a series of static functions in a main game controller class that handles all the logic for showing/hiding game screens, advancing an iterator through a levelData array and handling all the server side submits from one central location.

It's basically a class with a series of static functions such as:

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() {}

etc...

There is only ever going to be one of these controllers, so packing in static functions does the trick, keeps it easy to access from anywhere in the code, and is syntactically cleaner to call than making it into a Singleton.

Answer 3

Here's how I do it.

Since this is Flash, I make my game designer friendly. That means I instantiate object per frame. I know people will downvote me, but I know a lot of designers who thanked me for this (They didn't have to modify any code while they screwed around with the graphics).

Basically, make every visible object (that can be 'skinned') subclass a MovieClip. Have it communicate through custom events, to where it would be usually at - such as the 'board' (which is also a MovieClip).

Here is a code example of a simple Word Search game that will help you better understand of what I am talking about.

Answer 4

Fire Crow has the right idea. What you want to do is to separate what changes in your game from the game itself. So your Controller object will contain game functionality that applies to all levels, such as the score, the display sprite, GUI info, and an array of levels with a reference to the current level. Your game consists of a series of levels, so they should naturally be represented by Level objects. Each level knows how to draw itself and handle inputs from the player. The level object can inform the Controller when it is complete, and the Controller can then display the next level in the array.