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.

Q: Which programming language should I learn?

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.

Quote:Original post by lajoseph
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..

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.