Eldritch The Cat Mk I : 1988 - 1989
 |
| Steve Wetherill and Marc Wilding, the Eldritch Cats |
Eldritch The Cat Mark I
After Odin, Marc Wilding contracted with Ocean to create the Amiga & Atari ST versions of the Army Moves game. Next, he successfully pitched Hewson Consultants with an original game of his design called Astaroth for the 16-bit platforms. It was while Marc was completing Astaroth and after I had left Denton Designs that he and I decided to set out together and form the Eldritch The Cat dev studio. Initially, we worked out of my house on Crompton Drive in Croxteth Park, Liverpool 12, with graphics work contracted out. Marc brought Astaroth in under the Eldritch umbrella, and the next task was to find a project for me.
Projectyle
 |
| Projectyle |
Time to start pitching publishers. We were based in Liverpool, and publishers tended to be 250 miles away in the London area, so we'd catch a train or bus down to London and try to fit multiple publisher meetings into one day. I remember our meeting with producer Kevin Shrapnell at Electronic Arts in Langley. It was our final meeting of the day, and Langley is a good 30-minute train journey from London. EA felt like a long shot, and we did contemplate skipping the meeting, but we caught the train out toward Slough to meet with EA, and somewhat to our surprise, Kevin appeared to be genuinely interested in exploring the game design further. More conversations happened, and before long, we found ourselves signed up with EA to create a game for the Atari ST and Commodore Amiga with the working title Scrollerball! We received a nice (though decidedly 'American') letter from EA Headquarters soon after, welcoming us to the fold as "Electronic Artists"! Honestly, the first time I read that letter I was confused, "wait, we're not artists!" but I soon got with the program.
EA was to pay us the princely sum of £15,000 for Atari ST and Amiga versions of the game, to be paid in milestones during development as an advance against royalties.
We did not have the idea for the "game of three halves" three-player game at this early stage. The initial thoughts were more of a traditional rectangular pitch with a goal at each end. I forget when the three-player idea was introduced, it may have been due to input from our publisher EA based on how popular multiplayer games were becoming at that time, with various joystick splitters and expanders appearing on the market for the ST and Amiga.
EA was keen on the potential to include a lot of stats within a future sports game concept. This was to evolve into a full-blown league system along with the ability to earn in-game points ("Dosh") that could be spent on improvements to player stats. A large part of the game was about stats and leagues, and that effort took much more work than we anticipated (using my skill for understatement there).
I came across the manual for Projectyle recently (I do have a physical copy of the game), and the poster/manual included with the game is large and confusing.
For one thing, a biography for Marc and myself looks like it was written by a middle schooler. Given the content, I must have had a hand in it, but it is pretty impressively bad! The first two paragraphs are at least basically true:
ELDRITCH THE CAT was formed in April 1988 by Marc Dawson (editor: now Wilding) and Steve Wetherill in order to create original computer games software. Marc and Steve are both programmers with long track records In the computer games industry.
Marc started his programming career in business software, writing such diverse applications as a bookmaking system and a radio-linked information transfer system. From here Marc went on to join Imagine Software's team of programmers, where he was working on the third Imagine Mega Game. Steve's career started at the National Coal Board, where he learned 'Care and Maintenance of Hand Tools' - shoveling muck, but this was far too technical, and his hair was far too long, so he did a career switch and became a games programmer.
The remaining (cringe-worthy) paragraph is here, nicely tucked away from view.
For another thing, the game is referred to as Tribal, which was a candidate for the final game's name (I think we even had a Tribal loading screen at one point). I think Tribal is a better name than Projectyle, though I think the EA marketing folks disagreed. The Tribal game is described, but then the player is told to insert the Projectyle disk. Evidently, the game you are playing is 'Tribal,' but you are playing 'Tribal' (played with a 'projectile') in 'Projectyle'. Got it?
The Graphics
The initial graphics for Projectyle were done by Stoo Fotheringham, who created multiple player and arena graphics sets. As the game's development continued, the budget was getting decidedly stretched. We had hoped to have a complete set of art for the game by Christmas 1988, but Christmas came and went, and the art was not done. Additionally, based on feedback from EA, it became clear that we'd need a lot of iteration on the art to satisfy their expectations. With our art budget depleted and no further funding being offered by EA, I ended up taking on the bulk of the remaining in-game art tasks, with Marc pitching in where necessary and Elsbeth, my now wife, handling the player profile pics and animations that were deemed necessary for the training modes and game interstitials.
Stoo is not credited in the game but should be recognized for creating the initial graphics. That said, I spent hours and hours working on pixel art for the players, arenas, and logos. Much of it was technical art - as I evolved the capabilities of the graphics tech, it became possible (and necessary) to make changes to the art; however, there is not a piece of in-game art that I did not touch. Over and over.
Art additions I made to the arenas include all the parallax scrolling layers (I'll talk about those in more detail later on), animations (such as the lava bubbles in the Devils map), and a ton of finesse work. I made wholesale changes to several of the arenas.
The art tools du jour were Deluxe Paint on the Amiga and a customized version of Advanced OCP Art Studio on the ST that had been modified in-house at Ocean (I think) for use internally. Still, everybody in the game development business had a copy of it. This particular version of OCP Art Studio had additional capabilities for sprites and tiled map editing, which is how the Projectyle arenas were created. That tool and I became good friends while working on Projectyle!
The Music & Sound Effects
We were in a similar boat to the graphics for music and sound effects: no budget. I did talk to one or two local Liverpool musicians, but it was clear that we couldn't afford to contract out the music.
In my infinite wisdom, I decided to take on all music composition duties. And sound effects. I could play guitar and had previously created a small amount of music for games. And I used to be in a bedroom band (I never graduated to garage band status). Should be doable.
And in my even more infinite wisdom, and which EA was enthusiastic about (while not offering any additional budget), why not give each of the 8 teams their own theme tune?
In the end, I created 8 tunes using Quartet on the ST. Quartet offered an editing environment (albeit on a musical stave rather than the typical Sound Tracker style grid format), MIDI input (I had a MIDI-capable keyboard), and a player for the ST that could deliver 4 channel digital audio by flogging the volume registers on the ST's AY sound chip to death, using 100% CPU to do so. This meant that we could not play audio while the game was doing anything, but we did at least have music on the main menu.
A snag with this cunning plan was that Quartet did not provide an Amiga player, leaving us with a big hole. Quartet did not provide the source code for the Atari ST player. The solution to this turned out to be gallons of coffee, Def Leppard's Hysteria CD on repeat, Devpac, and a long overnight session disassembling the ST player and then creating an Amiga player, using the Amiga Paula dedicated sound chip to accomplish what Quartet was doing on the ST by hammering the PSG ports. I did this work in one (albeit) tiring session, and the next day, we had a Quartet player for the Amiga, allowing regular game development to continue. To be fair, this was near the end of the project; the ST version of the game was done, and creating the Amiga player became part of the "porting" effort.
An interesting note on this is that, to my ears, the music on the Atari ST version sounds better. A certain 'depth' is hinted at by the unavoidable distortion generated by (Quartet) clobbering the volume registers to play PCM sounds on the ST. On the Amiga, things sound arguably sterile. Because the music was composed and created in Quartet on the ST iteratively, those are the 'true' versions. In addition, Quartet on the ST does have a wider sample playback range than the Amiga, where I needed to use octave-shifted samples in places.
A benefit of the Amiga Paula hardware is that music playing does not consume all the CPU. This means that on the Amiga, we can have music while the game is playing; thankfully, there's an option to disable in-game music, which may get repetitive.
I like a few of the tracks, a couple I'm not keen on, but the music served its purpose on balance. I've separated out a brief discussion on each track; that page may be found here.
I created or sourced the sound effects, which on the ST were PSG bleeps and bloops but were PCM samples on the Amiga. The spoken voice for all the Amiga powerup/special sound effects is the Amiga SAM text-to-voice program played through various audio effects (in case it is not obvious)! DOSH!
The Coding
Projectyle had two main tech and design pillars:
1. Collision Physics
The game's physics needed to be solid. One of the first things I did was figure out how to resolve 'oblique impact' between multiple moving 'spheres' (circles - the game is played in 2 dimensions) and the playing arenas. The 'projectyle' (the game's name is deliberately misspelled, but the 'puck' or 'ball' is referred to as the 'projectyle' in the poster/manual) is inert and will normally move only when struck by a player. Once in motion, the projectyle will obey physical collision rules when it encounters the arena's edge or another player. The game is played like a 3-player version of Subbuteo meets Air Hockey but in a multi-zoned arena. In my first few years of developing games, I did not have much cause to use 'math' (I know that it is 'maths' in the UK, but after almost 30 years in the US, certain things stick!) beyond simple arithmetic and logic; however, I had done a fair bit of math in school. Would the two years I'd spent at Barnsley 6th Form College studying A-levels in Mathematics, Further Mathematics, and Physics, plus the two subsequent years at Manchester University studying Electronics yield anything of practical use? Not entirely! I could remember bits and pieces, basic Pythagoras, a couple of 'useful' identities like sin(A+B) = sin(A)cos(B) + cos(A)sin(B), equations of motion like S = UT + (AT^2)/2, but the glue holding these things together in my memory was losing its adhesion! It was time to go to the library in Liverpool's city center (no World Wide Web yet!) and refresh my memory. A few high school physics books later, I had things figured out and set about writing a program in Atari ST Basic to bounce circles around the screen, colliding with each other and the edges of a containing rectangle. This 'demo' would form one part of the 'pitch' materials when we met with publishers, demonstrating that we had the core physics figured out.
2. Scrolling Backgrounds
Naturally, Scrollerball would need a ball ('projectyle') and ... some scrolling! I've documented here, here, and here how I accomplished smooth scrolling backdrops on the 8-bit Sinclair Spectrum. Working primarily on the Atari ST (the Amiga version of Projectyle would follow), armed with learnings (but to be clear, no source code) from my efforts at Denton Designs on Gargantuan, I sat down and experimented with different ways to update the screen. Using pre-shifted blocks would cover the horizontal movement (and solve any complexity caused by the interleaved pixel format on the ST). Vertical movement was easy on the ST due to the linear screen layout; it remained to find a fast way to blast data to the screen. In my initial experiments, I tried using the MOVEM (move multiple) instruction to pull source graphics data, push it to the screen, or both. Still, it proved fiddly to use for anything other than linear blocks of graphics data, and I needed to support arbitrary tilemaps. Until I started researching this article, I had forgotten my final approach. It is simple, and while not yielding the ultimate speed (though plenty fast enough), it is extremely flexible. Here's a snippet from the screen draw routine that is responsible for writing one pixel-row of data to the screen.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 | MOVE.L #0x400,D1 ; step to next line in source pixel blocks MOVE.L #0x020,D2 ; step to next line on screen (stepping over score panel) MOVEA.L screen,A6 ; screen address MOVEA.L source,A5 ; graphics blocks address ADDA.L skip,A5 ; vertical offset into blocks to account for vertical scroll MOVE.W rows,D0 ; number of pixel rows to draw loop: MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ MOVE.L (A5,0x00),(A6)+ ADDA.L D1,A5 ADDA.L D2,A6 DBF .W D0,loop |
This code is simple, and the secret sauce is in the code *not* shown here! At the top, you can see that various registers are set up, A6 points to the screen, A5 points to the source map tile graphics data, D1 & D2 are set to constants to step down to the next line of pixels in the source and destination, D0 is a pixel row count that is used as a looping variable. At the business end of the draw code, there's an unrolled loop that copies long words (32 bits) from A5 plus a constant offset to A6 with post-increment. On the face of it, this is not that interesting, but you don't see the code to set up (using self-modifying code) the constant offset added to A5 in each move. By previously setting this constant (represented above by the 0x00 in the source part of each MOVE.L operand, it is basically a 16-bit offset) for each move instruction based on the current map position, we can point A5 to specific map tile graphics data and draw the map. Since each map tile is pre-shifted, this is all we need to draw the scrolling maps in Projectyle! Because of the interleaved screen format on the ST, the 4 bits for each 16-color pixel are spread across 4 x 16-bit words. It follows then that two long word moves (effectively 4 x 16-bit moves) will draw 16 pixels, and one can deduce from this that this code is drawing 16 16-pixel wide map tiles per row. Simples!
I will post a longer extract of this code to my Github when I can.
One interesting effect that becomes possible when using pre-shifted map tile graphics is that, if things are set up carefully, one can add a parallax layer into the tiles absolutely free (in terms of real-time performance). This was used to good effect in various of the 8 different arenas created for the game. The trick is to create the map tiles with transparent areas (using some sort of mask), and then *after* the tiles have been pre-shifted (either by the game or ahead of time), drop a parallax layer into the transparent areas that either does not move, or that moves at a different horizontal rate. A shadow effect is also possible and free! This approach has no vertical parallax, but the horizontal effect is quite pleasing. Animating parts of the background was also essentially free (see the asteroids) by simply animating map tile indices (since the whole play area is redrawn each loop). Here are a couple of brief examples. The third example (bright green) is running on the Amiga, where I implemented vertical and horizontal parallax. More on the Amiga specifics will be included in part 2.
 |
| Parallax and Background Animations in Projectyle |
In part 2 of Eldritch The Cat Mk1, I'll dive further into Projectyle, and talk about some of the other things we tried as we worked to get our new company off the ground!
Read part 2 here.
Comments
Is there a playable demo and or GFX available?
What the story of it not being released?