[mabster]

We had similar thoughts about "premature optimisation" in the games industry. That is it's better to have prematurely optimised things than finding "everything is slow". But I guess in that context there are many many "inner-most loops" to optimise.

[chii]

> That is it's better to have prematurely optimised things than finding "everything is slow".

or you found that you've optimized a game that is unfun to play and thus doesn't sell, even tho it runs fast...

[wongarsu]

The best-practice solution would be to write a barely optimized ugly prototype to make sure the core idea is fun, then throw away the prototype and write the "real" game. But of course that's not always how reality works

[chii]

> not always how reality works

yep. The stakeholder (who is paying the money) asks why the prototype can't just be "fixed up" and be sold for money, instead of paying for more dev time to rewrite. There's no answer that they can be satisfied with.

[mabster]

Or the timeline just doesn't have capacity for experimentation so the expectations are clear right from the start!

[mabster]

In context most of the major optimisation work was on the engine. The game code can be and usually is slow but we do try to tame things in an O() sense.

I worked licensed titles for a while and that area the quality of a title and whether it sells were largely uncorrelated haha!