Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Siquo]

It totally depends on the type of game. Plenty of good games are made in java, in flash, in python, and in c++.

If you want high-end CPU/GPU intensive games, you'll need c++. For anything less than high-end a scripting language will suffice.

And then there's java

[C4lv1n]

Here's my plan for anyone that cares:
Make a prototype in VB, the language I am familiar with, then, once it's done switch over to C++

[Eagleon]

Decent plan. You'll figure out the overall logic of your game's components, without having learning a new language's syntax and ugliness get in the way of progress. VB is great for prototyping, something most people ignore as a strength. If you know what you're working towards you know what to learn in the new language, which will seed the learning process in an ideal way.

[Outcast Orange]

That's exactly how it was for me.
I knew what I wanted to do, and how it would work,
 but the only language I knew was very limited.

Basically I found C++ equivalents of everything I was already familiar with,
 spent a few extra hours reading parts of the C++ Primer,
 and just started throwing code together to test its uses and see what I could do.

Every time there was something (reasonable) I didn't know how to do,
 I'd bother Alfie until he explained it to me.

[Bricks]

I enjoy python due to its readability, and the fact that I've never taken a class in a higher language.

The biggest problem with starting a game is getting something to display on screen.  Otherwise, it's easy to lose interest.  Find a good library.

If you are set on a roguelike, and don't entirely dislike the ASCII feel, I'd recommend libtcod.  With your language of choice, it's easy to quickly put together a playable game, and its full-color, so it could be somewhat graphical.  It already has a lot of nice algorithms implemented, like heightmap generators and FoV algorithms, but the meat of the game would be your responsibility.

[qwertyuiopas]

No matter what language you use, just keep working with it until you succeed. VB probably won't have the power for graphics(though you probably can shove OpenGL there, and get something decent), and anything you don't know means having two tasks instead of one(each with many steps to completion), but then you know an additional language and it will be easier to use it next time you need it.

One option for years from now is to start working on code you use often, and make it into a library that you can re-use. I plan on putting graphics file parsing into a .dll for personal use later, and one advantage of that is that I could add support for a new filetype without recompiling any old code that uses it. But such goals are for years later, if at all, since often the desired functionality exists in some other library... (I'm getting off track quickly. Should stop.)

[Normandy]

Y'see, the reason people use C++ for OpenGL programming is because most of the literature involving OpenGL is written with C/C++. If you think finding documentation on obscure features is hard in C++, try finding it in other languages. You'll quickly figure out why people program in C++ when using OpenGL. Also, you know that rather obscure console, the Xbox 360? You know those really graphically intensive games, they must be written in C++ right? They're actually written in C# (sort of): The Xbox 360 only runs managed code.

Really, the speed difference between all of the languages is negligible. By programming in C++, you don't magically tell your processor "hey, I'm a C/C++ programmer, ipso facto you run my programs faster". A 32-bit signed integer is a 32-bit signed integer anywhere (except for maybe when we're comparing dynamically vs. statically typed languages). The other commonly cited arguments: memory management, interpreted/compiled, are mostly nil as well. Memory management only makes noticeable differences under certain circumstances; and if you've ever written even a simple garbage collector (and if you haven't, you don't really have the credentials to be discussing the relative merits of different languages in the first place), you'll see that memory management doesn't magically introduce twice as many operations when before there was only one. The difference between interpreted/compiled code nowadays, is negligible as well - they still operate on the same processor.

The key to optimization is proper design. Do not choose a language simply because "it's faster". A skilled programmer utilizing the proper optimization techniques and knowledge, no matter what language used, will always write faster code than a not-so-skilled programmer. And C++ is hardly any more "powerful" than any other language. If it satisfies Turing Completeness, it is already the most powerful language you'll ever need. But you'll hardly see anyone recommend that you program in this language. But hey, look at the total lack of available features! Look at how close to the metal you get! Surely we are all folly for not programming in it.

[Siquo]

All Normandy said is true (emphasis on his "mostly" and "negligible"), but also true is that programming in C++ makes you look cool. 

[qwertyuiopas]

However, few high-level languages can interface with COM or similar binary standards without the compiler/interpreter specifically supporting it. C/C++/other low level languages give you the power to decide how your data is stored in memory. Usually, it doesn't matter, but when it does, such languages excel at it.

(COM is a system where a program gives access to one or more interface. An interface is a pointer to a table of function pointers. Thus, it is faster than accessing like a DLL. Additionally, an interface is identified by a GUID, a very large number generated originally based on the current time and your MAC, though more recent versions have put encryption in there, so there is little or no chance of ever generating conflicting GUIDs. All of this becomes important when you consider that it allows a program or DLL to basically say "I do that" and give a consistant interface for doing that, without any potential delays like finding a function in a DLL(And it mimics C++'s classes' vtable format). All of this is irrelevant except as example of the powerful tools present in low-level languages. However, COM is supported by many high level languages as a compiler feature. Making an ole control involves a few standard COM interfaces including IOleObject. VB and others will be able to do that silently during compile, but if a new binary standard comes out that is equally popular, VB programmers must wait for their compilers to support it, and the older compilers probably never will, leaving only the people who stay with the most recent and thus expensive compilers to have access to it...)

[Muz]

I'm personally biased towards instant game making products. Game Maker, Construct, Multimedia Fusion, RPGMaker, AGS, Adrift, and so on. You get good, graphical games. A lot of indie games sold use some of them, and many of the games that are fun to play do, so they're not really short of power.

It depends really on what your intention is. If you have an idea for a game and want to work on it as fast as possible, go for the game making products. But if you say, want to learn VB/C/Python/etc, actually want to spend your life with that language, and want to have fun learning it by creating a game, then it's a good idea to steer away from the quick game making stuff.

Funny thing is that on DF, everyone seems to want to sprint before they can crawl, always aiming for the language that's more efficient and stuff, but it's really not a good way to consider it. With say, C++, you'd probably spend like 2-4 years just trying to get to the stage where you can do a basic adventure game. And a few more years trying to make a 3D adventure game. And many, many more years before you even bother with optimization and stuff. Unless you're incredibly motivated.

With something like Multimedia Fusion 2, it took me literally a day with no programming experience to build a simple graphical bat-and-ball game. You'll probably never be able to code Dwarf Fortress or even Dungeon Crawl with it, but while you're learning it, you learn why those techniques they teach you in college are good. You learn a lot of good game design skills and experience, which you wouldn't if you start off from C, because you'd simply be spending more time programming than actually making games.

If there was only one "perfect" programming language, everyone would be using it and no other languages would exist. This may be true in the case of C++. But it's not, and you'll have to figure which is the best one for you.


But in short, what I use...
Pure game making, minimum flexibility and computationally inefficient:
Modding existing games (Warcraft, Civilization, Mount and blade, Dwarf Fortress)

Low flexibility, good time spent on making games:
AGS, Adrift, RPGMaker

Good flexibility, poor programming efficiency, excellent game-quality to effort ratio:
Multimedia Fusion, Construct, Game Maker

Prototyping concepts:
MATLAB, VB, Lua

Languages that there's a lot of game making resources on, maximum flexibility and control, minimum return on effort:
C, C++, Python, Java(?)

I'd discourage anything that you can't find some game-making tutorials on from a quick google search. If you're not taking a degree in comp science, you'd have a hard time getting resources for what Google doesn't give.

[alfie275]

Look at how close to the metal you get! Surely we are all folly for not programming in it.

You know assembly? The "machine code" as it were. Well C++ actually lets you use assembly with the __asm__ keyword.

[Normandy]

I've never really once touched assembly. I kind of want to learn it, but it's low priority. The effort required to ensure that it works safely far outweighs its benefits nowadays. Meh, it's all really moot. Getting something done is far more important than any choice of language. I should know, I suffer badly from it  .

[Blacken]

Oh boy. So much fail.

VB is slow, no way around it

...

My suggestion would be Java. The syntax takes a bit of getting used to, and there's a slight learning curve in figuring out why everything is the way it is, but it's a lot more readable than C++ IMO, and there are some similarities that will get you ready should you wish to start learning C/C++ as well.

Do you not realize why this post is hilarious?

(Hint: VB builds to the CLR just the same way Java builds to the JVM. Hell, Java can build to the CLR via J# or IKVM. Furthermore, VB is essentially a syntactic layer on top of C#, which, too, is a C derivative and shows significant similarities to C++.)

C++ is going to be fastest, the only excuse to use a "nicer" language is lazyness.

Or any number of other reasons for using a modern tool: rapid development, simple extensibility (Mono.Addins is fucking wonderful), object reflection, actual type safety (you do know that C++ is essentially type-unsafe if you're doing anything even remotely indirect, right?)...I could go on, but you get the picture.

"Fastest" only very rarely matters, and it's trivial in most modern languages to use a C or C++ library where native code execution speed is required and use a modern, safe language for operations where it is not.

generally awesome post

This. This this this this this.

However, few high-level languages can interface with COM or similar binary standards without the compiler/interpreter specifically supporting it.

.NET and Java both support it, and I think Python does as well. Not a big deal.

Here's my plan for anyone that cares:
Make a prototype in VB, the language I am familiar with, then, once it's done switch over to C++

Not a bad plan, if you enjoy masochism, but I would amend it thusly: once it's done, if I find I need additional performance, rewrite portions of it in C++.

See--there's a lot of people around here who beat the "C++ is the Master Language" drum, but the worst-kept secret around here is that there's very little that C++ actually gets you. There is no inherent benefit to writing code in C++, so I would suggest not doing it unless there is actually a demonstrable win out of it.

I'd look at C# before C++, to be honest. I can even say that you already essentially know C#: VB and C# are semantically extremely similar. The primary difference is syntactic (both are on .NET, and they're so similar that there are tools out there to directly port VB code to C# and vice versa--MSDN even shows examples of C# and VB code side-by-side). C# is much closer to the "standard" idiom of programming than VB is, and will let you easily branch out into that area while remaining in something of a comfort zone.

[Siquo]

Oh, and don't use C#. It's a decent enough language, (it's the good stuff from Java with the good stuff from C++, with more OO than either) but it restructures your brain and turns you evil. All C# developers suffer from this, but can't see it themselves.

[Outcast Orange]

I thought that was Java?

Oh right, incompetence.