- Stack the states deleted player update#
- Stack the states deleted player software#
- Stack the states deleted player code#
The constructors of each state will load all data and set everything up for that state. The job of each of the states that inherit from the game state base is to override the pure virtual functions of HandleInput, HandleLogic, HandleOuput. If( currentGameState->GetNextState() != NoChange)ĬurrentGameState = new TitleMenuState( gameEngine) ĬurrentGameState = new MainGameState( gameEngine) GameStateBase* currentGameState = new IntroState( theGameEngine ) //set up the intro state
This allows for ONE copy of the engine in the entire program but all states can use it. So I pass a reference to the state on construction and store the engine as a pointer. These are things each state needs to know about in order to do things. Things that would be here are the image manager, sound manager, music manager, and the SFML RenderWindow. Note on 'engine': In my programming, I pool all the things each state needs to run into an engine class. The last function is a VIRTUAL destructor. It has 3 virtual functions called HandleInput(), HandleLogic(), HandleOutput() and it has a function for getting the NEXT state that should be run (one option of which is ALWAYS NoChange). It has a template for the states enum (because I used this for running states within states and the enum I use for states is different for each state). It has a constructor, which is used for setting the one thing that is key to all game functions which is a pointer to the 'engine' (More on that in a bit). Each state of the game inherits from a game state base class called game state. In my programming, I utilize virtual functions to do this. It also helps to break your game into states in the code. This is also when you determine WHAT images should be drawn by finding the images that are on the screen and ONLY drawing them. This is when sounds are played and images are drawn to the screen.
Stack the states deleted player code#
If you tried to get the player to jump when the key is pushed during the input handling phase, then you would have to include all the code before and it will create a bloody mess of you program flow which will make a bloody mess of trying to debug your program.Īfter all of the logic is performed, then you will have the output phase. That is why the input just sets a flag to say, "hey you're suppose to do this because the key for you to do this was pushed". He could be caught in a trap or something else that would disable the ability to jump. If true, then he will see if he CAN jump.
Stack the states deleted player update#
The player update bit looks to the flag bool shouldJump and sees if it is true or false, which was set in the input phase. This is when the player looks to see if he should jump. This will likely be the largest portion of your program by far. The logic phase is where all of the rules of your game are checked and everything moves and does what it is suppose to. Don't make the player jump just yet, but let them know that when they are updating they should be trying to jump. For example, if the space bar key tells the player to jump, then have a flag somewhere that tells the player it is suppose to jump. Each loop, you will want to get and process the user input and store it somewhere that means something to the game. There are a few kind of loops and the complexity of your game calculations will be a factor in determining the style of loop you will want.Ī game can be broken into 3 basic parts: input handling, performing logic, output handling. It will be a good learning experience and you won't get a ton of stuff going along for the ride your aren't using.Īs far as games, all games are comprised in a loop that runs until it is told to quit. Pong is good so is space invaders), then you will benefit greatly by just starting from a bare bones library such as SFML. If you are making a simple game (which you should be since you haven't made one yet. However, typically, the more a library does for you, the greater the confines you have to work in or the more baggage you will be carrying around. A game engine provides those things, it is also a library of sorts. It will draw an image for you, but it doesn't contain any sort of collision detection or GUI code. It offers limited, low level fucntionality. I used SDL before SFML and I'm sorry it took me so long to switch. It even has a networking portion to allow you to write network code easier. It can play sounds and play music for you. SFML will handle getting user input so you can process it.
It also has a lot fewer DLL files to manage (it has two), and zero if you don't use the audio portion. SFML is structured better being C++ vs C. The ONE advantage SDL has over SFML is that SFML can't play mp3's whereas SDL can.
Stack the states deleted player software#
SFML is better over SDL imo because it's rendering is done by default using OpenGL vs SDL using SOFTWARE CRAP rendering by default. The forums have knowledgeable people and the creator himself is VERY active in the forums.
0 kommentar(er)
