Need opinion of this crap game.

[Raptor88]

The SFML skeleton in the tutorial samples has SFML window functions in the main loop with calls to user functions to do things.  The user functions update the window buffer and then return to the main loop which then displays the screen.

I would appreciate opinions from experienced SFML programmers about my proposed approach to coding my craps game.  Here's the game loop in skeleton form:

// CRAPS GAME

enum GameState (SPLASH, MAIN_MENU, COMEOUT_ROLL, POINT_ROLL, EXIT, QUIT);
GameState eGameState = SPLASH;

sf::RenderWindow App;

int main()
{
    App.create(sf::VideoMode(SCREEN_WIDTH, SCREEN_HEIGHT, 32), "CRAPS");

    while (App.isOpened())
    {
        switch (eGameState)
        {
            case SPLASH:
                Splash splashScreen;
                splashScreen.show(App);
                // Show splash screen.
                // Wait for user to click mouse or press a key.
                // Set eGameState = MAIN_MENU.
                break;
            case MAIN_MENU:
                MainMenu mainMenu;
                mainMenu.show(App)
                // Show main menu.  Wait for user to click desired action.  
                // Handle actions like "Setup", "Display Game History",
                // "Play Game", "Quit", etc.
                // If user clicked Quit button, set eGameState = QUIT.
                // If user clicked "Play Game" set eGameState = COMEOUT_ROLL.
                break;
            case COMEOUT_ROLL:
                ComeOut comeOut;
                comeOut.show (App);
                // Show crap table with all bets made (first time, table is clear).
                // Players make come-out bets, roll dice, pay come-out bets.
                // If diceSum = 2,3,7,11 or 12, loop in COMEOUT_ROLL.
                // else set diceSum as point and set eGameState = POINT_ROLL.
                break;
            case POINT_ROLL:
                Point point;
                point.show(App);
                // Show crap table with all bets made.
                // Players make point bets, roll dice, pay point bets.
                // If diceSum = not point or 7, loop in POINT_ROLL.
                // else set eGameState = COMEOUT_ROLL.
                break;
            case EXIT:
                // User pressed ESC key or clicked the EXIT button in any
                // of the GameStates.
                // Set eGameState = MAIN_MENU.
                break;
            case QUIT:
                // User clicked the QUIT button in the MAIN_MENU.
                App.close
                break;
            default:
                // Display "eGameState was invalid" messge.
                break;
        }  // --- end of switch ---
    } // --- end of while ---
    return 0;
}
 

My game only opens and closes the App window in the main loop.  I plan to pass App to each class and do the actual updating, drawing and display of the App window in each class.

But I'm thinking that this is a bad approach.  With so many different updating, drawing and display functions in each GameState, this approach would be a problem like when SFML changed from version 1.6 to 2.0.  If I had coded the program in ver 1.6, I would have to go into each GameState and change each SFML function for the upgrade to ver 2.0.

If make one "Screen" class which each GameState will use to display the screen, how do you recommend that I pass all of the data necessary to the Screen class that each GameState will have?  IOW, I would be passing sprites and their coordinates for all of the chips on the table, and anything else that I need to update on the crap table, to the "Screen" class.

Hope my point is clear enough to understand,
Raptor

[eigen]

The title was very misleading

I'm actually doing something similar with states in my game. It gets the job done and is pretty simple. However, I think you should combine different states related to the table into one and handle the different logics there. There's no need for a state for every action. SPLASH, MAIN_MENU and TABLE should be sufficient. Also, QUIT and EXIT make no sense because these aren't states. When you press Esc or an exit button in the main menu you should simply close the main loop or call a cleanup/close method of your main game object or whatever.

For drawing, why not implement a drawing class which would have a method like drawSpriteAtPosition(...). That would internally call the SFML methods needed but you only write it once. Should the API change, there's only one place you need to change it. States would stay untouched.

For sprites (and sounds) I would recommend a shared resource manager which each state could access.

[Raptor88]

The title was very misleading

Oh, sorry.  I'll try to think of a better title next time.  I updated the title to "Need opinion of this crap game skeleton" for now.

I'm actually doing something similar with states in my game. It gets the job done and is pretty simple. However, I think you should combine different states related to the table into one and handle the different logics there. There's no need for a state for every action. SPLASH, MAIN_MENU and TABLE should be sufficient. Also, QUIT and EXIT make no sense because these aren't states. When you press Esc or an exit button in the main menu you should simply close the main loop or call a cleanup/close method of your main game object or whatever.

I'll remove the EXIT and QUIT from the states.

For drawing, why not implement a drawing class which would have a method like drawSpriteAtPosition(...). That would internally call the SFML methods needed but you only write it once. Should the API change, there's only one place you need to change it. States would stay untouched.

For sprites (and sounds) I would recommend a shared resource manager which each state could access.

This is the part I'm not sure how to handle.  Looking for advice on how best to handle it.

1. How to insure that the SFML window remains in existence when I exit the class.  Just make everything static?
2. How to pass every sprite+coordinates to the class?  Use a structure?

Just looking for tips before I start coding so that I won't have to do several complete re-writes due to bad logic.  This is my first C++ program, though I have programmed in Basic and C like about 15-20 years ago.

Thanks,
Raptor