Is Game Programming very different from normal programming?

Question

By normal programming, I'm referring to application programming (which is all I'm familiar with at the moment). My goal is to make games, and I wanted to know if the path was different than other programming paths at the beginner level. Or perhaps it's too early for me to worry about that at this stage?

Answer 1

You'll probably find that the fundamentals of programming remain the same regardless of the type of application you're creating. However, game programming often requires a lot more optimisation and care over processing. Therefore, you'll find yourself trying to squeeze every little bit of memory in order to get the game running at a good frame rate. This is not to say that optimisation for 'normal' applications is not important, but users are more likely to forgive waiting a few seconds for something to load than to wait during gameplay. There are many game programming books that you can get and, depending on the language you're most familiar with, you should get started with those. You'll learn different paradigms of how you should approach certain aspects of games. There are also many different game engines already available. If you really get into it, you can look at the source for the quake games, as 1-3 are now open source.

You could look at various engines such as Torque or the Quake source code. If you come from a .NET background, you might find it easier to get started with XNA, a .NET-based game engine framework.

Answer 2

Games are applications -- some are highly interactive, with strict real-time response requirements, others are not; some are richly graphical, some are not; and so forth. Such variations applies to applications that are games as well as to applications that aren't games, and indeed even within applications to different parts of them -- e.g., Photoshop is an application that's richly graphical for many functions, but it also has configuration dialogs which are purely textual (and not especially "highly interactive", any more than just any other configuration dialog in any kind of application, game or non-game;-); some functionality require extremely responsive real-time interaction, other functionalities can perform very heavy computation in almost a "batch" mode; and so on, and so forth.

If you specify much more precisely exactly what kind of games you have in mind (sudoku? first-person-shooters? etc, etc), and what kind of non-game applications (video editing? accounting? etc, etc), maybe we can offer more helpful pointers or advice -- but this is just not feasible at this super-high level of genericity!-)

Answer 3

Bear in mind that there are lots of games out there that aren't first-person shooters, console games, or multiplayer online games.

Since you're at a beginner level, you could look at some simple game that interests you and figure out how to implement it, and how to make it better. Games like Artillery or Breakout let you play with physics, a 3-D Tetris game can demonstrate basic 3-D work, M.U.L.E. to see how to use economics, etc.

Personally, I think that applications and games have more in common (e.g. multiple platform support, OS interface requirements, management tasks) than different, but in game development you'll spend a lot of time on the different parts.

In short, find something cool, hack at it, and mess around a lot. Your early code is going to be a mess, but that's half the fun.

Answer 4

The big thing you'll have to get used to is writing a lot of state machines. The idea of writing a single function that takes 20 seconds to run just can't happen in games.

BTW, the reason I say this is the biggest difference I've seen between game industry developers and 'general' developers is the attitude towards long functions. Game industry devs seem to instinctively shy away from any kind of design that would require 20 second function times - even if working on tools. Non-game devs, in a lot of cases, don't have the same reaction, even to a function that could take multiple minutes to run. The general techniques to avoid these long calls seem to be far more rare in the non-game-dev world.

Answer 5

Games are applications, and there are many different kinds of games around. The game industry is becoming very large and complex. So you might even think about where in that field you want to be.

Games need many different things: visual artistery, sound effects, music, story, movement capturing, interaction and control, networking, data storage, graphics engines, physics engines (even in 2D), hardware interaction. Even inside these fields there are subfields. Very often a game is a result of the work of hundreds or even thousands of different professionals in contributing companies.

But you can dip your toes in at any of these areas, just to see what it's like. You can do things with Valve's source engine, you can make something fun en flash or silverlight, you can make you own levels for many open source games. Play around with it and see if you really enjoy it.

And I know people that have gone from business applications to games development, or the other way, so you can always switch later.

I, however, have decided not to develop games full time after reading the support forum threads for World of Warcraft for a couple of hours. I think the customers are the biggest difference! 12 year old experts seem to think that 50$ upfront and 15$/month gives them the right to be treated as royals.

Answer 6

Looking at how games are sold:

Much shorter maintenance - maybe half a year of fixing the worst bugs, one or two addons when you are really successful. But even with long-running franchises, significant parts of the code base are replaced to keep up with state of the art. Cotnrast that to many aplications that grow over the years.

Exception: online games.

Corollary: you have one shot. That usually means cutting corners, compromises and... ahem... a few extra hours.

Artwork vs. Code - graphics and audio are a large - sometimes the largest - part of games. If you consider that programming too, fine - otherwise, you might feel frustrated by managements priorities.

Culture - All the kids want to go into game programming. That means a large influx of highly motivated, but usually not-so-well trained workers. That affects work culture a lot.

---

Beyond that, game programmign varies - and application development even more. It's definitely more varied and "sexier" than hacking accounting applications, However, there is also boredom and repetition in games, where only the bitmaps differ.

Anyone thinking about game programming should also read ea_spouse - just to see the extreme (worst?) side, too.

Answer 7

The only thing I really want to point out that other answers didn't seem to address is that there are a number of highly specialized areas of "game programming". Just thinking over the team I'm working with right now we have animation programmers, AI programmers, physics programmers, gameplay support people, UI programmers, audio programmers, platform specialists, graphics programmers, tools programmers, network programmers, and leads or generalists who have to know a little bit of all of the above.

I'm sure that there are similar specializations among application developers, but the point here is that "game programming" is a deceptively simple phrase. Graphics programmers and physics programmers might need to know tons of math. Tools programmers might need to have a good handle on things like DB design, Python, Perl, or C#. These roles are all very different, yet they're all programming at their core.

Answer 8

Check out my accepted answer to a similar question about game programming vs. business programming here: http://stackoverflow.com/questions/209818/whats-the-difference-between-game-development-and-business-development/209868#209868

Answer 9

Obviously 'game' programming and 'normal' programming are awfully wide areas, and obviously games are a subset of programs so there will necessarily be a lot of overlap. But if I compare my experience programming games commercially with my time spent on other apps, the following stand out:

• You're working on a large lump of shared state in memory at almost all times. Contrast this with web development for example which typically has little more than a request and dips into the database a little to get other data. This has big implications for concurrency and correctness.
• You are aware of performance at every step, because you can't afford for a function to take much longer than you expect. You're often running everything essentially single-threaded and have to finish your main loop 15 to 60 times a second in order to render in a timely fashion so performance is paramount.
• You need to be able to appreciate a wide range of disciplines. Game developers these days often know everything from how to write shaders down to writing SQL queries to read the database, from the performance/size/reliability difference between TCP and UDP to blending animations via different bone weights. You don't typically get to be a specialist until you've proven yourself at a general level. And whereas almost all of my web programming knowledge gets used on games, the reverse is far from true.
• You're going to use one of a small number of prescribed languages, whether they seem like the right ones or not. Typical retail games use C++. Most web-based games use Flash. Everything else comes in a distant third. If you only learn Java then you'll be at a significant disadvantage, especially if you have to dive into C++ and learn about pointers and the like as you go along.

Answer 10

I think the major things come down to the focus of the programming. For all of the AI, physics etc. you can cram into a game (thinking high-end games here but it wasn't just the AI that made Doom the hit it was), it still comes down to things like immersive graphics, audio and that sort of "atmosphere" that gives a game that compelling property. If a game doesn't have that then all the best code in the world won't make it a winner.

Contrast with non-game software where all sorts of crappy UIs and illogical layouts live on to date (Microsoft Office anybody?). A spreadsheet might not be the prettiest piece of software but if it didn't add properly, no amount of sexy UI improvements would save you.

Thinking about that having written it, I suppose the benefit for gaming is often that UIs get built from the ground up on many occasions and thus bad features evolve out of standard practice a lot faster in an industry where software is replaced each time rather than upgraded and needs to be retro-compatible.

Answer 11

You have to know Linear algebra. It is not easy.