Keeping Jim Busy
« Rewriting My Competitors
Games: Allabrilyn, so play we all
Oops, got totally distracted by flying back to Chicago and forgot to write my So Play We All response post on time, so there’s $10 each to Luke and Jim. Late but not lost, here’s that response. (Luke didn’t post an update this week, so I’m only responding to Jim.)
This week, Jim had a brief but significant update, writing:
Well, after so many weeks of being seriously far behind, I’ll finally be making the progress towards being able to render a complete HTML page.
He’s written his Page, Session, and Form classes to the point that he’s only held back by not being able to template pages from displaying real pages. I’m a little surprised he got votes in this week’s poll without anything to demo, but it’s nice to hear things are coming together for him.
Actually, maybe I should be worried that he’s going to start displaying a game sometime soon. So let me mention a great Rails feature you should spend time reimplementing, Jim. The pending release of Rails 3.1 includes HTTP streaming, basically the ability to send parts of the page while still working on generating the page.
This is how PHP’s page-as-script model works out-of-the-box, but it often leads to bugs when state changes during the page rendering. I’ve seen a lot of browser based games with a bug where a page says you have 100 minerals in the header and then, lower in the page, say that you only have 50 because loading this page performed an action that spent 50 minerals. Having an explicit stage that builds and renders a page usually prevents these bugs at the cost of being able to send enough information for the client to get working at downloading page assets while the server is still performing work. Continuing to support that may cost Jim enough time in gold-plating to keep me comfortably ahead.
(But just in case it doesn’t the 3.1 announcement also mentions an asset pipeline that compiles and compresses CSS and JS for faster pageloads. Have fun, Jim.)