In need of some answers
Before anything, my name is João, i'm 19 years old and i have been learning about game development by myself for some time. I was born and live in Brazil, so i ask that you forgive my innacurate english. Though i try to learn everything i can about all the roles involved in the process of the creation of a game, the role that interest me the most is the one of the programmer. For a year i have been buying books, trying to learn C++ and really get something going but some stuff remained unclear and i would appreciate if you guys helped me out and explained them to me:
How to establish where the player would be able to walk and where he wouldn't? How to define with which objects the player would
be able to interact and with which they wouldn't?[/quote]
This is a difficult problem which involves pattern recognition. Without clear depth information you can only use heuristic algorithms to determine how far an object may be (for instance, looking at the color of two neighbouring pixels and determining the parallax delta to calculate the 3D "slope" at that point, and reconstructing depth from there). Usually - if I understand what you mean - these types of images are typically composited from multiple smaller images (for instance the image of the alley itself, which is "far away" and then the image of the dumpster is drawn on top of that, and is "closer").
How to draw the character in order for him to remain proportional in all angles and positions? What's the right way (or better way) to
create/draw a 2D character in order for him to remain proportional in all angles, positions and poses?[/quote]
I don't understand, do you mean in 3D? In two dimensions, rotation and translation preserves area. Can you describe what you are looking for?
Some of the more specific questions:
How to establish where the player would be able to walk and where he wouldn't? How to define with which objects the player would
be able to interact and with which they wouldn't?
Usually you have some kind of editor, with which you can edit levels. they are separate programs from the actual game, they can be 2D/3D, they can come with the engine you are using, they can be a separately programmed simple tool. Or you can even use notepad and type all the stuff in.
In an editor, you place objects, which have abstract properties that you, as the game programmer decide/choose. Levels are loaded from a file, and you can use whatever convention of coding to "read" the necessary things.
It's usual that defining "interaction" is somewhat different than defining the looks. Often you have simplified geometry that you use for interaction. This geometry is not visible.
(look into "collision detection" "collision geometry" "collision mesh")
The editor saves the data as a file. The format of the file is decided by the programmers/designers. There is a coding convention for the format, you save with this code, so you can decode it in the game.
Similarly, if my friend made a character like this one (the character below is not
my friend's):
How to draw the character in order for him to remain proportional in all angles and positions? What's the right way (or better way) to
create/draw a 2D character in order for him to remain proportional in all angles, positions and poses?
Well, that's not a programming question, that's an art question that depends on the skills of the artist. It requires practice, some learning of animation, anatomy, etc. There are tools for it, these are usually commercial ones, since a lot more people make art than games.
The artist can use whatever she wants to aid her work. she can use reference photos of a moving person, she can actually make these photographs herself. She can even do real sculpting of clay, so it's easier for her to make the images "remain proportional in all angles and positions". Or simple drafts with paper and pen.
She can then use these images as references, she can even manipulate the shit out of the images to produce the game art.
to sum it up: just do it, it's no magic. Practice.
My problem was that I later realized that I want to have some 3D aspects in my game and that it is very hard to achieve in allegro.
I've tried SDL after allegro, but it seemed too complicated for me. A too big of a jump, especially the win32 part was overwhelming.
It just happened that I found the right website where everything regarding win32 and DirectX was explained in detail.
So right now, I'm working with directX.
If they hadn't typedefed so much stuff then the way you can see winmain is that it returns an int and takes four ints as arguments. In assembler this is really what happens. Wndproc also takes a few ints and these are the messages that you dispatch to different cases in a giant switch statement.
SFML also provides other API's to control every other part of a game: Input, Windows, Audio, and networking. So, check out sfml-dev.org and see if it's what you are looking for.
[background=rgb(250, 251, 252)]This is a difficult problem which involves pattern recognition. Without clear depth information you can only use heuristic algorithms to determine how far an object may be (for instance, looking at the color of two neighbouring pixels and determining the parallax delta to calculate the 3D "slope" at that point, and reconstructing depth from there). Usually - if I understand what you mean - these types of images are typically composited from multiple smaller images (for instance the image of the alley itself, which is "far away" and then the image of the dumpster is drawn on top of that, and is "closer").[/background]
[/quote]
So you mean the way that is usually done is by placing images on top of each other and implementing each of them separately? If that's what you mean, i think it's a cool solution to the problem of, for instance, being able to open and examine things along the way. But what about the problem of the path? I mean, i don't understand how it is done, but would it be like creating the path in the code itself? Like "In this part of the image the character will be X size. As he moves away from the "camera", his size wil decrease. As he moves closer to the camera, his size will increase. In that part, and that part the character won't be able to walk since those are objects blocking the path." Another question: how to define which objects will be in front/behind the character and when?
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]
[background=rgb(247, 247, 247)]How to draw the character in order for him to remain proportional in all angles and positions? What's the right way (or better way) to[/background][/font]
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]
[background=rgb(247, 247, 247)]create/draw a 2D character in order for him to remain proportional in all angles, positions and poses?[/background][/font]
[/quote]
What i really want to know is if there is any source (a book, or a website) that really takes 2D graphics seriously and explain the technical aspects of it, like "to make the sprites of you character proportional in all angles and poses, you have to follow this and that rule", things like that.
szecs:
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]
[background=rgb(250, 251, 252)]Usually you have some kind of editor, with which you can edit levels. they are separate programs from the actual game, they can be 2D/3D, they can come with the engine you are using, they can be a separately programmed simple tool. Or you can even use notepad and type all the stuff in.[/background][/font]
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]
[background=rgb(250, 251, 252)]In an editor, you place objects, which have abstract properties that you, as the game programmer decide/choose. Levels are loaded from a file, and you can use whatever convention of coding to "read" the necessary things.[/background][/font]
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]
[background=rgb(250, 251, 252)]It's usual that defining "interaction" is somewhat different than defining the looks. Often you have simplified geometry that you use for interaction. This geometry is not visible.[/background][/font]
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]
[background=rgb(250, 251, 252)](look into "collision detection" "collision geometry" "collision mesh")[/quote]
I'll look into it.[/background][/font]
theo2005, Fredericvo, BeerNutts:
All of you suggested different API's or "engines", but what i really want to know is what are the advantages/disadvantages of them and which of them best suits my needs (a 2D game like Super Mario RPG).
I suggest people look into using SFML for 2D game programming, It has a great interface, and all the 2D API's are available and are performed in HW, unlike SDL (SFML actually sits on top of OpenGL).
SFML also provides other API's to control every other part of a game: Input, Windows, Audio, and networking. So, check out sfml-dev.org and see if it's what you are looking for.
I'd put another vote in for SFML. It's amazing, and it's API is very intuitive. Just make sure you use the upcoming 2.0 version rather than the outdated 1.6 version.
Though as an extra, I'm pretty sure the latest SDL runs on the hardware a well. So their won't be much of a performance difference between the two. Though it looks like SDL implements a C-like interface, whereas SFML implements a very OOP C++ interface.