First Everything
Author
Im brand new to game programming...I have never written nething and I know nothing about different languages. So what should be my first language to learn.
What should my first program be. Thx for any help you can give me.
I suggest Python. There is a Beginner's Guide, and the documentation includes a Tutorial.
As to what program you should write first, well, "Hello World" is traditional -- though it is more intended to test that you've installed your system properly than anything else. Since Python includes an interactive interpreter, you will probably start by reading the tutorial and trying out individual commands directly in the interpreter -- to see what happens.
What programs you do after that depend on your particular interests though, again, individual tests of library functions you find interesting or useful would be typical. At some point, you will want to install PyGame, which provides functionality for making games.
As to what program you should write first, well, "Hello World" is traditional -- though it is more intended to test that you've installed your system properly than anything else. Since Python includes an interactive interpreter, you will probably start by reading the tutorial and trying out individual commands directly in the interpreter -- to see what happens.
What programs you do after that depend on your particular interests though, again, individual tests of library functions you find interesting or useful would be typical. At some point, you will want to install PyGame, which provides functionality for making games.
If Python doesn't work for you, you may want to try C#. You can download Visual C# .NET 2005 for free right now.
i wouldnt suggest either because you may develop bad habits using these.. i would suggest getting a book called Beginning c++ Game Programming by Michael Dawson, since your new its all going to look eqwually hard so why not start with the hardest like most... and then every other language is a sinch to learn... i definantly suggest c++ but i suppose its up to you
Quote:Original post by willthiswork89Defiantly indeed..
i definantly suggest c++ but i suppose its up to you
C++ is about the hardest language there is to learn (if not to use when you actually know it), full of intricacies and special cases. Besides many (arguably) good coders started out in something much simpler, in my case it was QBasic and I managed to transfer pretty much everything I learned straight into C.
I'm not going to recommend any particular language, mostly since I don't have enough experience with any modern languages besides C++ but also since these discussions inevitably degenerate into flame-wars. Still, I do have fond memories of various game-oriented languages (mostly Amos and Blitz Basic).
Quote:Original post by willthiswork89As opposed to C++ beginners?
i wouldnt suggest either because you may develop bad habits using these..
In order to offset the unsupported arguments in this thread, I recommend not starting with C++, as it may lead you to developing bad practices.
Seriously, trust the moderators.
Seriously, trust the moderators.
I agree with the moderator's suggestions, but I fail to see how learning C++ can cause you to develop bad habits. What kind of bad habits? Most of the 'bad habits' exhibited from C++ programmers are because they're trying to do in C++ what they did in C, or some other language...
Quote:Original post by RDragon1Well, what constitutes bad habits is mostly a matter of opinion. But suffice it to say that you can (and will) develop these in all languages, mostly from trying to bend it into something it's not.
I agree with the moderator's suggestions, but I fail to see how learning C++ can cause you to develop bad habits. What kind of bad habits? Most of the 'bad habits' exhibited from C++ programmers are because they're trying to do in C++ what they did in C, or some other language...
And I wouldn't say they're necessarily bad per se, instead it's often just a matter of what's considered good style in a particular language. I mean, don't throw away a perfectly good hack just because it isn't object oriented enough..
You can start with C++ if and only if you have a really good teacher available. Otherwise it's a craptacular language to start with. And a good book doesn't cut it for the teacher requirement.
C++ is a bad language to start off with for several reasons, but they all boil down to this: C++ puts a lot of trust in the programmer. A beginning programmer, by definition, does not deserve this trust. There are a lot of things you can do in C++ that look like they what you want, but actually don't, and many of those show up in really bad ways that will take you forever to figure out why they're screwing up. If you ever figure out. Some things you can patch without understanding the root cause, but it only pushes the symptoms of the error to a different spot. If you try learning C++ on your own you may develop bizarre beliefs based on the bandages you've placed on your code that silenced symptoms rather than actually solving root causes.
Take for instance the common misconception that you shouldn't throw exceptions from constructors, or the irrational belief that one of our otherwise intelligent posters here has that you shouldn't put cleanup code in the destructor.
C++ is just not suited for self guided instruction and this is compounded by the fact that you've got all these other self-taught yahoos on the internet who have these bizarre patchwork of misconceptions that they try to foist off on others when they ask questions on message boards or newsgroups. You should go look at some my older posts here on gamedev. I honestly believed at one point that std was an alias for the global namespace. Actually, on second thought, don't do that. No use contaminating your brain with the half-baked nonsence I thought before actually sitting down and reading the C++ standard.
C++ is a bad language to start off with for several reasons, but they all boil down to this: C++ puts a lot of trust in the programmer. A beginning programmer, by definition, does not deserve this trust. There are a lot of things you can do in C++ that look like they what you want, but actually don't, and many of those show up in really bad ways that will take you forever to figure out why they're screwing up. If you ever figure out. Some things you can patch without understanding the root cause, but it only pushes the symptoms of the error to a different spot. If you try learning C++ on your own you may develop bizarre beliefs based on the bandages you've placed on your code that silenced symptoms rather than actually solving root causes.
Take for instance the common misconception that you shouldn't throw exceptions from constructors, or the irrational belief that one of our otherwise intelligent posters here has that you shouldn't put cleanup code in the destructor.
C++ is just not suited for self guided instruction and this is compounded by the fact that you've got all these other self-taught yahoos on the internet who have these bizarre patchwork of misconceptions that they try to foist off on others when they ask questions on message boards or newsgroups. You should go look at some my older posts here on gamedev. I honestly believed at one point that std was an alias for the global namespace. Actually, on second thought, don't do that. No use contaminating your brain with the half-baked nonsence I thought before actually sitting down and reading the C++ standard.
A significant amount of C or C++ beginners are Golden Hammer adepts. They were told their language can do everything, and is the fastest around, so they tend not to consider (or discard hastily) alternatives that would result in less code and less bugs.
When presented with a new language (for instance, Caml Light, in the class I give), instead of trying to learn how it can be used efficiently, they attempt to transpose their experience of C++, which results in highly unefficent approaches, and conclude that no other languages are worthy of using, except by 'newbies that cannot handle C++'s raw power'.
There is a block in a beginner's transition from a low-level language to a higher level language, which does not occur in the reverse transition. The low-level education insists on the 'machine' part of programming (efficiency, memory manipulation, bare-metal working, full powers to the coder, the coder is all-powerful), while high-level education insists on the 'human' part of programming (the biggest threat to the program is the coder, the weakest link in any computer system is the coder, code is the least desireable thing and should be kept to a minimum). A programmer only trained in the 'human' part will be forced to acknowledge the 'machine' part of programming, because he will always run into it and will not be able to work around it. However, a programmer trained in the 'machine' part will always be able to find workarounds around the 'human' part: these workarounds will take days longer to implement, will be bug-prone and impossible to maintain, but will allow the programmer to stay in a blissful ignorance of the most important element of programming — productivity.
While some people are mature enough to realize their wrong ways, many stay in this state of mind for a long amount of time.
When presented with a new language (for instance, Caml Light, in the class I give), instead of trying to learn how it can be used efficiently, they attempt to transpose their experience of C++, which results in highly unefficent approaches, and conclude that no other languages are worthy of using, except by 'newbies that cannot handle C++'s raw power'.
There is a block in a beginner's transition from a low-level language to a higher level language, which does not occur in the reverse transition. The low-level education insists on the 'machine' part of programming (efficiency, memory manipulation, bare-metal working, full powers to the coder, the coder is all-powerful), while high-level education insists on the 'human' part of programming (the biggest threat to the program is the coder, the weakest link in any computer system is the coder, code is the least desireable thing and should be kept to a minimum). A programmer only trained in the 'human' part will be forced to acknowledge the 'machine' part of programming, because he will always run into it and will not be able to work around it. However, a programmer trained in the 'machine' part will always be able to find workarounds around the 'human' part: these workarounds will take days longer to implement, will be bug-prone and impossible to maintain, but will allow the programmer to stay in a blissful ignorance of the most important element of programming — productivity.
While some people are mature enough to realize their wrong ways, many stay in this state of mind for a long amount of time.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement