What programing language is best for making games?

[GM.Casper]

What programing language is best for making games? I have some ideas for turn based strategies and the like. I plan to stick with 2D.

Any suggestions and advice?

[factotum]

I'd say, whatever language you're most comfortable with. I know there are fairly mature gaming development toolkits available for Java, C#, and C++--there are probably things like that available for most other common languages as well, so do a search to see if there's one for your favourite language.

[akma]

There are many tools for game development, for diffrent languages (there are some tools which don`t require programming knowledge at all).
From my little experience, I highly recommend Love2D (http://love2d.org/). It uses the language Lua, which is a scripting language so it`s slow, but for parts which will have to be fast* you can build code in C and call it from Lua.

*Don`t fall into the trap of trying to make everything as fast as possible. Computers today will run a 2D game with no problems, even if the code is very slow. However, if the AI is simply not good enough in Lua, you could implement the algorithem in C and it would work much faster, which might be a neccesity.

[hawkboy772042]

That depends on which platform you're developing for. e.g. The web environment would be best in flash or Java. But the PC platform would probably be C/C++. For Macs, iPhones, and iPads, it's inevitably, Objective C. For Android it's Java.

In general, you want to use a language that's good for heavy computing and doesn't require too much overhead in CPU usage since you're going to be using a lot of it if your game requires a lot of graphics animations. Fortran, for instance, is really good in that department, but it's not very good in the sense that it's not a language that makes for good organization.

[Grinner]

I'll second LOVE. It's a very well-designed engine.

[Gravitron5000]

I've heard good things about python, using the pygame addon.

[Ellye]

I really, really like Microsoft XNA with C#.

[GM.Casper]

I know Free Pascal and a bit of Java. The games will be for Windows Pc primarily, and rather light on graphics.

Ease of learning and a good IDE would be a priority.

[SMEE]

C# and Monogame works pretty well for 2D games, specially now that Microsoft is phasing out XNA.
Monogame also runs on several other plataforms that are supported Mono by Mono, such as Android devices, iOS, the future Ouya, Playstation Mobile, Next Xbox and hopefully in a short future WiiU and 3DS.

[Neftren]

There are many tools for game development, for diffrent languages (there are some tools which don`t require programming knowledge at all).
From my little experience, I highly recommend Love2D (http://love2d.org/). It uses the language Lua, which is a scripting language so it`s slow, but for parts which will have to be fast* you can build code in C and call it from Lua.

Nobody really programs games from raw scratch nowadays, at least, not AAA titles anyways. Those are typically put together using licensed engines and toolkits--you've probably heard of a few: Unreal, Source, GameBryo, CryEngine, etc. Or at the very least, using some sort of graphics rendering library (e.g. PyGame, Cocos2D, etc.).

From a baseline programming perspective, just about every programmer should be familiar with C/C++. Outside of that, for game engine programming specifically? You might want to look into C# for development on Xboxes, as well as Unity (the new "free" engine on the block).


*Don`t fall into the trap of trying to make everything as fast as possible. Computers today will run a 2D game with no problems, even if the code is very slow. However, if the AI is simply not good enough in Lua, you could implement the algorithem in C and it would work much faster, which might be a neccesity.

:smallannoyed: Please please please try to make everything as fast as possible (within reason). Modern computers have no issues with 2D rendering because the hardware has exponentially exceeded the requirements for 2D. It's still not an excuse for not optimizing as much as possible.


I've heard good things about python, using the pygame addon.

PyGame is great for starting out. Unfortunately you'll reach a point where you feel pretty constrained. It's also incredibly slow.

[SMEE]

:smallannoyed: Please please please try to make everything as fast as possible (within reason). Modern computers have no issues with 2D rendering because the hardware has exponentially exceeded the requirements for 2D. It's still not an excuse for not optimizing as much as possible.


While optimizing is okay, it also makes code less readable and takes time and effort to achieve.
When you're dealing with a small indie team, slow but proved solutions might be the best way to go, specially if you're dealing with 2D only.

[Ellye]

I managed to make my 2D bullet-hell scrolling shooter game so unoptimized that my current generation computer with gaming GPU had trouble running it during some parts.

Then I decided that I probably didn't need per-pixel collision detection, after all. :(

[SMEE]

Per-pixel collision is pretty CPU intensive and definitely not suitable for a bullet hell-game. :smalltongue:

Actually, I don't see too many types of games that would benefit from per-pixel collision.

For my fighting game, bounding boxes are being more than enough.

[Ravens_cry]

Platformers with a lot of jumping and opponents at dynamic heights, it's a good policy in my opinion.Few things are more annoying for an enemy that obviously 'missed' you do damage anyway or falling off a ledge you know you landed on.

[Neftren]

While optimizing is okay, it also makes code less readable and takes time and effort to achieve.
When you're dealing with a small indie team, slow but proved solutions might be the best way to go, specially if you're dealing with 2D only.

Optimization does not necessarily make code less readable. A significant performance boost can be achieved simply through good programming practice. Further optimization takes varying amounts of time, depending on how much speed-up you're trying to get.

A good example of optimization without compromising readability or code quality would be a language that is capable of optimizing tail-recursion to preserve the calling stack (most modern languages support this already). An implementation of say, Factorial is much shorter and cleaner to put together recursively rather than iteratively.

Another excellent example supporting my argument that "optimization doesn't take a huge amount of time" would be the naïve matrix-multiplication algorithm. In a serial (non-threaded) implementation, simply reversing the order of iteration (i.e. 'for k, j, i' vs 'for i, j, k') can potentially double your execution speed by minimizing cache-misses.


Obviously to some degree, there's optimization, and then there's optimization. I'm not suggesting programmers should hand-roll Assembler (this is really really painful to do-- I've done it before) or anything. That's just taking it a bit to the extreme. I'm just saying that there's a lot of optimization that a good deal of people neglect to consider when programming applications, when it really doesn't take all that extra time to figure out.


Per-pixel collision is pretty CPU intensive and definitely not suitable for a bullet hell-game. :smalltongue:

Actually, I don't see too many types of games that would benefit from per-pixel collision.

For my fighting game, bounding boxes are being more than enough.

For 2D games, everyone I know is using Box2D for collision detection. Messing around with pixel counts can be unreliable if you, for some reason, decide to change resolutions.

[Ravens_cry]

From what Shamus Young tells me, use comments. Seriously, being able to explain what you were doing to yourself weeks, months or even years later, not to mention doing the same for other people, saves a butt load of head scratching and cussing down the line.

[factotum]

From what Shamus Young tells me, use comments.

I would hope that's a programmer's standard modus operandi, regardless of what language they're using or what application they're using it for!

[Neftren]

I would hope that's a programmer's standard modus operandi, regardless of what language they're using or what application they're using it for!

You would be horrified at some of the code I've looked at. :smallwink:


I think this is one of the worst pieces of code I've seen this year:


# do some work
def doWork(self):
...

[Emmerask]

From what Shamus Young tells me, use comments. Seriously, being able to explain what you were doing to yourself weeks, months or even years later, not to mention doing the same for other people, saves a butt load of head scratching and cussing down the line.

The most important thing to do is to use descriptive class, method and variable names, especially with modern ides and code completion there is no reason to not use these.

And yes doWork() would be the worst offender in that regard :smallbiggrin:

Comments may be ignored in very short methods that do exactly as the name says, but yes complex or longer stuff where what it actually does is not noticeable at first glance should be commented.

[factotum]

The most important thing to do is to use descriptive class, method and variable names, especially with modern ides and code completion there is no reason to not use these.


But always remember the programmer's mantra: "Self-documenting code...isn't." :smallwink:

[Douglas]

:smallannoyed: Please please please try to make everything as fast as possible (within reason). Modern computers have no issues with 2D rendering because the hardware has exponentially exceeded the requirements for 2D. It's still not an excuse for not optimizing as much as possible.
Optimization in general is good. Premature optimization and excessive optimization are very very bad.

Optimization tends to make your code less readable and more difficult to maintain and modify. It also takes time to do. Trying to optimize every bit of code you write results in a screwed up unreadable mess of a code base that is probably riddled with tons of bugs, and also contains fewer features than you could otherwise have implemented in the same amount of time.

First and foremost, write readable code.

Then, when you're at a testing stage and you note that performance is a problem, analyze the design to determine exactly what part of the program is taking the most running time and why. Then optimize just that part, preferably with a conceptual algorithm change. Done right, this will get you large gains in performance for low cost in rewritten code and lost readability. When you reach acceptable performance levels, stop optimizing.

In general, the things that optimization will make a noteworthy difference on are things where Big O notation (http://en.wikipedia.org/wiki/Big_O_notation) analysis is relevant. If that kind of analysis is not relevant to the optimization you're doing, then you're probably not going to get a big enough gain to be worth a non-trivial effort.


But always remember the programmer's mantra: "Self-documenting code...isn't." :smallwink:
Only if it's done poorly. Properly done self-documenting code will be perfectly clear about what it's doing. If a competent programmer who's never seen your code can't glance at any given line or function name and immediately (without reading any comment in the code) describe in plain language what it does, then your code is not properly self-documenting. It's okay for why your code is doing whatever-it-is to be a mystery, though - that is what comments are for.

Oh, and if you need a variable or function name that reads almost like a complete sentence in order to achieve that self-documenting goal, stop and rethink it a bit. That should never be necessary, and if there really is no more concise way to say it then you probably need to reorganize that section to improve readability.

[GM.Casper]

So can anyone recommend any good tutorials for doing basic graphics in Pascal?

[Grinner]

Pick a graphics library first (http://wiki.freepascal.org/Graphics_libraries). Then find tutorials for that library.

[GM.Casper]

I have no idea which one to pick.

And does the Graphics library License have any relevance, on the off change I manage to actually make anything?

[Douglas]

The license determines what you would legally be allowed to do with your game, and any requirements for doing so. Typical requirements in software library licenses include giving proper credit for the library, bundling a full copy of the library (with license, manual, and maybe source code) with your game, paying the library's developer some amount of money, making your game open source and/or free, and similar things. The details vary a lot, potentially all the way to "do whatever the heck you want, I don't care", and you should read the license carefully to make sure the terms are acceptable to you.

More specific advice regarding license terms would be legal advice, which you would have to seek elsewhere as the forum rules here prohibit it.

[Tengu_temp]

I'd advise against Pascal, which is the programming equivalent of starting a fire by banging two rocks together. At least go with C++, which is like starting a fire by rubbing two sticks together.

Are you completely new to programming? If so, I have bad news: the old saying of "learn to walk before you learn to run" applies here. And making video games is definitely running. If you just leap into trying to figure out a graphics engine first, you're doomed to fail. Pick a tutorial, start with the basics, and start making your game when the tutorial teaches you enough.

Not gonna lie, this will be a long way. If you want to make a video game here and now, use Game Maker or a similar program instead.

[GM.Casper]

I already know the basic stuff. But apparently all the tutorials either assume the reader is an expert, or a total newbie.

I learn best with something practical to do, thus I want to make a game.
Don't want to use GameMaker because 1)it's not free 2) I want to learn proper programming, not skills that only applicable with the GameMaker.


Pick a tutorial, start with the basics, and start making your game when the tutorial teaches you enough.


I know the basics now. In Pascal at least. I could either start making something there, or start learning the basics in another language. But everyone apparently has a different opinion on what to use, so I might as well stick to what I know.