Handling game logic and such...

[Sivak]

Okay.  I've gotten my program to compile and I can see the 3 PNG files I made up for the title screen thus far.  It's laid out right, etc. etc.

The big problem though is how this is handled.  Using the tutorials, I have this variable:

Code: [Select]


sf::RenderWindow App(sf::VideoMode(640, 480, 32), "Shmuppy");  // the render window


...and it is global.  I don't know if this is bad or not, but it works.  The way I'm intending to do it is have App be used for drawing wherever...

Anyway though...  what I've basically done is made up 2 functions.  main and titleScreen.  I have a variable for the game state, which calls the respective function from main as well as one called navigateMode, which is like the "state within the game state".  This is the approach I've used for my ASM programs.

Anyway, the big problem I have is with the whole title screen.  It's basically doing state 0 all the time, which involves loading the 3 PNGs each frame, making them into sprites, and then drawing said sprites.  Obviously, it should NOT have to load these every frame, but I have no idea where to go from here which would involve loading these separately...

This is the program thus far:
http://pastebin.ca/1844303

I keep wanting to take the approach of having a lot of global variables, but I know that's not the C++ way.  

[Mindiell]

Maybe you can have a look on the wiki. I did this tutorial in order to be able to have menus and splashcreen without any questions about those ugly globals things

[Sivak]

Well, I've tried this, but it's not compiling.

I have 4 HPP files:  screen, screens, screen0, screen1.

screen contains the cScreen class and nothing else.
screens has verbatim what is in the tutorial

Right away, it says cScreen is redefined.  I don't know if this has something to do with the vector and the class?

Other errors include Screen base class undefined and vector conversion problems (though I'm sure these will go away after cScreen is figured out)

I'm using VC++ 2008 express and WinXP.  Thanks.

[Spidyy]

The big problem though is how this is handled. Using the tutorials, I have this variable:

Code:

sf::RenderWindow App(sf::VideoMode(640, 480, 32), "Shmuppy");  // the render window


...and it is global. I don't know if this is bad or not, but it works. The way I'm intending to do it is have App be used for drawing wherever...

I used a "linker" classe to access all my game systems.

The classe is simply a bunch of pointer to all my systems, with function to access thoses pointer.

I create my systems, in the main, bind them to the linker and then I access the system through the linker in my different objets classe.

The linker is the only global variable I declared, all the pointed objets are destroyed at the end of the main, so no real problems.

It's the best way I found to access my systems anywhere avoiding conflict and bugs with other SFML globals. =p

Code: [Select]

#ifndef SYSTEM_REFERENCE_H
#define SYSTEM_REFERENCE_H

class VideoSystem;
class PlayerPool;
class SoundSystem;
class ImageManager;
class ObjectManager;
class ClockPool;
class Settings;

#define SYSTEM SystemReference::system
#define WINDOW SYSTEM.GetVideo()
#define SOUND SYSTEM.GetSound()
#define PLAYERS SYSTEM.GetPlayers()
#define IMAGES SYSTEM.GetImage()
#define OBJECTS SYSTEM.GetObjectManager()
#define CLOCKS SYSTEM.GetClockPool()
#define SETTINGS SYSTEM.GetSettings()

class SystemReference
{

VideoSystem * video;
PlayerPool * players;
SoundSystem * sound;
ImageManager * image;
ObjectManager * object_manager;
ClockPool * clocks;
Settings * settings;

SystemReference();
public:
static SystemReference system;

// Accesseurs
VideoSystem & GetVideo();
PlayerPool & GetPlayers();
SoundSystem & GetSound();
ImageManager & GetImage();
ObjectManager & GetObjectManager();
ClockPool & GetClockPool();
Settings & GetSettings();

// Modificateurs de l'objet
void SetVideo(VideoSystem * video);
void SetPlayers(PlayerPool * players);
void SetSound(SoundSystem * sound);
void SetImage(ImageManager * image);
void SetObjectManager(ObjectManager * object_manager);
void SetClockPool(ClockPool * clocks);
void SetSettings(Settings * settings);
};

#endif

And in the main :

Code: [Select]

SystemReference SYSTEM;

int main()
{
ClockPool clock_pool(MasterClock::ClockCount, 1/60.f);
SYSTEM.SetClockPool(&clock_pool);

Settings settings("config.ini");
SYSTEM.SetSettings(&settings);
settings.Load();
settings.SetShowHitbox(false);

VideoSystem video(sf::VideoMode(800, 600, 32), "Eve Shooter", settings);
SYSTEM.SetVideo(&video);

SoundSystem sound(settings);
SYSTEM.SetSound(&sound);

ImageManager image;
SYSTEM.SetImage(&image);

ObjectManager object_manager;
SYSTEM.SetObjectManager(&object_manager);
object_manager.Load();

PlayerPool player_pool("control.ini");
SYSTEM.SetPlayers(&player_pool);

// All my game screens

// Game loop
} // objects are destroyed here


For the Screen, the solution of Mindiel is an excellent way to do. I use it but also combine it with my linker. =p

[model76]

Hello Sivak,

To solve this problem, object oriented programming is a great tool!

I used this system for my first couple of games:
http://gamedevgeek.com/tutorials/managing-game-states-in-c/

To understand it, you may need to read up on classes, inheritance, and polymorphism.

It is a nice enough system, and I am only changing away from it now, because there were some architectural details about it I didn't like so much.

Functions are good, but they will only get you so far, in terms of software architecture, and it sounds to me like you are starting to discover its limitations. Global variables and/or passing references around will get you a little further, but it will get start to get messy very, very quickly.
Object oriented programming can seem confusing and cumbersome at first, but once your projects start getting bigger, it will be worth it, many times over.