Slicy
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
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.
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.
https://gist.github.com/walm/4105005
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.
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.
A quick search returns potentially useful results for extracting PNGs from PSDs, e.g.
http://www.imagemagick.org/discourse-server/viewtopic.php?t=16072
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!
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.
Thanks from sharing the PSD file as well. I'm always interested in gaining a bit more insight on how people do things.
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)
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!
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.
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 https://github.com/adobe-photoshop/generator-assets/wiki/Configuration-Options). You can create subdirectories though (ie. foldername/output.png).
The whole generator feature is open source though so you can customize however you like:
https://github.com/adobe-photoshop/generator-core
https://github.com/adobe-photoshop/generator-assets
Then you can automate all the things! http://ddf912383141a8d7bbe4-e053e711fc85de3290f121ef0f0e3a1f.r87.cf1.rackcdn.com/automate-all-the-things.jpg
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.
Disclaimer: I have the Special Edition on Steam, which has no wheel-based anti-piracy device.
https://www.google.it/search?q=dial-o-pirate&ie=UTF-8&oe=UTF-8&hl=it&client=safari#imgrc=z4C84LaQdG-wnM%3A
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.
http://www.classicgaming.cc/pc/monkeyisland1/dial_a_pirate.php
https://www.dropbox.com/s/egsvezg4qud0uk8/WhatRadioStation.png?raw=1
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 (https://psdplugin.codeplex.com/), 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: http://www.swingswingsubmarine.com/2014/01/23/from-photoshop-to-unity/ (and if you have question, I'm @benblo42)
Everybody's lookin' forward to the weekend,
weekend podcast. - Ransom the clown
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?
https://bitbucket.org/marty_emmanuel/photocrunch
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.