>if I could transfer the pace of production from Ludum Dare into my normal work, I would complete a game like House of Shadows in less than 2 months<p>While the article lists many plausible reasons why the pace of work turned out to be faster on the shorter project, there is also one that is not mentioned but perhaps the most important: complexity doesn't scale linearly. It's always faster to write the first 1000 lines of code from scratch than to add 1000 lines to a project that is quite large already, mostly because each newly added component has a growing chance to interact with an ever increasing number of older components.
The linked <a href="http://strlen.com/java-style-classes-in-c" rel="nofollow">http://strlen.com/java-style-classes-in-c</a> was both horrifying and tantalizing. I'd expected a preprocessor that generates appropriate .hpp/.cpp, but instead I learned about yet another corner of C++ I hadn't exactly induced from experience.
Similarly, Eskil Steenberg talked about building tools for doing simple things quickly rather than for doing complicated things at all.<p><a href="http://www.youtube.com/watch?v=f90R2taD1WQ" rel="nofollow">http://www.youtube.com/watch?v=f90R2taD1WQ</a><p>His main point is that building a game is no longer about what you can do, but rather what you can get done.
Does anyone have a reliable system for creating artificial deadlines?<p>There are no external constraints on my work. When one artificially arises, I get my best work done, quickly. It doesn't burn me out because a rest comes afterwards.<p>I have no idea how to replicate this urgency consistently.
If you liked ActionScript but want to get back some performance I would recommend checking out NME. It looks a lot like ActionScript but outputs C++ (among others) and can be compiled as usual. Not the best, hand-tuned, C++ but probably good enough for a lot of projects.
As someone who works in another legendarily slow, computer-heavy artform (3D animation), this was a really fascinating read.<p>His point about metawork really hit home hard. I'm at the end of a 4-year project now, and I'd estimate 90% of what I'm doing is what he calls metawork.<p>The major takeaway I got from it was that I should try doing some 48-hour projects myself - or perhaps find some 48-hour film competitions to enter - and see what the results are.<p>And, of course, write them up as a blog entry.
>> During Ludum Dare, I remained tightly interfaced with Flash. I was continually in the midst of the edit -> compile -> test -> edit loop.
>> This was one of the largest reasons for the high pace of production.<p>I discovered this when I started building game ideas in Javascript instead of Xcode. I'd have a skeleton pounded out in an hour or two, and I'd add features in minutes instead of hours. I took a list of things that I though would take me the weekend, and I completed them in an evening.
>I could drag a bitmap into Flash to import it, then place it, position it, add filters, animate it, and attach the animations to code all in one tight motion<p>I want a tool where I can do this but in JavaScript on a canvas.
> Intensity of focus. Almost all my waking hours were dedicated to programming during the 48 hours of the contest. I even took less sleep. This intensity of focus allowed me to maintain contact with the concepts and issues in the game so that I was able to remain productive without costly ramp-up and ramp-down times.<p>Makes me wonder if it would make more sense to cram a 40 hour workweek into 3 days instead of 5. I think it'd be more enjoyable as well.
Epic quote:
>The C++ programmer is a deer sniffing the air for the scent of boots and gunpowder: everything’s an opportunity for gain; everything’s an opportunity for calamity.
Does game programming require C++? Ocaml can be just as performant, and Clojure might also be a good candidate (high-level functional programming, potential to get strong performance).<p>I admit that, for Java, the gain in language expressiveness isn't worth taking the performance hit, because the former is so minimal. On the other hand, moving to a truly high-level language with half-decent performance (e.g. Ocaml, Clojure) might ameliorate the schedule slippages for which that industry is known.