Before you ask, yes, I did draw those amazingly lifelike smiley faces seen on the templates for the Theme Park game. I traced a poker chip for the outline, then edited it manually and scanned it into my computer to add color. Of course I do not expect that to be the final card design.
I am talented enough to produce the designs seen on the Programmer: Battle for Bandwidth cards seen in the rulebook I posted. However, I prefer not to get bogged down with too much early graphic design as it is quite time consuming and the demands for the templates could easily change as the development process goes through its normal motions. It is painful to have to throw away a few hours’ worth of graphics work because you need to add, delete, or alter a mechanic. In fact, it creates a subliminal internal incentive to NOT make necessary changes to a design. You find yourself trying to find mechanics to fit the art instead of ones that are just fun.
I start with just enough work to make the first few playtests run smoothly. As I begin locking in mechanics and rules, I progessively add polish to a single template card but avoid applying it to the actual playtest cards as long as possible. My main tools for graphic design are Adobe Photoshop and Jasc Paint Shop Pro 8.
I always start with Paint Shop Pro to create the individual elements such as backgrounds or icons, because I find Photoshop to be far too cumbersome for relatively straightforward single-element creation. Then I load those individual elements into Photoshop and layers to position constant pieces of cards or whatever before adding text.
Unfortunately, this means that whenever I do make changes to a large cardset (Programmer had over 100 distinct cards) I am in for a long night. That is why I am eager to test those two programs mentioned earlier. If I can use a database-driven card design process I won’t need to manually apply graphic and layout changes, saving me a non-trivial amount of time and effort with each revision. Programmer’s card templates started as just plain text. At the top of the card it said “Code” or “Event”. If it was an event below that I added the card title. Then came pure text on both Code and Event cards. A Code card might look like:
Even back then I colored the number and the direction either blue or red, depending on whether it was moving the token left or right. This was technically unnecessary extra effort, but I felt it would very much smooth over the playtests because players would instinctively know which direction the token was moving by only having to read the number, which would quicken the speed with which they read through the program, thus speeding up their calculations and reducing analysis paralysis.
Unfortunately, I had to switch to the arrows for the playtest copies early in playtesting because some players were having difficulty with which way “LEFT” and “RIGHT” were when the token was currently at a player across the table from them. The circular arrows aren’t pretty, but they specifically show you which direction the token will move regardless of where it is relative to yourself. I kept the arrows colored for the same reason I colored the words on the previous version.
The key is to make the players aware of the entire game state with as little effort as possible. It also allowed me to ditch the extraneous words from the code cards and represent everything graphically. The only exceptions are the Function() cards and the GOTO cards. However, I gave the GOTO card a distinct graphical symbol, the green pentagon. And since the Function() cards were then the only code cards with pure text, that in and of itself allowed players to identify them quickly.
Physical design and creation of cards is the part of game design that drains all the life out of me. I am continually refining my process to reduce the amount of time spent in these two steps of prototype creation so that my brain has the strength to be creative, which is the important part. I wish I just had people to do the physical design and construction for me so I can focus on mechanics, which is what I find to be the rewarding part of game design.
I am talented enough to produce the designs seen on the Programmer: Battle for Bandwidth cards seen in the rulebook I posted. However, I prefer not to get bogged down with too much early graphic design as it is quite time consuming and the demands for the templates could easily change as the development process goes through its normal motions. It is painful to have to throw away a few hours’ worth of graphics work because you need to add, delete, or alter a mechanic. In fact, it creates a subliminal internal incentive to NOT make necessary changes to a design. You find yourself trying to find mechanics to fit the art instead of ones that are just fun.
I start with just enough work to make the first few playtests run smoothly. As I begin locking in mechanics and rules, I progessively add polish to a single template card but avoid applying it to the actual playtest cards as long as possible. My main tools for graphic design are Adobe Photoshop and Jasc Paint Shop Pro 8.
I always start with Paint Shop Pro to create the individual elements such as backgrounds or icons, because I find Photoshop to be far too cumbersome for relatively straightforward single-element creation. Then I load those individual elements into Photoshop and layers to position constant pieces of cards or whatever before adding text.
Unfortunately, this means that whenever I do make changes to a large cardset (Programmer had over 100 distinct cards) I am in for a long night. That is why I am eager to test those two programs mentioned earlier. If I can use a database-driven card design process I won’t need to manually apply graphic and layout changes, saving me a non-trivial amount of time and effort with each revision. Programmer’s card templates started as just plain text. At the top of the card it said “Code” or “Event”. If it was an event below that I added the card title. Then came pure text on both Code and Event cards. A Code card might look like:
CodeInstead of having the circular arrows seen in the rulebook with the number in the center of them, it would just all be written out.
Move
2
terminals
LEFT
Even back then I colored the number and the direction either blue or red, depending on whether it was moving the token left or right. This was technically unnecessary extra effort, but I felt it would very much smooth over the playtests because players would instinctively know which direction the token was moving by only having to read the number, which would quicken the speed with which they read through the program, thus speeding up their calculations and reducing analysis paralysis.
Unfortunately, I had to switch to the arrows for the playtest copies early in playtesting because some players were having difficulty with which way “LEFT” and “RIGHT” were when the token was currently at a player across the table from them. The circular arrows aren’t pretty, but they specifically show you which direction the token will move regardless of where it is relative to yourself. I kept the arrows colored for the same reason I colored the words on the previous version.
The key is to make the players aware of the entire game state with as little effort as possible. It also allowed me to ditch the extraneous words from the code cards and represent everything graphically. The only exceptions are the Function() cards and the GOTO cards. However, I gave the GOTO card a distinct graphical symbol, the green pentagon. And since the Function() cards were then the only code cards with pure text, that in and of itself allowed players to identify them quickly.
Physical design and creation of cards is the part of game design that drains all the life out of me. I am continually refining my process to reduce the amount of time spent in these two steps of prototype creation so that my brain has the strength to be creative, which is the important part. I wish I just had people to do the physical design and construction for me so I can focus on mechanics, which is what I find to be the rewarding part of game design.
I actually enjoy the graphic design part as equally as I do the design of the mechanics so I tend to expend a substantial amount of effort and time in designing my prototypes.
ReplyDeleteIt is true that it is time consuming, but the reward is that it improves playtesting in my opinion (more people will be willing to test a nice looking prototype), and will also help when looking for a publisher.
A dark ride is basically any ride in the dark, but most commonly refers to scary rides (to eliminate the love canal types). It can be anything from a haunted house to an abandoned mine shaft.
ReplyDeleteBTW, this’ll be the first year I miss Prezcon, which sucks cause I really wanted to see some of your creations in action. Good luck in your games and publisher hunting.
Actually I won't be able to go to PrezCon myself. I'm in a time and money crunch at the moment. I will have my stuff with me at Origins, if you want to take a look there.
ReplyDeleteSurely I am delighted to read this post regarding game design which contains plenty of helpful facts, thanks for providing these data. Great article, exactly what I needed.
ReplyDelete