next »

[SoftBlade]

I'm gonna try to keep the article short as I tend to go into more detail than is usually necessary

I'm trying to decide which language I should use to start my game programming. I've been using mostly game maker but I feel like I need more flexibility.

Now, the thing is, I'm starting my final year of my Computer Science degree next year, so I started taking a look at available jobs, so I'd have an idea of what was expected of me once I enter the programming industry, and it pains me to see that almost every company I found wants you to have 1-3 years experience in a specific programming language, even at entry level. Anyway, I figure even a small amount of experience will count towards something, right?

So, I got me a book on Allegro, and it looks like a promising language so far, but its a procedural language (if I'm wrong then I'd better start my degree at year 1 again), and I'd probably be better of learning to program games with an OO language (as most jobs I find seem to be for Java or C++ programmers). But using these I'd be programming with libraries (OpenGL, DirectX, SDL, whichever) which I won't use anyway in most available jobs.

SO, in conclusion, though I do feel I'd be better off learning to program in an OO style, would a future employer really care whether I used Allegro or rather DX or OpenGL?

On a side note, how about recommending some good books on Game Programming? Would be much appreciated.

[BlueSweatshirt]

I thought Allegro was a library, not a language itself. Unless I'm missing something, here. It was written in C, although it works well with many other languages.

I recommend learning C++, since it's basically an industry standard. Beyond that, it has features just about every other programming language has, so it makes it easier to adapt to other languages.

As for a graphics library, I recommend making friends with OpenGL. It's cross platform, unlike DirectX. If you have a job working with DirectX you can adapt, they don't work all that differently. But if not, you're already set. Most jobs for game programming are in OpenGL, I'd say, when you consider only Windows and the Xbox use DirectX.

I recommend just reading online tutorials and documentation. To my experience they've usually been a lot better.

[Aquin]

There is a programming language called Allegro, strangely enough.   Not sure if that's the one he's talking about.  But I gotta say you really should focus on C++ and anything related to that (AS3, Java, C#, that sorta thing.)  It seems to be what's popular.  I also recommend OpenGL (at least at first) since it's a lot more friendly to a theoretical background (over the insane puzzle-within-a-puzzle that is DirectX.)

[SoftBlade]

I thought Allegro was a library, not a language itself. Unless I'm missing something, here. It was written in C, although it works well with many other languages.

My bad on that. It is a library. I should probably rather say that using it feels to me like I'm using a procedural language. I've not yet delved deeply into it so I'm probably mistaken.

Reading through my post again I realize how stupid my question actually is. It makes sense to go with C++ and OpenGL. I don't intend to become a professional game programmer so there really is no need to learn DirectX, I think.

I'm just curious as to whether game programming with a specific library would be more of an advantage when I'm looking for a job eventually? And I don't really mean a job in game programming, but programming in general.

[mcc]

DirectX will actually be of real interest to a certain type of employer-- basically if what you're doing intersects with windows GUI programming. You never know when a program is going to need to do high-performance drawing. (In theory it seems like the same should be true of OpenGL, maybe more so because of the crossplatform thing, but I don't think I've specifically seen this to be the case. I've never used OpenGL in a professional context.)

Other than this, and other than maybe some of the basic sound libraries, a non-game employer is extremely unlikely to find any game library listed on your resume remotely interesting. Game libraries are pretty specialized.

I think game stuff can maybe make you a more attractive potential employee in indirect ways. I did actually include my game on my resume the last time I looked for a job. I think it helped a little, but if so it would have been not because they cared about the game, but because it showed I could see a project to completion. (Similarly there was a job some years ago I seriously think I got because I included a bit about a strange little firefox extension I'd written on the resume. The extension was crap but it made my resume stand out in the pile.)

Nevertheless if you're looking for things you can do specifically with the goal of making your resume look more attractive, game programming should be at the bottom of that list. Learn MySQL or something. (Also internships are going to count a lot more than anything you do on your own, if it's not too late for that.)

[Aquin]

cough cough, hey where does this link go?

http://www.sfml-dev.org/index.php

[Hajo]

SO, in conclusion, though I do feel I'd be better off learning to program in an OO style, would a future employer really care whether I used Allegro or rather DX or OpenGL?

It depends what kind of job you are looking for. In many IT jobs Allegro will not even be known to your employer, and DX or OpenGL are not important ... good knowledge in methodologies like object orientation and software development processes will be more helpful in general I think.

[bateleur]

In the wider world of programming jobs you really can't beat C++ experience. If you expect a career as a programmer outside the world of games, just make the effort to learn it. Not having it on your CV looks odd.

[LemonScented]

I'm just curious as to whether game programming with a specific library would be more of an advantage when I'm looking for a job eventually? And I don't really mean a job in game programming, but programming in general.

Not any particular library that I can think of. Different projects and platforms can involve using lots of different engines, libraries, APIs and programming styles. The trick is to learn to be flexible, to be able to understand each new environment quickly and continue being productive. So, I wouldn't say that any specific library is a huge advantage to learn, but the experience of having dealt with a few different libraries is what's really useful.

[Sar]

DirectX will actually be of real interest to a certain type of employer-- basically if what you're doing intersects with windows GUI programming.

Forgetting anything about drawing at all... I seem to recall (I've never used it, and it's been a while since I looked, so I could be wrong) that DirectX is built around Microsoft's COM, which - while technically superceded by .NET - is still in use in a billion and one places and COM experience will undoubtedly be useful for a lot of jobs.

In the wider world of programming jobs you really can't beat C++ experience. If you expect a career as a programmer outside the world of games, just make the effort to learn it. Not having it on your CV looks odd.

This, on the other hand, isn't entirely true. In the business world, C++ is losing ground to languages like C# and Java, which are widely recognised as increasing developer productivity for only a minimal loss in performance. (In fact, while I can't speak for Java, C# sometimes even outperforms C++, depending on the needs of the program.) Not having C++ on your CV only looks odd these days if you're over thirty and also don't have 'FORTRAN' or 'COBOL'... ;-)

(If anything, it looks to me like C++ is more uniformly demanded inside the world of games...)

I'm not saying it's not worth learning, and there's definitely still a lot of C++ jobs around - and there's enough loegacy code around that it's not going to go away for a long time. Just don't get into thinking that you absolutely need it to work as a programmer in the real world.

[nikki]

I am not a computer scientist, nor do i have a good carreer in IT, but i would advise http://www.openframeworks.cc/ to get yourself into c++ and openGL, it takes a bit of the nastiness away.

[Average Software]

My game programming hobby has gotten me two development job, neither of which are game related.

When it comes to programming experience, there have been two things that have helped me the most: sample code and "real" platform programming.

By "real" platform programming I'm referring to learning the actual platform APIs and not wimping out with stuff like SDL, Allegro, etc...  Learn Cocoa and Objective-C, learn Gtk or Qt on the Linux side, learn win32.  They really aren't that hard, and there's some good documentation out there.  Employers look for keywords in resumes, and libraries, languages, and APIs are hot keywords.

I also recommend learning as many languages as possible.  It's rare to find the job that demands the precise skillset that you have, so you need to branch out.  Don't be afraid of learning things that aren't "trendy" right now.  I spent some time learning Ada on my own (which it seems almost nobody knows) and it almost got me an interview at NASA.  (I would have had to move across the country, so I didn't take them up)

Don't sweat the object-oriented thing.  I have no evidence to back this up, but based on my own experiences in the industry, I think the OOP fad is finally starting to go away (yay!).  Know how to do it, because when you need it, you really need it.  I think most companies are starting to realize that they don't need it as much as they thought they did.  If you're looking for a game job, OOP is going to be more important, because it aligns well with that kind of work.  In other fields (scientific computing, for example) OOP just tends to get in the way, and employers are looking for people that actually know how to do other things.  Work in several different methodologies, learn their pros and cons, make a game or something in plain C.  It helps.

Sample code is huge, because it shows that you can produce something.  Understand your code (don't just use boilerplate code you found on the Internet somewhere) because you will probably be asked about it.  Make sure any code you turn in is something you wouldn't mind people seeing, try to hit a variety of languages.

Employers like to see auxiliary technologies too.  Try to learn things like SQL and how to deal with at least one database.  Set up a source control repository and learn how that works.  Know your way around different operating systems.

There's no one right answer, but these are the sorts of things that I've seen employers look for.  The hardest part is getting the first job, after that things get much easier.

[hatu]

Don't sweat the object-oriented thing.  I have no evidence to back this up, but based on my own experiences in the industry, I think the OOP fad is finally starting to go away (yay!).  Know how to do it, because when you need it, you really need it.  I think most companies are starting to realize that they don't need it as much as they thought they did.  If you're looking for a game job, OOP is going to be more important, because it aligns well with that kind of work.  In other fields (scientific computing, for example) OOP just tends to get in the way, and employers are looking for people that actually know how to do other things.  Work in several different methodologies, learn their pros and cons, make a game or something in plain C.  It helps.

What serious alternatives are there to OOP? I've always been in web and games so I'm not very aware of the scientific research side for example.

Learning C++ or Java should pretty much guarantee some programming job somewhere.

[BorisTheBrave]

OOP is fading away? First I've seen of it. Scientific research is done by PhDs with usually little training in compter science, away from the "mainstream" of development. They produce impressive works, but I wouldn't look to them for future trends.

Anyway, IMHO it doesn't matter what libraries you pick up. The sort of experience people are looking for for a fresh grad is not in depth expertise with a product, it's experience using the language, solving problems, debugging, etc. ANYTHING will qualify you for this. If you are interviewed for a C++ job, questions will be about understanding pointers, inheritance etc, not about what OpenGL call draws a dodecahedron. In java and .Net, (which I'm less qualified to speak on), libraries matter more (as the languages aren't so hard), but at early levels it'll still be about design principles (what is a Visitor?) and technologies (what is TCP/IP?).

[bateleur]

In java and .Net, (which I'm less qualified to speak on), libraries matter more (as the languages aren't so hard)

Whilst this is true, I'd actually be more careful hiring a Java programmer than a C++ programmer since the ease of use of Java can mask a lot of incompetence. A Java professional from a not-very-cutting-edge industrial sector could easily have five years experience and still be a complete clown.

As such, anyone thinking about a career using Java would do well to learn the language properly before going near an interview. Informal screwing around writing web apps isn't all that useful.

[thaaks]

Whilst this is true, I'd actually be more careful hiring a Java programmer than a C++ programmer since the ease of use of Java can mask a lot of incompetence. A Java professional from a not-very-cutting-edge industrial sector could easily have five years experience and still be a complete clown.

Of course you could also hire a bad C++ programmer who doesn't know anything about OO but has his roots in good ol' plain C and does inheritance by copy/pasting code 

In the "real" IT industry out there game development knowledge is absolutely not relevant or very helpful at all.
My personal advice (I am a professional software developer and project manager with a master degree in computer science and 23 years of programming on my back) would be to learn C# if you are a Microsoft addict or Java otherwise. Understand OO, learn to use design patterns when required, get some knowledge about UML and try to find out what areas you're interested in to dig deeper into required frameworks and libraries.

PHP might also be an option if you target some "cheap" web programming. Not that it's a bad language but PHP developers are usually paid worse (at least here in Germany) than Java developers.

Frameworks like Spring and Hibernate are very good to know (there are appropriate versions for Java and C#), also stuff like JavaEE.

You could code games in your spare time in Java (using Slick or LWJL for example) or in C# (Microsoft XNA) to get used to the languages but don't expect to impress your interview partners for the new IT industry job with your games...

You (the OP) mention you're starting your final year of your Computer science degree: how the hell did you get along without learning a programming language at all? 

Hope that helps,
Tommy

[mewse]

What serious alternatives are there to OOP? I've always been in web and games so I'm not very aware of the scientific research side for example.

It's true that in the games industry, OOP seems to have recently begun to make a very slow decline (though I imagine that it'll never be totally gone;  it's much simpler and easier to hack out OOP code than what's arising in its place).

That's not to say that the games industry is slowing in its use of C++ or objects;  just that there's currently a slow shift towards not having the objects represent "things", as is suggested by classical OOP design.  Instead, trends seem to be moving toward setting up individual processes as objects, and passing them large blocks of data.  Some call this "component-based programming", but I like to call it "Process-Oriented Programming", or POP.  Or, since the processes are implemented as objects, you could even get away with calling it "Process-Object-Oriented Programming".  If you really wanted to.

Anyhow.  In POP, you don't have objects representing each individual enemy on the screen;  instead, each enemy instance has a blob of AI data that sits in an array with the AI data of all the other enemy instances, and that array gets passed to an "AI" object to work on, and the results of that get sent in an array to an "EntityMovement" object, the outputs of which get sent to a "Physics" object, and so on.

The big advantage of this approach over OOP is that you can gain some surprisingly large performance wins due to data locality (no cache thrashing as each process advances through its array), and code locality (not jumping around wildly through code), and because each of these bits have defined inputs and outputs, it's much easier to put game code onto the different cores of modern multi-core CPUs, than it is with traditional "one monolithic object per entity" approaches;  if you were really gung-ho about it, .you could probably make the engine calculate and implement optimal multithreading automatically, just based upon timing data and the movement of data through the various processes.

Of course, this approach is harder to think about (or at least it is for me!) and harder to implement.  But it's difficult to argue with the performance gains on modern multi-core machines like current PCs, XBox360s, and PS3s.  And if it means that I get the benefits of multithreading without ever having to think about mutexes in my game code, then sign me up!  

[Hajo]

I'm not quite sure if OOP is on a decline ... but lately there seems to be movements away from hand written code towards generated coded again. This has been tried in the past, but wasn't really successful. Maybe tools and methods have evolved enough now to really make it work - and it sure has great potential.

Model driven architecture is another approach to life coding work onto a higher level of abstraction.

[Ivan]

Learn Flash. You'll always have a job.

[Ben Kuhn]

There are many paradigms other than object-oriented and procedural. The most popular one seems to be functional programming, for which you should look at something like Haskell or OCaml. Both of these include facilities for OOP (hell, the O in OCaml stands for Objective) but neither is very focused on OOP. I believe these are the types of langauges Average Software was referring to; they are pretty popular in academia and such as they tend to be very expressive, make semantic errors difficult, and run fairly fast but will also break your head for a while. Good to learn, though, I advise you to pick one up if you can.