by Ron Gilbert
Sep 21, 2015

I'm a firm believer in automation. Humans screw things up and the more times a human needs to touch something, the more opportunities there are for something to get screwed up. This is very true of build processes. Building a game should be a single step and complete handled by scripts; less opportunity for humans to get in the way.

Build processes are boring and monotonous and anytime a task becomes boring and monotonous it's ripe for humans to screw it up as our brains turn off and our mind drifts.

Automating the build process of code is relatively straightforward. You create a script (bash or .bat file) and execute all the steps. Automating art is a lot harder. Art is made up of a lot of little pieces and art tools are notorious bad at exporting as an automated process. There is a lot of clicking and naming files and each of these steps begs for humans to screw it up.

A few years ago, when I was working on Scurvy Scallywags, Clayton and I faced a very similar problem. We had a ton of little art assets all in Photoshop files and layers. If the art changed, I'd have to find the change and save it as a .png. Photoshop has a "Export Layers to Files" option that is all but useless since it requires typing in of filenames and exports as numbered sequences. It's also painfully slow.

Then I stumbled across a program called Slicy that takes a Photoshop file and exports .png files based on how you name the layers. It was like magic and (quite literally) change my life. If anything in the Photoshop file changed, I'd drag the file into Slicy and it would spit out all the .png files, named exactly how we needed them.

I would then type ‘munge_art' on the command line and everything would be run though TexturePacker and was in the game before you could say "robot overlords".

I adopted this same practice for Thimbleweed Park. The amount of art in the game compared to Scurvy Scallywags is staggering. Close to one hundred rooms, each containing a gaggle of objects and parallax layers, all needing to be saved out and packed into sprite sheets.

The Photoshop files for rooms are organized into layers as follows:

You can download the actual Photoshop file that Mark created here). Please keep in mind that this file still has to pass through a polish phase and is not done yet. There is even some programmer art in there. Programmer art is when the programmer will quickly add something to get functionality working, then it will be replaced later by a "real" artist.

The @bounds layers you see tell Slicy what part of the image to export and the name of the layer is the .png file that's created. TexturePacker then takes all the .png files and packs them together (with empty space remove) to produce a spritesheet that is used in the game.

I like this process because there is little chance of error. If Mark makes a change to the room art, we don't need to hunt down the layer and save it, we just drag the .psd file into Slicy and we're done.

- Ron

Josejulio Martínez - Sep 21, 2015 at 16:29
Awesome application Ron, thanks for the info.

Conradson - Sep 21, 2015 at 16:31
"Little change of error" ?

Christian - Sep 21, 2015 at 18:49
"...little chance of error..."

Jeff King - Sep 21, 2015 at 16:38
Cool post! I used a similar method for my first iOS game, so I could basically use Photoshop as my level editor. Each level was a photoshop Group, and within each group the layers represented the enemies/obstacles and were named in a way that matched up with my games sprites. I then wrote a script to process the photoshop file and spit out Xcode friendly plists containing the locations of all my level elements. I also developed some shorthand so I could put attributes for the various enemies right in the photoshop layer name.

I found it a lot easier than having to use some sort of open source map editor that didn't really fit with how my game levels worked.

Charles - Sep 21, 2015 at 16:40
Holy crap photoshop source files!!! I think I just nerdgasam'd...

Charles - Sep 21, 2015 at 17:04
Good god it would take me weeks of OCD pixel shifting to reach a quality of this magnitude, and even then it would be no where close to this... Equally as impressive is his alphas and transparencies... Speaking of, are you guys going to be using the "Ground Mist Demo" layer in here? (its currently turned off but looks damn good)

Ron Gilbert - Sep 21, 2015 at 17:08
We might trying doing ground mist with shaders so it can react to the actor walking. It's a B task depending on how things go.

Mattias Cedervall - Sep 21, 2015 at 17:30
That would be fantastic!

Jens - Sep 21, 2015 at 16:42
So why not go the next step and use a build script or source control hook to pick up changed psd files and run Slicy automatically?

Ron Gilbert - Sep 21, 2015 at 16:44
The one thing I don't like about Slicy is there is no way to run it from the command line. Also, a source control hook doesn't help because we're doing this mostly during dev before the files are checked in, and the .png files output from Slicy are source controlled.

Jens - Sep 21, 2015 at 16:55
Can it be run from AppleScript? Alternatively GIMP can open .psd files as well, supports Python and Scheme scripting, and can run scripts from the command line. You can even run it as a simple "server" through a remote control interface.
The source control hook would run on a build server, check out the psd files and add/submit exported png. Though that is less useful for iteration, and more useful for making sure all submitted assets are in sync with the source assets.

Ron Gilbert - Sep 21, 2015 at 16:59
It's not necessary to run Slicy on the build server because the .png files Slicy emits are under source control. I have found GIMP to be... ah... lacking to use polite word. I can't read modern PS files. From what I can tell, Slicy can't be automated via AppleScript. I've email them several times asking this and other questions and have only gotten a polite "We'll look into that." reply.

Brian S - Sep 21, 2015 at 18:07
Is this out of date?  Gives an example of how to run Slicy from AppleScript.

Have you thought about emailing the developer and asking for a command-line enhancement or special build?  Who knows - they might be Maniac Mansion fans.

Brian S - Sep 21, 2015 at 18:09
Never mind the question about emailing the developer...  I see you did that and got no useful reply in the past...  bummer.

Ron Gilbert - Sep 21, 2015 at 18:26
Oh, thanks for the AppleScript link...

AK - Sep 21, 2015 at 22:30
If you can get Slicy to run from the command-line, would it make sense to have the PS file in source control and the .png files the output of the build process ?

Jens - Sep 22, 2015 at 06:24
Personally I'd say it depends. We've got for example .fbx files in source control, even though they can be rebuilt from Maya files. But that would require Maya to be installed for everyone who needs to build the game. So it depends on installed software, software licenses and conversion times.

I quite like the idea of Unity's asset cache server, to store converted data in a simple hash -> file storage system, where the hash is calculated from the source file and the conversion options. The disadvantage is that you'd have to set this up on a server and make all your tools use it, so it may be simpler to just have converted files in source control.

Orcan Ogetbil - Sep 21, 2015 at 22:45
If GIMP left a bad taste, another tool to try is ImageMagick.
A quick search returns potentially useful results for extracting PNGs from PSDs, e.g.

Robert Megone - Sep 21, 2015 at 16:45
Clearly you are very lucky to have a great art team.
Obviously this solution relies on an artist who gives a crap about the technical aspects and cares about what the art looks like in game. That or some mug who sits there slicing this stuff manually. This whole post gave me nightmarish flashbacks and I'll be having nightmares about incorrect aspect ratios for the rest of the week!

David Fox - Sep 21, 2015 at 17:29
Mark generally gives us the elements in layers, showing us how he wants the room to look. Then I grab the file, regroup and rename layers, and export using Slicy. It's pretty iterative, with me adding mask layers so the actor can walk behind a door or something.

Note also that the foreground layer looks partially blank on the far right. Since that layer moves faster than the main background layer, it has to be longer. Likewise, the sky layer is shorter than the main layer because it moves more slowly. I have a spreadsheet that calculates how long each layer needs to be, and then I use the @bounds layer in that group to inform Slicy.

For example, generally using 0.25 for sky, and between 1.15-1.3 for foreground layers.

Bogdan Barbu - Sep 21, 2015 at 22:08
Right, so I was about to ask---how come the sky is as wide as the hills in the image in the article? (I'd check the PSD file but if I try installing PhotoShop or GIMP, I'll probably just get a message saying "Really? YOU? Hahaha".)

David Fox - Sep 22, 2015 at 00:57
We're only using a portion of Mark's sky layer, but leaving it all in the Photoshop file in case we need to adjust which portion we want to use.

Bogdan Barbu - Sep 22, 2015 at 02:19
That makes sense. Thanks.

tomimt - Sep 21, 2015 at 16:53
I can easily imagine how dreadfull it would be to save each layer by hand and then have to keep the chnages in check as well on a game like this.

Thanks from sharing the PSD file as well. I'm always interested in gaining a bit more insight on how people do things.

Patrik Spacek - Sep 21, 2015 at 17:02
I have a character who moves his hips to the sides when he walks (shifting body). Even you can change the pivot position  in TP (limited), the result is not correct. TP is centering each sprite, so if my animation was set up to hold his feet as i.e. IK, it makes the Character  sliding to the sides instead of holding his feet correctly on the ground (from feet up, not center out). Hard to explain. This is disadvantages of perfectionism, when I am trying to make animation as real as possible, which makes my life much harder. Well, unity3d fixed that for me w its own texture packer system, but unfortunately I need to have each frame separate. :/
and guys, since you have sprite sheet for characters, create normal map for them and you will get a nice lighting result. Just in case, you wanna burn more time on this game :o)

entropy - Sep 21, 2015 at 17:28
OMG, just look at this damn beautiful artwork! (last pic)

Mattias Cedervall - Sep 21, 2015 at 17:30
May Slicy live forever! :-)

Bogdan Barbu - Sep 21, 2015 at 22:00
I suspect that this project is not large enough that you have to wait for it to build for too long on current systems but the way you automate builds is using shell scripts rather than makefiles or a similar method that is based on dependencies? The great thing about those is that only the things based on files that have changed need to be updated; you don't need to rebuild the whole project everytime.

Grafekovic - Sep 22, 2015 at 01:08
Not a single word.... Most useless blog entry ever ;-)

Karza - Sep 22, 2015 at 01:24
Damn Ron,
I really would like to read a book when you explain the process of creating a game like this.
I mean, in details, from the building of the parser of the scripts to everything else.
I bet I would learn a lot from a teacher like you.
When you finish the game, think about it!

Zak Phoenix McKracken - Sep 22, 2015 at 04:51
Thank you very much for the PSD file. It's really interesting and a precious present from The Team!

Felix - Sep 22, 2015 at 06:32
Have you heard about/tried the Adobe Generator feature?
Not sure if it would do everything you need for game development but I'm using this extensively for automating webdesign exports and exporting icons at different sizes and it's quite magically and a real time saver.
Also, seeing that your layers are already named with the file extensions postfixed, I guess for an initial test you'd just have to turn on the feature and save the .psd file to get some output.

Ron Gilbert - Sep 22, 2015 at 09:49
That does almost hat we need, but there are two issues. The first (and not that important) is that is puts the assets in the same folder as the source .psd file, which is a little annoying since we need the .png files to be somewhere else. The second (and bigger) issue is that it exports the whole layer, cropping it to the visible pixels. Slicy allows you to specify the canvas using the @bounds, which is necessary so we can keep the relative placement of images and clip images.  I didn't know about that, thanks for the heads up, there are some situations where this might be useful.

Felix - Sep 22, 2015 at 10:18
Yeah, I figured the cropping would be an issue. It's an issue for some of my graphics too so I came up with a "workaround".
I usually just place a mask of the exact dimensions I need the output file at on the layer or group. The generator will pick this up and generate the asset including any padding that is created due to the layer mask. Works well for me but is obviously quite different from what you're currenty doing with those @bounds directives.

As far as I know the target directory can currently only be changed by setting a global configuration option (see You can create subdirectories though (ie. foldername/output.png).

The whole generator feature is open source though so you can customize however you like:

unwesen - Sep 22, 2015 at 08:17
Haven't tried this out myself, but instead of Slicy, you might be able to use ImageMagick

Then you can automate all the things!

Arne Lyngsfjord - Sep 22, 2015 at 11:44
Thank you so much for sharing the photoshop file! I had fun playing around with it in Gimp. I totally agree on Gimp being far inferior to Photoshop - I'm using Gimp now because it's free and I'm using it for personal tasks. If i were a professional, I wouldn't hesitate to pay for a photoshop subscription.

Zak Phoenix McKracken - Sep 22, 2015 at 12:00
Off topic, but an idea crossed my mind: what about including a sort of anti-piracy protection (altough useless nowadays), just for fun, in Thimbleweed Park? Similar to the wheel in MI2...

Marco Lizza - Sep 23, 2015 at 08:02
... although sometimes (as in MI2) funny and cleverly implemented, the anti-piracy protections where a huge pain the neck...

Ema - Sep 23, 2015 at 12:37

I don't think it could be a good idea.

It would be fun for somebody (including me), but maybe only the first time.

Perhaps it could be added just in the boxed physical limited edition... I think collectors and backers could appreciate. But it is expensive and time consuming. Not so much, maybe, but it is.

Bogdan Barbu - Sep 24, 2015 at 02:23
I see pictures of this wheel online. How does it work? I'm assuming that before you start the game you're asked to answer some question which you can "only" do by using the wheel?

Disclaimer: I have the Special Edition on Steam, which has no wheel-based anti-piracy device.

Ema - Sep 24, 2015 at 06:43
In MI1:

Before loading the game, it asked you in which year the pictured pirate was hanged in a certain place. You had to compose the face of rhe pirate with the wheel, then you had to type the year written in the correct window you see on the wheel.

Bogdan Barbu - Sep 25, 2015 at 05:24
Thanks. :)

Ema - Sep 26, 2015 at 04:54
Here's a working reproduction of the wheel:

Grafekovic - Sep 25, 2015 at 05:50
If this is completely optional, then it would be fun. For example, you have the same anti-piracy protection as in MI1+2, but you are able to start the game without entering anything. But when you enter the correct code, you get a reward like one of the characters is telling a joke or something like that.

Ema - Sep 25, 2015 at 09:27
This could make sense if you put it also in the online version. So that the majority of people will read the standard joke (something like "just kidding, no anti-piracy protection for this game"), and only the few people having the wheel will have access to the extended joke. Almost an easter egg.

Pottty - Sep 22, 2015 at 15:26

Zak Phoenix McKracken - Sep 23, 2015 at 06:04
The Caponian's spaceship took it!!

Benoit Fouletier - Sep 25, 2015 at 05:08
We're using a similar "auto-export PSDs to PNGs" process for Seasons after Fall. A quick look at our current asset database shows 376 PSD files, which runs to 1993 PNG files.
The whole process is completely automated even before build time, because we're plugging into Unity's import pipeline, but WAIT! this has actually nothing to do with Unity. We're using an open-source .NET library (, which you could totally use outside of Unity, and compile on a Mac using Mono (or Xamarin or Visual Code or whatever the cool kids are using these days).
Basically, the lib allows you to read the content of the PSD all the layers, channels, whatever, and then you decide what you do with. So you could introduce even more automation with your custom naming conventions, export layer data to XML, totally command-line it, etc.
If you want to learn more, we made a blog post about it: (and if you have question, I'm @benblo42)

Zombocast - Sep 25, 2015 at 21:40
It's Friday, Friday, Gotta big frown on Friday
Everybody's lookin' forward to the weekend,
weekend podcast. - Ransom the clown

Shigawire - Sep 30, 2015 at 10:46
This looks amazing! So gorgeous....... mmmmm

waitsnake - Oct 17, 2015 at 06:40
What about this  Scurvy Scallywags? I take a look into the german iTunes Store for interest but it was not available for this country.
So I changed to the US store to take a look but it was not even available there?
Is it now part of computer game history?

Emmanuel - Oct 23, 2015 at 13:37
I know this is an old thread, but I opensourced a command-line tool to convert psd's to individual png's for each layer:

It saves positioning info for each layer in a xml as well. It doesn't do all that slicy does (notably missing is defining the section to be exported), but the psd reader is very robust - much better than the Gimp and reading modern files - and you can modify it to your needs since all the code is available.

There are prebuilt binaries for windows and mac as well in the repo.

The psd reader could be spun into a seperate lib if anyone feels inclined to do so.

If anyone needs such a tool feel free to use it. If you want to contribute any changes and improvements that's also great.