A peek into the world of game developers

It can be interesting to see what the folks involved in another industry are discussing. This week the Game Developers Conference has been going on in San Francisco, and while I didn’t attend GDC (seeing as I don’t work in the games industry even ) I did head up to check out a couple of events taking place around GDC.

The first was an unconference taking place at the Yerba Buena Center for the Arts called Lost Levels. This was the first unconference I’ve really attended and the format was pretty interesting. The venue was the lawn area at YBCA on which three large tarps were placed to designate three ‘session areas’ (my term — not their’s, as far as I know). People signed up on a board to hold forth on some topic for around ten minutes. The organizers of the event would time speakers and call up the next speaker in turn while people gathered around one session area or another to listen in. By and large this was a simple system that seemed to work quite well — people could have their say on a topic and if others wanted to talk with them more they could follow up afterwards.

So, what can I say about the actual talks given at Lost Levels? There were a wide variety of talks and there was no way that I was going to be able to hear all or even most of them. I definitely do not want to give the impression of what the whole unconference was like — just the talks that piqued my interest.

  • At least a couple of speakers discussed interactive fiction (or, perhaps slightly more inclusive, interactive narrative). The impression I got was that this was being ignored by most of the game development community — a point that I’m not informed enough to comment on.
  • Another interesting talk challenged the limitations of character identities in games. Often a player is encouraged to create and identify with a character in a game, but at the same time there are often very few ways that players can really modify their character. The example brought up was gender, which is often simply a male or female option. By now we should know that is pretty limiting for a lot of folks. The speaker challenged game developers to build in more flexibility for players.
  • Another theme that came up in at least a couple of talks was the idea of non-competitive or non-confrontational games. Probably for most gamers the whole idea of a game is defined in some way by competition and conflict. There are game that do not necessarily have this element, and the speakers were encouraging gamers to pay more attention to these and for game creators to think about creating more non-combative games.
  • Perhaps the most interesting talk I heard was on how the gaming industry operates. This is a demanding industry that is notorious for burning out game developers. Driving that is a rather ruthless economics where a game is considered a loss if it hasn’t reached a certain level of sales. Some of the things the speaker was referencing flew by me but no doubt they would have been understood by others in the audience.

A number of the participants were clearly involved in the games industry making games at some level, either as game designers, artists, programmers, art directors, project managers, in small startups or larger, more established companies.

The second event was a smaller session The Future of Games and Entertainment at Swissnex San Francisco. This was a good event to meet others and do a bit of networking. Chuck Eyler gave a talk drawing on his own career in the film and gaming industries. On display were several interesting games that visitors could play.

While there were more games played on PCs or iPads, the main thing I took away from that event were the games that utilized different ways for players to interact with them. One game used small boats on a shallow pool of water, on which was projected a series of dots surrounding the boats. Each player fired the boat’s gun by blowing into a small round metal tube on their end of the game board. Another interesting game — although I’m not sure I’d call it a game exactly — was a picture where the subject (in this case a small child) ‘wakes up’ when a viewer approaches it and starts to mimic the facial expressions of the viewer in a manner that was both interesting yet disturbing at the same time. I’m not sure if this qualifies as an ‘uncanny valley’ type of experience, but it reminded me of that.

Games have by now become a huge thing — not just as an industry but in terms of our collective culture. I think it’s safe to say that gaming produces new sub-cultures. This has been building for a long while. There are clearly a lot of people thinking about the issues that are arising in gaming. There is a good amount of self-reflection starting to take place. Yet, I can’t help but get the impression from my day attending these events that there is a profound lack of theory here. Really I should say that there is a lack of familiarity with existing theories from the domains of cultural anthropology, economics, and so forth, as well as a lack of theories about the nature of gaming itself. Perhaps it is that it is still too early for that to have happened. Admittedly, it could be happening but it wasn’t evidenced by my day being a tourist on the fringes of the world of gaming.

Setting up and using Cron

Cron jobs are a mainstay of Unix and Linux. Cron basically lets you run a shell script or other program according to some schedule. The system has been around forever and it just plain works.. even if it is just a little on the cryptic side. The system is ubiquitous and so widely used. A common use of this is to automate backups, for instance. When administering a server I would say it is of the things to think about when setting up a system — what kinds of tasks will you need to run when? (This will, of course, evolve over time. But still….)

Pretty much every implementation of Linux/Unix does the same thing. There is a cron daemon that will go through all the cron files on the system and check in every minute to see what it needs to run. You can’t really do cron jobs any more precisely than at the minute level — there is way to say ‘run a script at 5:33:45 on Monday’ for instance (and why would you ever want to do that anyway?)

Basic Usage

Cron operates on crontab files. You don’t access these files directly to view or edit them. The system maintains these in some location. Whenever you want to do anything with a crontab file, you use the crontab command.

At the command line you can view your crontab with crontab -l. This simply prints out your crontab to stdout. If you haven’t set one up yet then you’ll most likely see a message saying something like ‘crontab: no crontab for you’ (where ‘you’ is your username on the system, of course.)

In general every user with an account has access to setting up cron jobs. To do this, run ‘crontab’ with the -e flag to edit your crontab file. That will kick you into your editor (whichever it is set to, or vi by default.) Initially this will be empty but here we’ll show you how to set that up.

[me@myserver ~]$ crontab -e

However, if you don’t want to edit the crontab file interactively, you can also edit the file in whatever editor you choose and set it up with the crontab command by giving the filename. Usually when doing that I check that I loaded in what I thought by running crontab -l right after.

[me@myserver ~]$ crontab my_crontab.txt

In a crontab file lines that start with a hash mark (‘#’) are comments. The cron program will ignore those lines.

One entry in a crontab file is set up per line. This is a space-delimited list that has the information about what program or script to run and how often. The format is:

mm hh dd tt ww command

Where each field is defined as such:

mm Number of minutes past the hour to run the cron job.

(having the minutes field first is usually the first thing that throws you off. We’re so used to using the hour figure first whenever we talk about time.)
hh Hour of day to run the cron job.
dd day of month (00 to 31)
tt month (1 to 12)
ww day of week (0 to 6, with 0=Sunday, 1=Monday, etc.)
command the absolute path to the script/program to run, along with any redirection to send output wherever.

The basic usage is pretty straight-forward. For example, we might want to run a script at 10pm every night…

0 22 * * * /backup/bar.sh > /dev/null 2>&1

Where cron can get a bit cryptic is when you want to run things multiple times a day or every few days. To run a command at two different times, say 10am and 10pm, you could put each hour value separated by a comma:

# Run foo.sh at 10:15am and 10:15pm every night and send the output to
* /dev/null (ie. throw it away)
15 10,22 * * * /home/me/foo.sh > /dev/null 2>&1

Or to run a command every four hours you would use an asterisk, but then specify the multiple of ‘every four hours’ with ‘/4’.

# Run foo.sh every 4 hours
0 */4 * * * /home/me/foo.sh > /dev/null 2>&1

You can also specify a range of values with a hyphen. In practice this probably only every makes sense in the column indicating which days of the week to run a script.

# Run bar.sh at 5:30pm every workday (mon-fri), and save the output to a logs directory…
30 17 * * 1-5 /home/me/bar.sh >> /home/me/logs/bar.log 2>&1

Version control of your crontab files

Since you can both load a crontab from a text file as well as list it out easily, it is not too much work to set up crontab files under a version control system (ie. git or subversion). Then as you add more things to your crontab you’ll have a log of these changes over time.

Considerations for scripts run via cron

There’s nothing to say you can’t run a compiled program with cron — we do this often enough. But probably the main use of cron is to run a script of some kind — BASH, Python, Perl, PHP scripts can all be run via cron.

1. At the risk of stating something kinda obvious, your script/program should start up, do it’s thing, and exit. It shouldn’t hang around running forever. If you want a daemon, set up a daemon (that’s a future blog post.)

2. Your script should use absolute paths — you can’t assume the script is run from your home directory, for instance.

3. Some jobs might take a long time to run. You should take this into account so that one invocation of your script does not overlap the next invocation by cron. Putting in a check of some kind — a sentinel or lock file — to see if your script is still running can be effective. Or, if they do overlap, that each instantiation of your script can coexist happily with the others.

*** Update: (2013-03-15) Just came across a link to Chronos, which is a replacement for Cron developed by the folks at AirBnB. I haven’t looked at it much yet but wanted to throw in a link to that here.