#13026 - djb7 - Wed Dec 03, 2003 10:31 pm
Hey all i would like 2 learn 2 make games how do u reccomend i get
started?
I hav no experience in game developing or any kind of software devoloping. Im a 100% Noob.
Thx Bye.
#13027 - Miked0801 - Wed Dec 03, 2003 10:56 pm
Um. If you have no programming experience, no games experience, etc. why do you want to make a game? Not a slam/flame, just curious. You'll need to learn C at least to get started. After that, come back and see if you're still interested. Making games isn't the easiest thing in the world to do...
#13030 - sajiimori - Wed Dec 03, 2003 11:32 pm
I think it's a reasonable question to ask. I wouldn't have started programming unless I was interested in making games.
Opinions differ as to what order you should learn things, but I agree with John Carmack that this is a good path:
1) BASIC -- Not Visual Basic; just simple text-based stuff, like QBASIC or something. QBASIC is cool because you can do some simple graphics.
2) Assembly language for some CPU -- If you have a PC, learn x86 assembly language using NASM or DOS Debug.
3) C -- Get the "C Primer Plus" (not the "C++ Primer"). It's a really great book.
4) Whatever you want. Stick with C, or move to C++, Java, Lisp, Python, Perl, or anything else you're interested in. C is to programming as the piano is to music -- if you know it, everything else is easy to learn (though Lisp is a whole other school of thought).
Some people think that you can just jump straight into something like C++, and still have the same level of understanding. I think this view is totally wrong...if you start with C++ or another C-based language, you're bound to have an incomplete understanding of the design of the language and the underlying concepts.
Most programmers today are not very good, often because they went to school and learned Java (or something similar) from the start, without ever building a real foundation.
#13032 - Touchstone - Thu Dec 04, 2003 12:18 am
If I where a complete newbie I would want people to advice me to develop games and solve problems in my head or with pen and paper first. You should atleast have a basic knowledge of the target hardware and game making in general. Figure out how games are made and what role in the game making process would fit you the best.
For instance, what is a sprite? Why do you use sprites? What could you use sprites for in your game? If game making is what get your gears going I don't think learning a programming language is necessarily your starting point, there's so much more to making games. Writing game design, draw graphics, create characters/story, lead a team of game developers.
Besides you don't seem to be the programmer type. Programmers are generally not afraid to type out the exthreemly long words "to" and "you" and adhere to strict rules such as correct use of commas and uppercase/lowercase. ;)
_________________
You can't beat our meat
#13033 - djb7 - Thu Dec 04, 2003 12:27 am
Thx 4 help.
#13034 - poslundc - Thu Dec 04, 2003 12:32 am
| Touchstone wrote: |
| Besides you don't seem to be the programmer type. Programmers are generally not afraid to type out the exthreemly long words "to" and "you" and adhere to strict rules such as correct use of commas and uppercase/lowercase. ;) |
Might want to go easy on the guy for his composition skills, Touchstone; you might come across as the pot calling the kettle black. Unless you think it's "exthreemly" unfair of me to say so... ;)
Dan.
#13043 - sajiimori - Thu Dec 04, 2003 3:42 am
| Quote: |
If I where a complete newbie I would want people to advice me to develop games and solve problems in my head or with pen and paper first.
|
What do you learn by designing games on paper? How to be a "Game Designer"? That's a semi-mythical job position, invented by teenage boys who wish they could dream up games and have other people do the hard work for them. The only people who actually carry that title have already proven themselves by doing the hard work on their own, and suceeded at it (think Warren Spector or Sid Meier).
And what problems do you suggest initiates try to solve? Quadratic equations?
| Quote: |
For instance, what is a sprite? Why do you use sprites?
|
Who cares? Not artists. Not designers. Only programmers deal with these low-level details.
| Quote: |
If game making is what get your gears going I don't think learning a programming language is necessarily your starting point, there's so much more to making games.
|
True, but if you want to make games by yourself, there's little choice. Since the original post requested information on how to "make games", that implies the entirety of games, not just some pictures or levels.
Of course, you could always use one of those hobby-kit game maker programs.
| Quote: |
Programmers are generally not afraid to type out the exthreemly long words "to" and "you" and adhere to strict rules such as correct use of commas and uppercase/lowercase.
|
Actually, in my experience, programmers tend to express themselves in the manner that they find most comfortable, as long as they convey the intended information. In fact, most programmers place a high value on terseness.
#13047 - yaustar - Thu Dec 04, 2003 5:55 am
If you want to get in the thick of things then something like Games Factory may be more suited to your taste http://www.clickteam.com
This will also give you a basic understanding how a game works from the inside as most of the hard algorithmic stuff is done for you (eg collision detection).
Want to learn programming? Pascal and basic are your 'beginner' languages as they are slightly low level then C/C++ are your bread and butter of languages.
useful sites:
http://www.gamasutra.com
http://www.gametutorials.com
http://www.spritedomain.net/
http://www.libsdl.org/index.php
http://www.gbajunkie.co.uk
http://www.thepernproject.com
_________________
[Blog] [Portfolio]
#13050 - Touchstone - Thu Dec 04, 2003 2:47 pm
| poslundc wrote: |
| Might want to go easy on the guy for his composition skills, Touchstone; you might come across as the pot calling the kettle black. Unless you think it's "exthreemly" unfair of me to say so... ;) |
Well, I didn't mean for the guy to take it that seriously. I apologize if he or anyone else felt offended.
| sajimori wrote: |
What do you learn by designing games on paper? How to be a "Game Designer"? That's a semi-mythical job position, invented by teenage boys who wish they could dream up games and have other people do the hard work for them. The only people who actually carry that title have already proven themselves by doing the hard work on their own, and suceeded at it (think Warren Spector or Sid Meier).
And what problems do you suggest initiates try to solve? Quadratic equations? |
I never said someone should "design games" on paper.
I suggest he figure out what a game screenshot is composed of. Where to use sprites instead of background layers for instance.
| sajimori wrote: |
| Who cares? Not artists. Not designers. Only programmers deal with these low-level details. |
Arists care cause they draw the sprites. Designers care cause they write the design documents. It is true that not all game designers and artists cares about knowing their target hardware but I think that's a big mistake. To some extend all game designers know about the target hardware and game engine or else he simply can't design the game. You couldn't have a gba game designer going "yeah, I'd like the game to look like Doom 3 and play like The Sims. Oh and there should be no any limitations to what you can do in the game world and the game should be played online with atleast 5000+ characters playing in the same world at the same time. The game should also be able to make toast-on-demand".
Anyways, apparently you don't like what I have to say Sajimori, so I suppose it's useless for me to express my opinions further.
_________________
You can't beat our meat
#13058 - sajiimori - Thu Dec 04, 2003 6:49 pm
| Quote: |
Anyways, apparently you don't like what I have to say Sajimori, so I suppose it's useless for me to express my opinions further.
|
Depends on what use you were looking for. I'm not afraid of a little conflict -- I even enjoy it sometimes, as long as there is some point to it. In this case, the point is to make sure that a wide range of viewpoints are expressed in this thread so that it can be more informative to current and future readers.
| Quote: |
I never said someone should "design games" on paper.
|
Ok, then I misunderstood when you said "develop games...with pen and paper first".
| Quote: |
Arists care cause they draw the sprites.
|
This seems to be an issue of semantics. "Sprite" is a technical term that differentiates some graphics by the way they are drawn to the screen. Since artists are not responsible for drawing graphics to the screen, they do not draw "sprites" -- they draw graphics. Only the programmer needs to think about how the software will display the graphics.
Anyway, I guess I'll finish up your argument here by saying that knowing the capabilities of the system often means learning the terminology, so (good) designers will almost certainly know what sprites are. Still, artists really only need to know the size and color requirements (and maybe poly count) of their work -- beyond that, they typically don't need to think about the hardware's capabilities at all.
#13060 - jma - Thu Dec 04, 2003 7:00 pm
I almost never post here in a promoting capacity (my brain tells me that it isn't quite right to try and promote my product on someone else's site).
However, given that you are just learning to program and want to learn to make games on the GBA, why not give Dragon BASIC a try? The url is http://www.jm-basic.com/dragon
If it works for you, great! If not, no harm in trying, but it is much easier than C, and you don't need to worry about the details of the GBA hardware.
Jeff
_________________
massung@gmail.com
http://www.retrobyte.org
#13062 - tepples - Thu Dec 04, 2003 7:06 pm
| sajiimori wrote: |
| This seems to be an issue of semantics. "Sprite" is a technical term that differentiates some graphics by the way they are drawn to the screen. |
To clarify further discussion: An "actor" is an object that moves about the playfield. A "cel" is a bitmap image used to represent an actor or a part of an actor in a given state of animation. A "sprite" is an entry in the display list that instructs the PPU to display a particular cel at a particular position. The video processors in some systems (such as the Commodore 64, the Atari 2600, and the GBA) allow arbitrary modifications to the display list following the raster, allowing a virtual display list system to reuse each sprite to draw multiple actors' cels; others (such as the NES) don't.
| Quote: |
| Since artists are not responsible for drawing graphics to the screen, they do not draw "sprites" -- they draw graphics. |
Or in my standardized terminology, they draw cels.
| Quote: |
| Still, artists really only need to know the size and color requirements (and maybe poly count) of their work -- beyond that, they typically don't need to think about the hardware's capabilities at all. |
Correct, except that artists may also have to know space requirements if the programmers have decided on a codec that uses more space to store more detailed cels.
Now that I've clarified the terminology, does anybody have any objections to these issues?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#13066 - sajiimori - Thu Dec 04, 2003 7:42 pm
Cel is a handy word. Back when I was in my Object-Oriented phase, I sometimes had a hard time thinking of names for different classes. It could be a pain trying to remember the difference between a Cel and a Surface, or a Sequence and an Animation.
The most important thing I learned by doing OOP was the importance of having the right terminology to distinguish between concepts that are truly different. The opposite end of the spectrum appears to be the Lisp community, where it is not uncommon to have deeply nested expressions in which every component is an anonymous contributor to the whole.
#13082 - dagamer34 - Thu Dec 04, 2003 11:33 pm
You want some advice??
Do this(or something like it):
1) Pick a language (just pick one, don't read the chats about one is better than the other)
2) Learn it. Make a SIMPLE game from it. Spend about 3-4 months on this. When i say learn it, i mean know how to set something up quickly so you aren't not repeatedly writing the same code that does the same thing.
3) Now you can move to the GBA.
My choice of a language: C++
_________________
Little kids and Playstation 2's don't mix. :(