So... what language to pick for Game Development ?

dysoco · 2012-04-14 23:06:48

Well, I know Languages aren't the most important thing when it comes to programming, they are just tools, but you need to focus in one right ?
So, I've been looking for my "perfect language" for a while, I know programming: I know Loops, Conditionals, OOP, I/O, that kind of stuff... but I've never really worked in a project (Except for some C# Apps and games),
so I don't have "Real world experience".

I run Arch Linux + Windows 7 in my Desktop, and Mint Debian in my laptop (I like diversity ), I've done some basic 2D stuff in C# + XNA, wich, I think: It's a great Framework.
But I don't want to be a Windows developer, now I only run GNU/Linux in my laptop, and I play less so I'm always in Arch.

Then, I'm looking for another language + framework to suit my needs.
C and C++ are far too low level for me, I'm not even in College yet (I plan to study CS) and I'm not really atracted to this kind of low level stuff.

I tried Python, and I know it can be compiled with CPython making it faster, and has PyGame, a really good Game Framework, I've tried it, but I'm not comfortable with the
syntax, I don't like the concept of using Identation and not Curly Braces, so I guess it's not the best choice for me.

Java... I've heard it's a bad language, I've used it and it's almost the same (In Syntax) as C#, but as I said, I've heard it's slow and bad... I'm not sure what to think, because some great games
are written in Java (Minecraft, Runscape, etc.).

Ruby seems like a nice language, I tried it once with Rails, I like it's syntax, but I don't know if it's suited for GameDev, maybe it's slow.

Now I tried Haskell, I've never used Functional Programming before, and I must say I love it, I solved the 1st Project Euler problem with a simple "sum [x | x <- [1..999], x rem 5 == 0, x rem 3 == 0]" (I think it was like that)
But I don't know if it's suitable for Game Development, I've seen some games written in Haskell, but I can't find a good Game Library/Framework to use it with, and now I'm loving it for that kind of Mathematic stuff, but who
knows? maybe it's a pain to write games in it without OOP.

So... any ideas ?

niriven · 2012-04-14 23:46:22

I would choose C, C++, Java or C# depending upon my speed needs and what systems I want the game to work on. All languages suck you just have to pick the right tool for the job. Not to knock ruby but the threading in Ruby is horrible, and with most games you will want to do threading.

If you want to do anything with complex 3d graphics, I would avoid any managed language (Java, C#, Python, Ruby) and stick with a native language. If you want to go 2d or text just pick your favorite language, but be aware that not many people are going to want to install a virtual machine to run the game. If you program something in .NET chances are a Linux guy wont want to install mono just to play a game. Python is available on most all Linux distros these days, but not on windows unless you choose to bundle with your game or force the user to download and install it. Native code, although an inconvenience to the developer always works out to be an easier experience for the person downloading your software in most cases.

Also be open to creating games that are accessible in the browser using JavaScript and some gaming libraries for the web, but these will be restricted to 2d / text games mostly (although WebGL for 3d is evolving but still slow).

ewaller · 2012-04-15 00:01:21

Well, what are you planning to write?
Something that plays chess or go?
Something that needs high frame rate graphics with millions of vertexes per sec?
A nice adventure game maybe?
Something that generates word and games like crossword puzzles or Suduku?

Yes, languages are a tool. Some are close to the hardware (C, C++), some protect the programmer from themselves (Manged code), some provide excellent tools in which to implement game theory (Lisp, Haskell, Python)

Awebb · 2012-04-15 00:08:47

If it's going to be a 3D game, I'd say python + blender could be a good start.

/dev/zero · 2012-04-15 00:17:13

I would call up some local game companies and poll them on what languages they use. Then I would look for open source projects that fit in either or both of two categories: projects using the preferred language(s), and gaming projects.

As with any job, you'll get in if you can confidently address the selection criteria. So also look up job ads for game programmers and look at what qualities they're after. Probably, you'll be able to address most of the criteria if you're an active contributor in an active project. See paragraph 1.

drcouzelis · 2012-04-15 01:32:10

I've written many "video games" (I never finish them) as a hobby over the past many years. The languages I've used to make a game include:

C (not C++)
Objective-C (but not Cocoa)
Java
Ada
Python
Assembly

Libraries I've used include:

Allegro
SDL
PyGame

I make a video game in order to learn a new language or library. It doesn't matter what language or library I used, all of the games I've made run fine.

I really don't think it matters what language or library you choose. For example, the Cocos2d library is written in 100% Python and it can handle pretty much any type of game. Just research the different languages and libraries, pick one that you want to learn, and start using it.

I might even go so far as to say that, if you're making a video game using any current library with any relatively current computer and you find that the game is running too slowly, it's not the fault of the the library or programming language.

KingX · 2012-04-15 05:48:07

C/C++ is probably your best bet if your focus is to make big 3D games (or be part of a team who works on one ). There is irrlicht and ogre3d game engines for making 3D games. It would be worthwhile to spend some time learning OpenGL as it will come handy down the line.

Java just gets a bad rep due to Oracle. If you feel comfortable with it then run with it. For simpler stuff really you can pick anything and see how it turns out, you will end up a learning a lot anyways.

Blµb · 2012-04-15 09:17:11

For a serious game I have to object to the earlier stated blender+python suggestion.
If you need real performance:
C, or *very low level* C++ (ie: use it only for example to operator-overload a vector class)

If you just want a simple 2D thing:
any language will work really, so long as it has some rendering capability

Generally: the more lowlevel the language, the better the performance.
This is not about "java is slow" - but about the fact that java simply doesn't really allow you to make efficient use of resources, since you simply do not have any lowlevel access as to how your final code will be organized, and all calls to renderers, like openGL, are wrapped in java classes, and even this small overhead can be pretty devastating if you need to render lots of things in single frames. Sometimes it's even noticable in simple 2D games, in which case I often ask myself what the developers were thinking...

Last edited by Blµb (2012-04-15 09:17:45)

Grinch · 2012-04-15 11:50:28

Well, like countless others I'm also working on a couple of games (which will be done 'any' day now, lol!). I'm doing my stuff in C (and just recently also in Go with glfw bindings) but really it's mainly a question of what you feel comfortable with unless you are making some AAA titles were every cycle counts. Since you mentioned you liked PyGame but wasn't comfortable with the syntax, I'd like to propose Löve. It's a lua based framework, and although it doesn't use curly brackets it uses function/if/elseif/for...end style encapsulation which may be more to your liking. Also it's a very nice community with lots of example code/demos and even full games with source posted regularly. I've used it briefly myself for some prototyping and I really like it. Also it wraps box2d into a nice physics framework if you are into sandbox games.

Take a look at and see if it's your cup of tea: https://love2d.org/

Bellum · 2012-04-15 14:57:48

I think criticism of Java tends to be overstated. It has its limits and it's a bit verbose, but it's a fine language. And it's proven itself capable of churning out multiplatform games cheaply. I'd take it over Python. Dynamically typed languages feel awkward to me. It's slow, though. No way around it. But not as slow as Python.

splittercode · 2012-04-15 15:27:46

Since you mentioned Haskell, I'll say that there are SDL bindings for Haskell that work great. Here is a decent tutorial for writing a simple 2D game using them. I don't know if writing a game in Haskell would be very good preparation for a real world job in the video game industry (if that is your intention), but it sure is fun.

Awebb · 2012-04-15 16:24:28

Blµb wrote:

For a serious game I have to object to the earlier stated blender+python suggestion.

Hey, he said he isn't even in college yet, so he has plenty of time at hand, right 8)

drcouzelis · 2012-04-15 18:55:43

Blµb wrote:

For a serious game I have to object to the earlier stated blender+python suggestion.
If you need real performance:
C, or *very low level* C++

What are your objections to writing a game using Blender and Python?

If a graphics library needs more performance than is provided by Python, then it can be written in C and imported into Python. (such as with PyGame) Since the OP is interested in writing a video game and not a graphics library, it doesn't matter which language they choose, since the most processor intensive part of the game will be written in a language that can handle it.

Awebb · 2012-04-15 19:00:41

Yeah, I was suggesting that the OP asked the wrong question, he should have asked: "Game development, where should I start?" It is obvious, that a game written in Haskell won't run on an iPhone. Cownose, the cat, that's why I suggested the blenderpython duo, as it is not teaching too much about game programming, but it is a good start for game development overall.

holland01 · 2012-04-16 06:07:16

If you really want to get serious about it, drop XNA and go straight to C++ with SDL or Allegro (hint: use SDL - it's much better). Then move onto OpenGL when you feel comfortable with that.

I know, C++ is hard. And the pointers (oh, dear...the pointers) are the worst hurdle (I'm not talking conceptually; I'm talking physically in terms of debugging and proper practiced use of them) for any programmer new to an unmanaged language such as C/C++. But guess what? You'll become a better programmer, and you'll also have a better idea on what you're doing.

I can tell you right now that before I really got into C++ I had made a few attempts at cracking the language and trying to understand it. Didn't go very well, because I was so intimidated by its massiveness. However, one day I just upped and decided to learn it, and I stuck with it by doing a simple pet project which helped me learn it (trust me, it's more fun that way - as opposed to "studying" the language bit by bit).

Also, since you're on linux, learn to use Valgrind; it's an invaluable tool. Ontop of that, get a handle for GDB (GnuDebugger).

After spending a few weeks with C++, if you find it's not for you (which, damn it, I'll say it one last time: you SHOULD learn it), go with Python or Java. Both are cross platform have great communities and support for game development.

Trust me: if you already know the basic fundamentals of programming, you're ready for C++.

Ishpeck · 2012-04-16 13:26:37

holland01 wrote:

If you really want to get serious about it, drop XNA and go straight to C++ with SDL or Allegro (hint: use SDL - it's much better). Then move onto OpenGL when you feel comfortable with that.
I know, C++ is hard. And the pointers (oh, dear...the pointers) are the worst hurdle (I'm not talking conceptually; I'm talking physically in terms of debugging and proper practiced use of them) for any programmer new to an unmanaged language such as C/C++. But guess what? You'll become a better programmer, and you'll also have a better idea on what you're doing.

The same argument could be made for going with straight C. In some ways, you could say that C is an easier language. It doesn't fight with some counter-intuitive ideas found in the STL, it has a few, very simple core concepts, and it will force you to be even more capable with pointers.

Now I tend to hate proprietary platforms as much as the next guy but I don't know that dropping XNA is entirely the best decision. If one prioritizes exposure, the distribution mechanisms matter. This is why MSFT's Live Arcade and Valve's Steam are favored (in spite of the obnoxious demands they place on developers).

My advice to the original poster is to pick a technology you're comfortable with and excel at it. Lots'a folks will try to prescribe things to you based on their personal preference but at the end of the day, there's really no right way to build a game. In fact, games tend to be bad software. This is okay so long as it's fun to play.

drcouzelis · 2012-04-16 13:55:20

holland01 wrote:

SDL or Allegro (hint: use SDL - it's much better)

In what ways do you feel SDL is better than Allegro?

I find them to be incredibly similar, but the Allegro API to be a little more tailored to writing video games (which could be a good thing) and the SDL API to be a little more of a generic media library. (which could be a good thing)

ewaller · 2012-04-16 14:43:06

I anticipate feedback from the OP with bated breath.

dysoco · 2012-04-16 17:34:13

ewaller wrote:

I anticipate feedback from the OP with bated breath.

Sorry, I was traveling this weekend.

So, I've heard of SFML, wich is a more "modern" SDL library for C++, more Object-Oriented, etc.
What do you think ? Anyone has tried it ?

It might be more difficult, but you're true: If I want to go serious with GameDev, I need to know C++... though, I'm not planning to work as GameDev... but who knows ?

Daedalus1 · 2012-04-16 18:18:24

It sounds like you would be good using the D programming language. It's a compiled language so it's just as fast as C++ but was reinvented from the ground up so it's not as ugly as C++. It's multi paridigm, can interface to C libraries, and optionally garbage collected.

It's a new language so it's not used often but the compiler has matured recently and is in the [extra] repository. It's mature enough to handle any project C and C++ can do at this point.

sudo pacman -Sy dmd

D Language Overview

I recommend learning some C as well though so you can call C libraries easier and reason about how they work, especially OpenGL. I've used SFML, it's faster than SDL because it isn't software rendered and has good object orientation.

Last edited by Daedalus1 (2012-04-16 18:34:49)

sas · 2012-04-19 16:38:47

For game programming, I think starting out by choosing an arbitrary programming language and then going from there, might not be the right way to go about it.

Instead, I would suggest narrowing it down in this order:

What kind of game do you want create?
Which toolkit/library/framework is best suited to base such a game on?
Which programming languages can be used with this framework?
(many freely available frameworks are written in C or C++, but also have bindings for other languages)

As for C++, note that it's only as complex/"low-level" as you choose it to be... ;-)
You don't need to use its many "advanced" features unless you want to, and many game/graphics programming frameworks available for C++ have lots of convenience API that shield you from much of the complexity that's going on behind the scenes.

----------

I'll probably get flamed for this (by hardcore C/C++ hackers and Gnome fans alike), but if you're interested in getting started with C++ games programming without having to deal with too many advanced/"low-level" C++ features, may I suggest you take a look at the Qt toolkit...
It's a generic C++ GUI-programming toolkit that provides a simple and consistent API (which uses only simple C++ features for the most part), and provides its own container classes and additional language features (like e.g. foreach loops, signals & slots, etc.) which IMO make C++/Qt programming much more newbie-friendly than dealing with the corresponding low-level C++ features and the C++ standard library directly.
Other noteworthy advantages of Qt are (IMO):

It has a very high-quality online documentation (especially compared to what most other open-source projects have).
It has an nice dedicated IDE, Qt Creator. You can of course use any IDE or text editor for Qt application programming, but Qt Creator makes it even more convenient.

For game programming, Qt provides four main options (the choice depends on what kind of game you want to create, and how "low-level" you want to go):

Using the Qt Widget framework directly [C++]
A traditional Qt application (game or otherwise) consists of "widgets", which can be conveniently laid-out/stacked/nested using "layouts".
To create a custom widget (for example a canvas on which the actual game content will be drawn), one basically needs to subclass the QWidget class, and in the custom sub-class implement the paintEvent() function which will be automatically called every time the widget needs redrawing. An advanced events handling framework allows responding to keyboard/mouse/joystick/touch events.
You will have to manage all "state" information of your game, as well as implement the logic of when to draw what, by yourself - this gives lots of flexibility, but is a lot of work and requires you to deal with low-level concepts like event-loops, etc...
The actual painting can be done in two ways (which can also be mixed):
- Using QPainter
  This is a powerful 2D painting framework provided by Qt, which allows performing many pixmap and vector drawing operations (drawing jpg/png/svg/... images; or lines/polygons/rectangles/ellipses/splines/text/...) as well as transformations (rotating, shearing, ...), filters (desaturate, colorize, ...), composition modes, patterns/gradients, path stroking, etc. in an easy, imperative fashion.
- Using OpenGL
  The QGLWidget class, which you can subclass instead of the normal QWidget, provides paintGL()/resizeGL()/initializeGL() convenience functions (which will be automatically called at the appropriate times) in which you can put QpenGL rendering commands.
  In addition, Qt also provides convenience classes for using OpenGL framebuffer objects and the like.

Using the Qt Graphics View framework [C++]
This is a more high-level framework based on QWidget, which conveniently manages scenes (QGraphicsScene) of large numbers of 2D graphical items (sprites/tiles etc.) and efficiently draws them (and allows the user to interact with them) on a QGraphicsView canvas. The framework takes care of remembering the positions and transformation (scale, orientation, ...) of all items in the scene (and allows the developer to dynamically modify these), and also allows global transformations on the view (e.g. zoom / pan). The framework also intelligently decides which items need to be repainted at which time (in a customizable way of course), and support various useful features like defining parent-child relationships and performing collision detection between items.
Ready-to-use convenience classes exist for pixmap and text items as well as items showing basics vector graphics primitives (ellipse, polygon, ...).
For creating items with a custom paint function (using the QPainter framework already mentioned above), or for making items selectable/clickabe/movable or respond in some other way to mouse/keyboard/joystick/touch events etc., one only needs to subclass one of the existing convenience item classes or the generic QGraphicsItem class, and implement the relevant member functions.
The QGraphicsEffect class provides a way to add pixmap effects (blur, drop-shadow, colorize, ...) to items in the scene.
All in all, if you want to develop a sprite/tile-based game (anything from chess to a Civilization-clone) using C++, the Qt Graphics View framework might be a good choice.
- "40000 chips" demo; - "colliding mice" example

Using the Qt Webkit framework [HTML + JavaScript (optionally also C++)]
Nowadays it seems to be "in" to use HTML+JavaScript for developing apps and games.
I'm not a big fan of this trend (HTML was never designed for that), but I might as well mention that Qt provides a Webkit-based browser framework which makes it possible to turn an HTML+JavaScript scene into a stand-alone application, or into a widget inside a bigger application.
I think the framework even provides some API to mess with the internals of the HTML scene (and its JavaScript objects) from the C++-side of the application that is embedding it.

Using the Qt Quick framework [QML + JavaScript (optionally also C++)]
Qt Quick is a relatively new addition to Qt, but is expected to become the default way of creating application user interfaces with Qt. It is not yet ready for replacing C++/QWidget in traditional desktop applications (due to missing look & feel integration), but is already becoming popular for mobile (smartphone/tablet) UI's, as well as (simple) games.
---
Qt Quick allows defining graphical, dynamic user interfaces using QML, a custom JSON-like declarative language invented specifically for this purpose. The QML files can then be embedded in a C++ application that calls the Qt Quick engine to interpret them at runtime. (Qt also ships with a stand-alone tool, qmlviewer, which can execute QML files directly.)
QML, unlike HTML, excels at defining pixel-perfect, sophisticatedly-layouted, modern, fluid UI's in a declarative way. Things like complex scalable layouts, input validation, focus handling, states, animations and transitions, dynamic property bindings, data presentation using model/view paradigms, reusable components, etc. can all be conveniently defined without having to write any imperative source code.
In addition, JavaScript functions (implicitly or explicitly defined, or even loaded from external .js files) can be used in event handlers ("onClicked" etc.) and other places, making it possible to implement all UI logic - or if desired even the whole application logic - in pure QML+JavaScript without any C++.
---
Here's a sample QML snippet (and a screencast of its result) to get a "feel" for what it is like:

(Note the dynamic property-bindings, used to define a property using an expression that references other properties. Every time one of the referenced properties changes, the calculated property will automatically be updated accordingly.)
---
It is also possible to implement the user interface using QtQuick/QML but the internal application logic using traditional Qt/C++ (for bigger applications, and apps which do performance-critical work in non-UI parts, this is recommended)...
- pure QML+JavaScript example; - QML example using C++ for game logic
---
The current stable version of the framework, "Qt Quick 1.x" (which is shipped with Qt 4.7 and 4.8), is based on Qt Graphics View (which in turn is based on QPainter). It is possible to tell QPainter to use QpenGL instead of software rendering for its drawing operations, but the performance increase is not that big because QPainter's imperative drawing paradigm is not what OpenGL (and modern graphics hardware) is optimized for.
Qt 5.0, which is expected to be released some time this year (first alpha was released two weeks ago) offers a new, written-from-scratch "Qt Quick 2.0", which is internally based on a new scene graph architecture which is highly optimized from the ground up for getting the most out of modern graphics hardware (it requires OpenGL/ES 2.0 or newer to run), and additionally comes with a much faster JavaScript interpreter (V8, developed by Google).
The actual QML syntax remains pretty much compatible with Qt Quick 1.0, but come with additional new features like perfectly fluid video playback, advanced particle effects, and the ability to define GLSL shader effects directly in QML.
- two nice Qt Quick 2.0 demos (QML+JavaScript only, no C++) [Youtube]

Some potential disadvantages of Qt are:

Many Gnome users (among others) avoid installing Qt-based applications like the plague. I don't think this dismissal is rational in most cases, but it's a fact - so you might loose some of your potential customer base if you use Qt for your application.
[I think the reasons have to do with the fact that the KDE desktop is based on Qt, and KDE is often seen as bloated/slow, so this prejudice (unfairly) reflects back on Qt. I guess historic feelings of rivalry between GTK/Gnome and Qt/KDE users also play a role, as well as the fact that in the beginning Qt wasn't a true FOSS project (it is now, though), and the historically bad look-and-feel integration of Qt apps into the Gnome desktop (which has also very much improved in the mean-time, though).]
I expect this whole situation to become less and less of a problem now that Ubuntu ships with Qt pre-installed by default, and distros in general care more about good look-and-feel integration between the different toolkits.

It uses a different naming scheme for class/function names ("QSomeClass") from what the C++ standard library (STD) and most other libraries use ("std::some_class"). Which one is nicer is a matter of taste, but if you ever need to use the STD or another external library with your Qt application, chances are you'll be mixing naming schemes which won't look too nice.

The fact that Qt implements its own container classes and similar features (instead of using the ones from the C++ standard library or Boost), and even dares to add its own convenience features to the C++ language using a custom pre-processor system, makes the heads of hard-core C/C++ purists explode... :-)

Last edited by sas (2012-04-30 18:28:13)

kyla · 2012-04-20 00:32:37

C++, if it's going to be at all graphically intense. (C is ugly, C++ isn't, and isn't much harder to learn than Java.) Because I cry everytime a game won't run (or run well) on my netbook because it was written in Java rather than C/C++ *cough*Minecraft*cough*

Daedalus1 · 2012-04-20 06:19:48

Sas makes an excellent point with Qt. It's good if you want to create a Qt game and I've done some projects in Qt + QtCreator (great IDE). I wouldn't use it for everything, it's a good library for getting GUI apps out there quickly, but I prefer more fine grained control and not being hidden from the inner workings of the programs too much. Qt hacks many features into C++ to make up for its bad design, effectively becoming its own language. If you want a compiled language more like C# and the power of Qt, I'd still argue D is the best way to go, it has bindings to the Qt library as well.

Last edited by Daedalus1 (2012-04-20 06:50:37)

sas · 2012-04-20 13:28:19

Daedalus1 wrote:

Qt hacks many features into C++ to make up for its bad design.

You mean Qt is badly designed, or C++ is badly designed?

In the latter case, I sort of agree with you, it does carry around quite some baggage from C times with it.

I like the whole "C++, done right" idea that seems to be at the core of D. Many of the specific design choices listed on the website you linked appeal to me as well.
So I might have to look into it further... :-)

However, what's the situation of D regarding...

...availability of high-quality compilers? (targeting different hardware architectures and operating systems)
...availability of high-quality open-source libraries for various purposes?
(the website mentions "Direct Access to C API's" - does that mean that you can use any C (but not C++) library with your application, without any additional hassle and bad surprises?)

Daedalus1 · 2012-04-20 20:35:54

sas wrote:

Daedalus1 wrote:
Qt hacks many features into C++ to make up for its bad design.
You mean Qt is badly designed, or C++ is badly designed?
In the latter case, I sort of agree with you, it does carry around quite some baggage from C times with it.
I like the whole "C++, done right" idea that seems to be at the core of D. Many of the specific design choices listed on the website you linked appeal to me as well.
So I might have to look into it further... :-)
However, what's the situation of D regarding...
...availability of high-quality compilers? (targeting different hardware architectures and operating systems)
...availability of high-quality open-source libraries for various purposes?
(the website mentions "Direct Access to C API's" - does that mean that you can use any C (but not C++) library with your application, without any additional hassle and bad surprises?)

I mean that C++ is badly designed. Its standard library is badly designed such that everyone hesitates to use even its string library; no native thread support; templates are hard for the compiler to reason about and produce cryptic errors; etc.

...availability of high-quality compilers? (targeting different hardware architectures and operating systems)
-------------------------------------------------
dmd made by Walter Bright is the de facto standard compiler for D and supports x86 and x86_64 in Windows, Linux, Mac, and FreeBSD. D code is often shorter and just as fast as C++ code when compiled with dmd. gdc is also another popular compiler that is a front end for gcc. I'm not sure if ARM architecture is supported or in the works, or other embedded systems.
...availability of high-quality open-source libraries for various purposes? (the website mentions "Direct Access to C API's" - does that mean that you can use any C (but not C++) library with your application, without any additional hassle and bad surprises?)
--------------------------------------------------
The standard D library phobos + D's native features are a replacement for a library like Boost for C++. There are many bindings made by the D community for C libraries, such as Derelict for game development, Qt and Gtk for GUI and graphics, X11 libraries, etc. If a binding cannot be found on the internet such as around dsource then you can manually convert C headers to D modules yourself. There's probably a tool to do it automatically somewhere; I'm not certain.

I realize there are problems with D arising from its new status and lack of wide-scale use but the solution for that is really getting more people to use it. There is no perfect language; every language has its drawbacks but under the criteria that dysoco listed, such as a language like C# that is not as low-level as C, C syntax, OOP, faster than java (so no interpreter), not C++, and suitable for game-development, D fits the best.

Last edited by Daedalus1 (2012-04-20 20:36:56)

Arch Linux

#1 2012-04-14 23:06:48

So... what language to pick for Game Development ?

#2 2012-04-14 23:46:22

Re: So... what language to pick for Game Development ?

#3 2012-04-15 00:01:21

Re: So... what language to pick for Game Development ?

#4 2012-04-15 00:08:47

Re: So... what language to pick for Game Development ?

#5 2012-04-15 00:17:13

Re: So... what language to pick for Game Development ?

#6 2012-04-15 01:32:10

Re: So... what language to pick for Game Development ?

#7 2012-04-15 05:48:07

Re: So... what language to pick for Game Development ?

#8 2012-04-15 09:17:11

Re: So... what language to pick for Game Development ?

#9 2012-04-15 11:50:28

Re: So... what language to pick for Game Development ?

#10 2012-04-15 14:57:48

Re: So... what language to pick for Game Development ?

#11 2012-04-15 15:27:46

Re: So... what language to pick for Game Development ?

#12 2012-04-15 16:24:28

Re: So... what language to pick for Game Development ?

#13 2012-04-15 18:55:43

Re: So... what language to pick for Game Development ?

#14 2012-04-15 19:00:41

Re: So... what language to pick for Game Development ?

#15 2012-04-16 06:07:16

Re: So... what language to pick for Game Development ?

#16 2012-04-16 13:26:37

Re: So... what language to pick for Game Development ?

#17 2012-04-16 13:55:20

Re: So... what language to pick for Game Development ?

#18 2012-04-16 14:43:06

Re: So... what language to pick for Game Development ?

#19 2012-04-16 17:34:13

Re: So... what language to pick for Game Development ?

#20 2012-04-16 18:18:24

Re: So... what language to pick for Game Development ?

#21 2012-04-19 16:38:47

Re: So... what language to pick for Game Development ?

#22 2012-04-20 00:32:37

Re: So... what language to pick for Game Development ?

#23 2012-04-20 06:19:48

Re: So... what language to pick for Game Development ?

#24 2012-04-20 13:28:19

Re: So... what language to pick for Game Development ?

#25 2012-04-20 20:35:54

Re: So... what language to pick for Game Development ?

Board footer