Sign in to follow this  

Object Oriented Programming

This topic is 4747 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Ok, i have a problem when it comes to application design, and specifically OOP. I know all about classes, polymorphism etc etc etc, its more of a conceptual problem i have in my head when designing. Example:
GameState
{
  -- Render()
  -- Update()
  -- KeyHandler()
  -- Activate()
  -- Deactivate()
}

MainMenu : public GameState
GamePlay : public GameState
etc

Utils (Singleton)
{
  -- m_ActiveState
  -- ChangeState(GameState newState)
}

CApp
{
  -- gsMainMenu = new MainMenu
  -- gsGamePlay = new GamePlay

  go -> Utils.ChangeState(gsMainMenu)
}


This allows you to run Utils.m_ActiveState.Render() each frame for rendering. When the game wants to change from MainMenu to Gameplay, it just calls Utils.ChangeState, and passes the GamePlay object as the new *active* state. Ah ha... but here is the problem. How do i get a function in MainMenu (say the result from a Keyboard input etc) to change the state to GamePlay? Because 'inside' the MainMenu object, the 'GamePlay' object doesn't exist. How do i get the two to communicate? I thought of some ideas: * Message Pump (is this the best i can do?!!?) * Registering each object with an object handler in Utils, and passing a string instead of an object to Utils.ChangeState() and getting it to keep a table of strings and their objects? * Making a whole load of 'global functions' bleh! * Having ALL the game logic contained within CApp - but that ain't OOP right? I hope you understand what i mean, if not, i'll post some more explanation. Cheers Synex Code Monkey [/source]

Share this post


Link to post
Share on other sites
I prefer message queues as they provide a great deal of flexibility. I usually create a message hub, and each component in application can subscribe to certain events with the type of message they want receive along with a call back function. This allows easier component swaps, as none of your components need to know about each other. All they do is generate messages and anyone interested in those messages can perform actions necessary. There is always some overhead with messages queues, but I think the flexibility and compartamentalism they provide is easy to maintain.

Share this post


Link to post
Share on other sites
This sort of thing troubles me too. It's great to do in Java because to have the current state continue you can just "return this".

But in C++ it can get messy because of pointer ownership and exception handling-related stuff. I've tried the following, but because I'm so fussy I'm not 100% happy with any of them:

1. Pass a smart pointer into the state for it to use in "return this".

2. Return null instead of this to indicate no change of state.

3. Use enums instead of pointers.

Hope this helps, or at least gives more options...

Pete

Share this post


Link to post
Share on other sites
Why not keep a protected list of pointers/references to each created state (they would register in their constructors)? That way you would have access to a pointer/reference to other states from the active state. In fact, if you take this a step further this would obviate the need for the Utils class as you could manage all game state creation/maintenance from with the base class which seems even more OO to me: why have an outside utility class do the work when it could just as easily be done from within the class (heirarchy).

Share this post


Link to post
Share on other sites

This topic is 4747 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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

Sign in to follow this