Tony’s Blog

I recently switched from a qwerty keyboard to a dvorak keyboard. If you want to see why an idiot like me would switch to a keyboard layout that is only used by less then 1% of the population then checkout the wikipedia article. I highly recommend the dvorak layout if you enjoy causing yourself unnecessary mental anguish with the slight possibility of increasing your typing speed. It’s also fun when you have to use someone else’s computer and you have to tell them to wait 4 minutes while you mentally prepare yourself to use a qwerty keyboard. Then, after looking like you have never typed before because your hitting the wrong keys, you ask them if you can switch their computer to dvorak and they tell you to go to hell because you are elitist douche bag.

I recently received an Atari 2600. Naturally I decided it would make more sense to write about it from the perspective of a man who traveled back to 1981 from present day. It’s sort of like a person moving to Phoenix, Arizona to work remotely for a company in Chicago, Illinois but instead of Phoenix, Arizona I am working remotely from 1981. To be more specific and to make the example more confusing I will be reviewing the system from the 1981 Chicago suburbs. I will be experiencing technology in the 80’s as most people living in the Chicago suburbs did at that time which was mostly through technology from the late 70’s.

It’s my first day since I moved to the 1981 Chicago suburbs. I am pretty bored. I was able to get my hands on an Atari 2600. I think my uncle bought it in 1979 and somehow I got a hold of it. When I pulled it out of the box the first thing I noticed was the front of the Atari appears to be made out of wood. Nothing makes a piece of technology look more advanced then when its made out of wood. The worst part is its not even real wood. Its black plastic with some sort of wood pattern on it. Somebody at Atari stood up at a board meeting and was actually like “Black plastic seems a little cheap looking don’t you think? I’m pretty classy and my coffee table is made of oak so this piece of technology should also be made of oak. Lets class things up by putting some fake oak wood panels on there.” Everyone else agreed with him. By everyone else I mean everyone else in 1977. Don’t get me wrong oak is very classy for a dining room table, a book shelf, or any item where wood has proven itself valuable both functionally and aesthetically but that doesn’t mean my electronics need to be encased in it or emulate its look. After the initial shock that someone would surround technology in oak I was shocked to find that it goes rather nicely with everything else in my living room. This includes my TV which, for some reason, is surrounded by oak too. I decided to place the Atari 2600 in my oak entertainment system cabinet and to my surprise it blended in perfectly because my stereo speakers, receiver, and record player all have oak cases. Good work Atari on that oak patterned front panel for the 2600.

I found that the power cord and TV wires were very long. This is pretty nice compared to systems from 2007 but seemed unnecessary because the system was so close to the TV in my cabinet. I hooked up the 2600 to the TV and attached these two little VHF prong things. I put the system on channel 3 and turned on my TV. I then looked through the games and found Super Breakout. I plugged it in and sat down on my couch. I quickly realized why the cords on the Atari 2600 are so long. There are no menus to start the game. The game select and game reset switches(I use the term switch instead of button because that is whats on the system. A huge dead man switch that you pull down on) are on the actual console so in order to start or reset the game you have to stand up and walk over to the console which is in my oak cabinet on the other side of my oak coffee table.

After moving my Atari 2600 to the couch next to me I pulled down on the game reset switch and started playing Super Breakout. It’s amazing. Using the analog paddle controller is awesome and I had such great control over the in game paddle. It makes it more like an arcade game. When I got past the last blocks my on screen paddle halved in size and the ball was flying so fast. I finally got my score up to 309 and was extremely proud of myself only to find there is no storing of high scores. You have to write it down or just remember it. After playing for awhile my best score was 428 but no one will ever know unless I am around to tell them and even then there is really no way to prove it.

I was extremely surprised at how fun the Atari 2600 was. I also played asteroids but I don’t think that game was ever fun in any form so I didn’t count it. When I was done playing I switched the Atari cable back to television and Trapper John, M.D. was on CBS so I just stared at a wall for 3 hours and then fell down. Perfect ending to a perfect day.

During a Buildbot build step you might need to have a list of files which have changed as a result of a commit to your repository. A quick way to get this information during a build step is to subclass the build step class of your choice and overload its start() function.

A build step’s start() function is responsible for telling the slave to start executing the command. Each step class has a member variable called “build” of type “buildbot.process.base.Build” which it inherits from its main parent class “buildbot.process.buildstep.BuildStep”. Here is a quick example of getting file change information during a ShellCommand step in your master.cfg file:

from twisted.python import log
from buildbot.steps import shell
from buildbot.process.buildstep import RemoteShellCommand 

# Executes a remote command with changed files appended onto the end
class ShellCommandChangeList(shell.ShellCommand):
  def start(self):
    # Substitute build properties into command
    command = self._interpolateProperties(self.command)
    # fail assert if command is not of correct type
    assert isinstance(command, (list, tuple, str))

    # Get changed file list from the build which invoked this step
    files = self.build.allFiles()
    # Log the changed files to twistd.log
    log.msg("Build Files: %s" % files)
    # Now we can do whatever we want with the list of changed files.
    # I will just append them to the end of the command.

    # Convert file list so it can be appended to the command's type
    if isinstance(command, str):
        files = " ".join(files)
    elif isinstance(command, tuple):
        files = tuple(files)

    # append files to end of command
    command += files

    # We have created the final command string
    # so we can fill out the arguments for a RemoteShellCommand
    # using our new command string
    kwargs = self.remote_kwargs
    kwargs['command'] = command
    kwargs['logfiles'] = self.logfiles

    # Create the RemoteShellCommand and start it
    cmd = RemoteShellCommand(**kwargs)
    self.setupEnvironment(cmd)
    self.checkForOldSlaveAndLogfiles()
    self.startCommand(cmd)

You can use the new ShellCommandChangeList class in the same way you use the ShellCommand class. The only difference being the ShellCommandChangeList class will append a list of changed files to the end of the step’s shell command. We use a similar class and method at Stolen Notebook to build large source asset files (models, levels, art, etc.) automatically with buildbot when they are checked into our repository.

Here is a short contrived example of using the new ShellCommandChangeList build step with a BuildFactory to call a remote command for a fictional program named `checksum`. Let’s say that `checksum` is a program which takes filenames as input, computes the checksum of those files and prints those checksums to standard out.

from buildbot.steps import source, shell
from buildbot.process import factory

f = factory.BuildFactory()
f.addStep(source.SVN, svnurl="http://svn.example.org/Trunk/")
f.addStep(ShellCommandChangeList, command=["checksum"])

Lets say two files named main.cpp and main.h are changed in the src directory of our svnurl and submitted to the repository which triggers this build. The normal ShellCommand step would just call “checksum” remotely. The ShellCommandChangeList step on the other hand would call “checksum src/main.cpp src/main.h”

You should note that the way your VC system works and how your repository is set up in terms of file location and branches may affect how the file change paths are presented to you. You can easily see the list of file changes by using log.msg in your start() function to print them to the twistd.log file.

This is a quick update to my last article on Running Buildbot as a Windows XP Service. There was an interesting comment posted by jdpipe regarding the previous article . He offered a nice solution for some issues I was having with environment variables and stopping the Buildbot service. You can check out the article he wrote about it at https://pse.cheme.cmu.edu/wiki/view/Ascend/BuildBot.

He recommends using a python script instead of a batch file to ensure the build environment is setup correctly. By using a python script the service now launches pythonw.exe directly. This solves the Buildbot service issue where it’s not able to stop or restart properly as a result of being launched from a batch file. The article by jdpipe has excellent information on setting this up along with some pictures to help illustrate the process.

I once tried to create a game called Hunt Fish Camp. The main goal of the game was to hunt various types of wildlife. The cool thing about this game was that it revolved around an A.I. ecosystem. The idea was that you would drop a bunch of different animals into a level and they would interact with each other. I had a basic ecosystem going in the Half-Life 2 engine with birds, bears, headcrabs, and some other creatures. The animals had basic needs like hunger, sleep, and procreation. The game was really cool because the world just took care of itself. You would spawn into a level and walk around seeing all these cool interactions between species. It was really cool but it had one major flaw. There was no game. It was a cool software project and really neat to look at but not really all that fun to play. I couldn’t figure out why and chalked it up to the game’s young development state and unpolished gameplay.

Recently, I have begun to crave this sort of ecosystem type game again. A long time ago I heard about a game called S.T.A.L.K.E.R: Shadow of Chernobyl by developer GSC Game World. It has been in development for a long time. The interesting thing about this game is that it’s ecosystem based. From what I understood or possibly imagined is that it contains an A.I. ecosystem of mutants and humans which live in a zone. The basic idea behind the game was to give the player a huge environment and have them achieve goals with the main goal being to find and trade artifacts. The player tries to accomplish these goals and most of the gameplay comes from them interacting with the various creatures in the ecosystem. This sounded like the game I always wanted to play. I read an interesting interview with Anton Bolshakov, one of the developers on S.T.A.L.K.E.R. In the interview it sounded like the developers of S.T.A.L.K.E.R ran into the same problem I did when creating Hunt Fish Camp. It was an awesome simulation but it just didn’t appeal to players in terms of gameplay. As a result they delayed the game and began working on a more structured story. In another interview Bolshakov gave an explanation of why they chose to do this:

It appears that S.T.A.L.K.E.R has now become an ecosystem based game with a storyline. It will be interesting to see since a lot of development went into the ecosystem’s simulation. Most games create the A.I. to facilitate the type of game and storyline they are creating as apposed to S.T.A.L.K.E.R where they kind of created a story over their A.I. system. I think it is going to be a really cool game but at the very least it should be very interesting to see how the gameplay works.

While writing the SNTask utility I had to do some network programming. I have done a lot of network programming in the past mostly using C and Berkley sockets. It’s pretty simple to get basic communication going with that combination but anything more sophisticated requires much more design, debugging, and maintenance. Using Python instead of C helps but I still have to use sockets. SNTask is a utility which is supposed to aid our game development. It’s not supposed to spawn a development cycle of its own. I didn’t want another piece of software our team had to design, debug, and maintain. SNTask has a lot of requirements but its purpose is to quicken our development. Luckily there is a wonderful networking framework called Twisted which allows us to add all the features we want to SNTask while still keeping the workload to a minimum. Twisted is written in Python and released under the MIT licence. Twisted greatly simplifies the task of writing almost any kind of network application. When programming with raw sockets I would usually dig around my computer and find my old networking library. It’s a small library I wrote along time ago which can send and receive packets over UDP or TCP. I would then start creating the application using that same old library. Twisted replaces all that and allows me to immediately start creating the application. It supports TCP, UDP, SSL, IMAP, SSH, FTP, HTTP and much more. The Twisted Framework has already allowed us to reduce the development time for SNTask while boosting its feature set. I have only been using Twisted for a couple of days so I have only grazed the surface of what it can do. So far I am very impressed.

I have been working on setting up the new automated build system. We were having some hardware problems with the new server which was very unfortunate. Denrei tracked it down to the new gigabit NIC I installed. For now we are going to revert back to the 100 Mbit onboard NIC. Despite those problems the build system seems to be working well. The server seems stable so I am finishing the automatic game source asset creation. The build system notifies developers through email about updates to the distributed files. This is a good method for keeping developers up to date on the status of distributed files but it is still far too slow. If a developer is using files which are changing then they need to know immediately when those files change. This led us to create a small utility called SNTask. It’s a small application which sits in the task bar. It shows developers the build system’s status in real-time so they will know immediately when there have been changes to files they are working with.

I proved an important theory today. Having a conversation at 150 yards can indeed be just as awkward as a conversation from 3 feet away. I often look down from my apartment building and spot people I know. I find it amusing to call them on their cell phones and notify them that I am judging them from an elevated position. Then I tell them exactly how and why I am judging them and hang up. Sometimes I keep it short and sweet. If you know me and are walking past my building it is not uncommon to receive a phone call and hear “Nice pants loser. Ya’ll just got judged!… CLICK”. If you quickly turn around and look up at my floor you might catch me ducking behind a sofa. Anyway, today one of my friends managed to pull me into an awkward conversation about network cards before I was able to judge them. The conversation was fine but it was made awkward by the fact that the person I called stopped and looked at me while having the conversation from 150 yards away. It’s very odd to make extreme gestures like you are yelling to someone far away but then be talking in a normal voice. The entire experience was terrifying. I’d like to try it again someday. Finally, incase you were wondering, I actually yell the work “CLICK!” before I hang up a phone.