LGDC Accounce

I have wanted to participate in the Lisp Game Dev Competitions for a while now, but it always seemed that work made it an impossibility. Things are no different this time around, in fact I am probably busier, but I figure that if I want it to happen I am just going to have to make the time.  Without further ado, I announce my entry into the October LGDC.

1 Asteroid Jumper

Due to the proximity of Halloween, it seems like a good idea to make a Halloween inspired game, a real fright fest.  I, however, have not followed that route at all.  My idea for a game involves hoping from asteroid to asteroid either battling or racing opponents.  This is an action game where the arena of play is constantly in flux; asteroids shift, collide, and break apart due to the actions of the players.

  This will be a 2D game where the basic gameplay will be running around the perimeter of asteroids and jumping from asteroid to asteroid.  I don't want this to be a shooter, per se.  I want something that mixes together the feel of Asteroids, Worms, an overhead view game, and a side scroller.

1.1 Weapons, etc

The items or weapons that will be available is really unclear at this time.  In my imagination, I think a few things that might be fun to have: grappling hooks, jet packs, shields, explosives, guns, and bouncing projectiles.

1.2 The Asteroids

The asteroids will have real physics.  They will have momentum (linear and rotational).  When they collide they will transfer that momentum between each other.

  I might want to include fault lines in the asteroids.  These cracks will define how the asteroid will prefer to fracture.

1.3 Technical Stuff

Okay, here's the plan: Since I am very familiar and fond of Common Lisp, I will be using it.  I always aim for cross implementation code, but for the time I will be developing for SBCL.  I am going to use CL-OpenGL for the graphics and the Squirl implementation of Chipmunk for physics and collision detection.  In my experience, CL-OpenGL works most places and Squirl works with SBCL and CLisp, but has issues elsewhere.  This is the route of least resistance as it will involve modifying the demos contained in the Squirl package.

  I am still unsure how to get sound effects and/or music into my Lisp programs other than spawning a shell process to play an audio file.  I hope to look into OpenAL for sound as it should be cross platform.

  A goal is to have this be multi-player, particularly over TCP, but time is short and I have never done this, so I'm not sure I will be able to accomplish this.  If I do attempt this I would try to use ZeroMQ, which seems to make this easy to do.

  If you are asking yourself, why not use Lispbuilder, well I have always had trouble getting it up and running.

scp and symlinks

Many would be surprised to hear that several common GNU/Linux programs don't handle symlinks properly.  By that, of course I mean that they don't handle them the way I would want them to, but close enough.  For instance, if you want to copy a directory from one server to another, the command scp -r source-dir target-dir looks very attractive. Unfortunately scp follows symlinks, meaning instead of copying a link to some other part of the file system, it instead copies that other part of the file system.  For a heavily symlinked directory this can be disastrous.

The correct and fool proof way to grab a portion of a file system from a server is to use tar.  Don't worry, this doesn't mean you have to actually create a tar file, you can use tar to pipe the output over ssh and untar it on the other side.

tar -c some-files some-dirs \
  | ssh -C my-server "tar -C path/to/extract/root -x"

If you want to download from a server…

ssh -C my-server \
  "tar -C path/to/archive/root -c some-files some-dirs" | tar -x

The -C switch to tar tells it to change directories prior to performing the operation.  The -C switch to ssh tells it to compress the traffic with gzip like compression.  You can even use a better compression if you have a slower connection to the server or a pay by the bit plan, by including lzma or p7zip in the pipe, or just passing a -j switch to both tar commands.  By the way, p7zip also treats symlinks badly and you need to protect any hierarchy with a tar archive.

In case you are wondering why scp defaults to bad behavior, well all file systems aren't created equal.  Since you are copying to a server and who knows what file system they have (for instance, it could be FAT), you might not be able to create symlinks there.  So it is an alright decision to only copy files and not links to files.  If you only deal with, hmmm, how to put it, modern file systems, this sure seems like incorrect behavior.  Maybe someday this will change, but in the mean time, the tar method works great and has been the method of choice since tar, pipes, and networks existed.

But wait, there's more.  Even if you don't have symlinks, piping a tar archive over ssh might be a good idea.  Since scp operates on individual files, it incurs an overhead on each one.  If you have many small files you want to transfer, small enough that the actual transfer time is almost insignificant, this overhead can become quite costly.  In these cases the tar method will be faster.

smithzv@ciabatta:~$ ssh scandal "ls -R kappa-slices-3d | wc"
   3993    3958  117715

smithzv@ciabatta:~$ ssh scandal "du -sh kappa-slices-3d"
36M     kappa-slices-3d

smithzv@ciabatta:~$ time scp -qr scandal:./kappa-slices-3d dat/

real    0m8.004s
user    0m1.152s
sys     0m1.184s

smithzv@ciabatta:~$ time ssh scandal "tar -c kappa-slices-3d" \
                      | tar -x -C ~/dat/

real    0m2.442s
user    0m0.824s
sys     0m0.728s

This directory on our scandal cluster has 4000 small files in it which total up to 36 MB.  Performing the piped tar method takes about a third the time of the recursive scp copy.  Also, I should point out that the scp process will, as far as I know, at best be as fast as the taring procedure.  Of course, note that we didn't use compression here as this is a transfer of already compressed files over a fast connection and compression just slows both commands down.  If you ever need to backup your computer over a your home LAN so you can reinstall an OS or something, this is a lifesaver (or at least a time saver).

So, piping a tar archive over ssh is a great tool.  That being said, there is a program that does so much more and might be a better choice as long as it is installed on both systems; it's called rsync. rsync follows symlinks just like scp by default (for the same reasons), but it has a switch, -a for archive mode, that allows it to perform the symlink preserving behavior as seen above.  rsync has other benefits over just an ssh or scp copy (like incremental updates: i.e. only transmitting data that has changed) and really should be preferred in most cases if it is an option, but you have to read the man page first or it will bite you, especially if you have heavily internalized the way cp and scp work.