Fog Creek Software
Discussion Board




game programmers

Just wondering if anyone has any impression of game programmers here.  I work on games for consoles, and a co-worker made a comment about other software companies not wanting to hire people who have mainly game experience.  I find this pretty believeable for some reason.  On the flip side, I noticed that my company doesn't want to hire people who don't have game experience, even though there are a lot of jobs that we do that are not really game specific (like developing Windows tools for content people to use).  They might as well come from any background.

It seems like they are totally different worlds for some reason, but I would think if you're a good programmer, then you can adapt quite easily.  There are a lot of differences, like game programming still involves a lot of assembly, and basic mathematics like linear algebra, while business apps require a lot of API knowledge and such.  But I don't think the two areas are so different.  I would think that game programmers would be desireable for jobs programming embedded systems.

Do game programmers have a reputation as "undisciplined" or "sloppy"?  There is an article on this site that casually pokes fun at game programmers.

So if you are an HR person or hiring manager and you see some hotshot game coder, and a less skilled guy with some business app experience, is there a no-brainer choice?

Roose
Wednesday, July 09, 2003

Was it like that when the economy was in better shape and there were less people looking for work?

I've noticed that people are getting more precise in their job specifications again; I think it's just to cut down on the number of applicants. So we're back to adds that finish with "must have had good grades at school, a good degree and know versions 6.1 and 7.52 of X", whereas when times were better and and available programmers were less abundant the add would have read "must know X".

In summary; is it just that you shouldn't expect to change domains during a recession?

Len Holgate
Wednesday, July 09, 2003

I can't comment on what HR does, nor what the perceived competence of game programmers is.

But I have worked with a game programmer once in my career, and he's among the only five I'd hire every time for a programming job, if I were to hire people.

Here Th. ere (e-Very Where)
Wednesday, July 09, 2003

Surely, games programming is quite a different field from typical business programming. It's more technical. On the other hand, it involves little or no work with database systems.


Wednesday, July 09, 2003

I left the games industry six months ago and went mainstream. I didn't find having worked in games any kind of handicap, in fact it counted in my favour because they wanted some graphical experience for the role.

Mr Jack
Wednesday, July 09, 2003


Regardless of background, you need to be able to meet the needs of your users.  In most business jobs, that means being able to talk to them and understand them in their language.

Code is code... but is it the right code?

No, business programming ain't all that complicated, but you need to have some basic understanding of what you are trying to accomplish.

Then again, some long time business programmers break the one holy rule of financial systems - all dollar fields should be signed.

Joe AA
Wednesday, July 09, 2003

Actually, my experience with games projects is that they aren't very organised -- largely because games companies won't hire people from business. They now have these huge projects that are rivalling large business systems in complexity {The banking systems I work on are not that much larger than a MMORPG} without any experience of how to get them working. That's why they start trying to retro-fit scalability after they find their initial plans won't scale enough...

It's partly because games companies are either owned by business people or by the people who made their money programming 1-man games which didn't need that much organisation. They can't see why it should be any harder to write 10 million lines of C++ than to write 20,000 lines of assembler. They also demand that everyone they hire is a games developer who knows the graphics APIs inside and out. Being able to structure large applications is never a requirement.

Because there's none of these people around who know how to do large projects, there's no culture of sensible project management to learn from: in the business world a project that doesn't overrun its budget and does what it's supposed to is unusual. In the games world, it's unheard of.

So games projects are run in ad hoc ways, with bizarre beliefs about how projects ought to work, and are then developed by the cheapest developers who can be hired.

And although lots of the projects fail and most of the rest are far more expensive than imagined, companies will not hire people who can build large bits of software but don't know DirectX.

I used to want to get into the industry, but I've changed my mind over the course of some interviews - There was a scary moment when I asked the lead developer of a title (while looking at his game running) "so you're doing all of this with a finite state automata behind the scenes?" and he was confused. And eventually I came to understand that, basically, because no-one on the team had any idea what one was, they'd done things the hard way...

And what's worse, is because they're so insular, there's no genetic drift away from this sort of thing.

Katie Lucas
Wednesday, July 09, 2003

Katie: Yup, that prety much sums up games programming, and all the reasons why I left.

Mr Jack
Wednesday, July 09, 2003


I think there's nothing particularly special about games programmers. I think you're just as likely to meet a rogue "business" programmer as you are a rogue games programmer, or even a rogue free software type.

I've seen games development teams that were totally disorganized. I was even approached once by such a team based on some work I'd done on a mod for Quake II. I was initially enthusiastic, right up until I asked for their design documents and schedule and was told they didn't have any yet. That would have been alright if they didn't already have developers working on content. Adios muchachos.

On the other hand, I totally respect the task that games developers face. For one thing, unless you're 3DRealms or John Carmack, you don't get as much flexibility to slip release dates. If a publisher wants your game shipped for Christmas, it's probably gonna ship, finished or not.

Games development also has a more "threads" to  coordinate. You've got:

- Game (not engine, but game) design
- Engine design
- Content (levels for a FPS, models, etc)
- Multiplayer code
- Music
- Art, textures, etc
- Web sites
- Development tools (which also tend to be released these days)

Not to mention the normal testing headaches for shrinkwrap type software. I suspect that business users don't bitch nearly as loudly as dissapointed game players.

Oh, and, if you're developing for a game console, there's no going back and patching your boo boos later.

That's a tougher challenge than most of us will ever face in our careers.

Take Unreal Tournament for example. High quality, relatively few bugs, high quality tools for user developed content. Now, I can't say for sure that that team is highly disciplined from a software engineering standpoint but I'd tend to doubt they could pull that off if they weren't.

DingBat
Wednesday, July 09, 2003

What short of databases do massively-multiplayer games rely on? That sounds like more transactions than you can throw at the everyday OORDBMS.

Li-fan Chen
Wednesday, July 09, 2003

About Databases for MMORPGs:
http://www.gamasutra.com/resource_guide/20020916/hallenberg_01.htm

Dirk
Wednesday, July 09, 2003

Sorry, you have to register to see articles on gamasutra.com - what did it say?

RocketJeff
Wednesday, July 09, 2003

This ad for a 'programmer' for Sony Online made me laugh.  Check out the line in the requirements section that says, 'have the ability to fix bad code.'  Kind of makes you wonder about the quality of the code that is being written and further more, what kind of programmers did they hire to write this code to begin with.

Dave B.
Wednesday, July 09, 2003

LOL . Guess I could include a link for ya:

http://66.129.87.69/candidate/default.cfm?szTemplate=3&szOrderID=1289&szCandidateID=0&szSearchWords=

Dave B.
Wednesday, July 09, 2003

Most programming shops of all types are "insular". This is not limited to the game programming industry.

That is, they only hire talent that they immediately recognize, they don't accept equivalent talent from another domain (generally), and they are very hung up on seeing people come to work for them who appear to have worked in exactly the same capacity in other places.

The concept of "cross fertilization" is pretty much absent in all programming shops, with rare exceptions. It can get really silly, and I think this ignorant stereotyping, carried to the extreme, creates the perception of lack of qualified talent on the street. Because every shop is looking for a chimerical "someone" so tightly defined that they never find them.

For instance,  a company that develops banking software may only look at candidates who worked in banking applications before... and NOT insurance applications, or accounting software.

I had a lot of trouble at one point getting some simple tentative respect when I moved out of the DOD environment, programming embedded stuff, into an equivalent and easier job developing embedded stuff for commercial applications. The @ssholes I worked with insisted on chuckling at $400 toilet seat lids instead of recognizing that I was doing the current work, better than they did.

This is one of the things that has made programming a much less than professional field: the attitude that all of your company's problems are unique and that candidates have nothing to contribute unless they're clones of your present staff. It really sucks.

Bored Bystander
Wednesday, July 09, 2003

About databases for MMORPGs: the article is more or less an introductiory cource into SQL databases for MMO programmers. An overview over their strengths and weaknesses, what to do and what to avoid.
To simply answer your question: MMO run with classic SQL RDBMS systems such as Oracle as data storage.

Dirk
Wednesday, July 09, 2003

"Business users don't complain as much..."

No. If you bring their 9 billion pound internet bank to a screaming halt, they hardly kick up a fuss at all. I'd recommend trying it sometime to see just how laid back and chilled out they are as thousands of customers call the helpdesk to ask why they can't use their credit card...

Katie Lucas
Wednesday, July 09, 2003

I moved to game programming from business software. Every game programmer I know is extremely productive and gung-ho. Why?

Game bugs are different. They are easy to find. A small army of teenagers (say, 2 or 3 for every programmer) plays the latest build (twice a day) and often catches bugs hours after a programmer introduces them. Unlike business software, the important bugs are usually blatantly obvious-- "I can jump through red brick walls" "The xyz-monster looks jerky and his head disappears"... Subtle bugs that don't get caught are usually not important. An off by one error in some AI calculation is likely to have the game play coefficients adjusted around it without even knowing it exists.

It's also important that you don't know exactly what you are making until you are half done.

matt
Wednesday, July 09, 2003

["Business users don't complain as much..."
No. If you bring their 9 billion pound internet bank to a screaming halt, they hardly kick up a fuss at all. I'd recommend trying it sometime to see just how laid back and chilled out they are as thousands of customers call the helpdesk to ask why they can't use their credit card... ]

That's not shrink wrapped software, is it? I guess I should have been more specific.

How about if I said that, in relation to their financial outlay, games users complain more than business users. Games users pack a lot of complaining into their $50, believe me.

DingBat
Wednesday, July 09, 2003

MHO's:
1) The "must have experience in our industry" comes from the business people, not the programmers. I think most modern programmers recognize how fungible code is; it's the guys writing the checks that think *their* business is so byzantine that only someone who's worked in it their whole lives could possibly understand it. (This is majorly screwing the medical community, that demands "health care experience" from their coders, which drives up coding prices)

2) My guess on "we don't hire gamers" is based on a stereotype that gamers can't be disciplined. Visions of guys sitting around playing doom all day don't sit well with a bank CIO.

3) Of course, all this is crap. Code *is* fungible, users are users, and every problem is new. Hire the people you hire based on their experience with the tools, not where they worked, and interview them based on who they are, not who you think they are.

Philo

Philo
Wednesday, July 09, 2003

I work with some games guys. They are first class.

The games world is weird because it is entertainment work and because it is often interesting work. Anything people want to do they will get paid less for and there will be millions of wannabes.  Also the financing of most entertainment stuff is weird. Nothing is solid. Companies are open and closed every 5 minutes.

The games world is pretty low level and deep too.  And these days your maths needs to be reasonably strong.

On the other hand they seem to live in a weird throw away world. Very little code is reused according to these guys. There is much less maintainence code.

Medman
Wednesday, July 09, 2003

Regarding MMORPG databases:

I remember reading an article by Brad McQuaid, who I believe was one of the guys to help code and design Everquest, that said the game items and quests are stored in a relation database to make it easier for the developers to add items using the tools they write, but this data is written out to a sequential flat file on the server during game operation to save the overhead of executing the SQL query.

Dave B.
Wednesday, July 09, 2003

I have not professionally programmed games, but I have worked a look with graphics development.

Business apps and graphics are different worlds to a large extent

Business apps typically involve database, building forms from pre-existing components.

Graphics may involve math, a sort of wierd combination of math and algorithm finding, squeezing last ounce of CPU performance

They are different. Not everybody can move from one world to another in either direction.  Even some great programmers are good at one thing (say) bits and performance, but never "get" databases - and vice-versa

If you hire somebody who is familiar with your field, it is a good bet he or she can do the job.  Whereas if they have to transition, you don't know in advance if they'll make it, or when they'll make it.

As for some games involve business like elements - yeh it might be true - but would you deliberately choose to have  a developer (assuming they never transition to full games mode) who is only ever going to be able work on some parts of your software - as opposed to one who can work on any part.

I don't know about project management, games vs business, but even if games PM is messed up, that wouldn't be that different from the average business PM! 

As far as it's possible to compare, I do think the average games coder has more skill than average business coder.  Everybody in a vertical probably know some business app written by people with no real programming skills! Not all business apps are this bad - but many are. I mean, you can be pretty bad at programming, and still cobble together some business form and database that more-or-less works using visual basic or whaever.

S. Tanna
Wednesday, July 09, 2003

From what I've seen, game companies are very prejudiced about hiring non-game programmers.  If you have more than a few years of experience outside of their world, you'll have a very difficult time getting a job in gaming.  Your only shot at that point is having very well-placed contacts.

On the other hand, I've never heard of a bias in the "real" world against game programmers.  I think generally, it is assumed that those guys are pretty good programmers.

One thing to keep in mind if you are planning on getting into game programming is that he pay generally sucks and so do the hours.  Because every geek out there wants to do games, they can pay low wages and expect the programmers to put in 60 hour weeks (or more near deadlines).

David
Wednesday, July 09, 2003

Interesting thread … 

Over a year ago, I ditched the business world and got into professional graphics and game programming.  The only reason was that I enjoy graphics programming more and am personally interested in games and the games industry. 

But, of course, I’ve encountered all of the problems many people here have already mentioned.  HR people at game companies don’t recognizing how fungible code development is.  The industry is outrageously difficult to break into.  And when you do, it will probably be for a startup company funded by a VC who doesn’t know what he is doing and has outrageous expectations.  Vast majority of game projects are horribly disorganized, ill conceived, and are doomed to fail.  And unless you have you name on the credits of at least 1 AAA commercial title, landing a GOOD industry job can be very tricky. 

I subscribe to all the industry rags and attended the most recent GDC.  It seems the larger studios that have been around longer understand and appreciate solid project management and good engineering practices (anyone care to comment?).  But good luck trying to get a job at an Electronic Arts, Ubisoft, etc … you pretty much have to know a developer on the inside to get around HR.  But in all fairness, an HR person at an established game studio probably has to deal with an absurd number of applicants.  The filtering mechanisms they apply may seem ridiculous and unfair, but what are they supposed to do, filter by last name!?

Also, as far as “fungibility” of programming talent goes, the difference between say an insurance app developer vs. banking app developer is admittedly much less than an insurance app developer vs. game developer.  I would have to agree that game development is lower level and more math intensive, you rely more on developing and/or applying techniques than on API knowledge when game programming.  Nonetheless, knowledge of certain engines and middleware products is useful and somewhat marketable (e.g. Unreal engine, Gamebryo, Havok, Karma, etc.)

Game development is a highly competitive entertainment media industry (like TV and movies).  I’ve read that only the top 5% of titles produced are actually profitable, and they allow for the development of the other 95%.  Sounds about right.  Studios open, shut down, are bought, and are sold every two seconds.  However, the work is fun, and my experience was that for the most part, the people I worked with were far more intelligent, interesting, and more pleasant to be around than typical programmers/IT people. 

Immature programmer
Wednesday, July 09, 2003

What always gets me is how to design "fun" into a game. I've seen some simple games that are a lot of fun (tetris, for example) or the more sophisticated games that seem just like work.

It's not the type of thing you could put into a spec.

pdq
Wednesday, July 09, 2003

Fun is what games are all about. I play a lot of games, but perhaps some of the best games on the PC are free or cheap. Check out PopCap games. By now most people have heard of Bejewelled, which is their most popular game. They have a lot of games that are a lot of fun, and I'm sure it's a small time operation.

http://www.popcap.com/

Just goes to show that being a "game programmer" doesn't necessarily have to mean doing something with the latest Quake Engine. :)

Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, July 09, 2003

Good point: another difference between games and other types of software. 

The primary design goal of a game isn’t something you can spec out in great detail effectively.  What sounds like fun on paper sometimes isn't, and prototyping or specing out on paper often isn't feasible or useful. 

Unless the studio isn’t committed to making a fun game (and studio's often aren't), 
missions/levels often have to be redesigned late in the project because the design sounded good on paper, but they are too boring, slow-paced, frustrating, tedious, etc.  And genres dependent on real-time gameplay (fps, racing, rts, etc.) have to be tuned just right to be in the fun-zone. 

Even more odd is how something that doesn't sound like fun at all sometimes is.  Take the very successful SimCity franchise for example. 

Oh gee whiz, I get to manage the commercial, industrial, and residential zones of a city.  BOOORIIIING, right?  Well it turns out that the SimCity games are completely addictive and enthralling to many (I still remember not being able to get roommates/neighbors out of my room when going to college because of that stupid game).

Game design is a mysterious art.  I think good designers have a strong understanding of certain psychological principles and popular media culture.   

Immature programmer
Wednesday, July 09, 2003

I worked at a company that made voicemail and related systems for phone companies; they decided to jump on the phone-game bandwagon, and I definitely learned a few lessons there.

One is that, even if coding skills are fungible, they're not necessarily the same as knowing when things are fun.  One guy took a spec I wrote for a game, and then added code that effectively killed the player every time combat happened (the combat was random and unavoidable, so the player effectively died randomly).  QA let it go, because the programmer assured them it worked according to his design--they didn't realize that "not being fun" is a bug in a game.

Prototyping is also incredibly useful in the games industry, but a lot of people (at least in the group I worked with) don't know how to do it right.  You can often get a playable version that encapsulates your major goals in a short time.  It won't tell you if the final product is good, but you can weed out bad ideas pretty quickly.  And (Joel to the contrary) I think a lot of that prototyping experience is useful in other projects, too.

Gav

Gav
Wednesday, July 09, 2003

Want to break into the games industry without relevant experience? Write a little game, or an OpenGL demo or a funky screensaver that uses Direct3D. Put it on the web to download. Include the link in your resume (or include a CD in your resume).

I know at least two people this has worked for. When I was working in 3D, everyone in the company had a side programming project (3D engine, Physics demo etc.) - everyone.

Andrew Reid
Wednesday, July 09, 2003

I was reading an article in MaximumPC about a Half-Life 2 preview. They're gushing over all the visual effects, lighting effects, transparency stuff, etc.
That's cool, and I love a pretty game, but I love a fun game more. I hope Valve is putting as many people on multipathing and NPC interaction as they have on the graphics engine.

Philo

Philo
Wednesday, July 09, 2003

I'm surprised at how accurate a lot of observations were about the game industry.  Interestingly, no one really said that game programmers were less desirable in other industries, which was my original question.

Katie Lucas: agree just about 100%.  I have only been at my company for about a year and I have noticed everything that you have said.

matt: yes, all my co-workers are both extremely productive and sloppy.  It is very strange, not what I expected.  Some of the most productive people produce the most bugs (even when you take into account their increased output).  Our code, to me, seems totally sloppy, but nonetheless almost all the bugs get fixed, and our product makes tons of money.

It is true that game code seems to have less branching than other code.  Just by playing the game through linearly, you tend to exercise most of the branches.  We don't do any whitebox testing -- we basically just code like hell, leaving tons of holes, then throw it all at an army of testers, and then fix all the bugs miraculously.

medman: yes, I have notice that reuse is not as popular as it should be.  I work for a large company with many similar games (how many different types of games ARE there really?), but the amount of reuse is appalling.  Basically it seems like we are inventing 20 wheels in parallel.  I don't know how it works, but our company makes tons of money.

David: I got into the game industry straight out of college, but it's true I knew someone from my alma mater who worked there.  But then I gave in about 25 resumes recently of very qualified Masters students, also from my alma mater, some with significant work experience, and I don't think a single one got hired.  And we're definitely hiring almost a whole game team.

About fun: bigger products, including mine, have designers that are responsible for the fun.  An engineer can contribute to the fun factor, but ultimately someone else has the responsibility for making sure the game is fun and will sell.  If you somehow inadvertently make the game less fun, someone's going to ask you to change it.

Anyway, I am trying to move out of games because I don't like the hours and the attitude toward code.  But it is a paradox.  Basically my conclusion is that Code Complete and those kinds of books were written by some obsessive-compulsives : ).  Or at least some people who are working in a radically different area.  Real world code is sloppy, like my team's, but it still works, can be fixed, and earns millions of dollars.

So you can either: develop the ability to write extraordinarily nice code, and keep it clean -- or just write "bad" code, and develop an extraordinary ability to read, maintain, modify, and fix "bad" code.  It seems like the latter is a bit more practical, because with the former you still need the skill of working with other's code, which could be "bad".  I lean heavily toward the former, but my co-workers lean heavily toward the latter, and as a result I think I am one of the least productive people on the team.

Or possibly a different conclusion: code doesn't really matter, it's a commodity.  As long as the DESIGN is good, then as long as the code sufficiently approximates the design, then you make money.  The design is what makes money.

That's not a really heartening conclusion after only a year of being a professional programmer.

Roose
Wednesday, July 09, 2003

Doesn't business code get maintained much, much more often (and for a much longer period of time) than game code?  If so, that might explain why writting unmaintainable code for games is feasible - because there aren't any maintenance programmers in the gaming industry.  Whereas business code must be kept clean because of all the maintenance that has to be done.

bpd
Thursday, July 10, 2003

Having previously worked in D3D drivers, I had enough experience with games (internals) to know the following generalizations:

1. Game programmers are typically not well-versed in scalability issues (as brought up by others). Hacking is more rewarded than design.

2. Game programming shops are sweatshops (almost always). It made working hours in the harder dot-coms look like banking.

3. The result is that almost every game project fails; and even the ones which succeed in the market almost kill their workers in the process.

4. That will not change until somebody with incredibly deep pockets (Microsoft?) makes it change by starting a new company from scratch and being very patient with the lack of quick revenue.

I never had any urge whatsoever to work in that market after seeing it from "nearby".

Mike Dahmus
Thursday, July 10, 2003

I think that game companies are under a lot of pressure to deliver an actual effective product. 


***************************************
Computer games have to satisfy the user. Period.
***************************************

If they do not do that, the game will not be a financial success and the company will (eventually) go out of business.

The business world is NOT like this.

In Business programming it is quite possible to develop a program that doesn't satisfy users. It might satisfy managemement but not users.  I've worked on a product like that. Mgmt thought it was great but it really didn't help the business, the users, or the business' customers.


They can't depend on an installed base of users being dependent on them.  I.e., when the new version of Quickbooks comes out it only has to be a little better than the old version because users' data is locked into that program and it's hard to migrate.


Computer games have to be:
1.  Fun
2.  Not buggy
3.  Scallable (internet play is the big thing)
4.  Developed without too much effort.  (I.e., if it costs more to develop than you will make on it, then you're out of business.

This is because games are subject to the free market.  If you develop a bad games, you go out of business.  No politicing can save you.  However, if you develop a product for a business to use and the users.

Entrepreneur
Friday, July 11, 2003

This would be why every game of any worth has a patch out the same day as release?

Simon Lucy
Sunday, July 13, 2003

*  Recent Topics

*  Fog Creek Home