alt Hacker NewsThis reminds me of a portion of a talk Jonathan Blow gave[1], where he justifies this from a productivity angle. He explains how his initial implementation for virtually everything in Braid used arrays of records, and only after finding bottlenecks did he make changes, because if he had approached every technical challenge by trying to find the optimal data structure and algorithm he would never have shipped.
"There's a third thing [beyond speed and memory] that you might want to optimize for which is much more important than either of these, which is years of your life required per program implementation." This is of course from the perspective of a solo indie game developer, but it's a good and interesting perspective to consider.
Replies
It's easy to see this outside of the perspective of a solo game developer. We all have deadlines to manage even in the regular 'corporate world'. And engineering time spent on a problem also translates to an actual cost.
It's a good consideration tbh.
I'd be careful extending learnings from games (solo or team efforts) to general programming as the needs and intent seem to be so different. We rarely see much code re-use in games outside of core, special-purpose buy largely isolated components and assets. Outside of games there's a much bigger emphasis on the data IME, and performance is often a nice-to-have.
That's very much the norm in the game dev world, especially for someone like Jonathan who's been doing this since the early era of PC gaming.
You've got 16 ms to get that next frame rendered, so stuffing everything into fixed sized tables and linear walks is a simple way to structure against that limit. You've got an entity budget of so many, and there's no unpredictable delays from dynamic allocation or similar.
Even when using scripting languages that offer more flexibility, like LUA or C#, you see a tendency towards this pattern.
> how his initial implementation for virtually everything in Braid used arrays of records
This is me with hash maps.
Jonathan blow has spent the past 10 years and almost all of his money trying to build the perfect programming language for his 3rd game.
Also, Rule 5 contradicts the idea you quoted from Blow.
This is slightly surprising to me, since Braid is kinda infamous for being in development for a pretty long time for a puzzle platformer
I feel like a game is a bit different though because you control the input. You can't profile input you've never seen.
The funny thing is even data structure is really an array of memory depending how low down deep one looks. All the people who took an intro computer science course knows, those who had to implement a heap allocator, it's all really just arrays underneath...
It's also notable that video games are programs that run for hours and iterate over large sets of very similar entities at 60 frames or more per second repeatedly and often do very similar operations on each of the entities.
That also means that "just do an array of flat records" is a very sane default even if it seems brutish at first.