How should I include SFML code in my craps game?

[Raptor88]

As previously mentioned, I'm using the "Manage different screens in a game" engine for my craps game.  Screen_0 is my PrimaryMenu.h/cpp files.  Screen_1 is my RTPlay.h/cpp files.  (RTPlay = RealTimePLay which displays the crap table).

Now I'm coding the RTPlay and my design follows:

// Note:  payBets = pay winning bets, collect losing bets.

    while (Running)
    {
        while (COMEOUT_ROLL)
        {
            // getBetsComeout();
            // rollDice();
            // payBetsComeout();
                // Pay bets.
                // If point, set POINT_ROLL, else loop in COMEOUT_ROLL.
        }

        while (POINT_ROLL)
        {
            // getBetsPoint();
            // rollDice();
            // payBetsPoint();
                // if 7, clear all bets and set COMEOUT_ROLL.
                // if made point, pay bets and set COMEOUT_ROLL.
                // else, loop in POINT_ROLL.
        }
    }

My question is, how can I retain the craps table screen with all bets when moving between different classes?

For instance, in the "while(COMEOUT_ROLL)" loop, I first go to the "getBetsComeout()" function.  Here the user clicks different bet areas on the crap table and makes bets.  I assume this will be a complete SFML loop within this class.

Then I go to the "rollDice()" class.  Here an animation of dice rolling across the table occurs.  I assume this will be a complete SFML loop within this class.

Then I go to the "payBetsComeout()" class.  Here winning bets are paid, losing bets are collected.  I assume this will be a complete SFML loop within this class.

So how can I retain the chip sprites on the crap table when I go to the rollDice class.  And then when I go to the payBetsComeout class?  I'll also have to retain the chip sprites when I go to the "while (POINT_ROLL)" loop.

How would you do this?

Thanks,
Raptor

[eXpl0it3r]

At the moment rollDice() is a function not a class...

I wouldn't manage it the way you suggested at all.
For me there would just be one class that holds the game logic. The class has mainly two functions, one for updating/game logic and one for rendering/drawing. It's also the class itself that holds the sprite/texture for the table. Now one can have different classes for the game play. There could be a player class that simulates things for player(s), or a dice class that holds a random number generator, etc...
The update function and draw function get called from the screen/state manager and one handles the whole game logic in the update function, and then draws the sprites/players/coins/etc. in the draw function.

[Raptor88]

At the moment rollDice() is a function not a class...

Yes, all of the functions (methods) I listed will be in their respective classes.  I showed them as function calls in comments just to show the logic.

I wouldn't manage it the way you suggested at all.
For me there would just be one class that holds the game logic. The class has mainly two functions, one for updating/game logic and one for rendering/drawing. It's also the class itself that holds the sprite/texture for the table. Now one can have different classes for the game play. There could be a player class that simulates things for player(s), or a dice class that holds a random number generator, etc...
The update function and draw function get called from the screen/state manager and one handles the whole game logic in the update function, and then draws the sprites/players/coins/etc. in the draw function.

What you described seems to be the typical method I've seen in some C++/SFML sample programs that I've found.  I was hoping to make the basic game flow as simple as possible, similar to what I posted.  Each function call would compartmentalize the different processes.

I'll play around with some code to see if I can do it the way I posted.  If not, then I'll go the more conventional route.

Thanks,
Raptor