0
\$\begingroup\$

My first question is about stateManagers. I do not use the singleton pattern (read many random posts with various reasons not to use it), I have gameStateManager which runs the pointer cCurrentGameState->render(), etc. I want to make a transitioning game, this engine should ideally cover both a platformer and a bird's eye RPG (with some recoding, I just mean the base engine), both of which will load different levels and events, such as world map, dungeon, shops, etc. So I then thought, rather then having to store all this data within all the states, I would break the engine into gameStates, and playStates... when gameState reaches gameStatePlay(), gameStatePlay simply runs the usual handleInput, logic, and render for the playStates, just as the low level gameStateManager does. This lets me store all the player data within the base playstate class without storing useless data in the gameStates. Now I have added a seperate mapEditor, which uses editorStates from gameStateEditor. Is this too much usage of the gameState concept? It seems to work pretty well for me, so I was wondering if I am too far off a common implementation of this.

My second question is on image resources. I have my sprite class with nothing but static members, mainly loadImage, applySurface, and my screen pointer. I also have a map pairing imageName enums with actual SDL_Surface pointers, and one pairing clipNumber enums with a wrapper class for a vector of clips, so that each reference in the map can have different amounts of clips with different sizes. I thought it would be better to store all these images, and screen within one static body, since 20 different goblins all use the same sprite sheet, and all need to print to the same screen, and of course, this way I do not need to pass my screen reference to every little entity. The imageMap seems to work very well, I can even add the ability to search through the map at creation of entity type to see if a particular image at creation, creating if it doesnt exist, and destroying the image if the last entity that needs it was just destroyed. The vectored clip map however, seems to take too long to initialize, so if i run past the state that initializes them to fast, the game crashes ><. Plus, the clip map call is half of this line =P

SPRITE::applySurface( cEditorMap.cTiles[x][y].iX, 
    cEditorMap.cTiles[x][y].iY, 
    SPRITE::mImages[ IMAGE_TILEMAP ], 
    SPRITE::screen, 
    SPRITE::mImageClips[IMAGE_TILEMAP]->clips.at( cEditorMap.cTiles[x][y].iTileType ) );

Again, do I have the right idea? I like the imageMap, but am I better off with each entity storing its own clips?

My last question is about collision detection. I only grasp the basics, will look at per-pixel and circular soon, but how can I determine which side the collision comes from with just the basic square collision detection, I tried breaking each entity into 4 collision zones, but that just gave me problems with walking through walls and the like ><. Also, is per-pixel color collision a good way to decide what collision just occured, or is checking multiple colors for multiple entities too taxing each cycle?

\$\endgroup\$
2
  • 2
    \$\begingroup\$ first of all, if you have more than one question ask more than one. this is a site for questions, it's not a forum you can post any topic for people to discuss. \$\endgroup\$
    – Ali1S232
    Feb 26, 2012 at 19:07
  • \$\begingroup\$ and since I'm too lazy to give you a full answer, I just point you towards cocos2d, there is a class name CCTMXTileManager, which handles all types of tile mapping (normal tiling, isometric, hexagonal). hope you can find what you need for your first question there. \$\endgroup\$
    – Ali1S232
    Feb 26, 2012 at 19:09

2 Answers 2

1
\$\begingroup\$

The simplest State Manager system I can think of doesn't use a stack or multi-object structure whatsoever, or even a "StateManager" type of object. You just need a GameState class with an Update function that returns a GameState pointer.

When its main function begins to run, assign a pointer, say, called "currentState", to a new GameState you want to run on startup.

In the game's main loop declare another GameState pointer called "nextState" and assign it to currentState->Update(). Depending on input and other events happening in the Update function, the function can either return the GameState it belongs to (continuing as normal), or a different GameState (something happened in the game requiring to switch modes).

After this update, compare nextState to currentState. If they are not equal, delete currentState and then assign it to nextState.

This is good enough for basic games which do not care in what order states have entered/left. It's a little tougher for a beginner to wrap their head around, but the code is much lighter.

\$\endgroup\$
0
\$\begingroup\$

Is this too much usage of the gameState concept?

It's hard for me to answer based on your description, but it sounds like a reasonable use of the state pattern. The game transitions between states to handle input and rendering differently, but the game engine (the means of handling input and ui, etc) remains the same. Just be sure you're not using the state pattern strictly to simplify your class hierarchy, which you mentioned briefly. There are better ways to handle that.

I recommend following Gajet's advice and breaking out the second and third questions into their own posts.

Good luck.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .