Sign in to follow this  
  • entries
    570
  • comments
    2427
  • views
    216028

Untitled

Sign in to follow this  
Mushu

46 views

  • Random Observation of the Day!
    Pickled herrings were invented in 1375.


Okay, so I'm still working (albeit slowly) on what I have tenatively dubbed "namespace mgf", another three-letter acronym for "Mini-Game Framework".

I've decided that I'm going to use some old code I wrote for a state stack to implement a stack of minigames. Essentially, this means that we'll have a common IGame interface which derives from the StateStack::IState interface which looks something like this -
class IState {
protected:
StateStack* m_parentStack;

public:
bool m_static;
bool m_active;

virtual void init() {};
virtual void pause() {};
virtual bool run(double) = 0;
virtual void resume() {};
virtual void shutdown() {};

void pop() {
this->m_active = false; }

IState() {
this->m_active = true; }
};

And I just noticed this is a much older revision than I originally thought - there is no implementation for "hollow" states (states which are pushed onto the stack and executed, but allow the state below them to run as well), which are useful for GUI rendering.

I'll code them in if I need to, but as we've offloaded all GUI-related stuff to a whole framework I think it should be fine.

Moving down the hierarchy, we have the IGame interface, which essentially adds in a couple of things - a list of pointer-to-players (if you remember, a player is essentially an attribute map) that are registered to it, and pointers to a static graphics adapter and GUI object.

Essentially the planned execution path for the completed system looks like this -
  1. Main game stack manager created. Graphics/Event adapters initialized. GUI interfaces initialized. Main game state loaded (probably a menu of some sort) and program enters main loop.
  2. Input from user is recieved by GUI (captured through the event adapter assigned to it) and is passed down to the Main game state (which has registered itself as a listener for button events, or whatever).
  3. The main game state loads the game selected, via m_parentStack->push(..).
  4. The state stack creates the new state and pushes it onto the stack. the main state's pause(..) method is called, and it unregisters its listeners and anything else that it doesn't need.
  5. The game state runs, possibly pushing more states on the stack, etc etc, and eventually pops itself.
  6. The main game state's is re-activated and its resume(..) is called. It begins cleanup, and pops itself off the stack.
  7. The state stack is now empty, and the main game loop is exited. The GUI interfaces are unloaded, and the graphics/event adapters shut down.
  8. The program then BSODs the system.


So yeah. I guess the only thing really left to implement is the Game State manager, which shouldn't be all that difficult. Then we can get down to the grub of writing mini-games [grin]
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now