Would this be too difficult?

It wouldn't be too hard. Just start with bounding boxes, then you can improve the CD algorithm as you see fit after you finish the game.

I'm also interested to know about this, i've tried to make some games similar to megaman before but never managed to continue.

Some things that is worth to think about is:
How to make the player jump, anyone have any idea how to make that?

Making the character run while he's actually moving (i've managed to do that, but it wasn't that good looking so the hard part should be to make it good looking). How do you make that part, if you've ever done that, advices would be appreciated.

The harder part should be making the AI.

I'm thinking of making a game like megaman too, now I mean a actually copy of the game with the sprites from the game itself, don't worry it's for personal use only, don't sue me for that :p

Quote:

Original post by password Some things that is worth to think about is: How to make the player jump, anyone have any idea how to make that?

Use a system of forces and gravity. Then to make him jump you simply apply a force upwards and gravity will naturally bring him down. Could probably be easier, but this creates a very real look and only took me a couple hours to get looking good.

Quote:

Making the character run while he's actually moving (i've managed to do that, but it wasn't that good looking so the hard part should be to make it good looking). How do you make that part, if you've ever done that, advices would be appreciated.

Once you get the animations set up for the sprite, it's all just timing. Just make sure the images in the animations and the speed look natural together. Not much in terms of programming besides tweaking the horizontal speed.

Ok, i've never done anything like this before, so could you guys elaborate on the "bounding boxes" and systems of force and gravity, how do you go about implementing something like this and having it affect everything in the game? If you dont have the time or it would take too long to write out and explain it, could you at least direct us to some good resources on this stuff. Thank you very much, you've already both been helpful at getting the basic concepts in our heads, I just need to know how to go about and begin implementing them :), thanks,


-Synt4x

Here is an article in the reference section here at GameDev about this stuff. It should help you out.

THe basic idea of a bounding box, though, is that each collidable "object" in your scene has a box associated with it... minX, maxX, minY, maxY, and you test those boxes for overlap to check for collisions. It gets a bit more complicated than that, but that's the basic idea.

Check out that article, though, it will give you a background so you know what to look for for more info.

Now when you told me about gravity, making the player jump doesn't sound so hard. Making a ground that drags the player down constantly should do it I guess and of course, not making it go below the ground.

Thank you for clearing things up, I should be able to think something out now..

i don't think a game like megaman would be THAT difficult

and most of the enemies (besides the bosses) follow a really simple AI

i'd actually think that in some ways mapping would be sorta difficult, you have to "string" them all together... hmm

the thing i'm working on now is a sprite manager; however i have like NO idea on how to do timing with sprites... could someone point me to a tutorial?

thanx :)

well telling me it won't be THAT difficult isn't helping me out TOO much :-p. but if someone could tell me, for collision detecting and physics in a game like this: a) where can I learn more about game physics, I havent ever really done anything like this ( I dont think ).
b) Do I make each of the platforms an object of their own with boundaries and stuff and always check the player against these... seems like it would be WAY too much checking, how do I limit it down? Thanks for the help,

-Synt4x

One trick you can use for keeping the number of collision checks reasonable is to use clipping. The idea is that you keep a general list of "stuff" that is near the player: either on the screen, or very close to the edges. Anything beyond that area is probably not going to be colliding with the player [wink]

Once you have your short-list of "stuff" to check for collisions, you're in good shape. Secret hint: this short-list is exactly the same as the list of things that need to be drawn on the screen.

(Disclaimer: I'm not really familiar with SDL so I don't know if that information is really all that easy for you to get access to. If it isn't easy, there's another trick you can use. Look up "bounding volume hierarchies" and think about how you could simplify the BVH technique to use in 2D.)

To me, it sounds as if you'd be able to do something like Megaman. Maybe you don't make it perfect, maybe you don't finish it, but if you're looking for a good learning project then this is probably a good choise. You'll certainly learn alot in a short amount of time!

In a brief estimation, ontop of what you already know, I believe you need to learn the following:
1. Basic collision checking
2. Basic physics
3. Basic AI
4. Tile-based scrollable game-map knowledge
5. Sprite animation handling
6. Joystick/gamepad handling (optional)
7. How to make a level-editor (optional)
8. Object/particle-ish system

Here's how I suggest you go about them:
1. As others have suggested, check out that bounding box tutorial.

2. For the very basic physics (they're easy - I promise! [smile]) go browse through the articles here on gamedev, under the category Math & Physics. I think you will find this one especially helpful.

3. For AI, I suggest you drive all enemies using an approach called 'Finite State Machine'. This is much simpler than it sounds, and for a VERY brief idea of what this is like - read this forum entry.

4. Hmm... I've used tiles on countless projects, but I can't seem to find a decent introduction tutorial into this area... But basically your map is made up of a large grid of values, where different values mean different images (tiles). You'll have to take into consideration where the 'camera' is over the map, to decide which part of the map to display on the screen. Maybe I should make a tutorial about this...

5. There are plugins you can add to SDL which are ready-to-use, but I think you want to learn, so I suggest you build the animation system yourself. I think it would be quite rewarding. Basically you put all the images in the animation on a surface, next to eachother. To display the different images, you blit only a cropped portion of this animation-chart onto the screen. In every frame, you calculate which image should be drawn, by doing some simple math. (i.e. 455 of 1000 milliseconds have passed >> draw image number 3 of 6)

You could have one textfile for each animation, where you specify how quickly it should be animated. First you tune the in-game speed of the object until it moves with a nice speed, then you tune the speed of the animation so they match.

6. SDL provides easy input from joystick/gamepad. You'll have this implemented in a day, by just following the included documentation.

7. Making a level editor would also be a rewarding experience, but you can skip this if you don't want to. You can use Notepad as your level editor, writing long strings of numbers in a grid. You can also use a paint-program to draw a image. Different colors represent different tiles. You can also download and use any of the free tile-map-editors which you can find online. They save their output as a special file-format, so you'd have to program a function to read the info stored in the file.

8. I hope you have learnt how to use the ++ in C++!! [grin] By spending a decent amount of time on planning and writing diagrams, prior to programming, you can save yourself lots of working hours later. I recommend trying to use an object-based approach, and thus make your game engine really expandable. Scetch things down on paper first, or in Word if you type faster than you write. Always assume that will will want to add things later, which you have not yet thought about. Plan ahead, to make such additions easier to do in the future.

For example, such a procedure could give you a result like this:
"Aha! Instead of checking if the player collides with a bullet, then if player collides with an enemy... blah blah blah... and then if enemy collides with bullet, if enemy collides with map... blah blah blah.... I could just make it 'if OBJECT collides with OBJECT' and it will be much less complex!"

Hope I provided some information of value.
Good luck!!

Well sir, this was EXACTLY the kind of post I was looking for, extremely informative as well as having resources to look to for learning each of these subjects. Thank you very much for this, Good luck with your art :), cheers,

-Synt4x

Quote:

Original post by NQ To me, it sounds as if you'd be able to do something like Megaman. Maybe you don't make it perfect, maybe you don't finish it, but if you're looking for a good learning project then this is probably a good choise. You'll certainly learn alot in a short amount of time! In a brief estimation, ontop of what you already know, I believe you need to learn the following: 1. Basic collision checking 2. Basic physics 3. Basic AI 4. Tile-based scrollable game-map knowledge 5. Sprite animation handling 6. Joystick/gamepad handling (optional) 7. How to make a level-editor (optional) 8. Object/particle-ish system Here's how I suggest you go about them: 1. As others have suggested, check out that bounding box tutorial. 2. For the very basic physics (they're easy - I promise! [smile]) go browse through the articles here on gamedev, under the category Math & Physics. I think you will find this one especially helpful. 3. For AI, I suggest you drive all enemies using an approach called 'Finite State Machine'. This is much simpler than it sounds, and for a VERY brief idea of what this is like - read this forum entry. 4. Hmm... I've used tiles on countless projects, but I can't seem to find a decent introduction tutorial into this area... But basically your map is made up of a large grid of values, where different values mean different images (tiles). You'll have to take into consideration where the 'camera' is over the map, to decide which part of the map to display on the screen. Maybe I should make a tutorial about this... 5. There are plugins you can add to SDL which are ready-to-use, but I think you want to learn, so I suggest you build the animation system yourself. I think it would be quite rewarding. Basically you put all the images in the animation on a surface, next to eachother. To display the different images, you blit only a cropped portion of this animation-chart onto the screen. In every frame, you calculate which image should be drawn, by doing some simple math. (i.e. 455 of 1000 milliseconds have passed >> draw image number 3 of 6) You could have one textfile for each animation, where you specify how quickly it should be animated. First you tune the in-game speed of the object until it moves with a nice speed, then you tune the speed of the animation so they match. 6. SDL provides easy input from joystick/gamepad. You'll have this implemented in a day, by just following the included documentation. 7. Making a level editor would also be a rewarding experience, but you can skip this if you don't want to. You can use Notepad as your level editor, writing long strings of numbers in a grid. You can also use a paint-program to draw a image. Different colors represent different tiles. You can also download and use any of the free tile-map-editors which you can find online. They save their output as a special file-format, so you'd have to program a function to read the info stored in the file. 8. I hope you have learnt how to use the ++ in C++!! [grin] By spending a decent amount of time on planning and writing diagrams, prior to programming, you can save yourself lots of working hours later. I recommend trying to use an object-based approach, and thus make your game engine really expandable. Scetch things down on paper first, or in Word if you type faster than you write. Always assume that will will want to add things later, which you have not yet thought about. Plan ahead, to make such additions easier to do in the future. For example, such a procedure could give you a result like this: "Aha! Instead of checking if the player collides with a bullet, then if player collides with an enemy... blah blah blah... and then if enemy collides with bullet, if enemy collides with map... blah blah blah.... I could just make it 'if OBJECT collides with OBJECT' and it will be much less complex!" Hope I provided some information of value. Good luck!!

yeah, wow that was a really thorough and in-depth post, probably very helpful to many people, rate++ from me!

synt4x, sorry, looking back at my post i realize that it was indeed useless and next time i will try to post something a bit more informative. :)

good luck on your project, be sure to post if you need help ^^

Will do, it seems like your really interested in a project like this as well, so I hope everything you do pertaining to this material goes well as well, Cheers, no worries about before,

-Synt4x