Hacker News new | ask | show | jobs
by munificent 1710 days ago
> Take game systems, as an example; far far more effort will be spent in the art and general asset management than is true for many business software setups. Which is why many of the business best practices haven't necessarily moved over to games.

You're right that game development involves a lot of asset stuff that other business software doesn't have to worry about as much. (And, conversely, a lot of business software has to worry about large mutable datasets much more than most games.)

But I don't think that has much bearing on why some business software practices haven't made their way to games. I think the reasons are mostly:

* Games are structurally different from business software, so the patterns that work for the latter aren't always great for the former. MVC makes sense when the "UI" is a relatively thin layer insulated from the "logic". In most games, the "UI" (rendering, animation, VFX, audio, etc.) is huge and more deeply coupled to the game state.

* A lot of enterprise software practices are about maximizing developer productivity in a single codebase over a very long period of time at the expense of runtime performance. Game codebases often have a shorter lifespan and can't afford to sacrifice runtime speed for developer speed.

* Game developers can be insular and are often either oblivious to what's going on outside of games or think it's beneath them and not applicable to their "real" code.

1 comments

I can't say with any authority on why practices are different between the different environments. So, to that end, I should have offered it as /a/ reason, as I don't think it is the sole one. I can't shake that it contributes, though. I mainly meant it is a counter to the implicit "devs at office job are too lazy to learn different ways."

For other examples, I would dip into major logistical simulations/optimizations. Which basically drop into linear algebra as soon as they can, where much of the idea of typing is basically thrown out, so that we can solve equations and constraints, with no real tracking of which is which at different locations. There is a tranlation in/out, but once in, things are effectively "matrix of values.

(As an amusing aside, I love that I get to message with the authors of books I'm reading on places like this. I have your Crafting Interpreters. Working through it at a glacial pace. Plan to pick up the other one next. Kudos and thanks!)

You're welcome! :)