Big Game Theory!

Musings on games, design, and the theory of everything.
 Thumb up

Don't Drown in Your Files!

Oliver Kiley
United States
Ann Arbor
flag msg tools
Microbadge: The multiverse!  Fan of theoretical physics I don't understandMicrobadge: Hyperion fan - The Shrike is My Hero!Microbadge: My Favorite Contribution to BGGMicrobadge: HumanistMicrobadge: Ask The Next Question
Game Design + Development - Managing the files!

In this thead, I mentioned linking graphic files is a good thing to do from a productivity standpoint when creating prototypes. A user asked for additional information and suggestions. As I started writing I figured this would be something worth sharing with others as well! Here we go!

I’ve been using the Adobe CS suite, principally Illustrator, Photoshop, and InDesign, for creating artwork and graphics for game prototypes and components. I use these applications, among many others, in my professional work, and managing your files and workflows in a good manner is key to being able to efficiently create prototype materials and generally stay organized. The Adobe CS programs also have the advantage of being able to link files between many of the applications, and having a nice structure to work with upfront can streamline the whole development process.

Below, I will share how I’ve been organizing and structuring my game design/development files, along with some tips and tricks for newer Adobe CS users to consider.

First, it’s good to put a folder structure in place when you start creating a lot of digital files and content. Keeping things organized will help a lot. I usually setup a project folder for a game design project once I start any serious amount of prototype graphic creation, rules documentation, or more detailed design planning (beyond my sketch-book).

Folder Structure

From gallery of Mezmorki
At the top level, there are the following main folders:

Contains communications, production notes, cost estimates, etc. that might be developed during the course of the design/development process. Can also store contracts with publishers or any other agreements, marketing materials, etc.

Typically contains lots of excel documents, tables, card lists, balance calculations, etc. used throughout the design process.

I’ll create a sub-folder for each major type of component in the game. For example, Hegemonic has sub-folders for (1) artwork (original raster images), (2) action cards, (3) technology cards, (4) tokens/chits, (5) player board, (6) sector tiles, (7) galaxy boards.

Each graphic sub-folder contains the main working file for that particular component, such as an Adobe Illustrator file (more on this below). Additional sub-folders are setup for each graphic component, including an Archive folder for saving old versions of the main graphic file, export folders (at 300dpi + 72 dpi usually), and an input folder. If I’m being particularly anal, I’ll create dated archive folders under the export folders as well, so I can save prior versions if I need to refer back to something quickly.

I generally use InDesign to layout print-sheets for prototype materials (or even for professionally printed materials). I create a sub-folder for the current version/draft of the game, and create an InDesign document for each component (based o the graphics above). These are all added to an InDesign book file as well for easy opening/closing and organization. Later in the production cycle, if you are having someone print your files, you can link their print layout templates into your InDesign files and layout out your components that way.

Each sub-folder contains an Export_PDF sub-folder where I save the component sheets as a single .pdf document, which can be easily printed or distributed.

I take a lot of notes during and after playtesting. This folder contains dated text/word files with any playtesting summaries, notes, or follow-up thoughts. Often, these playtest reports become my combined changelog and punch lists for design or graphic items to work on for the next major revision.

This is a folder for developing the written rules of the game. It contains the following sub-folders: (1) Archives for saving old versions/drafts (never know when you might need to go back to a prior rule/mechanic!); (2) Export for .pdf versions of the rules; (3) Any number of input folders as needed, which can contain rulebook specific graphic items such as diagrams, logos, titles, etc.

For the first many drafts of the rulebook, I will usually keep in a word document format (or equivalent) since the rules are changing so rapidly. Once the rules are getting closer to a final state AND I want to supplement the rules with relevant diagrams, play examples, etc. I will copy the text into a InDesign file for laying out the rules. Even with using InDesign you can quickly re-lay things out as the rules change once you get a good handle on the program.

Contains sub-folders for developing virtual copies of the game for playtesting (i.e. Vassal modules).

That’s it for the folder structure piece.

Production Tips

A few other workflow considerations and pieces of advice:

Think carefully about how you layout and develop specific components, particularly cards and player board type components. You need to be able to quickly make changes during prototyping, so you want to setup your files to that end.

In some of my earlier designs, I created individual Illustrator files for each card in the game. When I needed to change something (like the background, or text size), I suddenly found myself having to open and close dozens of files each time I made a change. Ugh!

There are a few better approaches that I now employ. For each major type of card (i.e. it shares a similar layout/elements) I’ll create one Illustrator file. All the background art, text box backgrounds, etc. can contained in a set of layers. Then all of the content text, icons, etc. are in their own layer for each card. If I wanted to change the text size on all the cards (for example), it becomes easy to turn all the card layers on, and select all the text boxes containing my text to modify and re-size/adjust it in one click. The downside to this approach is that you still have to turn on/off the appropriate background and foreground layers when exporting the card. Often times, I will export all the backgrounds separately from the foreground, and then lay the two together in he print sheet.

Another card design approach is create your background files as above. In another file, you can tile your foregrounds across one or more pages with the backgrounds linked in. This file can then be exported in one pass and linked directly into your print-sheets. With good layer control, you can keep different text/elements on their own layer so it becomes relatively easy to apply changes across all he cards uniformly. If adding Foreground text in InDesign, it’s even easier as you can setup paragraph and text styles for each element that can be quickly changed at the press of a button.

Take advantage of linking files across applications, particularly between exported graphic components and your print-sheets. So long as you consistently export graphics into the same graphic export folder and keep the same file name, your print-sheets will update very quickly with revised graphics when you open them. This is a big time saver. Again, my workflow is to export a graphic component into its Export_300dpi folder. The file is linked from there to the relevant print-sheet in the Packages folder.

Come up with a version tracking system that works for you and use it. I tend to put "_v00X" at the end of my main working files (i.e. Rulebook, graphics components, etc.). Since I don’t link to the main graphic files (I link to exported pdf’s or png’s usually), I’m free to change the file name to correspond with the cureent version/draft number. This is helpful to keep track of what is current versus old and keep tabs on prior versions if you need to go back to something.

That’s it for now! Hopefully these suggestions are helpful.
Twitter Facebook
Subscribe sub options Mon Sep 12, 2011 3:29 pm
Post Rolls
  • [+] Dice rolls
Loading... | Locked Hide Show Unlock Lock Comment     View Previous {{limitCount(numprevitems_calculated,commentParams.showcount)}} 1 « Pg. {{commentParams.pageid}} » {{data.config.endpage}}
    View More Comments {{limitCount(numnextitems_calculated,commentParams.showcount)}} / {{numnextitems_calculated}} 1 « Pg. {{commentParams.pageid}} » {{data.config.endpage}}