I was writing the first lines of code for a game prototype while listening to this. I looked at the code I was writing, and promptly put it aside -- I was coming up with a nice advanced, performance implementation of dynamic octrees to represent the voxels my world is based on ... but why do I need that, before anything runs at all? Sure, I will need it in the future (although not the super, super optimized version until well into the future), but I should have this running before moving forward. I'm glad I watched this, and saved myself some pain initially.
I made an iPhone game (tower defense) where everything used std:vectors until I ran into performance problems. And lo and behold they could all be solved with using data structures for which the necessary operations where less expensive. The changes were quite easy to make since the containers use a common interface.
The real gotcha is that the vast majority of containers are still vectors, since the operations on them didn't show up in profiling. So I guess yeah create some gameplay and optimize your bottlenecks not your lack of Data structure fun.
In the most important case it was sets.
There was a collision detection routine that took up too much time because checking membership for vectors is not constant time. The sets/vectors were very small though, low double digits, but once you do stuff 30 times per second for a couple a hundred objects it can get slow. (only on the iPhone though, in the simulator everything was good)
For the general world representation I used a static grid, as the object size was very homogenous, so a quad tree would have been overkill.
I liked a lot of Johnathan's ideas about writing simple code.
One idea that I don't think fits for the type of system I develop is the idea of preferring huge blocks code over function calls (around 30:00). He counters the benefit that the function name documents the chunk of code it encloses, but an even bigger benefit, in my opinion, is that the function signature documents the function's inputs and outputs. If you avoid global variables then you know when you modify a function exactly what information you have access to and exactly what information the function produces. This makes changing the function much easier.
He says he's talking about thousands of lines of code that always get executed in serial, so it doesn't sound like my code is very similar to the code he's talking about. I also expect that code I write gets read and modified much more often than the code he's talking about.
A lot of game code is actually "data" code, so the large functions come about naturally because so many assumptions and special-cases are made that you don't have anything resembling a CS-style algorithm, just a blob of "integrated assets" - and so the only route for further progress is a new syntax tailored towards the particular methods of integration being addressed.
That said, a new syntax can work, if it's the right one.
Braid is a wonderful game, for anybody who hasn't played it. Probably one of my top 3 favorites of all time. I really enjoyed this talk, the bit about optimizing for years of my life per program implementation (life) was great.
Now I'm curious what your top 10 looks like. With BK and Braid in the top maybe it's just an affinity with anything containing jigsaw puzzle pieces? =P
...it sure is interesting, especially that soak test or whatever that looks for leaks. So is the "preserving life time" idea, really. Although a lot of this, as the article points out is just for independent games.
I felt the hating on academic papers was a bit over the top, although it's possible his claims could be a little bit accurate. Anyone know more on this?
"... that the thing is playable and that people will want it, all of which are much more difficult than to making the right decision about where to sell something" (At 49:06)
Make something people want is not just for startups.
Thanks for sharing this excellent talk. As a grad student and someone who wants to be an indie developer, this really resonates with me. I also enjoyed the _years of my life per program implementation_ idea.
