Alexis Bauchu - On est pas des machines

Coders are also human beings

mercredi, septembre 2 2009

Working on Gray Matter

A while back I said that I'd talk about what I do during my internship at Wizarbox. It was in April, so it's been 5 months. Ok ok, I'm late, but when I post, I like to be REALLY sure! Seriously, if I haven't talked much about it, it's simply because there's not much I'm allowed to say. Game developers (and even more the publishers) like secrets.

What I'm allowed to say for the moment is that I'm scripter on Gray Matter, the new and greatly expected game by Jane Jensen. If you don't know her, she's the one behind the classical Point-and-click game series Gabriel Knight. I'm in charge of integrating the backgrounds of the scenes, the dialogs, but mainly to create the script of the game, which means the interactions with the world, between the characters, with your inventory, and to create the animated cut-scenes.

Here's the official trailer (in german) presented at Gamescom 2009:

lundi, août 24 2009

Bug Tracking and screenshots

I couldn't resist but to share this hilarious moment with you. At work, I've been assigned a bug. There's a screenshot joined with the description which is as follows:

In chapter 2, after the first mini-game, the screen became all black.
See screenshot.

And follows a picture of a window filled with black. Fantastic!

lundi, juin 22 2009

Bash Optimisation

Lately at work, I've been working on optimizing a bash script that was used to build the data of a game. Its role is to parse the game directory and for each file, match it with a building rule. If there's no rule for a file, well, then nothing happens. If there's a rule, then dates of the source file and the built file are compared, and if the source file is more recent, then the file is rebuilt. Yes, that's pretty much the basics of a configuration manager, but in this precise case Make wasn't an option.

What really bothered me in that tool, was its extreme slowness. Rebuilding modified data lacked a bit of punch, but more importantly, parsing data that hadn't been modified was slow to death. Even when a single value was modified in a file, it was taking at least 15 seconds to rebuild the script. I know this isn't too bad, but let's put this into perspective: doing nothing on about 300 files with a quad-core processor at 2Ghz was taking 15 seconds. This was already pretty frustrating as it was. Now, consider that the game contains at least 7400 files, which means when someone changes a file, you can't always know which one, so you have to rebuild the whole directory. Do the math: this blocks your machine for at least 6 minutes, just to do nothing. And that's a minimum! Because many files are rebuilt anyway. And you do this many many times a day. Fast iterating is key to success in game development, and that was nothing like it. Here is a chart with approximative time I benchmarked:

Chart: Time to build x files

At first, I thought that the problem was Bash. Browsing every file in the directory recursively was maybe slow in shell script. But it wasn't. So I thought maybe comparing the dates was long. But it wasn't. And then I saw function that was matching file extensions with rules. It was looking up extension files in an array, but had to do string manipulations because each element was of the form "extension ruleName". And it was checking the whole array for every single file you had to build! So I made improvements there.

The array looked like this:

ACTIONS=( 
"txt DoStuffForTxt"
"avi EncodeVideo"
"lua PreCompileLua"
"etc"
)

It didn't go has I expected because the building time got longer. My solution was to replace the "extension rule" array with an associative array. But associative arrays are not supported in Bash! (even though the manual says so). So I did some hacking to circumvent that (I'll talk about it in another post). I finally understood that my solution was using to much "echo"s, and removing them improved the building time. But not much. I couln't think of anything else slowing the thing, because the rest was pretty trivial, so started a hunt for "echo"s. And there it was.

In each build rule, the second line was:

echo "Extension: $ext" >> log.txt

This seems harmless of course, nevertheless, this can eat a lot of time if log.txt is actually a big file. My intuition was right and I discovered that the file was about 8Mo big. After all this investigation, the real solution to the problem was to add

echo "" > log.txt

somewhere at the beginning of the script. Then the building time improved a lot:

In fact now, trying to rebuild even a 1000 files with no changes takes less than 5 seconds. So mark my words: when you do optimisation of code, any type of code, first get a real good overview of the performances and track the lines creating bottlenecks. Unlike me, you'll end up saving a lot of time! Plus, if you're doing some bash scripting, remember that echo is quite greedy and avoid it as much as you can!

vendredi, juin 12 2009

NTFS directory junctions

Funny stuff, we had this problem at work:

The publisher needed to have the game tested, but for pratical reasons, they needed to be able to rebuild the game at any time. Fine. We send them our builder and the data. Unfortunately, we were working in a W: drive that they were already using for something else, and they had not enough disk space, and it was a network drive... The solution would be to just install the game on another drive, but all our file paths were hard coded...

So I figured: OK, we can do this quick and dirty thing: I think there is a way on NTFS disks to create symbolic links between two folders. That means that we can create an empty folder on their drive and then mount the right folder on it, wherever we are on the disk. That way we don't have to change anything.

Cool, let's do that.

Yes but... as I should have expected it, this doesn't work. Linkd.exe, the program that allows this procedure is only distributed in the Windows 2000 pack or whatever. That we don't have. So we're screwed. There's a fsutil.exe in winXP, but they only provide hardlinks from files to files, not from folder to folder. And I didn't even get it to work from files to files. Classic...

Even though this episode proved me once again that the things that are so easy and powerful under GNU/linux are just plain non doable on Windows, my colleagues laughed me for preferring Linux, saying that Linux is shit. They obviously meant that the combo Cygwin/Windows can be a pain in the ass, and it's really weird that Windows is the only OS that doesn't follow the standards that EVERY other OS follow. Yeah, that's what they meant... (sigh)