On with the links.

First, Commies, the game that introduced me to the LD48.

The web site for the LD48 competitions:
ludumdare.com

The top ranked games from the last competition.

Some recent LD48 games your really should check out:
Beacon
Mind Wall
Rara Racer

These are just a few highlights. There are so many great games.

Here is an updated version of my entry in the last competition. Caves and Bombs. I’ll be writing a post about this game some time soon.

Next, some tools:
Flixel. An open source AS3 framework for rapid game development.
SFXR. A small utility for generating retro style sound effects.
Pixen. An image editor that specifically targets creating pixel art.

Here is a link to a blog post that covers a lot of similar concepts that my talk covered. It seems I basically stole their title for my talk. Oops. Build something cool in 24 hours

Finally, a couple of unrelated links that would be relevant had I stuck with my original talk topic of Runtime Actionscript.
As3 Eval.
wonderfl

The concept is pretty simple. It’s about getting a group of people who are interested in game development together for a couple of intense days of game creation. I’ve only ever done this sort of thing online, but I’m excited about trying something like this with a local group.

More information is available from this organizer’s blog entry.

No date has been set yet, but if you are interested you should register your availability.

Finally, if you’d like to read more, there is some discussion on the TIGsource forms.

You can play the game online. Roads to Nowhere Competition Version

There is also the Roads to Nowere ld48 page.

What went right:

1. Motivation. For some reason the combination of theme, timing, my idea and my mood had me very motivated. I think I spent about 22 hours in front of the computer during the compo, and that time was almost 100% productive. The distractions of the internet sucked up very little of my time. It was a really great feeling to get so much productive time in. Unfortunately I couldn’t tell you exactly what the driving factor was that made my motivation level higher this time than it was last time.
2. Tools. I decided to work in Actionscript 3 so that my game would run in flash. I recently wrote a tutorial on using Adobe’s freely provided mxmlc, and I found that I had no trouble building a game from what I had learned. I even learned to use the included debugger, fdb. It’s pretty limited, but it’s helpful in a pinch. Though I’m still more productive with Python’s tools and libraries, I’m happy with my choice to work in AS3. The biggest thing I miss from Python is an equivalent to iPython. I really wish there as an interactive Actionscript 3 shell. Ultimately, being able to play the resulting game in the browser is enough of a win for me to be willing to tolerate a lot of down sides.
3. Idea. The Roads theme immediately had me thinking about cities collecting resources from around them by building roads to them. Something like the resource mechanic in the early Civilization games. With this in mind, I thought it would be interesting to try to make some sort of resource gathering puzzle game, similar to what Jolle had done with some of his ld48 games. I think this worked out well for me. Interestingly, two of the reviewers of my game noticed the Jolle influence and commented on it.
4. Crunch Time. I fond myself at a point where I had about eight hours left in the competition, and I had zero gameplay. I had to scale back my original idea, cut some features, stop implementing new things and start creating a game from what I had. The final game concept, the rule system, the user interface and the levels all came together in the last hours of the weekend. In fact, I put the levels together so quickly that I had no idea whether or not they would be interesting or fun. Fortunately, people enjoyed the game. There were even people that were impressed by the intricacy and design of the levels.

What went wrong

1. Pathfinding. My initial gameplay idea involved having workers transporting resources along the roads from the land into the cites. In order for this to work, I would need path finding from each of road tiles to the cites via the road grid the player built. I considered implementing A*, but I didn’t have an AS3 priority queue library and implementing one or finding one and learning in the short time frame didn’t appeal to me. So instead I decided that I would do a brute force depth first search from each road tile to each city. For performance reasons, I cached the paths that I found on intermediate tiles. Unfortunately, this scheme can cache bad paths when a road ends in a loop. I spent most of my programming time on Saturday, and a good part of Sunday fighting with this. I tried working around the problem, but the performance quickly hit unacceptable levels. I decided to start from scratch on the pathfinding, instead implementing a breadth first search starting from each city. As the search spread out, it found all of the connected road tiles, and stored the shortest path that was used to find that tile. I had my new algorithm up are running perfectly in about an hour. Of course I wouldn’t have been able to implement the new scheme so quickly if I hadn’t spent so much time with the old scheme. The most frustrating part of it was that with so much time wasted on pathfinding, I had to change my game idea to a simpler one that didn’t really need the pathfinding at all.
2. Graphics. I had hoped to make nice pixel art land tiles, resource gathering animations and rippling water effects. All of these ideas got cut in my last minute scramble to put something playable together. Instead I ended up with some crude last minute pixel art with big ugly blocks for land tiles. While graphics have never been a big focus for my games, I think that the visual impact counts for a lot. In this case, I think the visuals were so bad that some people might have been discouraged from giving the game a try.
3. Time management. Spending over a quarter of my time on a pathfinding feature than was never used certainly seems like a waste of time. But I have trouble categorizing my use of time as something that really went wrong. I had to give up on my original gameplay idea, but I ended up with gameplay that people like. I didn’t have any time to play test the levels I made, but on the other hand I didn’t over think the levels, and people were happy with the result. Plus there was something satisfying about grinding through the pathfinding problem and getting it working correctly in the end.

Results

My game did quite well in the competition ratings:

LD48 #13 full ratings.

6th Overall, tied for 6th in Fun, 3rd in Innovation, 7th in Use of Theme. The scores were very close in the Fun category. Second place had a score of 3.90, tenth place had a score of 3.80. I received a lot of great feedback in the comments, and these are the highest scores I’ve received for a ld48 entry. Pretty good for a game that I thought was too rushed for anyone to be interested in.

I’m really glad I made the last minute decision to enter this competition. It was a lot of fun, and I made a game that a lot of people seemed to like.

Finally, I suggest you take a look at all roads lead from home by dessgeega, and Rara Racer by increpare. These two entries really made me say wow.

When I wrote the main update loop I discovered that Actionscript lacks a foreach construct. Boo. I guess it’s back to C style for loops. So I came up with the following:

for(i = 0; i < length(bees); i++) {
	bees[i].update()
}

Looks reasonable, doesn’t it? It’s brutally slow. On my desktop the Python code can make 200 bees look good using hardware rendering, but in flash with this code it struggled to draw 25 bees at 30fps. I had to really fight to figure out where the problem was. It turns out that length(array) in Actionscript isn’t the same thing as len(array) in Python. The length function returns the number of characters in a string, not the length of an array. So why does the above work at all? And why does it run so slowly?

When I call length(bees), actionscript casts the array of bee objects into a single string containing the names of all the objects in the array, giving something like: “_level0.bee0,_level0.bee1,_level0.bee2…” It then walks the length of this string to count the characters, and returns that value. So what happens with the bees[i].update() when the index passes the end of the array? Nothing. The array access fails silently, and the loop continues. So the code calls update on every bee in the array, and the bees move correctly. It just happens very, very slowly. How slow? Well, if n is the number of elements in the array, length() walks a string of length 13n, and it does this 13n times before i < length(bees). So it's doing O(n^2) work to solve a problem that should be O(1). Throw in the overhead of the string conversion, and the extra length that it adds to the array, and it becomes easy to see why it is so painfully slow.

It seems that the correct way to loop across an array in Actionscript is like this:

for (i in bees) {
	bees[i].update()
}

After years of Perl and Python, this just seems weird. It’s like a foreach operator, but it returns the index instead of the value. Also, the magic “in” only seems to work in the context of the for loop. I guess it has something to do with the way arrays relate to objects in Actionscript. Take a look at this example:

a = [1,2,3]
a.myName = 'bob'
for (i in a) {
	trace(i)
}

The output is:

myName
2
1
0

Weird weird weird. You might think that this implies that array indexes can be accessed in the same manner as an object’s instance variables, and that a.1 is the same as a[1], but no that doesn’t work.

I don’t quite grok Actionscript yet, but I have bees swarming in flash reasonably well with the for(… in …) loop. If you have at least flash 7, you can check out my bad actionscript demo.

In other news I’ve been reading up on continuations. I’m fascinated by the way that Seaside takes tracking state in web based applications, and turns it into a list of imperative function calls. I wonder if I could do something similar for the structure of my games. Every time I work on handling levels and menus, animated clips, or any other number of tasks that require tracking state I feel like I’m writing bad hackish code and that there must be an elegant way to do it.

One last thing, Todd, Jay and I recently participated in the third PyWeek game programming competition. Shadow Runner is the name of our game, and it turned out to be kind of neat.

One approach I played with, just for fun, was animation without maintaining any state information. I have slightly expanded on my previous controller script. The major differences are that my new version will now print a stack trace if the current exception is different from the last exception. With the old script, if you eliminated one exception from your code, but a second exception prevented execution, no stack trace would be displayed. Also, this controller passes the livegame script the frame count when it calls play. You can view the updated script here: controller_stateless.py.

Here is my livegame_stateless.py:

fps = 30
screenWidth = 640
screenHeight = 480

# check to see if the pygame module is in the namespace
try:
    pygame
except NameError:
    # pygame doesn't exsist, so import it.
    # this only happens once.
    import pygame
    from pygame.locals import *

    # initialize the pygame display
    pygame.init()
    pygame.display.set_mode((screenWidth,screenHeight),0,32)
    display = pygame.display.get_surface()

    # initialize the pygame clock
    clk = pygame.time.Clock()

def getMotion(framecount, shapeSize, screenSize, velocity):
    """
        Calculates a linear position using a step number, a
        velocity, and a derived range of motion.

        Returns the position.
    """

    # calculate the range of motion:
    workingSize = (screenSize - shapeSize) / velocity

    # use mod to find position in the range of motion.
    # *2 is used to bounce back and forth inside the range
    pos = framecount % (workingSize * 2)   

    # if we are greater than the initial size, we are moving
    # in the opposite direction.
    if pos > workingSize:
        pos = 2*workingSize - pos

    return pos * velocity

def play(framecount):
    """ Main game logic, called once per frame."""

    # fill the display with black.  Clears the screen.
    pygame.draw.rect(display, (0,0,0,255),(0,0,screenWidth,screenHeight))

    shapeColor = (10,80,10,255)
    shapeWidth = 30
    shapeHeight = 30

    xVel = 10.0 # velocity in pixels per frame
    yVel = 10.0

    x = getMotion(framecount, shapeWidth, screenWidth, xVel)
    y = getMotion(framecount, shapeHeight, screenHeight, yVel)

    # draw a shape.
    pygame.draw.ellipse(display, shapeColor,(x,y,shapeWidth,shapeHeight))

    # update the display.
    pygame.display.flip()

    # check for events, and return true if we get an exit signal.
    events = pygame.event.get()
    for event in events:
        if event.type == QUIT or (event.type == KEYDOWN
                                    and event.key == K_ESCAPE):
            return True

    # try to maintain a set frame rate.
    clk.tick(fps)

    # No exit signal was recived, so return false.
    return False

This code isn’t truly stateless. I use the Pygame module loading to do some Pygame initialization and window setup. Even this could be removed, but you would need a very fast machine to be able to recreate the pygame window every frame at a decent framerate. I’ve tried it though, and it is pretty cool to be able to change your window size mid run by tweaking your initialization parameters.

The animation produced by this code is stateless. And the code was surprisingly easy to write. It would be interesting to see how far you could push this approach. I think that it would rapidly become impossible to work with, as any sort of complex program would need to be passed all of the previous user input as a parameter to the play function. While it would be interesting to try to write a game that constantly derived it’s state from a time coded array of past user input, I doubt it would be fruitful. I suppose games like chess could read a board state and return a new board state every frame. Its great, from a mental exercise point of view, but I expect a dead end productivity wise.

Caching

So, onward to the next approach. Caching. This essentially boils down to having some code that isn’t run every frame. For example, if I wanted to move a box across the screen, I could use some special code to initialize it’s x position to 0, and then the live code that runs every frame increments the position by 1. You rapidly run into problems with this approach though. For some interesting reading on the topic of state and live coding, take a look at this reddit comment.

When I started working on this approach, I immediately ran into problems where my initialized state wasn’t in sync with my live code. To expand on the box moving example, lets suppose that I want to add a second moving box. So I add a line of code to the initialization section that sets x2 to 0, and I add my code to the live section to increment x2 by 1 every frame. Should work, right? Nope. If you do this while the code is live, you get an exception because x2 was never initialized, because the init code hasn’t been re-run since you added x2. I don’t have a solution for this that I am really happy with, but I have a couple of hacks that go a long way towards eliminating this problem. One is having ‘r’ keypresses call the init function. This helps a little. You could add x2 to the init, save, press ‘r’, add x2 to the live segment, and save again. But that sucks. The other hack I added was to the controller. I put the controller in charge of the initialization function at start up. Also, if the controller encounters an exception when calling play() on the livegame, it attempts to call the init function, to see if resetting the system will resolve the exception. I’m not really happy with my implementation, but you can take a look at it here: controller_hackish.py.

Here is the corresponding livegame_hackish.py. To run this, you will need an image. I use my pixel art alien:

fps = 30
width = 640
height = 480

import random

class Alien:
    """
       Effectivly a very simple sprite class, with it's properties
       defined in it's init code.
    """

    def __init__(self):
        self.alienImage = pygame.image.load('eyealien.png')
        self.alienImage.convert_alpha()

        self.pos = [50,50]
        self.direction = [1,1]

        self.velocity = [2.5, 2.5]

    def draw(self, display):
        display.blit(self.alienImage, self.pos)

    def update(self):
        """
            Update is called every frame.
            Adjust the alien's position based on it's
            velocity.
        """

        if self.pos[0] > ( width - self.alienImage.get_width() ) \
                or self.pos[0] < 0:
            self.direction[0] *= -1

        if self.pos[1] > ( height - self.alienImage.get_width() ) \
                or self.pos[1] < 0:
            self.direction[1] *= -1

        self.pos[0] += self.velocity[0] * self.direction[0]
        self.pos[1] += self.velocity[1] * self.direction[1]  

# Ugh, has to be global because it is initialized in a function
# and used in a different scope.
global alien

def initState():
    """
        Called by the controller, used to initialize variables
        and objects that maintain state.
    """
    global alien

    alien = Alien()

# check to see if the pygame module is in the namespace
try:
    pygame
except NameError:
    # pygame doesn't exsist, so import it.
    # this only happens once.
    import pygame
    from pygame.locals import *

    # initialize the pygame display
    pygame.init()
    pygame.display.set_mode((width,height),0,32)
    display = pygame.display.get_surface()

    # initialize the pygame clock
    clk = pygame.time.Clock()

    initState()

def play():
    """ Main game logic, called once per frame."""
    global alien

    # fill the display with black.  Clears the screen.
    pygame.draw.rect(display, (0,0,0,255),(0,0,width,height))

    # draw a shape.
    pygame.draw.ellipse(display, (180,40,200,255),(200,160,100,50))

    # move the alien
    alien.update()

    # draw the alien
    alien.draw(display)

    # update the display.
    pygame.display.flip()

    # check for events, and return true if we get an exit signal.
    events = pygame.event.get()
    for event in events:
        if event.type == KEYDOWN and event.key == K_r:
            # reinitialize the program state.
            initState()
        if event.type == QUIT or (event.type == KEYDOWN
                                    and event.key == K_ESCAPE):
            return True

    # try to maintain a set frame rate.
    clk.tick(fps)

    # No exit signal was recived, so return false.
    return False

The above code loads an image, and uses an object in a way that maintains state across frames. There are a few things that I don’t like about it though. One is the globals. I had to make my alien object global, because I initialize it in a function and then use it outside of that function’s scope. It’s ugly, and I don’t know if python offers a better way to do it. The other problem is related to the contents of the reddit comment I linked to above. When my alien object is initialized, it captures the code of it’s methods. Which means that the method code is not live. If you change the Alien.draw() method for example, the change doesn’t take effect when you save the file. You must reinitialize the system to get an alien object that uses the new code. It’s possible to work with this, but it doesn’t fit with the spirit of keeping everything ultra-dynamic for live coding.

It would be really nice if a Python guru could just hand me a framework that addressed all of the problems, and made live coding a completely painless process. I really think this sort of thing could make for an amazing game development environment. I just wish I had more free time to work through the quirks.

Not on the topic of live coding, but still along the lines of game development and python dynamism, I recently discovered a Python project called Bruce the Presentation Tool. I don’t know much about it, buy one feature caught my eye. It has an interactive Python shell running inside a Pygame window. I imagine that this could be very useful for introspection when working with Pygame. In the past I’ve had a lot of success with using a keystroke to spawn an iPython shell in the console window I’ve launched my game from. It’s extremely useful for debugging and experimentation. I imagine that a deeper embedding of the shell might be even better.

I tried out the examples on Logan’s page, generated some weird drum loops, and had some fun with it all. The experience was a reminder that I want to learn how to make music. But it also opened my eyes to what seems like a new approach to programming.

After 30 seconds of looking I have failed to find a good reference on this, but I have read that a major factor in programmer productivity is the turnaround time between editing code and testing the results. If you are working on big project with a slow build process making changes takes a long time. Because changing too many things at once is a bad idea, you have to spend a lot of time waiting to test your code. If you are working on a small project in a scripting language, then it’s just save and run with little waiting to see the results of your edits.

What if we take this a step further? Are there productivity gains to be found through live coding, where you see the results of your changes when you save the code? I’ve decided it’s a neat idea, and I want to explore it. Since most of my programming focuses on game development, I tried out live coding with PyGame. What can I say? Recompiling your game’s codebase every frame strikes me as a wonderful way to trade cpu cycles for increased programmer productivity.

The first step is building the controlling script that does the live coding magic. I started with Logan’s example, but I wanted to do a couple of things differently. The first is I wanted to see a message and a backtrace for both syntax and runtime errors. The second is that I wanted the host and the client to be largely independent. Here is my controller.

controller.py:

import traceback
import StringIO

from time import sleep

done = False
imported = False
loadBroken = False
runBroken = False

def genTraceback(ErrString):
    """ Takes an error message as an arguemnt.
        Generates a traceback of the most recent
        exception, and prints it with the error
        message.  Sleeps for 2 seconds before
        returning.
    """
    fp = StringIO.StringIO()
    traceback.print_exc(file=fp)
    message = fp.getvalue()

    print ErrString,"\n", message
    print "\nFix livegame.py to continue.\n"

    sleep(2) 

# loop until we sucessfully import livegame.py
while not imported:
    try:
        import livegame
    except:
        if not loadBroken:
            genTraceback("Failed to import livegame.py.")
            # set a flag so that the traceback is only printed
            # once
            loadBroken = True
    else:
        imported = True

# loop until livegame.play() returns True
while not done:

    # attempt to reload the code
    try:
        reload (livegame)
    except:
        # if the reload fails, print the traceback once.
        if not loadBroken:
            genTraceback("livegame.py is broken.")
            loadBroken = True

    else:
        loadBroken = False

        # if the reload is succesful, try to run livegame.play()
        try:
            done = livegame.play()
        except:
            if not runBroken:
                genTraceback("play() in livegame.py is broken.")
                runBroken = True

        else:
            runBroken = False

Sorry for the \" silliness in the above code. It seems to be a wordpress bug. Anyway, what the above code does is load livegame.py and then reload it in a loop, calling livegame’s play function every time. Thanks to the traceback and StringIO modules, it outputs both syntax and runtime error tracebacks to the console seamlessly.

Here is a very basic livegame.py:

fps = 10
width = 640
height = 480

# check to see if the pygame module is in the namespace
try:
    pygame
except NameError:
    # pygame doesn't exsist, so import it.
    # this only happens once.
    import pygame
    from pygame.locals import *

    # initialize the pygame display
    pygame.init()
    pygame.display.set_mode((width,height),0,32)
    display = pygame.display.get_surface()

    # initialize the pygame clock
    clk = pygame.time.Clock()

def play():
    """ Main game logic, called once per frame."""

    # fill the display with black.  Clears the screen.
    pygame.draw.rect(display, (0,0,0,255),(0,0,width,height))

    # draw a shape.
    pygame.draw.ellipse(display, (0,40,200,255),(200,200,100,50))

    # update the display.
    pygame.display.flip()

    # check for events, and return true if we get an exit signal.
    events = pygame.event.get()
    for event in events:
        if event.type == QUIT or (event.type == KEYDOWN
                                    and event.key == K_ESCAPE):
            return True

    # try to maintain a set frame rate.
    clk.tick(fps)

    # No exit signal was recived, so return false.
    return False

The first time this code is run, it initializes PyGame and creates a window. Every time play is called, it clears the window, draws a blue ellipse, checks for events, and then sleeps long enough to try to maintain a set framerate. If you press the escape key livegame signals the controller script, and the controller exits. To see where things get interesting, change this line:

pygame.draw.ellipse(display, (0,0,255,255),(200,200,100,50))

to something like this:

pygame.draw.rect(display, (255,0,0,255),(200,200,200,100))

Save the change with the PyGame window open beside your text editor, and watch the small blue ellipse instantly turn into a larger red rectangle. A basic example, I admit. But it hints at very deep potential.

The next step is taking this live environment, and building a full game using it. I intend to give it a try, hopefully soon. It will take some cleverness to keep things both dynamic and running fast enough. I might have to set up some sort of caching system so that expensive operations, such as loading an image or level from disk, don’t happen every frame. I could perhaps bind a key so that the expensive stuff is only done on request, but I think the experiment will be most interesting if I keep that sort of thing to a minimum.

There are obvious improvements to the above code that could be made, but I wanted to keep things as simple as possible. Though I do want to add more features before I make an attempt at building something significant using the live environment. I hope to modify the controller so that it takes the name of its client as a command line argument. I would like it if the controller gave some sort of audible notification if the client code caused an exception and produced a new traceback. I will see if I can use Ipython’s handy syntax highlighting for the controller’s tracebacks. It would also be neat to modify the client code to use the python if name == '__main__' trick. Then the client could optionally run as an independent program without the controller. This would also allow changing settings such as the target frames per second based on the environment the code is running in.

If I haven’t stated it enough already this post: this approach opens up lots of interesting possibilities. The only downside is that some day I’m going to start writing flash games that run directly in the browser. When I do that, I’m really going to miss all this dynamic language magic that I’m learning to use with Python.

Edit: I’ve posted an update, Live Coding, Continued

Following up on one of the topics from my previous post, I’ve started using iPython with very nice results. One of it’s many cool features is the ability to embed a shell into your code and launch it whenever you want. I mapped the ‘~’ key to launching a shell, and with almost no effort the development version of my game had a rough approximation of the Quake console. This goes a bit further though, because the iPython shell has full access to read and modify the entire game’s state, whereas the Quake console doesn’t know anything about the underlying engine. Also, iPython brings with it the ability to automatically launch the debugger whenever an exception occurs. Surprisingly this is less useful than I expected, as the default Python stack trace usually gives enough information to locate bugs, and the extra power of the debugger isn’t usually needed. I still haven’t really gotten into the full swing of the fabled interactive development style, where new functionality is dynamically loaded into running code and tested from the shell. But I am getting closer. I do seem to have cured myself of the need to scatter my code with diagnostic print statements every time I have a bug. iPython is a very powerful tool.

Which brings me to another topic. I initially started learning to program in Python for three reasons. It has a solid set of libraries for game development, it has solid cross platform support, and it is a high-level, powerful language. C and C++ are the standard for game programming, but I didn’t want to have to deal with the headaches of memory management plus the lack of dynamic language features. Despite more than a few frustrations with Python, I’m very happy with the choice. But I have to ask myself a question; if Python is so great for hobby game development, why are there so few good Python games? The PyGame site has lots of games on it, but very few that strike me as being really great. Every ld48 has lots of Python based entries, but they are seldom as good as the C++ games. Some neat stuff comes out of PyWeek, but I’m typically more impressed by the ld48 results.

Is it because there are better tools and libraries for C? Not from what I can tell. If there is a really useful library, there is typically a Python wrapper for it. Does Python’s comparatively slow speed hinder it? Maybe, but I don’t think so. Some of the most graphically intense ld48 games of the past might be difficult to implement in Python, but most of the best ld48 games could have easily been done in Python without having to worry about performance.

One idea that came up when Jay and I discussed this is that the talent pool for C++ game programmers is simply a lot deeper. I think this has some merit. Most professional game programmers work in C++, and when someone first approaches hobby game programming, C++ seems like the natural choice. So we have more people with more game programming experience using C++. Which would account for the best ld48 games typically being from C or C++ programmers. Adding weight to the experience matters argument is Phil. Phil is one of the more experienced Python using ld48 participants, and his mixed Python/C++ entry is the highest ranked game in the most recent ld48. As well, after working on 5 Python game projects and participating in 3 prior ld48s, I’ve gotten much better at it, and my Python game received an above average ranking. So perhaps experience is the key, and language doesn’t matter much.

If there are simply more C++ programmers with enough experience, it explains why they are typically over represented in the top of the ld48 results. I guess it makes sense, but I would have thought Python could provide more of an edge. Could Python’s edge come into play in a different manner? Ld48s often have many Python games that are ranked below average. Maybe Python makes it easier for beginners to get a game done in 48 hours, whereas you have to have a great deal of experience and skill to do the same in C++. I’ve been thinking about average rankings of C++ games vs. average rankings of Python games. It might be interesting to look at the percentage of Python users that submit a final entry, vs. the C++ users that do so.

One of the reasons that Python vs. C++ has been on my mind is because I played the ld48 #8 games so shortly after playing the PyWeek #2 games. I felt that the ld48 game were noticeably more interesting and of higher quality. Now part of this is just a numbers game, there were 66 entries in the ld48, vs. 37 in PyWeek. Plus the ld48 has the C++ programmers that I argue have so much experience, vs. Python only with PyWeek. But still, I thought that week long team efforts would produce much better results than 48 hour solo efforts could. now that I’ve thought about it, I think the extra time and the option of working in a team make it more difficult to produce something really good in a competition. It’s hard to maintain intense focus on a project for a whole week. The communication between team members creates overhead and distraction. Team entries might result in games designed by committee, which is bad when you are trying to make something great.

I read a comment in the ld48 irc channel about the distinction between good crappy graphics and crappy good graphics and I wonder if this is a factor in the ld48 producing better games than PyWeek. “I’ve got a week and a group of talented people to work with. We can create something big and complex, it will be great!” vs. “I’ve got 48 hours and I’m on my own. I’m going to make something quick and dirty and simple. It probably won’t be much, but it’s all I’ve got time for.” Perhaps it is possible to do a really good job on something limited and simple in 48 hours, but trying to make some thing big and complex is hard to do in a week. Aim as low as you can get away with and build up from there, instead of aiming at where you think you should end up.

DrPetter is a participant from the last couple of ld48s. In both competitions he made fairly simple, but very well done, platform games. The most striking thing is his art work. It looks like it was taken directly from the best Genesis or Super NES games, it’s very cool. Reading his worklog from the last ld48 I came across something I thought was interesting. He had implemented a zoom feature in his game that let him view the level from any distance, and adjust it in game. He initially created this to make debugging easier, and he was considering letting the player control the camera as part of the game play. He decided against including the feature though, because he felt that the zoom ability ruined the retro feel of the game. He has an interesting point. A Genesis wouldn’t have had the power to pull off the zoom, so you never saw that sort of thing in old games, it’s a modern feature made available be the power of 3d accelerated video cards. If he had included the feature, his game would have felt more modern, and players would probably more naturally compare it to modern games, which a 48 hour game can’t compete with. It would have crossed the good-crappy/crappy-good line. As the game stands though, it is very cool with an excellent 16-bit retro feel.

So, the moral of today’s story. I like Python for game programming, and I’m liking it more as I gain experience with it. Also, good-crappy is way better than crappy-good. If that makes any sense at all.

In my experience, when writing a game I end up with a lot of constants in my code that determine how the game plays. The values for these numbers are typically not derived by any sort of logical process, instead they arise through a guess and test process that is apparently known as tuning in the industry. I think that the quality of a game’s tuning is one of the major factors in determining if it is any fun. Of course I want to make my games more fun, so I come to the question of how do I improve my tuning?

Should I be more rigorous and put more effort into the logic of the numbers that I chose? To some extent I think that I should. It would be nice if I could look at the numbers in my code and actually understand roughly what they meant in terms of units that I use in the real world. With the extremely rapid game development environment that typically drives my projects, it is far to common that the numbers are pure magic. So I should work on that. But I think there are limits to the benefits of this approach. If I take it to it’s extreme, I’m trying to build physically accurate simulations. While good physics can be a lot of fun in a game, there is a big difference between a racing game and an accurate car simulator. I’m more interested in making a fun racing game.

How then, do I make game engine tuning more effective? I’ve been asking google this question and came across one very useful tip in a Gamasutra article on physics tuning (bugmenot required). Integrate live parameter tweaking into your game, so you can try different values as you play, without having to edit the source and restart. I picture a python object that I can somehow initialize with my constants, which would then allow me to tweak values live in game, and store the results back to a config file. All with minimal pain. I discussed this with Jay a bit, and he had some interesting input. He mentioned that while working on Steamrollers he sometimes would load a level, test it, back out to the menu, edit the engine source code, and then load the level again to see the changes, without ever fully exiting the program. As well, he thought that the place to interact with constant tuning would be the terminal window, not the main game window. This is contrary to my initial thoughts, but it makes a lot of sense.

So I want to use the terminal to interact with my running program, load changed source code on the fly, and test out tweaks to constants while I play the game. I think that this sort of dynamic program interaction is starting to sound a lot like what Lisp people talk about with the Lisp shell environment. Fortunately Python has it’s own shell, and it is apparently quite powerful. Ipython sounds interesting as well. The only downside is that I really don’t know how to use the tool effectively, or if it is even possible to do what I want within the framework of PyGame. So now I’m reading a lot about the Python shell. Or at least I was until the whim to update my blog hit me.

I’m quite intrigued by this path. It should be good to learn some more powerful tools than just the text editor. I keep reading about the power of Python’s introspective abilities. I hope that learning this sort of thing will make me a better programmer. I tend to focus too much on the power and ease of use of a language, and completely ignore any tools that could save me time or solve problems for me. I think that it’s time that I stop missing out. Or at least finally break the habit of using print statements instead of the debugger. Changing habits and learning new tricks will probably be a hard slog, but I’m enthusiastic. At least for the moment.

So hopefully with some research and some practice I’ll soon be tweaking my gameplay using all sorts of insane ninja Python dynamic language-Fu. Which should help make my games more fun. I hope. But I wonder. One of the problems that I encounter is that after a while I become too close to the code and it becomes very difficult to tell if the game is enjoyable to play. Fun and playability are a hard thing to judge. In fact I think there is another whole rambling bloggy essay in that last sentence alone. I’ll leave that for another day though, and try to stick with tuning.

What if I could test and measure the results of trying different game engine tunings? When Valve developed the first Half-Life they had playtesters play their levels. Valve recorded all sorts of useful statistics, and set up rules to tweak their level designs. If the numbers showed that players were going for long stretches without firing their weapons, monsters were added to relevant parts of the levels. If the players health was always very high or very low, the level difficulty was adjusted. If a player took a very long time to get past a puzzle, a hint might be added to make the puzzle less frustrating. If you want to know more, the details come from this Gamasutra article. (again, bugmenot is your friend.)

Unfortunately I’m never going to be able to do this sort of playtesting for a 48 hour game project. But I will have to spend some time thinking about the possibilities of having friends try my games, and getting usability information that would let me tune the game appropriately. Of course there is the standard feedback. “It would be better if you could move faster.” “I can’t control it.” “Your game sucks.” This sort of thing can be valuable and helpful. But what I would really like to see would be some numbers that pinpoint the problem areas. I just don’t know if it is doable in a general, reusable sort of way, or if I would have to write measuring tools on a case by case basis.

I don’t seem to be coming up with anything sensible at this point, and I’m getting tired, so I’m going to leave this thought here. Making a game measure the amount of fun it’s player is having seems to be a non-trivial problem.

So, this was a fun exercise from my point of view. I updated my blog. I enjoyed writing it. I explored some ideas that are on my mind. Fun. I might have to try this approach again. My only question is, how does it read?

• Source: steamrollers-bugfix.zip
• Mac (Tiger Only): steamrollers-bugfix.dmg.gz
• Windows: steamrollerswin32-bugfix.zip

Also, take a look at the SnV entry page.

I’m quite happy with what we produced, but there are a bunch of quality improvements that I would like to get to now that we are outside of the one week timeframe. As always, finishing something is surprisingly hard. Especially without the pressure of a deadline.

I have a renewed interest in my last ld48 game. Hopefully I’ll find the time to put some work into it soon.

On an unrelated topic Jay and I had a discussion of the relative merits of different keyboards as weapons. He tells me that his generic plastic 105-key is the ultimate in keyboard weaponry. Silly boy. A quick blow to the head from a Model M would teach him the error of his ways.

I really should fit the above documents into the blog page structure. Other things that are on the bloggy todo list:

• Create a page for datacam, my latest ld48 entry.
• Create a page for evilboxes. Which has a minor update: evilboxes-1.1-Win32.zip
• Replace the template. I like WordPress’s default template, but it would be nice to have something less common.
• Get a real server. There has been talk about colocating a real server for a while. I need to get off my but and make it happen.

In other news, I’m looking forward to being on vacation next week. 3.5 days in Toronto then 4.5 days in Montreal. Should be fun.

Also, I’m really looking forward to the PyWeek programming competition on the 26th. It’s about using Python to make a game in one week, with no restrictions on team size.