Hide Notes 

Slide 1: Programming Aesthetics learned from making independent games April 1, 2011
Slide 3: Braid source code http://cloc.sourceforge.net v 1.53 -------------------------------------------------------------------Language files blank comment code -------------------------------------------------------------------C++ 221 25736 8312 73223 C/C++ Header 239 3655 2029 9467 C 3 1046 2249 5986 HLSL 20 354 143 1287 ... -------------------------------------------------------------------SUM: 488 30907 12746 90347 --------------------------------------------------------------------
Slide 4: The Witness source code http://cloc.sourceforge.net v 1.53 -------------------------------------------------------------------Language files blank comment code -------------------------------------------------------------------C++ 329 37708 14900 96822 C/C++ Header 331 5303 2221 12889 C 2 583 647 3883 HLSL 51 986 311 2458 ... -------------------------------------------------------------------SUM: 720 44659 18095 116204 --------------------------------------------------------------------
Slide 5: “Industry Average”: 3250 lines/year (90000 lines) / (3250 lines/year) ≈ 28 years
Slide 6: 512 MB RAM (you can’t use it all), no VM 3 slow in-order cores Slow file access
Slide 7: Certification Program can’t crash, even with antagonistic user Loading time is capped
Slide 8: Certification “Soak Test” 3 days * 86400 sec/day * 60 frames/sec = 15,552,000 frames If you leak 4 bytes per frame, you’ll fail.
Slide 9: game design level design art direction audio direction business development marketing / PR financial management
Slide 10: be extremely effective at getting things done
Slide 11: … by the way …
Slide 12: Impulses to optimize are usually premature.
Slide 13: Most code is not performance-sensitive.
Slide 14: Optimization is usually bad! (Unless practiced very carefully!)
Slide 15: Data Structures
Slide 16: Data structures are about optimization.
Slide 17: “using the right data structure” is usually bad! (Because it is premature optimization!)
Slide 19: Now I use arrays of records for almost everything.
Slide 20: Things you might optimize seconds per program execution (speed) bytes per program execution (space)
Slide 21: Instead, optimizing years of my life per program implementation (life) This is a valid optimization parameter you can consider just like those others!
Slide 22: Data structures are about memory or speed optimization. They are not about life optimization (unless you absolutely need that speed or memory).
Slide 23: Complicated Algorithms are not good!
Slide 24: Almost all applied CS research papers are bad propose adding a lot of complexity for a very marginal benefit doesn’t work in all cases (limited inputs, robustness) “supported” by bogus numbers, unfair comparisons This isn’t fooling anyone any more…
Slide 26: A generalized system is usually worse than a specific / hardcoded one!
Slide 27: Adding new systems is bad! This should only ever be a last resort. deleting code >>> adding code
Slide 28: Straight-line code preferred over function calls { a = b + c; a *= f(k); a /= g(a); print(a); } } { recompute(a); print(a); } float recompute () { float a = b + c; a *= f(k); a /= g(a); return a; { { // a a a Update a. = b + c; *= f(k); /= g(a); } print(a); }
Slide 29: What is a good programmer, then? (in this context)
Slide 30: gets things done quickly gets things done robustly makes things simple finishes what he writes (for real) broad knowledge of advanced ideas and techniques (but only uses them when genuinely helpful)
Slide 31: it’s easy to see benefits of an idea developed for benefit’s sake! very hard to measure subtle negatives chained to this idea (which often outweigh the benefits)
Slide 32: “knowing” vs. deeply, intuitively understanding