| > it rarely makes any sense to even think about these things before you have working code you can run through a profiler. Almost always, spending your time and effort finding and using higher-level abstractions pays off much more than tinkering with your ghetto-hashmap implementation 'to make it faster'. There is a circularity to this logic that you should address. On the one hand, you shouldn't write your own abstractions because someone else did a good-enough one already. On the other hand, you shouldn't try to write more appropriate abstractions because you should have working code first. Well, which is it? If you intend to write appropriate abstractions(and that's a goal of HH), you have to start off being a bit too crude and slow so that you have a working test case; then you can gradually improve that with better algorithms as you uncover the performance profile. Jumping to "use someone else's code" introduces a dependency and a guess about average-case behavior. That is okay if we're making "Premade Hero", but it teaches nothing about algorithm design. And w/r to your own project, there are a lot of guesses about what will be useful or helpful - the specifications boil down to "it would be fun to add more physics and scripting to Thrust" which, as a game design goal, is quite impoverished. HH also lacks for design right now, but everything in it is built on direct experience and isn't going to box in Casey later. It is motions he is going through to show to the crowd how it all works if you were going to do it yourself. |