In need of some answers
Author
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:
Author
I forgot to mention that i have already looked for this information in many books but most of them only deal with 3D graphics, modelling, texturing and stuff like that. I would go and try to learn Pixel Art if there were good Pixel Art books, but i have searched and didn't found any book seriously dealing with the subject, and the tutorials i have found are very vague and don't do a good job at really teaching it. Even if i tried to learn through these tutorials by my own, they are not focused in making art for games, therefore, they wouldn't teach me the technical aspects i mentioned above (proportion, sprites, tiles, backgrounds, size of the image, animation, and so on...).
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?
These things are pretty hard to explain, because these are not specific questions, and you have to have a level of abstraction to understand them.
Some of the more specific questions:
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.
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.
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.
After I've learned what I needed in C++, I moved on to allegro. It's a great library for 2D games.
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.
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.
Win32 programming seems overwhelming at first but it's really very simple when you get past that. It's because they typedef lots of stuff and use lots of structures to fill in that a hello world program has so many lines but after that you'd always use that same framework to build other programs. The main thing to understand is the message loop and callback function.
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.
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.
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.
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.
Author
Bacterius:
[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).
The win32 API isn't really an engine. It's relatively close to the metal. What you need depends on how far you want to adventure under the hood or how fast you want to get visible results on your screen. If it's the latter then you should go for unity. If you want to dig a bit deeper and closer to the metal but without feeling overwhelmed then maybe something like SDL. Are you very adventurous? DirectX/OpenGL.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
