Some prefer oysters while others prefer snails (and some prefer both)......

Quote:Original post by alunharford
Brainfuck is *the* language for portability.
It's not a nice language for people who've never programmed in assembly, but it's SERIOUSLY easy to write a compiler for.

Ook! is vastly superior to brainfuck in all aspects.
You are correct though, BF is easy to write compilers for, though an optimizing compiler might be tricky.

As any of the other posts, this one is only a comment and an advice.

I would recommend that before choosing a programming language, you should shift your attention to more important issues at the beginning of the development of your game. More important questions at this stage include:

What is the target platform? (Windows, Linux, etc)
Is it portable, i.e., does it run in Windows and Linux (and other OS's), or does it run exclusively in a single OS?
Are the graphics 3d or 2d?
Is graphical performance critical? (Smaller games do not require the best graphics card)
Is there a deadline? Is time even a factor?
What is the game genre (RPG, RTS, something completely new)?
Is the game static or expandable? E.g.: Are there exactly N weapons (if any) in the game, or is there a possibility to customize and add your own weapons? Will there be new types of enemies or not?
Will you need a script engine?
Is it open source?
What is more important to you: the development of the game (to learn how a graphics/physics/sound engine is done) or the game environment (story, characters, look and feel, etc)? If development isn't that important I recommend using third-party engines (Ogre3d or irrlicht, etc) so you can focus on what really is important.

These questions should be answered before choosing a programming language.
Don't choose a language because you are more comfortable with it. Choose one that gives you more power to do what you want to do.

Some side notes.
I would recommend reading books on game development and architecture (if not yet done) before jumping to the code. The one I like the most is "Game Architecture and Design", from authors Andrew Rollings and Dave Morris. The book is somewhat pricey so I would only recommend buying it if the game is going to be a medium to large project.
Also, for medium and large projects I recommend learning UML or, at least, create your own scheme.
I believe this is the best advice I can give you: if you plan to do more games after this one, write as much info during the development phase as you can, so you can learn from past mistakes and have better productivity in the next one.

I hope this post will help you to achieve your goals.