How to make a 2d game
Pages: 12
I am competent in c++ and i have a good grasp on sdl, I thought that once I reached this point making a game would be no problem but then 4 hours and 200* lines of code in I realized that I had no idea what to do. What do you guys recommend I do.
*I had an error on almost every line
*I had an error on almost every line
(If you have errors on almost every line, I wouldn't exactly call you competent)
I would recommend you try fixing the errors. =P
I would recommend you try fixing the errors. =P
i fixed them all within 25 min. it was mostly typos and me trying new things.
@rdprado
I'm trying to make an oo game engine but I dont know how to design it.
@rdprado
I'm trying to make an oo game engine but I dont know how to design it.
bboy212,
You have a couple choices: You can try to make the game while still learning the concepts, or, you can learn the concepts first then try making the game.
But I recommend you do something even better. Learn the concepts. Read an entire C++ book if you haven't already (I'm currently reading 'C++ Primer Plus' and it's the best out of many books I've looked at.). Don't skip any chapters and make sure you understand everything. If you have any questions come to the forum and post it.
Then get source code (open source code) for a simple game that was developed by an experienced and proficient programmer. This will give you a great outline and you can use and modify this code to your liking.
After you've messed around a little with the game, you'll naturally want to start from scratch and make your own, but this time you'll have a much better idea of how to do it. You'll save time in the long run, and aggravation too, and you'll be a better programmer as well.
Also, as a newbie I like to compile and run my code after every couple of statements. If I make a for loop I run it. If I add a function I run it... This way if I get an error I can fix it right away. I add '-Wall' to my compile parameters to catch some extra potential errors and some bad programming (like not setting a value to an integer or having dummy statements..).
You have a couple choices: You can try to make the game while still learning the concepts, or, you can learn the concepts first then try making the game.
But I recommend you do something even better. Learn the concepts. Read an entire C++ book if you haven't already (I'm currently reading 'C++ Primer Plus' and it's the best out of many books I've looked at.). Don't skip any chapters and make sure you understand everything. If you have any questions come to the forum and post it.
Then get source code (open source code) for a simple game that was developed by an experienced and proficient programmer. This will give you a great outline and you can use and modify this code to your liking.
After you've messed around a little with the game, you'll naturally want to start from scratch and make your own, but this time you'll have a much better idea of how to do it. You'll save time in the long run, and aggravation too, and you'll be a better programmer as well.
Also, as a newbie I like to compile and run my code after every couple of statements. If I make a for loop I run it. If I add a function I run it... This way if I get an error I can fix it right away. I add '-Wall' to my compile parameters to catch some extra potential errors and some bad programming (like not setting a value to an integer or having dummy statements..).
1. http://www.sfml-dev.org/
It's more modern and IMO easier to use than SDL, though not as well documented in the sense that there aren't any books for it, though the website is very in-depth.
2. I'm a learn by doing kind of person, but I would recommend researching everything new you want to add in (i.e. rendering and animating sprites, collision detection, multi-threading, event handling) BEFORE adding it into the engine and then take some time to screw around with it and figure things out. Then you don't end up with spaghetti code and you know what you're doing before you start screwing with your code.
It's more modern and IMO easier to use than SDL, though not as well documented in the sense that there aren't any books for it, though the website is very in-depth.
2. I'm a learn by doing kind of person, but I would recommend researching everything new you want to add in (i.e. rendering and animating sprites, collision detection, multi-threading, event handling) BEFORE adding it into the engine and then take some time to screw around with it and figure things out. Then you don't end up with spaghetti code and you know what you're doing before you start screwing with your code.
I guess my real question is: how do I go about putting all the different pieces together?
If a job is large or confusing, break it down into smaller tasks.
For example you're looking at "build a game engine" and one task, and it's confusing you because it's a complicated thing. You need to break it down into smaller parts and work on each of those parts individually.
So what are the smaller parts to making a game engine? To start with, you might want to start with the following tasks:
1) create a world/map
2) draw that map to the screen
3) draw the player on the screen
4) allow the player to move around the map
So take a look at creating a world/map. This smaller task can be broken down into even smaller tasks. Assuming you want a tile-based world:
1) decide which properties you want to give to each tile
2) decide how you want the tiles to be arranged/accessed
3) etc.
That's all there is to it. If you run into a step that's too complicated, just break it down into smaller steps and work on them one at a time.
For example you're looking at "build a game engine" and one task, and it's confusing you because it's a complicated thing. You need to break it down into smaller parts and work on each of those parts individually.
So what are the smaller parts to making a game engine? To start with, you might want to start with the following tasks:
1) create a world/map
2) draw that map to the screen
3) draw the player on the screen
4) allow the player to move around the map
So take a look at creating a world/map. This smaller task can be broken down into even smaller tasks. Assuming you want a tile-based world:
1) decide which properties you want to give to each tile
2) decide how you want the tiles to be arranged/accessed
3) etc.
That's all there is to it. If you run into a step that's too complicated, just break it down into smaller steps and work on them one at a time.
On this forum people like to give people a push so that the asker can reach the answer on the own. Disch told you how to put everything together, so start to break things down. Teach a man to fish :)
Last edited on
I don't really know how I can go more in depth than that. The exact steps involved depends on what kind of game you want to make, so really you're the only one that can say what each task will involve.
| ascii wrote: |
|---|
| 1. http://www.sfml-dev.org/ It's more modern and IMO easier to use than SDL, though not as well documented in the sense that there aren't any books for it, though the website is very in-depth. 2. I'm a learn by doing kind of person, but I would recommend researching everything new you want to add in (i.e. rendering and animating sprites, collision detection, multi-threading, event handling) BEFORE adding it into the engine and then take some time to screw around with it and figure things out. Then you don't end up with spaghetti code and you know what you're doing before you start screwing with your code. |
He's already into SDL, switching rendering libraries probably won't help him much here... (Plus I like SDL better =] )
However, I agree mostly with your second statement. You don't have to reinvent everything, it's already been done.
You should separate the definition of your game from the code that executes it. Develop some tools first (tile, map, world, character, item, script, etc editor) so you can use them to focus on the actual design of the game. The engine takes the content created with those tools, plus game assets, and executes the game accordingly.
I can make all the different classes for different things: player, object, map, and so on but then i have no idea how to make them interact. Any ideas?
Set up a switch statement in the main loop and have the engine act based on the current game state. For example, if the current state is "playing": get input, react to input, update PC, update AI, update sprites, render view. If the current state is "menu": get input, react to input, display menu. Each state must have a transition to another state. For example, if the player presses Esc in the "playing" state then change state to "menu". The switch statement is essentially a state machine and the same can be used to control AI behavior.
If you're already using C++ you might as well use an object oriented model to represent the states rather than a switch - it's not really more code to write, but it's much more pleasant to work with (and allows you to just write new code when you need new functionality instead of changing old code).
Pages: 12