|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Product description:
Fuel up your spaceship, buddy, you've
got some hostages to rescue! Using amazing 3D
real-time fractal technology, terrain is created
instantaneously as you shoot up your enemies and
maneuver your rescue craft to save the pawns. With
3D sprites, booby-trapped transport pods, power ups,
aliens and fuel issues, you better know what you're
doing...or the hostages die.
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
Killer soundtrack
Developer Insight:
Cranberry Source had a mutli-product deal (three, in
fact) with Philips Media Interactive. QAD was to be
the first game released, Super Match Soccer (or
Match Day 3 as it was known then) the second, and
the third game had a provisional title of
“Redemption”. QAD and SMS were developed at the
London office, and Redemption was to be developed by
staff at the Cranberry North office. Ultimately,
Redemption never really got much further than the
drawing board, but the initial designs focused
around the kind of puzzle elements found in Jon
Ritman’s previous games such as Head over Heels and
Monster Max.
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.
WRITTEN BY: MATT TAYLOR |
|
|
|
| |
|
|
|
|
