Coding quality into games

Quote:

Original post by neonleif From a coding perspective, what do you see contributing to high quality in a game? How do you, as a coder, ensure that your code does the best for your games' overall quality? I anticipate answers in the direction of 'minimising bugs', 'optimising fps' or 'structuring code for readability'. I would love some elaborations and personal opinions on those matters and I would be ecstatic if you could enlighten me with some new aspects. Your answers will help me focus later interviews and surveys.

Well, yeah, minimizing bugs, optimizing for performance, keeping the code maintainable... but then the question is, how.

For bugs, it's important to keep track of the current bugs, who's working on them, when and how they have been fixed - and of course, ensuring they don't creep in again. That's where bug-tracking software and automated test suites come in.

For performance, you'll want to figure out what's taking too long before you start optimizing things. First profile, then optimize. It helps when you know beforehand what area's are likely to cause trouble - sometimes it's good to build some prototypes to figure this out (and/or to check other aspects beforehand).

Keeping code maintainable is a bit of a discipline. It's good to refactor now and then, to keep the code clean.


I also noticed how useful automated build processes are. Manually converting files quickly gets tiresome, so tweaks are done less frequently, which shows in the final product. The same goes for tools: the easier they are to use, the more artists and designers can focus on their work. Bad tools will hinder the workflow (for programmers, long compile times have the same effect). That, and simply keeping quality in mind. If you're working on a game with a 'just make that deadline and be done with it' mindset, then you're going to get mediocre games.

Oh, and communication is important. You're not coding on an island. You're working together with others. Maybe you can do something to make the art come out better, maybe an artist can do something to cover up a technical flaw. Or maybe you're working on something and you notice how it's just no fun. It's a good idea to inform the designer or the team before wasting time on a feature that's going to be (or should be) cut later.

You'll also want to keep improving your own skills, by reading good books and articles and by staying in touch with other skilled programmers. I always have some books around just in case there's some dead time. :)


I hope that helps you somewhat. I'm by no means an expert, I'm simply figuring out stuff as I go along. ;)

You need to define what you mean with quality.

If you mean bug "free, stable and performant", then it is not different from any other kind of software development.

If you mean "fun and awesome", then the answer is probably that everyone involved in the project needs to work well _together_ toward a common goal. The rest is smart decision making and luck.

I've seen the code for a lot of games. It's much like the bamboo scaffolding I saw in Shanghai last year ... scary and wobbly as hell, but it works, and people only die now and then :P

From my personal experience the "quality" part of games comes from the art. Seriously 95% of code is about either how to get the art on screen, or how to make the art do what you want when its there. Think about it - you want a good collision system why? Its not because you have a moral obligation to the laws of physics, its because it *LOOKS* bad when stuff doesn't move correctly. You can never see the code, so anytime you think something is "quality", its because the art was good and the programmers managed not to ruin it.

There needs to be 2 or 3 decent bits of code usually related to physics and hardcore rendering for performance reasons ... anything called more than 100 times a frame basically. Once your deep system code is done, layer upon layer of horrible hacks is added to get it to do what your designers demand, and the nice design goes mostly out the window as you add global variables, and expose private data in the last crunch before release. Then you pray to every god you know that the damn thing holds together long enough to get past QA without them finding the bugs you KNOW are there but don't have the time or motivation to fix.

Probably not what your after ... but from my programmers perspective the "Quality" part of all the games I've worked on has always been good art. You start making a game, its ok, then the art goes in and INSTANTLY its fun. Happens every time! Bad code, smothered in pretty pictures with lots of particles makes very good games. I try to write nice code, I really do - but when it comes down to it if the art is good your code only needs to be good enough to not screw it up. Anything more is a bonus.

The quality that a player sees has relatively little to do with the quality that the programmer sees. After all, the player isn't looking at the codebasee; they're looking at what the codebase generates. Your code could be a horribly mangled pile of spaghetti logic, but as long as it generates the right result without horribly lagging the computer, the player doesn't care what it looks like.

So coding quality is mainly there to help you a) deliver your product on time, and b) reduce the bugcount. And that's an issue for any program, not just games, so I'd recommend looking to general "how to make high-quality code" articles and books for more information. There's certainly no shortage of those. :)

I read an article by a game developer (sorry cant remember who) that said something about getting a working version up and running at the expense of 'quality' (that's my paraphrasing). I don't work in games, and would be in perpetual conflict with them if they were on my team. I do acknowledge however that games are unusual in that you rely more on "patrons" than in other software development. Also the nature of the industry, being entertainment as opposed to government and security, which is my expertise, you would need to sell a product with bling early on in the development cycle. Just thought I'd share that, don't know if it helps.

Games are just software and software quality is nothing new. Quality can be measured in functionality, robustness, maintainability and good design. There is to note though that what the user / player sees of the quality of the software is basically only a limited set of functionality and robustness and that only when it crashes or slows down without any noticeable origin.

Let's take a non game example: Wordpress. I pick this example, because you can actually look at he source code, which is not really the case with your average game. Wordpress is perceived as very height quality software. When it comes to usability, interface and stability they really put the polish. But if you look at the source code they committed almost any crime a programmer can do. If you ever try to change something it is a real pain.

What the example shows is that user perceived quality is not total software quality. It is only a subset of it, but the overall appearance also plays a role. So if your software / game is ok, but looks crap, people will think its crap and vice versa.

When it comes to actual business value of software the other quality aspects come to play. If your software is simple to understand, properly decoupled, rigged with unit tests and other automatic quality assurance measures in place you can be sure that you will be able to add any feature you are asked for in no time.

The traditional cost of change curve is a myth that results not from actual cost, but from the fact that at every stage added some cruft to the result and quality slowly degrades. See http://www.agilemodeling.com/essays/costOfChange.htm.

pto is right. I've also worked on many games, and seen the source code for quite a few more. This includes some very "good" games. None of them had code that I would call "good". The deadlines and realities of game development often force the issue. We certainly try to write clean, maintainable code ... but that's not really the end goal. Making a good game is the end goal.

The most important thing when writing code for games though, is ensuring that programmers aren't required to get things done. Make every system data-driven. Ensure that iteration time is as low as possible. Support real-time editing of art and gameplay. Programmers don't make games. They make frameworks, and artists + designers + animators makes games using those tools. Make those people as productive as possible, everything else is secondary.