The Strange Loop conference last month was one of the best technical conferences I have ever attended. The topics ranged greatly, and the depth of each talk was amazing. The speakers included: Bret Victor, Jeff Hawkins, Brendan Eich, Rich Hickey, and more (talks are available on github). In the aftermath of my head exploding from the awesomeness that was Strange Loop, I decided to try to apply a few small nuggets to my game framework, Gamebox.
Gamebox is a framework for writing games in Ruby. The domain is modeled after an elementary school play. There are actors with behaviors that exist on stages. Actors only exist as buckets of behaviors and observable data attributes. (See Component Architecture talk by Marcin Chady.) That means all the heavy lifting is done by behaviors.
While not specifically mentioned in any of the talks I attended, I was reminded of live reload and the immediate feedback that comes with it. The idea of “save the file,” “see the results” is very powerful. Autotest in the Ruby community is another example of live reload. It watches for files to change and reruns your tests; giving you up-to-date test results without the hassle of running them yourself. Gamebox (HEAD) now allows live reloading of behaviors and will pick up new actors. Live reload should speed up game development by reducing the restart overhead while tweaking algorithms and values.
Bret Victor’s talk on Visible Programming was both exciting and very frustrating. If you didn’t see it, or don’t know Bret Victor’s work, go read it now; I’ll wait…
My initial thoughts were “That’s great for drawing triangles, but how does this help me when writing a webserver?” Then I remembered that I was writing a video game! What could be more visual than that?
Bret made a point to try and “show the data” in your application. Gamebox now shows a subset of the data, via watch blocks that can be modified at run-time. What’s the actor’s velocity? What’s the last known ground normal? Just hit F1 and read for yourself. A large part of visualizing the data is just simple debug drawing. Karlin Fox has been bugging me for months to add debug drawing whenever possible. I have since added debug for bounding boxes, collision points, velocities, etc. Debug drawing lets me quickly detect things that seem just a little off.
Here’s a screenshot of a little game that some atoms and I have been working on called foxy:
Another common theme amongst the functional linguists at Strange Loop was REPL use. Gamebox has had REPL support via pry-remote for quite some time now. However, I have recently started actively using it for debugging support and as a way to manage the visible debugging of a running game.
1 2 3 4 5 6
Pry-remote:  pry(#<GameboxApp>)> f = actors(:foxy).first; [31:0:736875] [debug] found 2 actors  pry(#<GameboxApp>)> f.x += 10 => 120.0  pry(#<GameboxApp>)> watch :time do Time.now end
These are some of the ideas that I picked up from Strange Loop. I’ll continue trying to apply these ideas to all my projects, including Gamebox. For instance, I’d like to use the kvo gem to add more reactive programming to wire up my games ala Elm. (That’s a post for another day.)
How are other Strange Loopers applying what they’ve learned?