Just thinking in advance. I've got my simple game operational, granted without any safe guards for the moment. Eventually I'm going to want to allow for an entry screen and/or setup screen for player names.

My question, when implementing screens like instruction screens or game setup screens do you run that through a separate loop? I envision a main loop with the gameplay loop called from that loop. When the game was over or player quits, you would return to the main loop responsible for the opening screen?

Is that a common approach or a problematic approach? Thanks

You can create another variable, game_state.

Some options:

You can make separate functions that handle events for certain game states or have one function, but it gets confusing.

I don't know how well you are at reading code, but I have a simple tictactoe game. It has game state. There is an opening screen with a menu. You can escape during gameplay back to the menu and the menu changes (from new game to continue game).

I kept it to one function for the logic, but multiple functions for drawing the screen depending on game state.

Link here

In the game there are numerous game states.

    enum class GameState
    {
      Undefined,
      Initializing,
      TitleScreen,
      HelpScreen,
      AboutScreen,
      Shuttingdown,
      PlayerXTurn,
      PlayerOTurn,
      PlayerXWin,
      PlayerOWin,
      Tie
    };

most of the logic is triggered by mouse or key up. It gets messy. I only show you to show the mess.

This is easily handled with a little inheritance and a screen pointer. Have a base Scene class with a few virtual functions to override like so :

For instance, here is my Scene class for the latest game I am working on :

It lays the framework to derive new classes of scene. One for each screen you want to have, because each will have different inputs, handle events differently, and draw different things. That's what the virtual functions are for.

Damn Edgar that makes we want to start making a new game!

{"name":"giphy.gif","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/3\/4351345c99eba961790182ff75abacf7.gif","w":332,"h":168,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/4\/3\/4351345c99eba961790182ff75abacf7"}

Thanks for the input all.

I'm not very familiar with virtual functions Edgar but sounds like I need to learn.

Daniel, I'm assuming all of this runs within the same while loop?

I was looking over my last game using A4, It didn't work with events but I think the concept will work the same. Previously I used main to call all other functions. IE Title screen. Instruction screen, Playing screen. Outside of calling inits and declaring arrays/variables, main was less than 20 lines of code. I used while loops to keep the game running with in the different functions but stopped for readkeys. I think that will be the major difference.

Again I appreciate the input.

Polymorphism

Each subclass inherits everything from the base class. Then you can have one Base class variable. Each subclass can have it's own logic, drawing, event handling.

TitleScreen* title = new TitleScreen();
MenuScreen* menu = new MenuScreen();
Base* base = nullptr;

Depending which game state you are in, you assign base to that subclass.

base = (Base*)title;
base->draw();

Then switch if game state switches.

base = (Base*)menu;
base->draw();

Virtual tells the compiler to use the function of the child class if there is one. Otherwise use the function of the base class. The functions of the subclass is optional.

You can force it by declaring your virtual function like this

class Base
{
public:
    Base();
    virtual ~Base();
    virtual void draw() = 0;
};

Not each child class is required to have it's own draw function.

https://cplusplus.com/doc/tutorial/classes/

The virtual keyword is just a signal to the compiler and base classes that they may override the behavior of this function. If it is a pure absolute function (virtual and ends with )=0; ) then it must be implemented in the derived class before it can be instantiated.

I'll have to read up on it some more. I'm familiar with base classes and inheritance from the stand point that I've read up on them. I've even done a few exercises. My limited used of classes isn't much different than structs. Well other than private and public. As such I typically use structs. I guess it's time to graduate on.

It has it's uses. Don't for get protected keyword also.

Here is my dialog class, which is a subclass of a widget. It's abstract, meaning you can't create a Dialog.

My starting dialog. I don't use most of the events in this class. I left them in there, but commented them out.

Java's one listener class for every event is total over-engineering. In my opinion so is having an OnEvent method for every event type. It's simple enough to let a widget or a dialog or a screen or an object to handle a single event and modify it's behavior based on the type.

In your opinion, you can keep to yourself.

In any case, talking with you guys lets me know how much I really don't know .
I appreciate the input.

Wouldn't want to offend anyone with my opinion.