This topic is 3851 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hey out there, Just the other day I bought "Game Programming for Teens" in order to get a good grasp on programming. My true dream is to become a Game Designer, but I'm aware that it's much easier to get your foot in the door of a company with some other skill (such as programming).I'm eager to get involved with community projects but know that there's almost no chance in doing so without knowing something other than how to write and come up with ideas (which is where I am pretty much). So, I've read good reviews about this book, but never see the language it teaches you, BlitzPlus, mentioned in any of the forums as one recommended beginners. So far (Chapter 3) it's been simple. Even easier than Visual Basic which I became familiar with last year. My question is: should I start out with something else like Python or Pascal? Or should I continue my training in BlitzPlus? Though I'm sure some of you will reply saying that all 3 are good for beginners, I suppose my real question is which will give me better preparation for C++? Any insight would be great, thanks!

##### Share on other sites
Pascal was written as a language to learn C and C++ so I guess that's good. Starting out though; just learn what you find easiest. All procedural languages are pretty much the same, so don't sweat it.

C++ is the current industry standard, so it's worth learning it at one point. It's important to get a good C++ book, otherwise there are some undefined areas, or gotchas that will hurt you.

##### Share on other sites
Good preparation for C++ is computer science theory.

BlitzPlus isn't considered a "real" language. But it can get your job done fast.

So decide on what you want - write games fast, regardless of how they are coded, or learn proper software engineering (5+ years) for use of any language, including C++ (knowing it is a huge plus, since it requires extremly solid understanding of computer architectures).

Game designers are cheap. Everyone has hundreds of ideas for the next greatest game. But eventually you need to put your money where your mouth is.

BlitzPlus and similar toolkits are fine for some prototypes. But even then they simple don't scale to anything serious.

Pascal is for all practical purposes obsolete. Visual Basic and games simply don't mix. Python, Java and C# are the tools you're supposed to know these days.

But when it comes to software engineering and concepts it requires, C++ is still the defacto required knowledge, even if the language is getting used less. C++ simply covers so much ground, that being proficient in it will make learning anything else easy.

But above all, you will never get a job based on what you want. If you're looking for a practically applicable simple and easy language, look at Flash. Flash skills are in high demand, the tools provided are powerful, and it even allows you to use it outside of game world.

##### Share on other sites
I'd seriously recommend C. In my opinion it's the most immediate preparation to learn C++ later.

greetings.
seb

edit: and for the startup, I'd recommend the following open source (lightweight) ide's:

*GNU/Linux*
-Code::Blocks (http://codeblocks.org)
-Anjuta (comes with most distros)
*Win*
-Code::Blocks
*Mac*
-Code::Blocks :D

And as nearly all GNU/Linuxen are highly coder friendly, they come with the GNU Compiler Collection (GCC), which contains the gnu c compiler (gcc. yes, very case sensitive).
As gcc is regarded as standard in the open source field and easily competes with ICC (Intel C Compiler) and esp. with MSVC (Microsoft) I highly recommend it (code::blocks has a windows-installer including a win-port of gcc, btw).

[Edited by - greenhybrid on June 2, 2007 10:56:17 AM]

##### Share on other sites
Quote:
 Original post by BalaamPascal was written as a language to learn C and C++ so I guess that's good. Starting out though; just learn what you find easiest. All procedural languages are pretty much the same, so don't sweat it.

Huh? Is it true that Pascal was written to learn C/C++? Pascal was designed for teaching purposes and ease of natural language syntax, not to learn C or C++. Pascal was even released before C.

Taran Shiro, just learn Pascal. But if you even want to possibly go easier than you might want to try its descendant Modula-2, or ITS even more compact descendant Oberon-2 (there's also Oberon-1 but forget that). The only problem with this is that there aren't many resources to find probably. So in the end, for learning, go for Pascal (FreePascal: http://www.freepascal.org/) or Modula-2.

##### Share on other sites
Quote:
 Original post by BijoTaran Shiro, just learn Pascal. But if you even want to possibly go easier than you might want to try its descendant Modula-2, or ITS even more compact descendant Oberon-2 (there's also Oberon-1 but forget that). The only problem with this is that there aren't many resources to find probably. So in the end, for learning, go for Pascal (FreePascal: http://www.freepascal.org/) or Modula-2.

Alright, thanks. I'll definitely take your advice look into it. After all, it is one of the most frequent recommended languages from what I've seen.

##### Share on other sites
If BlitzPlus is working for you, then stick with it. As you have noticed, one of its drawbacks is that not many people use it (just the people that read that book, I guess)> But at this stage, that is not a huge drawback, so stick with it until you have finished the book and have proven to yourself that you are ready to move on.

I suggest Python as the next step. C++ is a difficult language to learn and it will just slow you down at this point. Depending on how far you want to go with programming, you may want to learn C++ eventually, though.

Another good choice might be Flash. The reason it is a good choice is that with Flash you can make complete games very quickly and put them up on a web site so others can try them out.

##### Share on other sites
*Insert the usual recommendation for c# here*

(I won't bother wasting valuable minutes typing more as there's a million posts about c# already).

##### Share on other sites
Quote:
 Original post by JohnBoltonIf BlitzPlus is working for you, then stick with it. As you have noticed, one of its drawbacks is that not many people use it (just the people that read that book, I guess)> But at this stage, that is not a huge drawback, so stick with it until you have finished the book and have proven to yourself that you are ready to move on.I suggest Python as the next step. C++ is a difficult language to learn and it will just slow you down at this point. Depending on how far you want to go with programming, you may want to learn C++ eventually, though.Another good choice might be Flash. The reason it is a good choice is that with Flash you can make complete games very quickly and put them up on a web site so others can try them out.

yeah, that seems like the wisest thing to do. I'm a junior in high school so I have plenty of time to make my way to the industry standard C++ if I choose to do so. Thanks for the advice :D

##### Share on other sites
Quote:
 Original post by gharen2*Insert the usual recommendation for c# here*(I won't bother wasting valuable minutes typing more as there's a million posts about c# already).

Quoted for truth. C# and XNA is IMO the way to go for new programmers, nowadays.

##### Share on other sites

Right, I'm bored and I need something to fill my time while waiting for this video file to render so...

# Game Programming FAQ Part 1, Draft 1.

## A:

This is easily the most frequently asked question on these forums. It's also very hard to explain the answer without going into some detail about what it entails...

Programming is not magic. It is not particularly hard. It's also not maths, regardless of what you may have been told.

Programming is how you tell a computer exactly, and in very, very anal detail, what you want it to do. Precision and accuracy are key. An understanding of cause and effect are also very useful, as is a grasp of basic logic.

All programming languages boil down to the same thing in the end: the computer's own native tongue, generally known as Machine Code. Now, I'll explain what Machine Code is first as this is an important point to understand. It will also help you understand many aspects of programming.

Machine Code: The computer's native language.

Machine Code is numbers. That's it.

Computers don't know about anything other than numbers. All a computer's processor ever sees is numbers. Imagine a long, long row of identical boxes. Each box contains a number. (Specifically, an integer -- i.e. a whole number like '1' or '77' or '973'. No fractions.) The number can have two meanings:

1. An order, or instruction, to be performed immediately.
2. A value, or "operand", which is used by an instruction.

For example, let's imagine that the first two boxes contain the following numbers:

BOX 1: 66
BOX 2: 9

You fetch the '66' from the first box. You haven't been given an order yet, so this becomes your first order. You were designed to 'know' that 'Order 66' means "Take the number from the next box and jump forward that number of boxes."

So you pick up the next number -- '9' -- and move forward a further nine boxes. Now you're at Box 11. You've finished your first order, so you now know that the number in Box 11 is your next order. You pick it up...

...and so on, and so on, and so on. That is, quite literally, all a computer processor ever does. It picks up numbers, processes them, moves them around, tests them against other numbers, and continues on and on in this vein until you switch it off.

The programmer's job is to provide context.

For instance, when you push a button on your keyboard, the number in one of those boxes will change to reflect the button you pressed. A programmer will know which particular box to watch for this and write a program to read that number, do some simple maths to work out which letter it was, then tell the processor to run another bunch of instructions which tell it how to draw that letter on the screen.

The maths abilities of a typical processor tends to be limited to the simple functions found on most pocket calculators. In the early days of the 8-bit computers like the ZX Spectrum and Commodore 64, processors didn't even know how to perform simple division and multiplication. Programmers had to write instructions for the processor so it could do even these basic functions. Today, they can generally manage basic trigonometry, but don't expect one to do calculus or understand imaginary numbers.

Also, those boxes can only contain integers within a fixed, unchangeable range -- usually defined by the number of bits a processor can process at a time -- processors also have a hard time dealing with very large (or extremely precise) numbers and have to be told how to deal with these too. (There is, for example, no way to store 'infinity' in one of those boxes, nor can a computer ever understand that concept.)

The trick is to understand that the processor has no bloody clue what it is it's doing. It's just following orders. It's the programmer's job to know that some memory boxes correspond to the pixels on the screen. It's the programmer's job to work out ways of drawing lots and lots of those dots very quickly to make pretty animations happen. Similarly for sound, reading joysticks, making them rumble, reading and writing data from a hard disk or a network... etc.

To make matters worse, each processor family -- Intel's Pentium / Core series; IBM's PowerX series; Freescale's PowerPC / Cell series; ARM's cores (used in most mobile phones), and so on -- has its own specific machine code. Instruction code 66 will mean different things to the processor inside your PC and to the XScale CPU in your mobile phone. This is one of the main reasons why programs written for one platform, such as the PC, won't run on another, such as a games console.

*

Machine code, as you can guess, is not a pleasant language for humans to work with. It's just numbers. Over the years, many people with beards and terrible social lives have invented programming languages which we humans can work with more easily. The first was "Assembly Language". This was just a case of assigning simple, short words to each machine code number, so instead of "66 9", we could type "JUMP 9". It's easier for us to follow, but as each processor family had its own machine code and, therefore, its own Assembly Language, it wasn't very advanced. (An "Assembler" is the name of the program which translates the Assembly Language into the Machine Code. As this is just a case of looking up each Assembly Language word and writing out the code, these were pretty simple.)

Some languages were quite odd. LISP, for example, processed lists of information which were linked by logical chains. COBOL, an early language aimed at business software development, was famously very verbose and resulted in programs with lines like this:

           ADD 1 TO STOCKTOTAL

Other programming languages were much more terse -- C and C++ being the classic examples. The above example might look like this in C:

          ++stockTotal;

These languages were more complex than Assembly Languages. They had to be parsed and analysed carefully as some of the more powerful instructions corresponded to a great many machine code instructions.

These complex programming languages must still be converted into machine code. How this is done has long been a bone of contention.

Compiled languages are translated all in one go, with the end user only ever seeing the machine code file. (E.g. a ".EXE" file in Windows, or a ".app" for Mac OS X.) This was considered the Gold Standard for programming languages as it meant your program would run as fast as possible. However, if there is a bug in the code, it'd invariably cause a crash.

Interpreted languages are translated piecemeal, while running. This makes them run more slowly as the processor has to first translate each line of code into something it can understand, before it then performs the instructions the programmer intended. An advantage of this system is that it makes development much faster. If an error is found in the code, the interpreter will usually spot it and catch it before it can do any serious damage. It can also bring up the offending line of code and tell the programmer exactly where the error occurred.

Many programming languages designed for the Web, such as Ruby and PHP, are interpreted. These are often referred to as "scripting languages", but this is just the new, fashionable name for "interpreted languages". It's still programming.

In recent years, the line between Compiled and Interpreted code has become blurred. Interpreters now store their translations as they go, so the next time the processor needs it, it doesn't have to translate it again. This is known as "Just-In-Time Compilation". (This is most famously used by Java programs.)

Another variation is for the compilation process to be done when the program is being installed on the user's system. This allows the compiler to optimise it for each specific computer it is running on. (This is the system used by the .NET programming languages.) This is also known (confusingly) as "Just-In-Time" (or 'JIT') compilation. Both methods are also occasionally referred to "Deferred Compilation".

BASIC used to be almost exclusively Interpreted. However, most modern dialects are now compiled, including all three Blitz Basics and DarkBasic.

*

There are two major schools of thought about how programming languages should be designed:

"Generic Languages"

These are your 'Jack-of-all-trades' languages. C and C++, for example, have been used for anything and everything, from hardware drivers to operating systems right up to games and even word processors. Their primary fault is that they tend to become increasingly bloated as each industry tries to twist and change the languages to better fit their needs.

The games industry has, for reasons best explained while on narcotics, standardised somewhat around the C "family" of languages. (C++ is a direct descendant of C and is mostly compatible with programs written in C. C# was inspired by C and looks very similar, although it won't run either C or C++ code without major changes.)

"Domain-Specific Languages"

These languages are designed to fit a particular industry niche. For instance, Microsoft's Visual Basic was designed from the ground up to build Windows applications. And nothing else. There was never any intention to produce a version of Visual Basic for, say, building graphics card drivers, or mobile phone operating systems. Examples relevant to the games industry include the likes of BlitzMAX and DarkBasic. (Both are dialects of BASIC.)

Domain-specific langauges tend to focus on doing a few related things well. BlitzMAX, for example, is a BASIC dialect aimed at building 2D games. You can heave sprites and bullets around the screen with ease. But try and get it to handle a printer or video camera (or even complex 3D) and you're out of luck.

So-called "Scripting Languages" are often domain-specific.

*

## So which programming language should I learn FIRST?

A professional programmer is always learning new programming languages. Each one will also open your eyes to new ways of approaching programming problems. (I strongly recommend studying LISP and Forth at some stage.) However, this doesn't really answer your question.

The problem with recommending a specific language is that I'll inevitably get flamed by all the fans of other programming languages. Languages like Python, Ruby, C++, C, C#, Java, COBOL (okay, maybe not that), Modula-2 and so on are all very good languages. But I feel that someone who wants to get started making game really ought to begin with a domain-specific language aimed at this industry. You'll get much quicker, more rewarding results, more easily than with a more general-purpose language like C++ or C#.

The simple fact is that BASIC -- from "Beginners All-purpose Symbolic Instruction Code" -- and Pascal were designed specifically for students and to be easy to learn. (BASIC is one of the few programming languages never to have been standardised, which is why there are so many, seemingly unrelated, dialects.)

For this reason and this reason alone, I strongly recommend something like BlitzMAX, DarkBasic or Blitz3D as your starting point. While you certainly won't find anywhere near as many resources for these as for, say, C++, the simple fact is that you probably won't understand most C++ resources right now anyway. The support environment for these domain-specific languages may be small, but it is much more focused on your own goals: building simple games quickly and learning how to program at the same time.

Your first step is to wrap your head around the process of translation. You begin with a concept or a set of instructions you'd like your computer to perform, and the programming part is translating those into a language the computer can understand. Once you realise that there are only so many ways to write "IF (CONDITION) THEN (ACTION)", it becomes much, much easier to move on to other languages and you can then focus on the really hard part: learning the platforms. ("Windows & DirectX" is a platform. "XBox360 + XNA" is another platform. "MacOS X & OpenGL" is yet another platform. "Linux & OpenGL" is yet another... and so on. And don't get me started on the umpteen mobile phone 'standards' out there.)

In all honesty, my opinion is just that, and is based on 20-odd years in this industry. There are certainly people with a natural talent for programming and if you're one of them, congratulations. If not, you'll still have a much better grasp of how computers actually work than the vast majority of the people on this planet. This is always useful.

In any case: good luck.

##### Share on other sites
hey,
if I were you, I'd start off with c++ to begin with! that's what I did, and everything is working out fine for me, I don't have any hard time understanding anything. sure, Pascal and Python are probably a whole lot easier than C++, but I honestly don't see why you should have to "build yourself up to" C++.

by the way, I've personally been asking around about what a game designer works with. I think you might be mixing up the title "game designer" with "game programmer", 'cus how I've understood how it works, game designers don't need to know programming, they need to know what the people want in a game, whatever makes the game sells, that's what the game designer needs to know. then it's the game programmer's job to take those ideas, and make a game out of 'em...

I hope I was to any help for you..

##### Share on other sites
Quote:
 Original post by lajosephhey,if I were you, I'd start off with c++ to begin with! that's what I did, and everything is working out fine for me, I don't have any hard time understanding anything. sure, Pascal and Python are probably a whole lot easier than C++, but I honestly don't see why you should have to "build yourself up to" C++.by the way, I've personally been asking around about what a game designer works with. I think you might be mixing up the title "game designer" with "game programmer", 'cus how I've understood how it works, game designers don't need to know programming, they need to know what the people want in a game, whatever makes the game sells, that's what the game designer needs to know. then it's the game programmer's job to take those ideas, and make a game out of 'em...I hope I was to any help for you..

Would you pay someone to build you a house if they had absolutely no idea how houses are built? No? Then why in Codd's name would you expect a business to hire a game designer who has no idea how games are actually made?

A game designer does need to know how to program. He should also have a solid grasp of visual arts, music, audio, QA processes, asset pipelines and basic scheduling. (The line between "Game Designer" and "Producer" is blurred.)

In short: a game designer needs to know enough about each medium he's dealing with to recognise bullshit when he hears it.

You don't need to be a seriously hardcore programmer, but you must have some idea of what's involved in the process or how else will you ever know whether a design is even remotely feasible? (And before anyone shoots back the hoary old chestnut that knowing where the limits are limits your ideas, please give me your proof. Almost every original computer game genre on this planet was designed by programmers. "Limiting"? My arse! If anything, knowing how it all works can often open the door to new ideas.)

I would not hire a game designer who couldn't put a simple game together on his own. Ever.

##### Share on other sites
sorry, just sharing what I "know"... I'm still learning the differences between the different offices within making a game, sorry!
atleast I learned something new ^^
and good luck becoming a game designer!

##### Share on other sites

This topic is 3851 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.