Print

[King Tetiro]

King Tetiro

[C++] Rooms

Howdy folks! Im doing c++ in a unit and it's time to work on my end of academic year assignment already. I have most of it done in my head! Except a few things. The first thing of course is rooms!

In one of the high leveled criteria, we need to have multiple levels. Now I have a theory in mind though I want to know what you guys would do in my shoes?

For this example lets assume there are 3 levels.

• 

[Mamoruanime]

Mamoruanime

Re: [C++] Rooms

Create a gamestate manager that loads rooms from files? O.o?

I'm not entirely sure what you're getting at in terms of what you need to know Do you need to know how to make it load rooms in general or how to make rooms or what? Also I'm not even sure "Room" is going to be the appropriate term (GM always bugged me with that).

[Zaeranos]

Zaeranos

Re: [C++] Rooms

I think what he wants to know is how to load level data and than have the game manage the level data. Like how you move a character through a level and have the objects in view do their stuff.

[Mamoruanime]

Mamoruanime

Re: [C++] Rooms

That's probably a few too many areas of discussion to get into for one thread That's a pretty big scope of game design learning right there :s Between writing your own level designer/tilemap reader to designing a game state manager to designing your object classes and managers :s

[King Tetiro]

King Tetiro

Re: [C++] Rooms

Alright then lets start with this then.

-You load a level
-It places the player, the solids, the interactives, etc
-You play the level

Exclude any graphics for now.

• 

[Mamoruanime]

Mamoruanime

Re: [C++] Rooms

Well then to break that down:

-You load a level

Before you do this you need to create a class for tilemaps. This ignores objects since...

-It places the player, the solids, the interactives, etc

...you also need to create your actor classes for the players. Solids should be handled through the tilemap system (assuming you mean collisions), and then for...

-You play the level

you need to have a gamestate manager and states to support playing those levels.

[King Tetiro]

King Tetiro

Re: [C++] Rooms

Well then to break that down:

-You load a level

Before you do this you need to create a class for tilemaps. This ignores objects since...

-It places the player, the solids, the interactives, etc

...you also need to create your actor classes for the players. Solids should be handled through the tilemap system (assuming you mean collisions), and then for...

-You play the level

you need to have a gamestate manager and states to support playing those levels.

Okay let's look at the tilemaps first then

• 

[Mamoruanime]

Mamoruanime

Re: [C++] Rooms

Well; you can do those a few different ways.

You can either A) have the tilemap store image data (tiles) and collision data separately, or you can have a class for Tiles that holds image index values and collision values. I typically do the latter.

You construct tilemaps with either an array (or linked list; I prefer arrays for these) of indexes for images and collisions (the first option), or for the second option you have an array of Tile classes.

[King Tetiro]

King Tetiro

Re: [C++] Rooms

Well; you can do those a few different ways.

You can either A) have the tilemap store image data (tiles) and collision data separately, or you can have a class for Tiles that holds image index values and collision values. I typically do the latter.

You construct tilemaps with either an array (or linked list; I prefer arrays for these) of indexes for images and collisions (the first option), or for the second option you have an array of Tile classes.

That makes sense. Going to note this down.

Now onto this actor class for players etc.

• 

[Xiphirx]

Xiphirx

Re: [C++] Rooms

I just finished writing a gamestate class for a game I'm working on, I could help you out with that, although my code might be terrible

Have you learned inheritance? This will make a difference in the suggestions I make.

For The Swarm (StarCraft II Zerg strategy)

I whip my hair back n forth

• 

[King Tetiro]

King Tetiro

Re: [C++] Rooms

I just finished writing a gamestate class for a game I'm working on, I could help you out with that, although my code might be terrible

Have you learned inheritance? This will make a difference in the suggestions I make.

I know of inheritance. I will be using it for the interactive objects.

• 

[Xiphirx]

Xiphirx

Re: [C++] Rooms

Great! That makes things easier lol.

So, not sure if you want to adopt my method, but here is how I handled game states in an unannounced project of mine:

First, I created a base class called GameState like below

Code: [Select]

//GameState
#ifndef GAMESTATE_H
#define GAMESTATE_H
class GameState
{
public:
GameState(){};
~GameState(){delete _pGame};

virtual void update(float delta);
virtual void render();

virtual void create();
virtual void discard();

protected:
GameApp* _pGame; //This is specific to my game, not sure how yours works
};

#endif

Now that we have the base game state class down, you can start creating other states. In this example, I'll make a introState.

Code: [Select]

#ifndef INTROSTATE_H
#define INTROSTATE_H

#include "GameState.h"

class introState : public GameState
{
public:
introState();
~introState();

//These were inherited
virtual void update(float delta);
virtual void render();

virtual void create();
virtual void discard();
private:
int someVar;
};

#endif

For the implementation, (the code inside is specific to my game, you will want to change it. I'm giving you the general idea)

Code: [Select]

#include "introState.h"

introState::introState(GameApp * Game)
{
_pGame = Game;
this->create();
}

introState::~introState()
{
this->discard();
_pGame = NULL; //or delete _pGame
}

void introState::create()
{
someVar = 0;
}

void introState::discard()
{}

void introState::update(float delta)
{
someVar = someVar + delta;
}

void introState::render()
{
printf("%i", someVar);
}


Now that you have the two files, introstate.h and introstate.cpp done, you just need to use them.

So somewhere, you will include gamestate.h and introstate.h, along with the std library stack. You'll want to use a stack, as it serves the purpose of managing your states well.

so you would do something like the following

Code: [Select]

stack<GameState> gameStates;
intro = new introState(this); //this refers to the gameApp class in this example (specific code to my game)
mainMenu = new mainMenuState(this);
gameStates.push(intro); //This puts the intro state to the top

then in your update loop

Code: [Select]

gameStates.top()->update(delta);

and in your render loop

Code: [Select]

gameStates.top()->render();

You'll want to make some functions that handle the stack as well (accessors). Such things can be changeState, which will push a new state to the top, or you can do something like removeState, which pops the top state off, revealing the state under it. This allows you to have some pretty complex menus without the complexity, if that made sense

For The Swarm (StarCraft II Zerg strategy)

I whip my hair back n forth

• 

[TheDarkJay]

TheDarkJay

Re: [C++] Rooms

Just some "best practice comments":
Xiphirx, you need to make GameState have a virtual destructor. Any class which can be inherited needs a virtual destructor otherwise the order the destructors get called in can be messed up. And any call of to delete a base* will not call ~child(). Which can be very very bad.
Also if you aren't defining any implementations of "create()" etc. functions in the base GameState, those should be ended with = 0 e.g virtual void update(float delta) =0;

Also the usage of virtual in introState, if this is not intended to ever be inherited, is not required (as later comments show, it's a personal-preference decision here though).

[Zaeranos]

Zaeranos

Re: [C++] Rooms

Also the usage of virtual in introState, if this is not intended to ever be inherited, is not required.

It does not matter if you add virtual to those function declarations or not, because the parent already defines it as virtual. This means that overloaded functions in the child are implicitly virtual. It is not required that virtual has to be added, but everything that I have been taught about C++ says that for readability it is good practice to add it.

[TheDarkJay]

TheDarkJay

Re: [C++] Rooms

Personally I find it pretty unclear either way, since it could mean "new virtual function with default decleration" or "override of old virtual" or "I want to provide a new implementation, but if you want even this implementation can be overridden".

Not including the virtual for me is demonstrating "I want to override, and then nothing following is intended override my override".
Including the virtual for me is demonstrating "I want to override, and if anything following wants to that's also totally cool and I have definitely allowed for it".

This is why I said "is not required" instead of "should not be done".

C++0x has introduced it's own tag that you can use to define an overload anyway, so when they gets adopted....yay?

[Zaeranos]

Zaeranos

Re: [C++] Rooms

Personally I find it pretty unclear either way, since it could mean "new virtual function with default decleration" or "override of old virtual" or "I want to provide a new implementation, but if you want even this implementation can be overridden".

Not including the virtual for me is demonstrating "I want to override, and then nothing following is intended override my override".
Including the virtual for me is demonstrating "I want to override, and if anything following wants to that's also totally cool and I have definitely allowed for it".

This is why I said "is not required" instead of "should not be done".

C++0x has introduced it's own tag that you can use to define an overload anyway, so when they gets adopted....yay?

To me virtual says that if you derive a class from this class and override this function, the declaration of the derived class will always be used, even if the derived class is called as one of its base class. The virtual says that it is certain that this will happen, because it is declared in this class or one of its ancestors.

If you don't add it and it is declared virtual somewhere in the inheritance hierarchy, than you won't be able to see that from the class you are deriving from.

[TheDarkJay]

TheDarkJay

Re: [C++] Rooms

Fair enough. I've seen both explicit-always and implicit-explicit-different-implication practices used all over the place. It's usage depends on personal-practice (for solo projects) and party-practice (for group projects).

I just figured it was worth pointing out since Xip either through hecking code apart for presentation or a simple mistake made some inheritance-related errors. The not-declaring-destructor-virtual one can cause some huge memory leakage...
http://en.wikipedia.org/wiki/Virtual_function#Virtual_destructors

Also it's one of those situations C# and D have it right (makes sense, being newer languages and all) with their explicit abstract/virtual/override keywords.

[Xiphirx]

Xiphirx

Re: [C++] Rooms

Just some "best practice comments":
Xiphirx, you need to make GameState have a virtual destructor. Any class which can be inherited needs a virtual destructor otherwise the order the destructors get called in can be messed up. And any call of to delete a base* will not call ~child(). Which can be very very bad.
Also if you aren't defining any implementations of "create()" etc. functions in the base GameState, those should be ended with = 0 e.g virtual void update(float delta) =0;

Also the usage of virtual in introState, if this is not intended to ever be inherited, is not required (as later comments show, it's a personal-preference decision here though).

I actually have the virtual destructor commented out in my source code, I think it was causing a weird error. Thanks for the info though.

Sorry, but what does = 0 do on functions?

As for the virtual keyword in inherited classes, that's how I was taught to do it... :/

For The Swarm (StarCraft II Zerg strategy)

I whip my hair back n forth

• 

[TheDarkJay]

TheDarkJay

Re: [C++] Rooms

virtual void SomeFunc() = 0; means SomeFunc() is a pure virtual function. It is entirely abstract, so the class containing it can't be created by itself. The child then overrides it and can be created.
See more at: http://en.wikipedia.org/wiki/Virtual_function#Abstract_classes_and_pure_virtual_functions

[Mamoruanime]

Mamoruanime

Re: [C++] Rooms

D: totally derailed at this point lmao

Anyway Tetiro:
There are a lot of fundamentals you need to learn before jumping right into this stuff. As you can see from above, there are a lot... (a LOT) of different concepts that are way beyond game maker's flexibility. Before you can jump right in and make rooms, objects, etc you need to create a backbone for those things. Rendering systems, actor systems (placeable objects mainly), image loaders, and everything that builds up to that point. There are many wrong ways to do it and probably the best way to get a grasp on it is to look up game design concepts and practices beforehand, and get yourself acquainted with C++ as well.