My dice portrait of Albert Einstein is finally finished and hanging on my wall.

A little over a year ago, I read a blog post about creating an amazing portrait of The Madonna using dice. I loved the idea, and after some minor hesitation, decided to blatantly steal the concept. Einstein would be my subject, almost purely so that I could use this title, though it is a bit of a mis-quote. I immediately started writing code to visualize different dice images, and playing with different algorithms for picking the dice. In an effort to differentiate my project I tried using a mixture of black and white dice to give 12 colour choices.

Ultimately I decided that the resulting image looked too blocky and pixelated. I was able to generate some interesting images by adding grey dice and working with 18 shades. But that seemed to sacrifice some of the purity, fun and craziness of making an image in dice. As one of my friends said, I might as well be working in a medium that is appropriate for a portrait if I am going to throw grey dice into the mix.

An idea from the reddit discussion of The Dice Madonna was rotating the 2s, 3s and 6s to create more detail. I experimented with generating images that rotated these dice and used an error calculation to look for an improvement. I was never able to generate a result that I was happy with using this technique. I find the white space created by rotating adjacent 2s and 3s creates weird interference patterns without contributing to the image. Here is an image showing the problem.

I ultimately decided on a 4950 dice image generated with a population algorithm for dice distribution. My final image uses some rotation of 2s 3s and 6s in very limited situations. I also experimented with dithering, but decided against it.

Once I had an image, I ordered 5000 dice from Koplow Games. I chose the 12mm dice, as they are smaller, lighter and cheaper than the more common 16mm dice. However they are still large enough to qualify as what most people consider normal dice.

The next step was to build a flash program to help me place the dice. Follow the link to try it out. Click to give the program focus, and use the arrow keys to move around the image.

Actually placing the dice took about 12 hours, spread out over a week. A friend built a case from plywood and lexan, which was a huge help. Carpentry is not one of my strengths. Interestingly the assembled dice were not very square. There is enough variation in the dice that I needed to use foam tape around the inside of the frame to even the edges out. The final package weighs 53lbs, and I was concerned about hanging it from the wall. But a trip to a local framing store provided all of the needed hardware.

I took me over a year of off and on work to go from idea to art on my wall, but it was very fun. Incredibly, about a month ago I saw this link to a 10 year old web page that demonstrates just how rare new ideas are.

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.

There are some amazing visual effects and impressive programs amongst the entries. My favorites include:

• diagonal snake by tomee6, it’s a minimalist game that is actually kind of fun.
• eye by messages. Very cool visuals depending on where you position the mouse.

You can see the code for my entry on my twitter page, and here is the resulting SWF: Langton’s Ant. Langton’s Ant is a cellular automaton algorithm with very simple rules. If the current grid cell is black, paint it white, turn to the left and take a step forward. If the current cell is white, paint it black, turn to the right and take a step forward. According to the Wikipedia Langton’s Ant article, given an infinite grid, Langton’s Ant is a universal Turing machine, capable of performing any computation. I don’t expect to win any prizes, but I’m happy with the geek factor of my entry.

Taking an algorithm and trying to implement it in 140 characters of source code is, like many optimization activities, quite fun and addictive. But what surprised me was how much I learned from the experience.

Langton’s Ant does interesting things after about 10,000 iterations. At 60 frames per second, it would take almost 3 minutes to reach that point. So an extra I had to build into my implementation was a loop that ran the simulation 15 times for every frame. After doing this, I discovered that the framerate would start to seriously drop after 15k ~ 20k iterations of the algorithm. With some very rough profiling I discovered that it was the graphics render step that was taking so much time, which was surprising seeing as I was only plotting 15 pixels per frame. It seems that whenever you draw to a graphics object in flash, it re-renders every drawing operation to recreate the image from scratch. So after 15k iterations, the flash player is performing 15k drawing operations per frame. Yuck.

I wasn’t able to find much information online about working around this. Here is a blog entry that incorrectly characterizes the problem as a memory leak. I tried using cacheAsBitmap, but it didn’t help. Switching from drawLine, which the tweetcoding framework provides shortcuts for, to drawRect improved things by about 30%. Setting the render quality to low had similar results, but using drawRect cost me less characters.

Using bitmap graphics, with setPixel calls avoids this problem and allows the algorithm to run at full speed even after 10’s of thousands of iterations. Unfortunately, the minimum code required to get a bitmap graphics object onto the stage is something like this:

addChild(new Bitmap(m=new BitmapData(w,h)));

With only 140 characters to work with, I couldn’t find a way to fit this technique into my entry. So I went with the drawRect method, and you will see a serious performance degradation problem as my entry runs.

There are many ways to compress source code. Some techniques can be used methodically: using single character variable names, removing comments and unneeded white space, chaining assignments, using the result of an assignment statement as a parameter and using the ? : operators instead of if() statements.

But what I found to be interesting was finding ways to express the algorithm more succinctly. My biggest revelation came from compressing the code that handles the direction the ant is moving. The ant needs to make 90 degree turns to the left or to the right. Here is an uncompressed version of my first implementation of this logic:

v = [ [1,0], [0,1], [-1,0], [0,-1] ]; // a list of the direction options.

d = (d + 1) % 4; // rotate the ant's heading 90 degrees to the right.
x = x + v[d][0]; // Change the ant's x position based on it's heading.
y = y + v[d][1]; // Change the ant's y position based on it's heading.


In my efforts to optimize this, I first looked at the list of direction vectors. The X components of the list being 1, 0, -1, 0 and the Y components being 0, 1, 0, -1 stood out. The Y list is the same as the X list, rotated by one position. This lead to the following code:

v = [1, 0, -1, 0]; // a list of vectors.

d = (d + 1) % 4; // rotate the ant's heading 90 degrees to the right.
x = x + v[d]; // Change the ant's x position based on it's heading.
y = y + v[(d + 1) % 4]; // Change the ant's y position based on it's heading.


With this revision, the 1,0,-1,0 list is specified once instead of twice and the X and Y components of the heading are derived from the same value. I thought that this was as compact as I could make the logic. Then I was struck by the idea of using the sine function. A sine wave varies from 0 to 1 to 0 to -1 based on multiples of pi divided by two. Cosine does the same thing one step out of phase. With this insight the code becomes:

d = (d + 1) % 4; // rotate the ant's heading 90 degrees to the right.
x = x + sin(d * PI/2); // Change the ant's x position based on it's heading.
y = y + cos(d * PI/2); // Change the ant's y position based on it's heading.

I’m sure that to some people the relationship between the cardinal directions and the sine function is obvious, but for me it was a very cool discovery.

I had a lot of fun with this, and I’m looking forward to seeing which entries get picked to win by the judges, as well as seeing that future competitions hold.

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.

• Would be free.
• Would work on OS X, Windows, and if I was lucky, Linux.
• Would not involve working in Flex with MXML.
• Would produce bytecode for the faster actionscript virtual machine 2 (AVM2).
• Would allow embedding assets such as images and sound directly into the SWF file.
• Would allow the use of existing flash libraries such as PaperVision3d and Box2dFlash.

I was able to meet all of my requirements with mxmlc, the compiler that is the core of the Flex Builder SDK. I was initially uncertain about this, as I wanted to avoid developing with the Flex framework. Happily, I discovered that you can use mxmlc without needing a single line of XML. Gamedev.net has a good article on building flash games with mxmlc, but it uses XML files to set up the build. I’m going to discuss doing similar things while sticking to just actionscript. I’m not really saying anything new or unknown here, I just wanted to document what I figured out, and I hope that this might be useful to someone else.

Getting Started

Mxmlc is a command line tool, and I assume that the reader is comfortable with the dos or unix shell. If you using Windows, you might want to investigate FlashDevelop. Here is nice introduction to using FlashDevelop.

The first step is to get mxmlc. It’s part of the Flex SDK, which Adobe provides for free. Download it and unpack it somewhere reasonable. You might want to add the bin directory to your execution path so that you can use mxmlc without having include the full location of the command.

That’s all you need. Here is an example Actionscript file that you can now build.

package
{
  import flash.display.Sprite;
  import flash.text.TextField;
  import flash.text.TextFormat;
  import flash.text.TextFieldAutoSize;

  [SWF(backgroundColor="#ffffff", frameRate="24", width="400", height="224")]
  public class HelloFlash extends Sprite
  {
    public function HelloFlash():void
    {
      var textfield : TextField = new TextField();

      textfield.text = "Hello Flash!!";
      textfield.autoSize = TextFieldAutoSize.LEFT;
      textfield.setTextFormat(new TextFormat(null,48));
      textfield.x = stage.stageWidth / 2 - textfield.width / 2;
      textfield.y = stage.stageHeight / 2 - textfield.height / 2;

      addChild( textfield );
    }
  }
}

To compile it, we use a command like the following:

~/flex_sdk_3/bin/mxmlc HelloFlash.as

And here is the resulting swf:

The command line options for mxmlc are documented online. There is also detailed information available from the compiler itself, with the mxmlc –help command.

The key to being able build this program with mxmlc is the [SWF] compiler meta-data tag. It’s not properly documented on the Adobe site, but the oversight is corrected in the comments of the meta-data documentation page.

Here is an example of using an additional metadata tag to embed an image in the SWF.

package
{
  import flash.display.Sprite;
  import flash.display.Bitmap;
  import flash.display.StageQuality;

  [SWF(backgroundColor="#ffffff", frameRate="24", width="400", height="224")]
  public class HelloImage extends Sprite
  {   

    [Embed(source="cow.png")]
    private var Picture:Class;

    public function HelloImage():void
    {
      var pic:Bitmap = new Picture();

      pic.width *= 4;
      pic.height *= 4;

      pic.x = stage.stageWidth / 2 - pic.width / 2;
      pic.y = stage.stageHeight / 2 - pic.height / 2;

      addChild( pic );
    }
  }
}

If you’d like to read more, here is a blog entry detailing the use of the embed tag. Here is another blog entry, describing more advanced embed techniques.

Finally here is an example of using an external library. I’ve added a simple animation using the TweenLite library.

package
{
  import flash.display.Sprite;
  import flash.display.Bitmap;

  import flash.events.Event;
  import flash.events.MouseEvent;

  import gs.TweenLite;
  import gs.easing.*;

  [SWF(backgroundColor="#ffffff", frameRate="30", width="400", height="224")]
  public class HelloTween extends Sprite
  {   

    [Embed(source="cow.png")]
    private var Picture:Class;

    public function HelloTween():void
    {
      var pic:Bitmap = new Picture();
      var running:Boolean = false;

      pic.width *= 4;
      pic.height *= 4;

      pic.x = 10;
      pic.y = 10;

      var myTween:TweenLite;

      function tween1():void {
        myTween = TweenLite.to(pic, 2, {x:stage.stageWidth-10-pic.width,
                                        y:stage.stageHeight-10-pic.height,
                                        ease:Bounce.easeOut,
                                        onComplete:tween2});
      }

      function tween2():void {
        myTween = TweenLite.to(pic, 2, {x:10,
                                        y:10,
                                        ease:Bounce.easeOut,
                                        onComplete:
                                           function ():void {
                                             running = false;
                                           }});
      }

      function clickHandler(e:Event):void {
        if(! running) {
          tween1();
          running = true;
        }
      }

      stage.addEventListener(MouseEvent.CLICK, clickHandler);

      addChild( pic );
    }
  }
}

In order to compile this, you need to specify the location of the library as part of the source path.
mxmlc -compiler.source-path+=~/code/flash/TweenLiteAS3/ HelloTween.as

Click the cow to see the animation in action:

That’s all I have to show for now. I think once you know how to use it, mxmlc provides all the building blocks you need for full featured flash projects.

Here is a zip file bundling all of the code and files. mxmlcintro.zip Everything is public domain, except for the cow image, which belongs to Jay. You would have to ask his permission if you would like to use it.

Alternatives

Command line mxmlc might not be right for you. FlashDevelop, which I mentioned earlier, can serve as an IDE and GUI for mxmlc, making it a nice option for Windows users. Other compiler alternatives Include MTASC, which compiles Actionsscript 2 for the original Actionscript virtual machine, and HaXe which is a language with tools that will build for multiple targets, including AVM2 SWFs.

Last month there was an informal weekend long game development competition that Jay and I were planning on participating in. One of the themes chosen was “anti-text”. The voting was happening in IRC, and Jay suggested that we create a textless IRC. The idea of making something like a web based pictochat was kicked around, and after spending the weekend working on it we ended up with imageboard.net.

We built a site that is like a web based discussion form, except that you draw low resolution pixel art instead of typing text. I made the pixel art application in Flash, and Jay did the backend in Python, as well as the HTML/CSS/Javascript. Our icons on the web interface were contributed by users.

The site has resulted in some awesome pixel art, as well as some really clever image threads. For example, chickenz is one of my favorites.

Here are the top voted images, animations, and threads.

Here are the images that I have signed.

Now that you are done reading this, go draw something. The site is more interesting when more people are playing with it.

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