14Jul

Web development is game development minus two lines of code

Posted by Elf Sternberg as programming, python, web development

I recently wrote a game, and found it very much like developing a Javascript-based web application. (My wife, who’s a journalist with the video game industry beat, insists “it’s a toy, not a game. There is a difference.” I will defer.)

If you’re a web developer who does a lot of Ajax, there is one kind of event in which you’re often very interested. Most events describe what just happened, but advanced Ajax and DOM coding often rely more on what just stopped happening. The Image.onload() and the XHR (XMLHTTPRequest) objects’ onreadystatechange handlers are interesting because they tell us when something that takes time is done, not when something has begun.

Another, related component of javascript development is setTimeout(). setTimeout is basically on(when clock reaches this point)=somefunc(). It’s not worded that way, but eventually you’ll wrap your mind around that basic idea. setTimeout() is just another way of shoving something into the list of events. Along with all the objects on the screen, each of which might have one or more events associated with it, there’s a general object, the clock, to which you hook up events with setTimeout(). When you understand this, you’ll realize the basic truth:

Everything in web application development is event-driven. Everything. The same is true of games.

The gametoy I wrote is Thinksaber, which is basically a re-implementation of MacSaber for Linux-based Thinkpads. It’s written in python and the core is pretty straightforward:

    idle_channel.play(sounds['idle'][0])
    while 1:
        event = pygame.event.wait()
        if event.type == idle_channel.get_endevent():
            idle_channel.play(sounds['idle'][0])
        if event.type == pygame.JOYAXISMOTION:
            self.make_noise()

This is a very stripped-down version of the actual core, but it’s all we need to understand the main point. Lightsabers, when not being swung around, make an ambient menacing hum. I reserved a channel in the pygame sound interface for that, and call play() on it when the gametoy starts up. (Actually, there’s a chunk of code in the actual program that also plays the startup sound, too.)

That sound clip is only so long. When it stops, it has to be restarted. That’s what this loop does: if the event was a sudden motion of the laptop, call the make_noise method to figure out how fast and in what direction, but if the event was “end of idle sound,” restart the idle sound.

I was struck by just how similar this is to monitoring onload, onreadystatechange, and setTimeout. You, the programmer, don’t actually have to do the monitoring; these events are delivered to you on an as-needed basis. The only major
difference between game programming and web programming is that in game programming, at least using the PyGame interface (and many others that I’ve seen), the loop and the dispatcher are explicit. They’re only two lines long, but once you know they’re there, you start to see their presence under the hood of IE and Firefox.

2 Responses to Web development is game development minus two lines of code

Christian Wyglendowski

July 14th, 2008 at 1:12 pm

Nice observation. Yeah, in web dev you live in the loop, whereas with game dev you own the loop.

Elf Sternberg

July 14th, 2008 at 1:57 pm

Wow, that’s actually a really smart way of saying it. Thanks.

Yeah, I haven’t written anything resembling game code since 1986 or so, and back then we were all CPU-bound and the idea of waiting for something was a joke.

Comment Form

Subscribe to Feed

Categories

Calendar

July 2008
M T W T F S S
« Jun   Aug »
 123456
78910111213
14151617181920
21222324252627
28293031