Hacker News Reader

Comment by wlievens | Hacker News Reader

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

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.

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 :)

Reply on news.ycombinator.com