I reached a milestone I have been aiming for which was to understand how to tile out a 2d world with interactive tiles and have a player walk around with a camera following.
Now I am stuck trying to figure out an organized way to have multiple levels in my game, I kind of understand the concept of inheritence and polymorphism (how lazyfoo explains in this article http://lazyfoo.net/articles/article06/index.php ) the problem is that he confuses me because he just mixes all of the classes into one file with comments all over the place for his examples.
Is there any tutorials out there that are organized and clear?
should the gamestate class be the base class? or is the base class below the gamestate class?
multiple levels is easy, just have one area of ram where the level loads in, and just keep reiniting that ram with file loads, each file is its own stored level. only one level can be open at once, your basicly just reusing the same space for every level.
I think maybe my question isn't clear, I do have my map files stored as seperate files. I just don't get how to organize my classes so I can switch between the levels in my game. I was hoping someone knew of a tutorial around some where that breaks it down
you know what id do, i wouldnt use classes.
like...say I have three different rooms the player can walk in between and each one loads the new game state... that is what I am trying to figure out how to organize
While it's not for everybody, take a look at UML. What better way to organize and understand your code then to visually map out all the classes and their relationships. You can download a community version (free) from Visual Paradigm, which has the best UML editor out there (IMO).
As for how you should design your code, that can be pretty subjective. What works for some, might not work out for others. One place to start is to read up on software design patterns. This won't outright solve your problem, but if you read through some of them it will open your mind to how you could potentially implement your solution in a way that's not destructive to your overall codebase. Keep these on hand and if you have the time, build a couple test projects and try them out. Get a feel for them and see how they work first hand. You'll more than likely come across a need for one of them in the future and you'll be happy to have already studied them.
To get you somewhat started on your problem, try not to think of a level as a class. Instead, break down your game into major and minor components. A major component would be rendering graphics, detecting collisions, loading and caching map files and its resources (sounds, textures, polygons), scripting, etc.. Next, break down these major components into minor ones, which are the core of your classes you will implement. You're interested in level rendering and interaction right now. To break this down into minor components, you need to figure out what are the inputs and outputs of your game. What can someone do and see in a level and are there any special considerations. Your final solution should have a set of reusable classes that are fed the exact same data every time, but have a sort of API that your maps can use to perform certain types of actions. Most games implement this as scripting.
function pointers get rid of nasty switch statements, but you wouldnt even need them, just have a file with the level list in it and load through that to go through the levels. a "level" of levels.
i never have used c++ oo ever, and i never will, its completely perdantic using classes, i never do. trust me, you can do anything without them.
give me any oo code and i can write a straight version of it of equal power, straight c just gets the job done.
Generally, for me anyway, each level is comprised of a game loop, or a portion of a game loop. The render is usually the same for all levels. I switch between levels by changing the game state in the main loop, so it's basically just a switch/case and when I change levels, I give the switch case a different variable. Enums work great or constants so you can just change by using a variable name that is the name of the level. You can use a class, but it's not really necessary depending on how you feel about it. You might want to read about state machines because they are all basically the same whether it's game state or the state of an entity in your game.
Thanks guys, I was looking for some tutorials about State Machines I was able to find a good one