Programming language to use?

[Davey]

I started toying around with game programming, but before I take the time to make something more than just a half-assed demo, I'd like to decide on a programming language. Right now, I'm considering three: C++, C#, and Java.

C++:
C++ is what I'm using right now, along with Allegro to make things easy (and cross-platform). However, I haven't done anything in C++ since my freshman year of college, and now I'm remembering how much I hate pointers and such. Perhaps I just need to get used to managing memory again.

C#:
I'm considering C# because that's what I use at work, albeit for a much different purpose (business app, ASP.NET frontend). I find it much easier and faster to code in C# than C++, although I'm sure part of that is probably due to Visual Studio (although Intellisense is probably making me dumber). However, I'd like to make something cross-platform, if possible. Most C# game examples seem to use DirectX, which obviously won't be cross-platform. It looks like you can use SDL to do this, but I haven't toyed around with that yet.

Java:
From what I've read, Java performance has improved quite a bit in recent releases, and incremental garbage collection can help reduce random pauses. I've hardly used Java at all, but given it's similarities with C# I'm not too worried about that.

What are you guys using?

Yes, I'm reading around the net to get more info, but I could always use some opinions. Mainly, I want to avoid buying books I'll never use...

[Matt McFarland]

Honestly, a lot of people have expressed that using the languages you provided takes much longer to develop a game. Unless you're using libraries , which are abundant. I personally use Blitzmax which you can find at www.blitzmax.com

With blitzmax I have made what you can see at the screenshot below (aside from the graphics, which were done by paid artists) in roughly 40 hours(in pure coding time, and that's largely to the fact that I had no idea how to use blitzmax at hour 1)

SCREENSHOTS HERE: http://www.shmup-dev.com/index.php?topic=40.0

There are about 5 screen shots you can browse.. Just to give you an idea of what you could do in maybe even less time if you put your programming experience in mind.

Also, there is another great C++ SDK called Torque2D, and it comes with a great and easy to use particle generator (which allows you to make cool explosions, etc) and it comes with a map editor, and physics engine, and torque-script for those who dont know C++

If you have money, and you want to make really cool explosions, you should consider using Particle Illusion - which is at www.wondertouch.com . There are lots of programming languages out there like Pure Basic, Play Basic, Dark Basic, Blitz 3D, BlitzMax, etc.

One of the pro's of using Torque2D or BlitzMax is that you can port your game to Mac and linux as well. However, I believe Torque is going to be able to let you port your game to XBOX 360 so that might be even better if you want to put your shareware on XBOX LIVE ARCADE.

[ReKleSS]

C or C++ are the tried and true options... really, pointers aren't a problem once you get your head around the idea. If you really want ease of use, take a look at Python with PyGame (http://www.python.org) which is a nice, straightforward language. It has bindings to just about any library you could need. It's compiled at runtime, so it's not too slow either. You probably won't reach the performance you could get using C and assembly, but I doubt you'll be needing performance that badly...

As for libraries, you might want to take a look at SDL. Cross platform, handles most system stuff you should need, integrates with OpenGL, bindings to most common languages, more up to date than Allegro.
-ReK

[landshark]

Ditto with C++/C. All of a sudden pointers will just 'click' and you'll be angry other languages don't have them.

I prefer C++ to C.

[Dave_K.]

Ditto with C++/C. All of a sudden pointers will just 'click' and you'll be angry other languages don't have them.

I prefer C++ to C.

Don't take this personally, as I'm also a fan of having control over heap and stack memory, but its not a matter of just understanding pointers, its the fact that as your program gets more complex, you are more likely to cause memory leaks or overwrite memory, which causes all this weirdness that takes a long time to debug.

Im a fan of OO as well, but the C++ STL (Standard Template Library) for Linux sucks, still has lots of memory leaks, and is generally avoided by most hardcore developers.

Personally I'd love to see a Java shmup library be developed, and contributed to. Yeah, its hard to stay platform independant when you want to take advantage of graphics hardware, but I've herd the OpenGL bindings have come a long way.

[Davey]

First, thanks to all for your replies.

really, pointers aren't a problem once you get your head around the idea.

I understand them well enough to use them, but like the other Dave said, they can sometimes be a pain in the ass to debug. However, maybe I'll run into less problems once I get back in the habit of using them.

If you really want ease of use, take a look at Python with PyGame (http://www.python.org) which is a nice, straightforward language.

I've never heard of PyGame before (and haven't really done anything with Python), but this could be an option. What is the performance like? You're right that I won't be needing optimal performance... I don't plan on making anything too complex. Right now I just want a relatively quick and easy way to get a simple game up and running.

[landshark]

Don't take this personally, as I'm also a fan of having control over heap and stack memory, but its not a matter of just understanding pointers, its the fact that as your program gets more complex, you are more likely to cause memory leaks or overwrite memory, which causes all this weirdness that takes a long time to debug.

There are lots of tools out there to detect memory leaks and array over/underwrites. I guess I've just been doing it long enough that it's not really a problem anymore. To each there own.

Im a fan of OO as well, but the C++ STL (Standard Template Library) for Linux sucks, still has lots of memory leaks, and is generally avoided by most hardcore developers.

I've used the linux stl commercially and not run into compounding problems. There are memory leaks that are 1-time leaks and are eventually released when the process exits. But other than that, it has worked quite well for me. However, I would not use STL in a game.

Memory structures such as linked lists can be written in a matter of 15 minutes so if you need something like it, just whip it up.

Personally I'd love to see a Java shmup library be developed, and contributed to. Yeah, its hard to stay platform independant when you want to take advantage of graphics hardware, but I've herd the OpenGL bindings have come a long way.

But java is so damned slow. I don't want to start a debate or anything, but I spent 5 years doing java work at my job and it's a complete memory hog and well, it's slow. Don't get me wrong, I really like the language, but I dunno ...

I should probably give the GL bindings a try and see how they are. I've just never been sold on GL for anything fast.

[mrMagenta]

I'd go for Java and LWJGL or like Matt said, some higher level soution. LWJGL is what i'm presently into. I chose it because it's multiplatform and fits mediumsize indie games. I think puppygames are using use the same combo. I'm also making a shmup in gamemaker on the side. performance wise i've had no real issues with gamemaker or java so far. i'm not doing anti-aliasing or shading 1000+ polygon models in gamemaker though but i can do that with LWJGL, so far it doesn't seem all that much slower than C++ and openGL. DarkBasicPro seems like it could be a decent option too if one can stand basic.

The trick is to choose the fastest language and environment that can fill the project needs (fast as in fast development). C++ will always be more powerful.. but time flies.

Java is something different now that it has "just in time compilation", but the time before that still gives it a rep of being too slow for games.

[oNyx]

>I think puppygames are using use the same combo.

Heh. Yea sure. Caspian is the guy who initiated the project. So of course hes using it, too.

One of the most impressive games is tribal trouble. Its even playable on some 500mhz machine with a gf2mx. So, java is really fast enough for most games.

Thanks to JIT and a bunch of other optimisations the speed difference to C++ became very small or non existant. And 1.6 comes with some new optimisations, which give again a pretty nice speed boost. With JIT you have the advantage that you get machine code, which is optimized for *this* platform. Its nice to see that it starts to pay off.

Well, there are always some cons. Like you have some startup time (so its not really suited for small command line tools) and it takes some cycles until all important parts are jitted (so if it runs only for some seconds it will be surprisingly slow in comparsion). It takes some more memory and eventually you lose 10-15% speed.

However, the pros outweigh the cons for small to medium sized games. For one the productivity gain is pretty big (2-5 times) and as long as you dont do anything stupid, the graphics card will be the bottleneck anyways. Oh and you get mac support for free (linux too, but it doesnt really make a difference).

During the last 5 years a lot of things changed and it really became a lot more usable for games than it used to be. Sure you could say I imagine that, because my hardware got faster n stuff... well, thats not the case. I'm still using the same hardware, I used back in 2000 (java 1.2 days)

One cool thing is that you can generate byte code on the fly and run it directly. So you can for example have something like bulletml with native execution speed, but without losing the flexibility of scripting. Evaluating some expression is about 50-100 times more expensive than simply executing it. With many scripted bits you could easily gain a few % more speed. In theory someone could do stuff like that in C++, too... but it doesnt really sound practicable. I would say its several magnitudes more difficult over there.

[Dave_K.]

oNyx, it would be nice to get a peak of your java source for fuzetsu.

[landshark]

You can make low poly games in java, yes. But I still do not see higher poly games becoming a reality in java and ever being on par with C++. It all depends on the needs as you said.

It may be feasible for shmups.

I'm currently fighting with the JDK/JRE. I have no idea why, but anything launched via the web (jnlp files) fail to work. I've tried many install combinations and gave up.

I can run jar/class files just fine.

[Davey]

You can make low poly games in java, yes. But I still do not see higher poly games becoming a reality in java and ever being on par with C++.

What about that Java port of Quake 2? I heard it is now running like 80-90% as fast as the original C code. Actually, that is what made me consider using Java... before that I always thought Java was too slow for games.

[oNyx]

oNyx, it would be nice to get a peak of your java source for fuzetsu.

Well, 4k source is generally *very* bad for learning anything. Its ugly weird cryptic stuff, with unusual constructs all over the place.

There are some interesting things there, but they arent explained and I would say they are pretty well hidden.

Well, I wont make it public, because I think it will do more damage (teaching bad practise, discourage beginners etc) than being helpful. However, I will do release some useful well written and documented stuff in the (hopefully) not too distant future. Its my scripting framework, which helps you writing small to medium sized games. I also used it for prototyping fuzetsu, because... well, its easier and because it saves a lot of time.

For example loading some image (and caching it) and moving it around with a joypad or the cursor keys looks like this:

Code: Select all

import com.kaioa.y3.game.*;

public class TestModuleBsh2 extends Game {
	int x=10;
	int y=10;
	TGATextureManager tga=TGATextureManager.getInstance();
	Texture img;
	public void init() {
		img=tga.add("foo.tga");
	}

	public void tick() {
		x+=Controls.simpleX();
		y+=Controls.simpleY();
	}

	public void render() {
		GTool.clear();
		GTool.drawImage(img,x,y);
	}

	public void destroy() {
	}
}

Then you can change things, save, press F5 for reload and you can see the changes in action some msecs later. (Already loaded media wont be reloaded.)

You dont need to quit the application, you dont need to compile (depends on the loader), you dont need to restart, you dont need to reload any media...

Excuse the shameless pluggage, but its really nice stuff.

You can make low poly games in java, yes. But I still do not see higher poly games becoming a reality in java and ever being on par with C++.[...]

Tribal Trouble uses low poly models, because there can be thousands of em on screen. Worst case was around 2000 iirc.

The poly count doesnt really make a big difference... as long as you dont use immediate mode. Thats because you have a *tiny* overhead per gl call. If there are shitloads (say 50000 per frame) of calls this overhead adds up, therefore you end up with surprisingly bad performance. However, if you batch up things properbly with VAs or VBOs (which you should do anyways) then that overhead doesnt really matter anymore.

[landshark]

You can make low poly games in java, yes. But I still do not see higher poly games becoming a reality in java and ever being on par with C++.

What about that Java port of Quake 2? I heard it is now running like 80-90% as fast as the original C code. Actually, that is what made me consider using Java... before that I always thought Java was too slow for games.

Quake 2 is a low poly game. I'd love to see something like Far Cry attempted in Java, or Morrowind.

Java games and engines always seem to be on the tail end of things. Quake 2 was made around 10 years ago wasn't it? I haven't seen anything 'current' ever done.

Yes, you can create as many things as you can with vertex buffers and such.

But it's still a memory pig

[mrMagenta]

There are no Far cries in java because most middleware, tools, expertise and reusable resources for large scale dev are geared toward c++ and in such productions you need to stick with an environment that has a proven track record to keep everyone happy. and ofcourse one shouldn't go about making a game that vast without a large team of developers and dedicated programmers hacking away. those are prolly the main reasons why you don't see far cry in java.. yet... but i'd also like to see an attempt on something like that.

there's also a silly thing.. c++ is considered more prestigous among programmers. but thinking that way is pretty backwards. the future is in time effective tools. especially in independent dev.

Yeah, Tribal Trouble is a good example of effective design. It has style while keeping things simple.

OnyX
a question: can you use some kind of namespaces in java so that LWJGL GL calls don't have to precede by GL11. or GLU. etc? haven't found anything on this. i've written "GL11." so many times.. seems a bit heavy.

[oNyx]

[...]
But it's still a memory pig

Thehe

Well, the thing with those latest AAA first person shooters is that that fart of memory overhead wouldnt make a difference. No one cares about a handful of mb (~8mb for the vm and ~40bytes per object) if the game already needs around a gig for the massive amount of content.

The latest commercial (non indie) game written in java is Myst V. Google brought up this gallery: http://www.myst5.com/myst5gallery.html

Oh and there was Chrome (and soon there will be Chrome2), but its afaik "dirty" java like Vampires the Masquerade.

And those latest FPS arent really that hi poly. All those details are done with shaders and we all know that those run on the GPU anyways. The detail level of the used models is about the same as in Quake3.

The reason why you wont see all that fancy stuff in most homebrew java games is that its a) very complicated, b) content creation takes too long and c) the minimum system requirements would be too high. Additionally you would need to implement different rendering pathes for different hardware capabilities. I rather target opengl 1.2 and only lose about 10% of possible customers instead of... say... 1.5 and losing 90%, which doesnt really sound appealing.

Ah well, I cant work 100+ years* on a single game anyways. I wont live long enough for finishing it. And no one would be interested in something that dated.

[* One F1 racing game from 2000 took 100 people working full time for 4 years. Sure there are other AAA games with "only" 20 people working 2 years... but still... stuff like that is totally out of reach.]

You need to be realistic about what you can actually finish. And there are other factors you need to consider like how much performance/ram you actually need and if spending more time with programming (c++ heh) will actually make a difference.

Like say... you make a shump in java which needs 500mhz, 128mb ram and a geforce 1. Imagine the same thing in C++. You "only" spend twice as long with programming and now the system requirements are 450mhz, 96mb ram and (still) a geforce 1, and the download is now 3mb smaller (compared to the windows version).

Is it worth the trouble? Unlikely, because the previous system requirements were already at the very end of a PC's lifetime. The smaller filesize yields maybe 1-2% more finished downloads (which means 0.01-0.10 times more sales). But at the same time you lost mac (very important) and linux (well, no work for you so dont complain) completely, which cuts your sales in half. Ouch.

However, if I were in charge of some new AAA game I would decide to go the C++ route, because there is lots of nice middleware and I wont mind spending shitloads of money on em. (And of course because it wouldnt be me who needs to debug that stuff... ).

[oNyx]

[...]
a question: can you use some kind of namespaces in java so that LWJGL GL calls don't have to precede by GL11. or GLU. etc? haven't found anything on this. i've written "GL11." so many times.. seems a bit heavy.

In 1.5 there is static import. Once you static-ally imported GL11 you can omit it.

However, I advise you not write any 1.5 code right now, because the mac user base still uses 1.4 for the most part.

That "GL11." bit seems to be more annoying than it actually is. Once you abstracted things away you wont need to write it anymore.

edit:

[...]there's also a silly thing.. c++ is considered more prestigous among programmers. but thinking that way is pretty backwards. the future is in time effective tools. especially in independent dev.[...]

History repeats itself.

C is too slow... you should write everything in ASM.
C++ is too slow... you should write everything in C.

And now managed languages are to slow and you should use some unmanaged one (and implement your own managment there... haha... yea, right).

[TalkingOctopus]

I agree with oNyx. Java and other alternatives to C++ are probably fast enough and can save you lots of time, especially if you don't develop software for a living. Pointers and memory managment can become a nightmare.

...but the C++ STL (Standard Template Library) for Linux sucks, still has lots of memory leaks, and is generally avoided by most hardcore developers.

Do you have any sources for this? It is news to me.

I made a puzzle game in C++ and SDL. I thought SDL w/ C++ was pretty easy, but I've worked almost exclusively with C/C++ and (unfortunately) assembly at school/work. I haven't released the game yet, because the artwork and animation are not the greatest and I have not had a chance to work on it lately, (it takes me forever to do graphics). After I finish this game, I would like to eventually make a shmup.

[mrMagenta]

Myst V is pretty. I wanna play it.

oNyx
Thanks for the tip, didn't know about static import. You're right.. those GL11. will get tucked away eventually.

heh humm, would you mind peeking at my image and/or image font classes and give me some general pointers. i'm sure i'm doing some obvious bads. the problem isn't connected only to computer performance, a computer with a radeon 9800 GPU was as slow as my laptop with integrated Intel chip, while on my other computer (radeon 9700) it zips along fine.

[oNyx]

[...]
heh humm, would you mind peeking at my image and/or image font classes and give me some general pointers.[...]

You can try to catch me over at [url=irc://irc.freenode.net/lwjgl]#lwjgl[/url] (I'm "aho" there). Or you could ask at the lwjgl forums or over at JGO.

And you also might want to checkout kev's stuff.

[mrMagenta]

danke! i'll check those once i've caught some sleep, mIRc seems to be acting up atm. the kev link looks great.

[landshark]

Well, the thing with those latest AAA first person shooters is that that fart of memory overhead wouldnt make a difference. No one cares about a handful of mb (~8mb for the vm and ~40bytes per object) if the game already needs around a gig for the massive amount of content.

I don't have any sources, only from past experiences with java - but I have to say there is more than just 8 megs of vm and 40 bytes per object overhead.

The latest commercial (non indie) game written in java is Myst V. Google brought up this gallery: http://www.myst5.com/myst5gallery.html

Now that's interesting. I had no idea any commercial games were written in java. I've been meaning to pic this one up.

Oh and there was Chrome (and soon there will be Chrome2), but its afaik "dirty" java like Vampires the Masquerade.

What do you mean by dirty java?

The reason why you wont see all that fancy stuff in most homebrew java games is that its a) very complicated, b) content creation takes too long and c) the minimum system requirements would be too high. Additionally you would need to implement different rendering pathes for different hardware capabilities. I rather target opengl 1.2 and only lose about 10% of possible customers instead of... say... 1.5 and losing 90%, which doesnt really sound appealing.

I understand that. But I still don't see that much "work" overhead with C++ once you have your libraries available or created (from previous projects).

History repeats itself.

C is too slow... you should write everything in ASM.
C++ is too slow... you should write everything in C.

Hahahah ... I remember all those usenet wars. I love asm

[Dave_K.]

...but the C++ STL (Standard Template Library) for Linux sucks, still has lots of memory leaks, and is generally avoided by most hardcore developers.

Do you have any sources for this? It is news to me.

This is from expierence working on a large scale (web scale) data analytics project processing billions of documents. At this large scale, even the smallest unfreed memory, or inefficient algorithm, bubbles up to make things unbelievably slow or eventually crash. Probably not as much a problem for game developers, but like I said, hardcore programmers don't like even the smallest leakage or inefficiency.

[oNyx]

[....]
What do you mean by dirty java?
[...]

There are two ways. With opengl wrappers (like lwjgl) you access some C methods, which allow you to use opengl.

The other way is having some C or C++ program, which invokes a vm and you basically run java stuff within your progamm. So you can for example use some pre-build 3d engine for the rendering and the game logic can be written in java.

Quake3 for example also used some VM for the logic (it wasnt java tho, but at least they thought about using it).

Well, imo it isnt really a good idea, because keeping stuff in sync is tiresome and error prone.

You can find some articles if you google for: gamasutra "dirty java" (Keep in mind that those articles are pretty dated. Be sure to ignore any performance related "tricks".)

[landshark]

[....]
What do you mean by dirty java?
[...]

There are two ways. With opengl wrappers (like lwjgl) you access some C methods, which allow you to use opengl.

The other way is having some C or C++ program, which invokes a vm and you basically run java stuff within your progamm. So you can for example use some pre-build 3d engine for the rendering and the game logic can be written in java.

Quake3 for example also used some VM for the logic (it wasnt java tho, but at least they thought about using it).

Well, imo it isnt really a good idea, because keeping stuff in sync is tiresome and error prone.

You can find some articles if you google for: gamasutra "dirty java" (Keep in mind that those articles are pretty dated. Be sure to ignore any performance related "tricks".)

Ok. I thought you meant some proprietary java VM. I haven't heard of too many people embedding java into their engine. They usually go the route of lua, python, or proprietary.

[ELLioT]

Hi all.

Is Anybody familiar with PlayBasic ?
http://underwaredesign.com/

Is there any C-like Struct feature in DarkBasic ?

[MaNaR]

I'm using DarkbasicPro to create my shooter.

The editor and language aren't the best in the world but at least you don't have to worry about creating a 3d engine or how to load 3D models, textures or even mp3's.

There is also a c++ sdk for Darkbasic which allows you to program in c++ using all darkbasic features. Here is a link:
http://darkgamesdk.thegamecreators.com/

[the2bears]

Onyx and others are correct, Java and OpenGL combined are fine for shmups. There's a much different approach to coding a game, it's not your average day job with Java. You manage your objects intelligently etc. For goodness sake, the Naomi boards and Dreamcasts are still running shmups without complaint! Java on a new machine with LWJGL is certainly more power than that.

Bill