This file is a tutorial introduction to the use of the Cosmic Encounter PostScript files in PS-headers and the ce-convert program. This tutorial is designed around the idea of creating a small Cosmic Encounter set -- just enough to play the game. (This might be a good gift if you want to create new game addicts.) We will produce five components: the cone, the hexes, a destiny deck, a Challenge deck, and several Powers (with Flares). You're on your own for tokens; I glued colored paper to cardboard and used a large hole-punch. At various times I will refer to the files. The prefix PS-headers/ indicates the files are from the PS-headers directory; the prefix PS-tutorial/ indicates they are from the PS-tutorial directory; the prefix CE-convert indicates they are from the CE-convert directory. Make sure you have all of these directories and files before continuing. PRINTING -------- You will need a PostScript printer -- that is, a printer which processes page descriptions written in PostScript -- in order to produce the game. A number of PostScript printers are on the market, including the Apple LaserWriter and the NeXT printers. If you don't have access to such a printer, you will not be able to use the Cosmic Encounter PostScript. I am going to assume that you are working on a UNIX [trademark] operating system or something similar. If you have a different system, you will have to use whatever commands are appropriate to your system in order to concatenate and print files. You print the Cosmic Encounter PostScript by sending the appropriate file(s) to your PostScript printer. Sometimes you only send one file, but generally several files will have to be concatenated and sent to the printer. Under UNIX you can use the command cat file1 file2 file3 | lpr -Plaser to concatenate the three files "file1", "file2", and "file3" and send the whole thing to the printer named "laser". (Your printer may have a different name; adjust the command appropriately.) POSTSCRIPT ---------- PostScript is a postfix language -- like an HP calculator. Operands are pushed on a stack, and operators pop off operands, perform some actions (which may include drawing on the page), and sometimes push results on the stack. For example, the sequence "3 4 add" will push 3, then push 4, then execute "add" -- which pops 3 and 4, adds them, and pushes 7 on the stack. PostScript is a full programming language, and permits the user to define routines which behave much as operators. The files in PS-headers largely consist of definitions of routines. When you invoke these routines with the appropriate arguments, the printer draws things -- the cone, hexes, cards, etc. -- on the page, and then produces the page. For now, that's all you need to know about PostScript. Let's start making a Cosmic Encounter set. THE CONE -------- The cone is the simplest of the components to produce. Simply send the file PS-headers/cone.ps to your printer. The UNIX command would be: lpr -Plaser PS-headers/cone.ps Now, one of three things happens. Ideally, your printer will work for a short time and produce a single sheet of paper which contains two large cones (one regular and one reverse) and a row of small cones in circles suitable for reverse-cone stickers. Congratulations! Cut out the cones and glue them to an appropriately-cut piece of cardboard. Less ideally, your printer will produce about three or four pages of text which starts out something like this: %! % PRINT COSMIC ENCOUNTER CONE % version 1.0, May 8 1991 % % Code copyrighted (C) 1991, Ken Cox, kcc@wucs1.wustl.edu % Distributed as Freeware /inch { 72 mul } def /cm { 28.34645 mul } def This is just the PostScript code that draws the cone. It indicates that the file has been transmitted to the printer, but either (1) you don't have a PostScript printer or (2) somewhere between your printing command and the printer something decided that cone.ps was NOT PostScript and arranged for it to be printed as text. The latter can occur on UNIX systems if the line "%!" is not the first line of the file (% and ! must be the first two characters of the file). You may need to contact your system manager to find out how to send PostScript to your printer. THE HEXES --------- We will now print some hexes. We require the files PS-headers/font.ps and PS-headers/hex.ps -- plus one more file. We need the extra file for a simple reason: font.ps and hex.ps contain PostScript programs which define everything necessary to print many different hexes, but these two files do not actually print anything. This is similar in principle to a calculator program; the program has been written to do many arithmetic operations, but unless the user enters commands nothing happens. Let's say that we want four standard hexes (five planets and a sun) and a Warp. Remember, routines that do all the work necessary to print these hexes are defined in font.ps and hex.ps; we just have to use the routines in the correct manner. Referring to PS-headers/PS_usage, we find that hex.ps has routines with the names "StandardHex" and "WarpHex" that produce the hexes that we want. Therefore, all we have to do is invoke the StandardHex routine four times and the WarpHex routine once. Start up an editor and create a text file (the file must be simply ASCII, with lines separated by newline characters (ASCII 10) -- don't use some fancy WYSIWYG editor or it won't work). Put the following five lines into the text file: StandardHex StandardHex StandardHex StandardHex WarpHex Save the file under some name -- perhaps "my-hexes". What you now have is a file that invokes the routine StandardHex four times and the routine WarpHex once. These routines are defined in PS-headers/hex.ps. To produce your hexes, concatenate PS-headers/font.ps, PS-headers/hex.ps, and your new file (in that order) and send them to the printer. Under UNIX you might use cat PS-headers/font.ps PS-headers/hex.ps my-hexes | lpr -Plaser The printer will now work for a while (rather longer than with the cone) and (hopefully) will produce five pages, with one hex per page. Of course, there is the possibility of failure. If you managed to print the cone but the hexes don't work, check your file first -- make sure you spelled "StandardHex" and "WarpHex" correctly and that the file contains only ASCII characters. If it still fails, you might ask your system administrator if there are any printing quotas -- cone.ps is only 3K, but this latest file is over 40K. Assuming that it did work properly, you can glue the hexes to cardboard. As you're doing so, you will probably notice that the four standard hexes all differ subtly -- the "starry background" on each is different. This is because StandardHex was invoked four times, and each time a new hex (with a different random background) was produced. This is also why you had to wait the same amount of time for each of the hexes. If you want the hexes to have the same background, or if you want them to print faster, you can use a little bit of PostScript "magic". Create a file which contains the following four lines: /#copies 4 def StandardHex /#copies 1 def WarpHex If you concatenate font.ps, hex.ps, and this new file and send them to the printer, you will get four standard hexes and a Warp; but the four standard hexes will be identical, and after the first prints the other three will be produced as fast as the printer can move paper. Recall that PostScript is a postfix language. When the printer reads "/#copies 4 def", it first pushes "/#copies" on the stack. "/#copies" is a PostScript literal -- think of it as a variable name (actually, #copies is the variable; /#copies is the syntax to put the NAME, not the VALUE, of the variable on the stack). The number 4 is then pushed. Finally, the printer executes "def"; this routine pops two operands, and defines the first operand as being equal to the second. By executing the line, we have assigned the value 4 to the variable #copies. In other words, "/#copies 4 def" is roughly the same as "#copies := 4" in an infix language. #copies is a special variable to the printer; it indicates the number of copies that are to be produced whenever the printer is told to emit a page. Thus, when we set #copies to 4 and execute StandardHex (which draws one hex and emits a page), 4 copies of the hex are emitted. We then set #copies back to 1 and emit one Warp. DESTINY DECK ------------ Of course, traditionalists will want to cut Star Discs from cardboard and use them. I am including this section as an introduction to printing cards, before moving on to the complexities of the Challenge deck. The files we need are PS-headers/font.ps, PS-headers/cards.ps, and one more file that contains invocations of the card routines; I have included this file as PS-tutorial/destiny-deck. When cards are printed, some work needs to be done to set up before printing and to clean up afterwards (for example, since nine cards are printed on each page, the cleanup forces out any partial page of cards). These functions are done by the routines Setup and Finished. The first line of any file containing invocations of the card routines should be Setup, and the last should be Finished. We want a Destiny deck with four colors (red, green, blue, and yellow, although you can use any colors -- burnt umber, if you want); we'll have three regular and one reverse-cone card for each color, plus Wild Destiny and reverse-cone Wild Destiny cards. Referring to the section on cards.ps in PS-headers/PS_usage, we find that ColorDestiny, ReversedColorDestiny, WildDestiny, and ReversedWildDestiny are what we want. Unlike the hex routines, the card routines have arguments: number color ColorDestiny number color ReversedColorDestiny number WildDestiny number ReversedWildDestiny where "number" is an integer and "color" is a string. Numbers in PostScript are represented in the usual way -- as illustrated above in the #copies discussion. PostScript strings are ASCII character sequences delimited by parentheses (strings have some syntactic requirements; these are discussed in PS-headers/PS_intro). For example, to produce our three red destiny cards, we would use 3 (red) ColorDestiny To produce one burnt umber reverse-cone card we would use 1 (burnt umber) ReversedColorDestiny To print the Destiny deck, concatenate the files font.ps, cards,ps, and destiny-deck: cat PS-headers/font.ps PS-headers/cards.ps PS-tutorial/destiny-deck | lpr -Plaser The output should be the 18 cards, printed 9 per page. Once you have verified that the cards print correctly, you may want to put some heavy cardstock (I use "basis 110", whatever that means -- I think it's also called 110-pound) into the printer and print the cards again. You may have to use the manual feed and print the cardstock one page at a time. Each Destiny card has a circle, which is filled with some grey-scale approximation of the color named. Assume that you did not want the circle to be filled in (perhaps you want to color the circles). In this case you are lucky, because there is a PRINT OPTION which controls the filling of the circles on the Destiny cards. Print options are PostScript variables which you can set to various values; the values of the print options modify the printing of the cards. In the case of the destiny circles, the print option is DestinyFilled, a boolean variable (either true or false). The default value of this variable is true, but if you want the destiny circles empty all you have to do is change the value before you invoke the card routines. To change the value, you use the "def" command with the variable name and value, thus: /DestinyFilled false def If you insert the above line at the front of PS-tutorial/destiny-deck and print the files again, you will get cards with non-filled circles. Before rushing to the paper cutter with your cards, there are a few things you might want to do. The most important is probably putting a pattern on the back of the cards; this both improves the appearance and prevents people from reading through the cardstock. After you put the back on the cards, you might want to laminate them; this can be a bit expensive but will increase the lifetime of your set. PS-headers/back.ps has a number of card backs pre-defined, as described in PS-headers/PS_usage. Each of the routines that does a page of card backs has one argument, the number of times you want the page to be printed. Since we have two pages of Destiny cards, we want two pages. Assume you select the QuestionPage back (which prints a pattern of small question marks). Then create a file containing the line 2 QuestionPage Concatenate font.ps, back.ps, and the above file and send them to the printer. The result will be two pages containing the question-mark back. You can print these directly onto your cards by feeding the two sheets of cards back through the printer. Be careful with the orientation of the sheets so that the question marks end up on the back of the page. CHALLENGE DECK -------------- We can now make a Challenge deck using similar techniques. This deck will include Attack and Compromise cards, Kickers, and a few Edicts; we will do the Flares separately using the ce-conv program. To do the Challenge deck, we need PS-headers/font.ps, PS-headers/cards.ps, and the file containing the invocation of the routines. I have provided this file as PS-tutorial/challenge-deck. This file produces a very small deck -- it has only 72 cards, just barely enough for our introductory set -- but the file is intended mostly for illustration. You can easily expand the number of cards by modifying the file. Once again, the file begins with Setup and ends with Finished. Between these are invocations of the four routines Attack, Compromise, Kicker, and Edict. The first three of these are quite simple; the documentation in PS-headers/PS_usage lists their arguments as number value Attack number Compromise number value Kicker For example, to print four Attack 10's you use 4 10 Attack and to print eight Compromise cards you use 8 Compromise The Edict routine is another matter, as might be expected from the complexity of Edicts. The routine has the arguments: number title bold rest icon Edict Here is an example from the challenge-deck file for the MOBY TUBULAR Edict. (This Edict is similar to the Mobius Tubes Edict, but of course Mobius Tubes is copyrighted material so I can't use it.) Each argument is on a separate line, except the argument "rest" which is a string split across two lines. 2 [ (MOBY) (TUBULAR) ] (Free all tokens.) (All tokens are freed from the Warp to their owners' bases.\r\rPlay before \ the start of any challenge.) {} Edict The number argument is the number of copies of this card that we want; we get two copies of the MOBY TUBULAR Edict. The next argument is the title of the Edict, which is an array of strings. In PostScript, an array is delimited by []; strings are delimited by (). Thus [ (MOBY) (TUBULAR) ] is an array of two strings, the first being MOBY and the second TUBULAR. When the Edict routine is invoked, it sets the title in large bold letters, centering each of MOBY the strings on a separate line as illustrated to TUBULAR the right. The next two arguments, "bold" and "rest", are the text of the Edict; as indicated by the names, "bold" is the part of the Edict that is printed in bold type, and "rest" is the remainder of the Edict. Line-breaking of the "rest" argument is automatic; "bold" must fit entirely on one line. The above "rest" argument illustrates two syntactic aspects of strings. The first is the use of \ at the end of the line as a continuation. The effect is the same as if the string were entirely on one line. If this were omitted, the string would still be legal PostScript; however, it would contain a newline. This can cause minor problems with the routines that do line-breaking, since a newline is not recognized as whitespace; it prints as a space, but the two words and the newline will be treated as a single longer word. The other syntactic element is the use of \r (carriage return). When the typesetting routines of font.ps find a \r, they immediately terminate the current line and begin a new one. The use of \r\r causes a blank line (a line break followed by a line break). Thus, the text of the above Edict is rendered as Free all tokens. All tokens are freed from the Warp to their owner's bases. Play before the start of any challenge. where "Free all tokens." is in bold. The final argument is the icon. This is a PostScript routine which draws the small icon in the upper left corner of the card. Unless you know PostScript, you really can't do anything with this; so you can leave it as an empty routine, as indicated by {}. You can print the Challenge deck by using cat PS-headers/font.ps PS-headers/cards.ps PS-tutorial/challenge-deck | lpr -Plaser With 72 cards, you get eight pages of cards. Put a back on them (remember to use 8 as the argument to the back you select, so as to get eight pages) and cut them up. Let's examine some of the print options that apply to these cards. The first thing you'll notice is that Attack and Compromise cards are printed in an Eon-like format. If you want to change this and get some artwork on the cards, change the variable OriginalCards to false; i.e. /OriginalCards false def The next thing is that the Kickers are printed in white on black. This is nice but can be wasteful of printer toner. To print Kickers (and Flares, when we get around to them) in black on white, set the variable WhiteOnBlack to false. Finally, note that the Edict is printed with a small circle in the index position, with the Edict title printed in the circle in very small type. Normally the "icon" routine would draw in the circle; but because the routine was empty (i.e. {}) the title is printed instead. To control the appearance of the card "index" (the upper-left material) of Edicts and Flares, you can use the GraphicIndex and IndexByName routines. When GraphicIndex is false, a letter (E for Edict, F for Flare) is printed. When GraphicIndex is true, a graphic will be put in the upper corner. If IndexByName is false or if the "icon" routine is non-empty, the icon routine will be used (the routine {} simply leaves an empty circle); if IndexByName is true and the icon routine is empty, the title is printed. To summarize: GraphicIndex IndexByName icon resulting index --------------------------------------------------------------- false N/A N/A letter (E or F) true false N/A icon true true non-empty icon true true empty title POWERS AND FLARES ----------------- Powers and Flares are actually the easiest game components to produce, since the program ce-conv automatically produces the necessary PostScript code. All you have to do is concatenate the proper files and send them to the printer. We'll produce six Powers and their Flares. The file PS-tutorial/powers contains the Powers in the "raw text" input format used by ce-conv. (None of these Powers are from the Eon or Mayfair sets, but you may notice certain ... similarities. I think these six would form a reasonable set to get people started on the game; but I would prefer, say, Clone, Mind, Mutant, Zombie, Empath, and Amoeba.) The exact format of the input file is described in the documentation for ce-conv. Compile the C program CE-convert/ce-conv.c into an executable; assume it's named ce-conv. On most UNIX systems you should be able to do this with the command: cc -o ce-conv ce-conv.c Run the executable, either providing PS-tutorial/powers as standard input: ce-conv < PS-tutorial/powers or providing it as a command-line argument: ce-conv PS-tutorial/powers The program will create three new files: POWERS.OUT, FLARES.OUT, and FLARES.ONE. Remove FLARES.ONE (normally this file would contain any one-shot (Mayfair-style) Flares that appeared in the input file, but PS-tutorial/powers does not have any such Flares). The other two files contain the PostScript for the Powers and Flares. To print them, concatenate the proper files: cat PS-headers/font.ps PS-headers/powers.ps POWERS.OUT | lpr -Plaser cat PS-headers/font.ps PS-headers/cards.ps FLARES.OUT | lpr -Plaser The print options for the Flares were discussed above. The Powers have several print options. The most important is the SixPerPage option, which controls the format of the Powers on the page. The version you printed has three Powers on each page; the Powers are set up so that they can be folded in the middle. Note the large white circle on the Power card's front; by adding PostScript code to the POWERS.OUT file, an icon (drawing of the Alien) can be put in this circle. However, most people don't want to mess with this, meaning that the whole front of the card is pretty much wasted space. By setting SixPerPage to true, you get six cards per page -- essentially the back half of the Power card. This particular option differs from the other print options, which can be modified in the input file that you create (the file corresponding to POWERS.OUT); the SixPerPage option must be modified in the PS-headers/powers.ps file. Edit the file, find the line that says /SixPerPage false def and change "false" to "true". Powers also have the WhiteOnBlack option, which acts like the one for Kickers and Flares; this one can be modified in the file you create (or in POWERS.OUT). Actually, you can modify the definitions of all the print options in the header files. This will have the effect of setting your own customized default values for the options, so that whenever you print materials you get these values. CONCLUSION ---------- This tutorial does not cover all the headers (for example, there are headers for making Moons and Lucre), nor does it cover every aspect of the headers. However, with this experience, the documentation in PS-headers/PS_usage and PS-headers/PS_intro, and the example PostScript files in the PS-examples directory, you should be able to manufacture what you need. The PostScript headers remain in an active state; as time permits, I modify them and add new features. For example, I am planning a major revision of the Flare and Edict cards to permit timing icons such as are used by the Mayfair set. If you have suggestions for new card types or hexes, or if you have bug reports, please send them to me. I make every effort to respond. Ken Cox kcc@wucs1.wustl.edu