STEP 1
OF MICE AND MEGABYTES
PART 1 · THE INITIAL TREK
by Maurice Molyneaux
When not writing articles for ST-Log, Maurice Molyneaux designs game graphics, consults for software companies and creates animated cartoon productions using microcomputers. Despite a ridiculously French name, he claims to have been born in Vicenza, Italy, and denies vicious rumors that he eats escargot and calamari while computing. He is the creator and director of the Art and Film Director sales video for Epyx—a 10-minute fully animated cartoon demonstration created entirely with ST systems. His DELPHI username is MAURICEM.
Last month's topic was designing computer game graphics. This time out we're going to stick to a graphically-oriented subject (as it were), but the key difference is that the graphics in question were created not for display on a computer, but on a more common medium: videotape.
At the June '88 CES, Epyx Inc. was showing off its Art & Film Director software package (which should have shipped by now). A videotape was used to demonstrate the capabilities of this package: a 10-minute computer-generated "cartoon." The videotape was created, animated and directed by yours truly (with added assistance from Randy McClanahan, Mrs. Andy Morrison and Vincent Reynolds). I thought it would be valuable to relate the history here, so those of you interested in creating computer animation might benefit from my experience.
Please note that this discussion is not going to be merely a blow-by-blow description of animation or video techniques. Rather, I will be outlining the history of the project (including the project that spurred it), goals, results and techniques. Hopefully such background will give you an idea of the process of making computer-generated videos.
But first, a little background: Art & Film Director (AFD from now on when referring to both programs, or Art or Film when referring to one or the other) is a paint and animation software package. Art is a full-featured, bit-mapped, low-resolution (16-color) paint program which allows up to 16 workscreens in memory at once (if you have one meg or more RAM), and up to eight distinct palettes per picture.
Film animates graphics created with Art (or imported from other formats) and is the closest thing to a true "cel" animation system as I've yet seen on a personal computer. The AFD package sold by Epyx contains both programs (which really do work best together). Somewhere you may have read that both Mirrorsoft and Pharma Data Systems (PDS) in Europe sell Art and Film. As of this writing, they sell older and less refined versions of the programs, and they package them separately. The package sold by Epyx contains updated and improved models of both programs. All versions of the software were produced by Novotrade Software in Budapest, Hungary.
And, yes, at one time these programs were to have been sold by Broderbund. For various reasons that never happened, and the programs found their home at Epyx.
Warp One
In August of 1986 I found myself frustrated at the complete lack of any good animation software for the ST. My local ST dealer informed me that in one of his catalogs he had seen a listing for an upcoming ST animation program. He made a phone call and got in contact with Stephen Friedman—the American representative for Novotrade Software—and told him that I wrote for ANALOG Computing/ST-Log, and that I was interested in seeing the software. Mr. Friedman and I chatted, and he agreed to send me some demo disks. After that, and a visit to his office the following October, he decided to send me advance (prerelease) copies of the programs, which at that time were in the process of being updated and improved (by the Hungarians) for American release (this under Broderbund).
In the course of our discussions, Mr. Friedman had made it clear that he would like some of my input on game ideas and design. As a longtime Star Raiders player who always wanted more than that game had to give, I decided to try my hand at designing the ultimate action space-combat game. Star Raiders was a graphics-oriented adaptation of the old mainframe Star Trek game, so I decided to go to the source. A 3-D Star Trek space combat game it was to be. I reasoned that since it was a known property, it would have instant identification with users. While the game concept is too complex to detail here, suffice it to say at the lowest level it would be about as complex as Star Raiders, but at the top levels it would make that game look simple (and easy).
Once I had the idea down (it just fell together in one sitting), I felt that paperwork alone would not sell such a game. Neither would mere mock-up screens. Nope, I wanted prospective clients to see what the game would look like.
Using Art and Film I would create an animated demo of the game. But no simple demo was this to be! In the end it would consist of over a dozen animation sequences and run several minutes in length. The demo would begin with a simulation of the game's titles (Figure 1), then show the player's ship in the act of cruising through space, warping here and there, fighting Romulan warships, limping to spacedock for repairs, sending a security team to clear out an invaded dock, and finally the player's ship being destroyed by a hostile starship in a heated exchange of phaser blasts and photon torpedoes! In effect, it was like watching someone play (and lose) the game.
The primary view in the game was over the helm on the Enterprise bridge, looking at the main viewing screen. There, tactical projections and visuals would appear. (Forward, port, starboard and aft views could be called up, and weapons could be fired in the selected direction.) The biggest challenge visually (besides designing a screen that was both functional game-wise and recognizably the USS Enterprise bridge) was to create starships and space docks that looked good. Unlike the ships in Star Raiders, which you only see from one view, the ships in this game would be seen at many angles (front, back, side, three-quarters) and at varying sizes.
I wanted the ships to look realistic, so I used CAD-3D to build three-dimensional models of them. I generated pictures of each vessel at all necessary angles and saved these images as DEGAS low-resolution screens. These pictures were then converted to Art format, resized, cleaned up and detailed—adding highlights, spotlights, windows, etc. Figure 2 shows an actual shape-table page for the demo, featuring a Federation starship (from myriad angles and in myriad sizes), a spacedock, as well as phaser blasts and explosions.
For the game, I created Enterprise-Reliant- (Star Trek II), and Grissom-type (Star Trek III) Federation starships, as well as a spacedock (Star Trek III and IV), an asteroid base and a Romulan Bird of Prey (traditional, 1966 model, a la the episode "Balance of Terror"). Since the demo featured a dock-and-repair sequence inside a spacedock, I also built 3-D models of a shuttle craft and a Work Bee (small construction/repair vehicles seen in the first movie).
The Work Bees, though their appearance is brief, have the most detailing of any of the ships in the game. They feature flashing running lights, and they roll as they fly towards the Enterprise. In fact, when one passes slowly by the viewer, you can read the number on its side and even see the silhouette of the pilot through the window! The space-dock sequence also features another starship in for repairs and a little space-suited man who waves to signal that your ship is repaired and ready to go. (The dock interior, Bee, Reliant class starship and man all appear in Figure 3.)
Research was not tough, but it did take time For various tactical displays I studied some of the tactical projections used in the first Trek film and animated nearly identical ones for the demo. To build the Grissom-class starship, I had to step frame-by-frame through a video of Star Trek III, trying to determine the size, shape and positions of the various parts of the ship. I sketched and studied, replaying one shot over and over and over. After an hour or so of this, I was able to go to CAD-3D and build the ship. (Ironically, after all this work it ended up being the one ship not used in the final demo!)
Additional research was done through magazines and books, taking note of logos, designs, etc. I even bought a videotape of "Balance of Terror" (after which the game was named) just to study up on the Romulans (who were to be the antagonists). The research, I felt, was necessary, because if this was to be a Star Trek game, it needed to have the flavor of the show, from the concept all the way through to the design. (If you're going to show a Romulan ship, I reasoned, it had better move, act and look like a Romulan ship, or the Star Trek fans will know it's wrong.)
I think this kind of research is appropriate in many kinds of game design—and in videos too. Sometimes, the limitations of a subject can at first seem a burden, but most times I've found that you can incorporate those limitations as part of your project and use them to ground your concept in reality—or at least the "reality" of the subject you are working with.
For example, using Romulans instead of the ubiquitous Klingons at first seemed a pain. The Romulans, as shown in the series, lived by very strict codes, and their motivations were quite different than that of the Klingons. In a game you could get away with having Klingons want only marauding, but Romulans are more coldly calculating. They had to have a strategy that was consistent with their values as shown in the series. It took me a little thinking, but in the end I did manage to find a strategy that worked. In fact, it made for a much tighter and interesting concept, because it made strategic sense from the Romulan point of view.
Animating the game demo was no Cakewalk. The earliest versions of Film allowed the use of only two screens of shape data, which caused colossal limitations. The background for most scenes in the game was the aforementioned bridge. If drawn normally, it would have taken one entire page of shape data, leaving me with only one other page in which to store all the images of enemy ships, explosions and things such as pieces of bridge readouts, etc. This would not work, so in the end I had to create bridge building blocks (which fit on a single screen), pieces that I would assemble on a Film "stage" to make a full-screen background. Once that problem was licked, it was time to tackle the actual animation.
The ships and weapons were relatively easy to animate. (In particular, I had great fun designing and animating the photon torpedoes.) In addition to phaser beams, et al., I animated some scenes which took place on a spacedock (Figure 4), with Enterprise security guards in battle with invading Romulans. (I know, I know, Romulans don't take captives, but there was a good reason for their invasion in the game.) The arrival and departure of the security guards gave me an opportunity to simulate the transporter effect. I managed to make a nice sparkle and dissolve (and the reverse) effect that looked very much like the effect used in the old TV series.
Unfortunately, these graphic goodies were amongst the least seen items in the demo. The bridge scenes were a nightmare Not only did I have to animate moving star fields on the viewer (ever try to simulate warp drive by manipulating individual stars?), but I also had to constantly update all the visible control panels and displays. Frame by frame I had to update the tracking system, the astrogator, chronometer, various ship's status readouts, etc. After a few days of animating zooms through space, you get real sick of animating scores of instruments!
Since the demo was quite complex, I was forced to videotape the thing in order to achieve the desired effect. Just playing the animation sequences wasn't enough. This gave me some (later much-needed) background in creating and taping ST animation.
Video woes
One of the most complex parts of the demo was the title animation. As it was a Star Trek game—and as a kid I was something of a Trekker—I was determined to be true to the concept and details (hence all my references and research).In fact, I took this so far as to make the titles a computerized duplication of the titles of the old TV show! The Enterprise would whoosh! out from the distance, titles and credits appearing in her wake. (Figure 1 is a composite of two images some forty frames apart. The title doesn't actually appear until after the ship has left the screen.)
This wasn't too hard to do (animation-wise). The trouble was that I wanted the old Star Trek theme to play in the background. (I have a record of the original music—the game would have had programmed music.) Therefore, I had to adjust my animation so that everything was synchronized to the music. At the proper points in the music the Enterprise would zing by, just like on TV. I had to play the music time and time again, adjusting the timing by deleting a frame here, adding a frame there.
I had thought to just determine the timing on the music, break this down into frames-per-second and calculate on which frame what should appear. Well, I quickly learned that the more things I had moving on the screen, the slower the computer ran. Thus, when space was blank, the frames zinged by at the appointed speed, but when the Enterprise appeared, it slowed down a little. And the bigger the ship, the slower the speed. This eliminated all chance of solving the timing problem mathematically. Hence I was forced to play the music again and again and adjust it all manually.
(A small aside here: As I have researched and worked with animation in the intervening 20 months, I have learned that timing sound to animation is one of the most imprecise of sciences. Sometimes you will get a sound to start precisely where it should, but discover to your horror that it seems wrong. According to the book Disney Animation—The Illusion of Life (Frank Thomas & Ollie Johnson, Abbeville Press, 1981) this problem occurs quite frequently in traditional animation as well. There seems to be no hard and fast rule as to how to apply sound. It must be timed to the specific action being shown, either right on the frame where it occurs, or before or after it! Wherever it works best. This sounds like nonsense but it is true!)
When it came time to commit all the animation and graphics to tape, the fun began. My trusty old 520ST (upgraded to one meg of RAM) is one of the old summer of '85 STs that were not equipped with an RF modulator—meaning I couldn't get a composite or RF signal out of the machine to send into a videotape deck. (At that time, there were no RGB to composite converter boxes available, and I didn't want to videotape the screen using a camera.) This small logistical problem was solved by borrowing an RF-equipped 520ST from some friends of mine and using the RF (TV) output. (This would work only on this one project because later versions of AFD allow use of RAM beyond 512K, and there is no way a 520 sans memory upgrade could play any animations created using more than two screens of shape data.)
The animation was taped by loading one sequence at a time into Film, playing it while the VCR was recording, pausing the VCR at the end of the sequence, loading the next one, etc. The VCR in use was a five-head deck where one of the heads was an effects head. When the tape was paused, the machine would back-up the tape about a half-second so that no speed change or other video "bumps" would occur.
All this would normally have made taping easy. However, the warp-drive effect I had designed had to be created (for technical reasons) using Art and using a lot of color value changing (to simulate the "tunnel-oflight" effect seen in the first film). So, every time the ship shot into warp, I had to quit Film, run an Art slideshow, tape a couple of seconds of this effect and jump back into Film. And I had to do this quickly enough so that the video deck wouldn't hit the end of its pause timer and unpause itself (easy now, but at the time I didn't have a hard disk!).
The biggest shock I received was seeing for the first time the tremendous difference between my SC1224 RGB monitor's image and the same picture displayed on my composite monitor! Yech! It was awful! Colors were completely and utterly wrong. Before committing anything to tape I had to go back and adjust almost all of the colors on every animation. The most unpleasant surprise came in the spacedock sequence, where medium gray on the RGB became light gray on the composite and where the difference between dark blue and medium blue was utterly lost! If you intend to tape computer graphics and animation, I strongly suggest checking everything on a composite monitor or color TV long before you prepare to go to tape.
Once I had recorded two copies of the animation, it was time to add the sound. Film supports some sound and music, therefore the animations themselves already included a great many sound effects (phaser blasts, etc.), and these had been recorded on the videotape.
The video deck I used could record two separate soundtracks and allowed audio to be dubbed over the tracks after the video was recorded. The sounds in the animation were recorded on one track and all overdubbed sounds on the other. (Overdubbing means recording a "new" soundtrack onto an existing piece of film or video.) This permitted special dubbed sounds to come in without wiping out the noises in the animation proper. An audio cassette had been prepared, containing all the necessary sound for dubbing. This included the Star Trek theme music from the Trek soundtrack record (The Cage) and a series of photon torpedo and warp-drive sound effects culled from a videotape of Star Trek—The Motion Picture.
Dubbing the sound was not easy. It is surprising how noticeable being a quarter of a second off can be It was especially difficult to time the warp-drive sound effect, because it was a thrum and a racing sound followed by a bang. The bang had to hit precisely on time with an on-screen flash. On average it took six tries to get the sound synched properly.
How useful?
Alas, nothing ever came of that game. Simon & Schuster (S&S), who have the software rights to Star Trek, were not interested. Having seen the Star Trek game they did release for the ST, I only have to heave a sigh. While it's not a bad game, it doesn't have much pep, and their drawings of the Enterprise are awful—but I digress.
How useful is creating a demo like this? Well, while it did not sell my game concept, it certainly showed the people at S&S exactly what was being proposed to them. Even if you do not intend to use such a video to sell an idea, it can still be a useful tool in designing software. It gives you an opportunity to see your designs on screen, looking as they would if you were actually to use them. Furthermore, if you have a number of people working on the project, it gives all of you a reference as to what the project might end up looking like. If nothing else, you'll quickly learn that not everyone will like the idea as presented, and you can proceed from there, eliminating serious problems early on.
I believe this kind of proposal can be a worthwhile tool for selling a concept. My mistake was designing a game around a property that only one company can sell (S&S alone has rights to produce Star Trek games for personal computers). Hopefully one of you developers will someday (or may have already) use such an animated demo to sell a software concept. It's an exciting way to present an idea.
Of course, that's not to forget animating something like this for its own sake. Making cartoons is fun too. (More on that next issue.)
I am still quite proud of that demo. Whenever I show it people are always excited and ask "Where can I get that game?" While it's too bad the game never sold, I did nonetheless profit from it. I learned a lot in the process of creating the demo. First off, and most of all, I learned how to push the then limited-to-two-pages-of-shape-data version of Film to its limits, and many of the techniques I had to develop out of necessity gave me an edge in pulling off some complex tricks with later, more powerful versions of the program.
Off to see the wizard
Back to the time before S&S passed on my Star Trek game proposal: Once the master tape of the Trek game demo was completed, copies were made, and I undertook a journey to Silicon Valley to present the demo (and the 16-page proposal) to Stephen Friedman, who would then pitch it to S&S. He was expecting me to bring some animations that he would tape; he did not expect me to show up with videotapes of a complete and self-contained demo animation!
Anyway, he sent one tape and the proposal off to S&S, but he also took a copy of the tape to Broderbund, to show them what kinds of things people could do with Art and Film. He was hoping to push them into getting in gear and setting a real release date for the programs. Broderbund turned around and hit him with a question: How much would I charge to produce a videotape for them to promote Art and Film?
Next issue, we'll talk about the making of the Art & Film Director sales video, and the creation of a cartoon character by the name of Megabit Mousetm.