Elysian Shadows

Posted: **Sat Aug 18, 2012 1:17 pm**

Hi CC Ricers,

thank you very much for your post. I think this helped me a lot.

To be sure that I did understand it well

for example layer 0(basic) is main menu and game. credits and options in main menu are layer 1. Inventory and other screens are in game layer 1. And layer one can be changed depending on changes in layer 1. e.g. changed shield can give aura or something.

For better understanding I made a picture of it. Where BLACK layer 0 is game it self, GRAY is inv layer 1 - obvious :D and the WHITE one is HUD wich is with layer 0 but it is changing because of things ins layer 1(dameged by enemy) and 0(changed equip).

http://imageshack.us/photo/my-images/853/rpgh.jpg/

So did I understand it well?

If so, could you show some implementation? LIGHTLY :D Because it needs a lot fo code, it's enough to show only necessary parts.

- Tetriarch

Posted: **Tue Aug 21, 2012 10:00 am**

Tetriarch, that's a good way to start. The mock-up you made can be managed with a system like the one I described, with each part of the screen being its own self-contained "Screen" (in the term I use to define class) with its own logic. It helps keep your game code from spilling all over the place.

Keep in mind these layers of screens can overlap each other too. If you open up a settings menu screen and click on "Exit Game" it can trigger an event to load a small pop-up screen appearing in the middle of everything, that will say "Are you sure you want to exit?"

I don't have access to my code right now, but when I can I will give a stripped down version of the class that I'm using that I use other types of screens like menus, backgrounds and pop-ups to inherit from. I see you're using C++, but I'm using C# / XNA. I took advantage of its runtime features of being able to get object types and assign events and delegate (which are a form of generalized callback functions) in order to save time to make the screen management system work. These things are still possible in C++ and you don't need to use all those features, they just need some workarounds.

Code: Select all


// Handles all the screen's updates

class ScreenManager
{
private:
std::list<GameScreen> screens;

public:
ScreenManager() {}
~ScreenManager() {}

void AddScreen(GameScreen screen)
{
    screens.push_back(screen);
}

void RemoveScreen(GameScreen screen)
{
    screens.remove(screen);
}

void Update()
{
    // Iterate through all screens
    // If screen.IsExiting == false, handle input
    // update and draw the screen
}

// Base class for all your game screens

class GameScreen
{
private:
ScreenManager _screenManager;

public:
GameScreen(ScreenManager manager) : manager(_screenManager) {}
~GameScreen();

virtual void Load();

// Take input here. Screenmanager will not call this for disabled screens

virtual void handleInput(InputSystem input);

// Put your own logic in this method for the screen's derived class
// If all screens need common updates (like timers or debug stuff), use this base class

virtual void update(float timeStep);

virtual void draw(GraphicsSystem graphics);
}

This should be a good enough base to build a screen system on. I removed all the extra stuff like transitions, was originally gonna use them but they would add too much bloat to the example.

Some other things you might want to do is give screens the ability to become "disabled" or "sleep", meaning they won't take user input or updates (or maybe it will update but not take input), but still draw themselves. This is useful when you want to bring up an inventory screen and put your action screen out of focus, so your player doesn't move.

Posted: **Sun Aug 26, 2012 9:41 pm**

So, I am finally back

Haven't enough time, sorry.

CC Ricers: Thank you for your answer, I am already using most of that theory, well I do something by myself, well at least I need to get to the point of using it.

So far, I think these my problems are already solved. Thank you all for answers

Well, I am still looking for gamedev friend or for teacher, if anyone interested - please PM me.

- Tetriarch

Elysian Shadows

Few problems :)

Re: Few problems :)

Re: Few problems :)

[SOLVED] Few problems :)