Game Programming Compared to Other Programming?

Started by
10 comments, last by SaurabhTorne 7 years, 4 months ago

I am taking my first programming course and enjoying it. I've just become a Computer Science major this semester. I'm going to a smaller branch of a state university. I've always enjoyed games, and I want to make a text adventure once I learn a little more about Python in my class. I also enjoy programming, and I think I might like it as a career. I'm currently a Junior in college.

My question is, how is a career programming in the game industry different from other programming jobs and careers a Computer Science major could get? Other than working on games of course.

Advertisement

A tricky trick question. Programming is programming. There is little difference in salary and work environment (expect to do plenty of unpaid-overtime in the Game Industry, however). Don't be so concerned if you don't "love" your product, only that you strive to make a "good" product (and get a decent contract :)). A career as a programmer in the Game Industry isn't reserved waiting for you whenever you please. Since you enjoy programming for it's own sake, then it really won't matter which industry you end up working for, will it?

Cool name by the way. :D

For the field of programming, the differences between a game developer and an app developer, or any other specialization is exactly that -- the specialization. Its not much different than the differences between an auto mechanic and a diesel mechanic -- the tools and fundamentals are more or less similar, but the workings and surfaces of the things you'll crank on day-to-day are different.

Concretely, game developers historically are focussed on low-latency and high throughput, which is a lot different than a mobile app developer, but not at all different than, say, a developer doing financial trading software for a wallstreet firm. About the only thing you can say about games being unique is that they're really the only mainstream, consumer-facing software that exercises the state-of-the-art in everything a computer can do, all at once, with more-or-less soft-realtime constraints.

throw table_exception("(? ???)? ? ???");

My question is, how is a career programming in the game industry different from other programming jobs and careers a Computer Science major could get? Other than working on games of course.

Differences are minimal in some ways, major in other ways.

First, it is the same.

You will use exactly the same kinds of algorithms and data structures. You will use many of the same CS topics. In this regard all the programming is the same. Programming is programming. It doesn't matter if you are creating a spell checker, a javascript web page, a business server, or anything else. The theory is portable.

Languages and tools come and go, but the algorithms, data structures, and other computer theory will always be around.

Second, it is different than many others.

The mindset of games tends to be far more performance oriented and results driven. In business software if you can query a database and get a result in 200 milliseconds that's quite acceptable. In games performance is often measured in microseconds. In business software you might occasionally profile the code if things are absolutely horrible. In games a profiler is one of the early tools. This by far is the biggest difference in my experience. When I jump between the game industry and business software --- which I've done several times over my career --- the most jarring thing for several months is the timeline of what is acceptable; hearing that 150 milliseconds for results ti display is by far the most upsetting. The shift back into games is far more comforting, leaning on the profiler and figuring how to bring execution times back below microseconds and into nanoseconds.

Game code tends to be less permanent, and consequently there is far less done for automated testing. In a business environment where the code needs to continue working exactly the same way for the next 15 years, or even then next 5 years, automated tests make complete sense and you should write them for everything. In games the engines and core technologies are fixed and deserve unit tests, but gameplay code is highly experimental and volatile all the way through the ship date. It gets locked down somewhat as you go through finalizing the project, but most likely a few weeks before you send in for certification half the team will break off and begin making the sequel or followup game, throwing out huge swaths of code, rewriting most behavior, and completely changing the way things work; automated tends to not make business sense in that environment. That's the other big difference for me. In the business software world everything revolves around an enormous suite of automated tests. That's as it should be. In games, it often feels like we're just praying everything works okay and we don't accidentally break anything. Unfortunately that is the nature of the ever-changing code base.

Finally, and this one is lost on most people, computer games tend to take all kinds of knowledge far beyond other industries. Games rely on more math than most other software out there. Games tend to rely on more research papers than most other software. Some game developers never push their boundaries, but many of us need to actively follow emerging research topics, actively follow journals, and figure out how to apply emerging algorithms to emerging hardware. This is most evident in computer graphics, but can apply to everything. Great game developers tend to apply far more knowledge and learning to their day job than most people will ever know. Not just the more obvious math topics of linear algebra, statistics, and calculus, but also physics and spatial relations and hardware knowledge and such. You can talk with game developers about topics like high dynamic range imaging, physically-based rendering, constructive geometry, properties of physics like rolling resistance and torques, statistical curves, finding the location of an object based on orientation to a few points, rather complex spatial data structures and dynamic spatial restructuring. In the business world about the most varied conversations come around transaction idempotence and transaction boundaries -- you still get those in games, so you don't miss anything.

In my experience:

  • game developers get paid a little less than their counterparts in other businesses
  • game development workplaces are more casual and laid-back
  • working hours are more variable (usually upwards) in the games industry
  • the games industry is much more focused on performance, and less focused on code quality
  • there are relatively few game development studios, so developers get used to relocating for every job
  • the skills you need as a game developer change much less frequently than in web development, but more frequently than in a lot of enterprise business development

Outside of the games industry companies tend to focus on all the modern so called "best practices". TDD, BDD, Continuous Integration, SOLID design, Scrum, Kanban are all things that companies outside of game programming care about just as much as how well you know a specific language.

In games programming you tend to focus on using a single programming language (C++) whilst outside of gaming I can find myself having to, write, fix and review code in about a dozen different languages on a day day to day basis. Think this is similar to what Kylotan refers to when he mentioned skills change less frequently in games.

In a games team pretty much everybody is an expert on all areas of the game. Sure some people are focused on the engine and some on the networking and some on the game play but everybody is using the same tools and can help out when needed.

Outside of games there is more of a seperation between teams with some teams not even knowing how to use the tools that the other developers use.
Another thing is that development outside of games has become very "web orientated". Most desktop apps seem to be migrating towards running in the browser.

For example in one hypothetical large company you may have all of these:
Devops using C and various Unix scripting tools.
Back end team using Java, Scala, Clojure and various DSLs such as R.
Rest API team providing a bridge between the back end and the client using Ruby, Node.js, PHP or something similar.
Web client dev using javascript
iOS team using ObjectiveC and/ or Swift.
Android team using Java.

The lines of what is a games programmer and what isn't has become blurred recently with some of the massive F2P studios such as Zynga and King. These companies are run much differently than the traditional games company as the tech they use and the senior management tend to be a lot more similar to what you would find in a finance company.

The "game development industry" is not a single, heterogenous industry with a monoculture.

What you'll find is many game developers tend to be small development shops (100 employees or less). Turns out that most small development shops work the same way: casual atmosphere, long hours, lower salary and poor job stability. That's not specific to the game development industry but a property of small shops.

If you want a steady job with good pay and stability, work for some large corporation that does centralized server-based data processing with a web-based front-end. Cloud, web, yadda yadda.

The one distinguishing feature of game software over most software is the maintenance story. Most software spends eighty to ninety per cent of its life in maintenance, with bug fixes and new versions shipping over a period of sometimes decades. Games tend to be tossed over the fence and aside from DLC revenue streams, the development teams move on to something else right away. That has an effect on the entire development environment since you can write Krap Kode and as long as it runs it ships, whereas if you're going to be eating your own shit in six months like in other software development industries, you better make sure it smells real sweet. It turns out pretty much all consumer software other than a few bright lights also follow the dump and run model. Maintenance is hard and expensive and hard to justify to the bean counters.

But aside from that one difference, the game development industry is just like the rest of the software development industry, people move in and out all the time and there is nothing particularly special or unique about it.

Stephen M. Webb
Professional Free Software Developer

Concretely, game developers historically are focussed on low-latency and high throughput,

I'm sorry, I'm still just a beginner programmer. What is low-latency and high throughput?

In business software you might occasionally profile the code if things are absolutely horrible. In games a profiler is one of the early tools.

I don't have a lot of programming knowledge yet so a lot of what you mention is beyond me at the moment. What is a profiler? What is automated testing?

Games rely on more math than most other software out there. Games tend to rely on more research papers than most other software.

Could you elaborate on this? How do games rely more on math? How do they rely more on research papers?

You can talk with game developers about topics like high dynamic range imaging, physically-based rendering, constructive geometry, properties of physics like rolling resistance and torques, statistical curves, finding the location of an object based on orientation to a few points, rather complex spatial data structures and dynamic spatial restructuring. In the business world about the most varied conversations come around transaction idempotence and transaction boundaries

I understand none of the terms you use here, but it makes me excited. :)

In my experience:

  • game developers get paid a little less than their counterparts in other businesses
  • game development workplaces are more casual and laid-back
  • working hours are more variable (usually upwards) in the games industry
  • the games industry is much more focused on performance, and less focused on code quality
  • there are relatively few game development studios, so developers get used to relocating for every job
  • the skills you need as a game developer change much less frequently than in web development, but more frequently than in a lot of enterprise business development

What do you mean by casual and laid-back? Is it a social vibe thing? I've heard that work in game companies is often very stressful due to deadlines and such.

Outside of the games industry companies tend to focus on all the modern so called "best practices". TDD, BDD, Continuous Integration, SOLID design, Scrum, Kanban are all things that companies outside of game programming care about just as much as how well you know a specific language.

I don't know what those are. I'm in the middle of taking my first programming class.

These companies are run much differently than the traditional games company as the tech they use and senior management tend to be a lot more similar to what you would find in a finance company.

I don't know the differences between any kind of senior management. What do you mean here?

If you want a steady job with good pay and stability, work for some large corporation that does centralized server-based data processing with a web-based front-end.

Sorry, I'm a beginner programmer. What is "server-based data processing" and a "web-based front-end"?

Thanks to everyone who responded.

I don't know what those are. I'm in the middle of taking my first programming class.


Explaining those terms you asked about is beyond the scope of the Job Advice board. I recommend Google,
or asking your professor. The important point, as far as your question is concerned, is that programming
outside of the game industry is not hugely different from programming in the game industry. Every pro-
gramming job has a different focus from every other programming job, but you're off to a good start for
any of them. Do well in your classes, and work outside of class at improving your skills.

-- Tom Sloper -- sloperama.com

I don't know what those are. I'm in the middle of taking my first programming class.


Explaining those terms you asked about is beyond the scope of the Job Advice board. I recommend Google,
or asking your professor. The important point, as far as your question is concerned, is that programming
outside of the game industry is not hugely different from programming in the game industry. Every pro-
gramming job has a different focus from every other programming job, but you're off to a good start for
any of them. Do well in your classes, and work outside of class at improving your skills.

Okay, thanks!

This topic is closed to new replies.

Advertisement