Basic concept of game design?

[nottrulyevil]

Hi, I'm about to write my first game with SFML (I've used plenty c++ before) and I have a few question about how a game is ought to be designed.

I'm thinking of creating a game with a few different "modes/states" you can be in (eg. main menu, character creation,  battle mode, map, dialog, options), so, at least to start with, you can't move your character around freely.

How is this best archived with SFML? Can I create some sort of layers with the different modes which can be activated, deactivated?  Does all code that changes something on the program window have to be in the main "while (window.isOpen()){}", or can separate functions (that's not inside that loop) change the graphics/get events? Or can I somehow make a function that only handles the graphical output and is separated from the "main" where I gather input etc? 

I'd be very grateful if someone could help me out with this, thanks in advance!

[Ixrec]

There is an SFML Game Development book, which everyone says is very good, so you might try that.  I'm pretty sure it has at least one approach to handling finite states like that.

At the high level you're asking about, there's only two common approaches I'm used to seeing: 1) everything is done in the main while loop, or 2) all event handling is done in the main while loop, and rendering is done in a separate thread.  I would start with 1 because it's guaranteed to be simpler and easier.  Threads aren't for the faint of heart.

For states specifically, it's probably okay to just have a current_state enum declared in main(), and a switch block in your while loop that calls mainMenu(event, current_state) or gameplay(event, current_state) or whatever depending on the current state.  I wouldn't worry too much about it.

If you're also asking about whether events can be processed or graphics changed in functions outside main: I believe it's yes for both, but the pollEvent() call should only appear in the top-level while() or things could get very weird.  Manipulating graphical objects is absolutely fine anywhere except global scope.

[nottrulyevil]

Okay I'll try that out then. Oh and thanks for the fast response   

[eXpl0it3r]

If you need a basic example of game states you could look at my SmallGameEngine. It's just one way of implementing things.

If you don't want to buy the Game Dev SFML book (although you should ), then you could at least take a look at the source code ob Laurent's GitHub account.

You might think about in more details what the difference is between a game state and a game mode and see if they need different implementations.

[nottrulyevil]

Hi again, I'm wondering how make so the mission, dialogs etc can be managed without a couple of hundreds /thousands if-statements in the main while-loop. Like how can avoid to have tons of ifs for every scenario? Doing it like that might work if I have 10 mission or so, but when I come over 50 missions it will be really really hard keep it like that.

Oh and I'm thinking of making a class for both the character/mobs and one for items. How are they best stored when the game is closed? In a txt file that's read at launch? And can object from the character class have "child object" from the item class?

[Ixrec]

Well it's true that you definitely shouldn't be doing if(mission1) all the way up in main().  The simplest way to organize that is probably to make a Level class storing the map and enemy placements and whatnot and you pass it an integer in the constructor, then have a current_level variable in main() where you simply call its draw() method or something.  But how you handle everything else will affect whether this is a good idea.

I'm not sure what you mean by "child object", it almost sounds like you aren't sure how C++ inheritance works and need to go learn more about that.  Depending on what you're trying to ask, I think the answer is "probably."

Classes for mobs and items seem fine.  For storage, or "serialization", the simple answer is you have to invent a format for them, then give each one a method to output themselves as strings (possibly operator>>) and a constructor to recreate themselves from those strings.  There are also more advanced solutions out there like boost serialization.

If you want a lot of high-level guidance like this, you're probably better off reading the SFML book.  I'm sure it has examples of possible approaches to all of these things.

[eXpl0it3r]

The point is to use abstraction. You don't have object1 and object2 and object3 and ..., but instead you abstract things in a way, that lets you reuse operations for multiple things. So for entities, you'd could have an entity class and then derive different types from that base class. That way you don't have to care whether it's a robot enemy or another monster, they are all entities and behave kind of the same. The keyword for that example would be: polymorphism.

Abstraction is one thing, another one is to structure classes and functions properly. Functions should be kept small - mostly less than 100lines - and classes should follow one purpose and should not be responsible for all kind of things. The keyword here would be: Code design.

For starters you shouldn't be trying to implement a game with missions and items and x and y, but instead start small. A good way to get the feeling of writing games, is to take a classic game and writing a clone of it (Pong, Tetris, Breakout, etc.). These games have a simple logic and thus let you concentrate on writing the mechanics of the game rather than spending weeks on some complex logic.

[StormWingDelta]

If you need a basic example of game states you could look at my SmallGameEngine. It's just one way of implementing things.

If you don't want to buy the Game Dev SFML book (although you should ), then you could at least take a look at the source code ob Laurent's GitHub account.

You might think about in more details what the difference is between a game state and a game mode and see if they need different implementations.

Looks like fun to try and change that thing into C#.    I'm going to see if I can just for fun.   Also I've been hunting for a basic SFML setup for a game engine for a while and just forgot who made what ones and where they were.