Key Features:

-More than 20 missions available–with up to 200 hostages to rescue

-One-or two-player modes available

-Resource management of your spacecraft: fuel, weapons, rescue pads

-Uses Beyond Landscape and Polar Sprout—revolutionary landscape and display technology

The PC version of QAD was based around two non-polygon software rendering technologies: the “Beyond” landscape engine which rendered an interpolated landscape that did not use polygons but instead “Polar Sprouts” which were voxel-based sprites. The landscape engine was a huge leap over polygon-based systems of the time, with a deep draw distance not seen in similar games. The sprout engine was also impressive, with the ability to render tens of objects per frame. These two technologies differentiated Cranberry Source from other 3D PC game developers at the time and were key to convincing Philips Media to sign up.

My role at the company was to take the PC code base and port it to the PlayStation, resulting in a multi-platform code base that would also support the Sega Saturn version. I worked on QAD from around October 1995 to June 1997 which is the point I believe Philips Media were looking to exit the games industry. The path of development is detailed below:

The initial intention by Cranberry was to port the Beyond landscape engine to the PlayStation, and then use the PlayStation’s 3D polygon-based system to render enemies and objects. After performing tests to determine the maximum speed this might work at, the very best speed that could be achieved would be 10-12 frames-per-second without game code running and without rendering objects. This was due to the fact that each scene had to be rendered in main memory and then transferred to video memory, which is a slow operation on the PlayStation.

Despite this outlook, the company decided to press ahead with porting the engine and three months were committed to trying to get it work. The best result was a non-textured landscape running at around 8-10 frames-per-second which was clearly not going to be good enough. The effort was not entirely in vain, as I had also ported the bulk of the PC game code to the PlayStation during that time.

By this point (around February 1996), a Sega Saturn developer had started with the company. To try and recoup development time, non-PC development was split between myself and the Saturn developer. He was assigned the job of developing a polygon-based landscape engine and I was assigned the task of continuing the game code porting and integration. After around 8 further weeks of development, the polygon-based landscape engine running on the Saturn generated a non-textured landscape which was colour-shaded according to height, running at around 12 frames-per-second with a limited draw distance. The code design choices were based on the Saturn’s slow rate at rendering textured polygons and the number of polygons required to get a decent draw distance.

After seeing the Saturn version I decided to write a polygon landscape engine for the PlayStation that took advantage of the PlayStation’s ability to render polygons quickly. This was an unsanctioned effort and had to be done in my spare time and took about two weeks to write. I wrote the engine to take advantage of the PlayStation’s processor’s instruction and data caches, and (later) direct access to the PlayStation’s geometry processor. The core code was written in highly-optimised assembly language for maximum efficiency.

The end result was largely comparable to the PC landscape engine and utilized converted PC map and texture assets, which meant that the landscape data could be shared across platforms. The end result was shown to John Cook and John Ritman (Cranberry Source management), and also to Philips Media who approved it. Due to major hardware differences, the Sega Saturn version was very unlikely to be able to perform as well as the PlayStation version. That difference ultimately doomed the Saturn version (and perhaps the Saturn itself generally) and the Saturn version was canned at that point (around April/May 1996).

With the landscape problem solved, attention switched to the rendering of enemies and other objects in the game. It was clear that the PC polar sprout system would not work and that polygon-based objects would be required. This was a huge problem, as the 3D models that the sprouts were generated from had an extremely high polygon count and could not be used. The problem was compounded by the variety of objects used on each level, meaning that a huge volume of textures would also be required – too much to fit into the PlayStation’s video memory.

To get around this problem PlayStation-specific versions of game objects were created and the variety of objects per level decreased. This was a huge task at a late stage in the project, but the artists managed to produce these assets in a relatively short space of time. Some of the objects such as the hostages were done as 2D sprites, which actually worked well. However, Philips Media were ultimately not happy with the overall quality of the objects and this was understandable as they were very low-polygon versions of complex objects such as witches on broomsticks and bi-planes. As a result, the graphics were tweaked over time at Philips’ request up until the point the PlayStation version was cancelled.

QAD is actually pushing the PlayStation hardware very hard, especially on the graphics front. Where it suffers is in terms of 3D models and use of textures on those models. Had more time been given to producing the graphics and creating objects that were not attempts at directly copying the objects from the PC version, the end result would have been much, much better.

The collision detection system was not quite as efficient as it could have been and – when combined with the PlayStation’s limited memory bandwidth – slowdown is almost always a result of too many objects colliding in the same general location. This, of course, would have been remedied by adjusting levels to contain fewer enemies and/or limiting the fire-power of those enemies during play-testing. Some of the weapons in particular generate wide-area collisions that require a large number of collisions tests to be performed, so those would also have need tweaking too.

There was never a problem getting the game running fast enough once the PlayStation-specific landscape engine was in place. The landscape engine on its own would run consistently at 50 frames-per-second, and with the game code running the whole thing typically ran between 18 and 25 frames-per-second. The state of the PlayStation version and its differences from the PC version at the point of cancellation were as follows:

• Game development lagged behind the PC version by about 6 weeks and was at a pre-Beta stage.

• The front-end menu system differed from the PC version in that it had a 3D rotating icon behind the menu for each item in the menu. It also had menu items for memory card and controller configuration.

• The memory card handling and controller configuration screen code had just been started.

• Two player link play (over the PlayStation link cable) was working, but not fully tested due to one of the two development systems Cranberry owned failing during testing. This was a common problem that could occur if the serial cable between the two systems became damaged or disconnected while the systems were switched on.

• All product assets were in place and the game was fully playable, running from CD.

• All 30 levels were complete. The game could be played from start to finish, including the final end game video sequence.

• The in-game map screen differed from the PC version in that it rotated in 3D in real-time according to the direction of the player’s ship. This proved very effective and players could easily traverse a level by using the map alone.

• The level selection screen differed from the PC version (which was 2D sprite-based) by rendering 3D solar systems. This section was at the prototype stage, and the planet models and textures had not been polished, but code-wise it was complete.

• The sky backdrops to levels that appeared in the PC version could not be performed on the PlayStation due to video memory restrictions.

• Dual analogue “flightstick” joystick (SCPH-1110), NegCon, and mouse peripherals were supported. A prototype version of the analogue controller (the pre-cursor to the DualShock- SCPH-1150 in Japan, SCPH-1180 in the United States and SCPH-1180e in Europe) was also supported.

• The game had not been through QA or play-tested. As a result, some of the later levels (level 20 onwards) were really too difficult to play when using the standard digital controller. Some levels also had way too many objects, as those levels were directly ported unmodified from the PC version, resulting in slow down and occasional crashes on later levels due to the collision detection system becoming overloaded.

QAD PC was not well received by reviewers or players, particularly as it was pitched as a straight-forward 3D shooter which wasn’t really the point of the game. Although QAD PC was virtually finished, QAD PlayStation still had some work (mainly front-end and QA) to do on it. Based on the poor reception of the PC version it made sense not to spend money testing and releasing it, particularly as the Sony licensing fees alone may not have been recouped if it had failed to sell. The statement “spent too much, earned too little” sums it up pretty well. So this combination of factors sealed QAD PlayStation’s fate.