Comment by pandaman | Hacker News Reader

Comment by pandaman | Hacker News Reader

Parent Full thread

I don't have any extended experience with non-game programming so I may be completely delusional but it appears to me that the most of non-game programming is not as much about programming as about solving some problem with a computer. E.g. there are programmers working for Coca Cola, Match.com or FedEx. But these companies don't sell any programs and none of their customers really care if their business involved any computers at all. I am pretty sure about this because some businesses that hire programmers today had existed since before computers had been invented.

Game programming, on the other hand, is exactly opposite. The game does not solve any problems at all. Its value is in itself. It's not just gameplay experience or art, it's the binary code and data: there are quite a few cases when a game with the same gameplay and art but running on a different platform does not sell nearly as well. Of course, the gameplay and art are vey important factors in the game's success and the reasons the sales of the ports vary so much are not related to the particular code as much as to the competition and consumer preferences. The point is that the game companies literally sell binary executables that the game programmers create as opposite to the other businesses that sell services or products, which are not binary executables.

So my answer to your question is that no, it is not "good programming" in the mainstream sense of solving a problem with the help of a computer. It is, however, pretty awesome programming in the literal sense of making a computer do what you want it to do.

I don't see how the code is any more or any less relevant for a game than for any other pure software product.

Game code has to be performant first, readable second.

I don't see where I said the code can't be different in style. I said that I don't see how the code is somehow more important in the end product. No non-programmer gamer has ever cared one bit about what the code looks like, if the game is good. Like every other user of any software product ever.

You said you couldn't see how the code was more relevant, which I interpreted in another context; ultimately gamers won't care as long as it's a good game. However, I don't see any value in following that line of reasoning, as it halts all further discussion.

The truth is game code often needs to be performant first, and the pursuit of that goal usually comes at the cost of maintainability and readability (and programmers' sanity), so I think further discussion is warranted.

> The truth is game code often needs to be performant first

This is true, of course. All else in this discussion is semantics, probably :)

I don't see how I claimed the opposite. As I said I don't have any experience outside the game industry so I could not be able to tell if either is true anyway. I am just saying that game programming is not "good programming" in the sense most people use that term since we don't even attempt such programming (i.e. solving a problem with the help of a computer).

I don't see how the problem "write an amusing simulation of space ships shooting missiles" in intrinsically different from "write a data model for invoices and expenses and report on how they add up".

Obviously the techniques are different, but you're both solving a "problem" with the help of a computer.

Is the writing a data model actually a problem that is being solved here? I'd imagined that the problem was reporting invoices and expenses. So you solve this problem with the help of a computer by writing a data model. You could solve it without a computer too by hiring somebody to add the invoices and expenses with an abacus and the difference would be just the cost.

What problem writing an amusing simulation of space ships shooting missiles is solving in your opinion? Other than the lack of such simulation, of course. Could you solve such a problem without a computer? I don't think many people would be amused flying a real space ship and shooting missiles.

Games solve the problem of people having too much money and being bored. You could solve that without computers. Or money.

I think that's merely a matter of scale. The analog equivalent to a computer game is a video game, or playing a sport. Vice versa, there are plenty of "problems solved with the help of a computer" that simply cannot be solved without a computer: anything that needs a computer's scale to be calculated.

The problem being solved at the high level is one of how to entertain. These problems tend to be solved by the game designers themselves.

Every solution involving software has many many layers of software inside it, and every single one of those layers is solving a problem of some sort.

Some layer somewhere in that expenses report is solving the problem of how to save and load data, for example. It has nothing to do with the business problem being solved, but it's still a technical problem that needs to be solved.

It's the same for games.

Nor do I, but I do feel there is a difference. More specifically, game programming seems to be more demanding in the "programming" part, while many other programming jobs emphasise the "domain knowledge" part.

If you're doing a business application for a small shop (payroll system, cash registry, invoices printer…), good accounting is probably more precious than good programming: you have plenty of computing resources to waste, your programs can be relatively small…

But when performance starts to be key (video encoders, AAA games, databases…), the effort devoted to programming becomes comparatively bigger.

True, though there are many other application domains where nonfunctional (i.e. non-"domain") requirements are at least as important as the domain modeling itself.

Search at Google, scaling at Twitter, any chip that powers your car's airbag, ...

So game programming is not a different animal, it's just one of the domains where performance is a lot more relevant than for more mundane domains.

I agree, which is why I mentioned video encoding, databases, and three little dots.

Reply on news.ycombinator.com