Site index page
Simon N Goodwin's commercial softography, updated May 2008
This is an incomplete list of commercial products I've played a
substantial part in programming since the late 1970s.
The many games I wrote for publication in magazines in the early 1980s are
not listed here, as the software was not retailed separately. I've made another page with details of some of those games -
such as Whitehall and Space Intruders (Practical Computing), Gladiators and
Holocaust (Computing Today),Shop Steward (Personal Software and CT), Sniper
(Personal Computing Today) Runaway Robot (Games Computing) and the Spectramon
utility, including some background on how they came to be written and the
early days of home computing and the UK games industry. One day I
might start to collate information about some of the hundreds of
features, reviews, hardware articles and software utilities I've contributed
to dozens of hobbyist magazines over two decades. But don't hold your
breath...
Quick index
Eight-bit beginnings
Sinclair QL developments
HiSoft compilers
Silicon Studio Ltd.
Amiga Inc.
Attention to Detail
Codemasters Central Tech
Dance Factory
Brian Lara Cricket
Colin McRae DiRT
RaceDriver GRID
Everyone has to start somewhere. In 1979 I wrote a handful of simple games in
Apple Integer BASIC on one of the first Apple ][ computers to reach the UK.
It arrived at my school with a generous 24K of memory and the original red
manual, with handwritten pages, shortly after the maths teacher who had been
lobbying for its purchase gave up and went to work for King's School in
Worcester, which already had a computer of sorts - an elderly mainframe
retired from the manufacturer Metal Box.
![The original Apple ][ (6K)](pix/Apple][.jpg)
This left Wycliffe College with a micro that no one on the staff showed much
interest in, busy as they were making unwilling pupils clean rifles without
pointing them at one another and run round and round the playing fields in
the drizzle for showing insufficient enthusiasm for the school's main focus,
Rugby Football. Somehow I ended up with the book used to log use of the
foundling computer, priority access to the machine, and enough enthusiasm -
having previously attempted to cajole a shop's PET 2001 to work out square
roots the hard way, by Newton Raphson, not knowing about the SQR function -
to teach myself BASIC, 6502 assembler, and the mysteries of GR and HGR
graphics and one-bit sound.
Several of these games were published in early hobby magazines like Computing
Today and Practical Computing, and one of them found its way onto the shelves
of Oxford Street pioneer software retailers called - appropriately generically
- The Softwarehouse, in the days when you could register a company with such
a name and not be told that the term was too general.
Following up a magazine ad seeking new programs and programmers, I gave The
Softwarehouse a 5.25" minifloppy disk with a handful of titles, including a
balloon flight simulator and a Breakout derivative with the innovations of
ball steering and quick return. Returning to London a few months later in
search of magazine payments, after spending my last nine quid on a return to
Euston, I bounded up the stairs to The Softwarehouse's shop and en suite
offices, to see how the world was reacting to my work, only to be told that
my games had been shown to a few potential distributors overseas but they'd
not taken the bait.
This was the first of many encounters with publishers reluctant to pay up,
and on the way in I'd been thrilled to see my game bagged up for sale with
others on display in the shop, so I scooted out of the office, grabbed one
and returned to demand my pound of flesh (I was not a vegetarian on those
days). The game was up, a royalty cheque was forthcoming, and I was on my way
to software stardom (sort of) forewarned of the ways of the industry. The
cheques have got bigger but the ways haven't changed much since.
I still have a copy of the disk, in the eccentric software RLL Apple DOS 3.2
format, but no way to read it, so I can't include a screen-grab or check if
the game was eventually published under the name WALLBALL or the alternative
title DROPOUT. Digging through my old mags I found an advert in the April 1981
issue of Personal Computer World which lists the game at £10 on Apple disc) as
'Wallbanger'. In any case it was written in Steve Wozniak's 6K integer BASIC
(itself written with the one-line mini-assembler in the same ROM). That Apple
][ had some interesting quirks, including a tendency to spontaneously convert
letter Y's in programs in to letter I's (a consequence of the use of the
early 4K 4007 DRAM chips which led to the inclusion of redundant parity bits
in IBM PCs for decades thereafter) so I got into the habit of using X and I
co-ordinates, rather than the X and Y I originally entered. Besides the 130K
floppy drive the Apple was connected to a noisy 10 character per second
ASR-33 teletype and tape punch, so I have several of those early programs on
paper tape as well as disk. Not that they're any more machine readable in
that format, but at least - with a bit of practie - you can read paper tape
by eye - a skill which still eludes me, 25 years on, when it comes to
magnetic disks. ;-)
GOLD MINE, 16K Spectrum, dk'tronics 1983
A few years later I'd
moved from the 6502 processor to the Z80, via my own first computer, a 1.77
MHz Video Genie (TRS-80 clone) and then to the ZX Spectrum which turned up
after a long wait late in 1982 and prompted me to sell the BBC Model B I'd
obtained, for a lot more money and similarly late, six weeks before. The
Spectrum had fewer pixels, half the ROM and less bus bandwidth, but it was a
vastly better machine and after a three-day stint learning the keyboard
layout I started work on what was to become my first chart success, a 48K
Spectrum game, written in a mixture of ZX BASIC and Z80 code assembled from
REMs in the source. This was Gold Mine, published at the height of the first
micro boom the following year.
More about Gold Mine, my game for
dk'tronics
Magic Micro Mission, Atari and Commodore 64, Quicksilva 1984
I worked on
a TV series about home computing, between July and December 1983. The six
programme series, entitled the 'Magic Micro Mission', was made by Central ITV
in Birmingham. It was broadcast at 5.15 on Wednesday evenings in November and
December, in six ITV regions: Central in the Midlands, Ulster, TVS, Border
Television, Tyne Tees and Television South West. We recorded the programmes
on Sunday afternoons, in the studio where 'Bullseye' was filmed during the
week.
The
left column shows some rather grainy grabs from the original Atari 800 title
sequence (via Crash magazine) and the inlay alongside is from the spin-off
game, brutally ported to the Commodore 64 and published by Quicksilva. The
artwork is by David Rowe, who also produced the cover for FirST BASIC (see
later).
My role of 'software designer' - a new title for TV - meant that I designed
and programmed the graphic titles, jingles and credits used in the series. I
worked with Central staff Graphic Designer Dave Beeson and Gus Chandler, a
programmer on the production team. Geoff Negus from Central News was Editor,
and Terry Johnston was Executive Producer.
The
series was thrown together in great haste to beat off a challenge from other
independent TV companies - from green light to recording the series was
prepared in about six weeks. The standard improved steadily and programme six
was 'Pick of the Day' in the Birmingham Post. It was hosted by the talented
Adrian Hedley (fresh from Jigsaw, another kid's TV series) and the pneumatic
Jo Wheeler, with a disembodied computer called 'Prune' for reasons not worth
elucidating, played by good-natured thesp (and comedy German in BBC TV's Allo
Allo series) Hilary Minister and 'Egghead' an escaped and bizarrely disguised
Warwick University academic. It featured full-screen game graphics - a
revolution for broadcast TV, in those days - and guests like funny man Willy
Rushton, musician Rick Wakeman, DJ and self publicist Dave Lee Travis,
cricketer David Gower (gamely reviewing early cricket software with a
one-pixel ball), comedy air traffic controller David Gunston, (testing early
flight-sims) plus a studio audience of schoolkids - typically sweating under
the studio lights in home-made robot costumes - and the Astronomer Royal.
It seems unexceptional today, when computer games are part of mainstream
culture, but the series was a breakthrough in 1983, as issue 4 of Crash
magazine reported in May 1984: "...to date television as such has been
remarkably uninterested in computer games. Central Television's Magic Micro
Mission was the first programme which actually examined the phenomenon."
Unfortunately it was not shown in London, which is why media historians often
claim UK game TV didn't start till years later.
I was closely involved in the production of the series, writing half of the
initial 3000 word proposal after my friend Graeme Kidd (who had been business
manager of the student newspaper I edited the year before) lent my issue 1 ZX
Spectrum to one of the bosses and got the TV company interested in the idea
of making programs featuring the new home computers. I contributed background
knowledge of the micro industry and script material, and appeared in the
final programme, discussing the graphics software used on the series,
nervously waving my hands around and illustrating the sound-effects orally.
Sorry, I don't have a tape of this! ;-)
The specification for the title sequence was that I should produce 'the best
graphics possible on a cheap home computer'. I chose to use an Atari 800
system (retailing at under 200 pounds) although I had had no previous
experience of the machine. The end credits were programmed using a 16K ZX
Spectrum, as that meant I could type the names of the team directly into the
BASIC as they changed from week to week.
The big text and scrolling was handled with code snarfed from Sinclair's
Horizons demo tape, accompanied by animations that played on the names and
roles of key members of the team. The whole lot was genlocked over live
footage with equipment costing 320 times more than the micro producing the
graphics; Spectrums and broadcast TV standards took quite a bit of
reconciliation!
The software which generated the TV title sequence - almost entirely in
real-time - featured some sophisticated techniques. An interrupt-driven
routine was called thousands of times a second, during the flyback period of
every displayed line (allowing a maximum execution time of about 25
microseconds on a processor running at less than 2MHz). This provided a high
resolution display of over 100 colours on the screen at once, even though the
computer could only allocate two bits to the colour of each pixel, presaging
the later Amiga 'hold and modify' mode.
Dave drew the graphics on acetate, then stuck that to the TV screen, traced
and coloured them in using commercial Atari 'Paintbox' software, saved out
the resultant four-colour version and tweaked the colour line by line using
custom software to select the palette registers and new colours progressively
down the screen, to make a data file which could be loaded at the same time
as the basic 160x192 pixel image and copied to the hardware on the fly by my
horizontal display list interrupt server.
Another interrupt-driven assembly language routine controlled the rudimentary
'sprite' facilities of the computer, allowing symbols to move over the
background without altering the bit-map. Up to eight sprites moved fifty
times a second, during TV vertical blanking.
The remaining CPU time ran a control program to move the sprites, detect
collisions, read and respond to the joystick, trigger four-channel sound
effects, and advance the player character through a sequence of screens.
Seven different sections were used to generate the title sequence, which was
different for each episode. Two of those were developed into the game, while
the others were used as rewards and to set the scene.
The initial section displayed a multicoloured version of the Central ITV logo
on a background of stars - a four-part musical rendition of the 'Central
tune' played while a spaceship flew onto the screen, around the 'ball' of the
logo, and vanished (in perspective) into the distance. The next bit used
palette line interrupts for a moving road effect, rather than extra colours,
as UFO sprites flew around the player in a first-person 3D chase sequence
(obviously influenced by the Planet of Zoom arcade game) heading for a micro
screen on the horizon. After some transition graphics the spaceship zoomed
through the screen and into the micro itself and a Pacman-style circuit board
with eight sprites representing chips and resistors wandering around a
maze.
The gameplay took second place to the graphics, which was a pity as the
Commodore 64 tape sacrificed almost all the colour (and even some of the
gameplay) of the Atari 800 version, which was finished but unpublished due to
the small number of punters with a 48K disk-based system capable of running
it. But as it's the only game I've ever had my name on the cover of, I'd love
to hear from anyone with a spare copy as I was never sent one by Quicksilva,
though I did get paid royalties (rather less than the £1200 I got from
Central for the TV work) so presumably a few thousand copies were sold...
ZIP, 48K Spectrum, Sportscene/GK Computing 1983
In 1983 I was a Computing Science student at Aston University
when I was approached by Roger Munford, former editor of Argus Press magazine
ZX Computing, to which I'd contributed Spectramon, an uncommonly large Z80
memory monitor and machine code disassembler. He was moving to Sportscene,
publishers of Personal Computer World (formerly Bunch Books, latterly Dennis
Publishing, the empire of former Oz magazine defendant Felix Dennis :-)
Roger was looking for a series of articles which could illustrate structured
programming in a new magazine, Your Spectrum, which he was about to launch. I
opined that any such series should develop a real, useful and complex program
- not just an exercise - and suggested that a compiler for a substantial
subset of the ZX BASIC language would be a suitable topic.
The result was the ZIP compiler, an elaborate and uncommonly well-documented
integer BASIC compiler which read ZX BASIC tokens directly from memory and
stored the results beyond the reach of BASIC, after a small runtime library.
ZIP and its demo game Star Base featured in four articles in issues 2 to 5 of
Your Spectrum, and later thousands of copies were sold on cassette with
manuals - initially printed on an ancient and smelly Gestetner duplicator
with tapes recorded in parallel on a row of cheap cassette decks screwed to a
plank, later professionally duplicated and printed.
Version 1.2 of ZIP was printed in the magazine, along with coupons inviting
readers to send in three pounds 50 for version 1.4 on tape with the full
manual. Graeme Kidd, later editor of Crash magazine (among others) and mayor
of Ludlow, handled the distribution from his Harborne squat, encouraged by a
cockup that scrambled the text in the second part of the magazine series and
obstructed by a postal strike in London that winter.
ZIP resurfaced a few years later in a version for 128K as well as 48K
Spectrum computers, first on the Tech Tape published by Newsfield Ltd to
accompany the Crash magazine Tech Niche 16 page special, and later in a
mail-order offer managed by CGH Services.
Version 2 of ZIP, distributed on the Tech Tape and in the CHH offer, was
itself compiled, making the compilation process a lot faster, and was
extended with multichannel sound and screen-reading code. Its final
commercial outine was a decade after its launch, when it was 'exclusively'
covermounted with the Christmas 1993 issue of Your Sinclair magazine.
I`m grateful to Jon Smith and Alan Cox for help in the development of various
versions of ZIP.
There were versions of ZIP for other computers. A port to the Timex 2068, the
US version of the Spectrum with a new ROM and improved sound and graphics,
was licenced to Knighted Computers in New York and sold retail and by mail
order to North American Sinclair enthusiasts. This was a challenging port as
I did it without ever seeing a TS-2068, and with only a list of ROM entry
points as my guide. After a few tries I produced a saleable version 1.5 and
royalties, generous even after the 50:50 split with my Texan agent Carl
Zielgler, rolled in for years after.
A version for the Memotech MTX, another Sinclair-spin-off micro, was not
finished before the manufacturers ran out of cash and recalled the
development hardware I did produce a working version for the MGT SAM, with a
few extensions, in the early 1990s but this never lived up the promise of the
hardware and was shelved till a decade later, when it resurfaced and was
published by the SAM/Spectrum Profi club of Cologne, Germany.
Unlike many of my other home computer programs, ZIP is still not freeware; I
have a dwindling pile of printed manuals and still sell them periodically.
Mail me if you'd like one!
Soon after I finished the first version of Zip I returned to Aston University
and needed to come up with a proposal for a final-year project. Having
learned by that time that the only thing you can be sure of delivering on
time is something you've finished already, but wanting to do something new
and cool if I got the chance, and delve into the Motorola 68008 processor in
Sinclair's new QL home computer, I proposed 'a compiler for Sinclair
BASIC' as my project.
With luck this could be a compiler for Sinclair SuperBASIC - the
vastly improved, Comal-based interpreter programmed by Jan Jones and built
into the QL's ROM, alongside Tony Tebby's Unix-influenced Qdos operating
system - but if I got stuck, or busy with something or someone else (maybe
even a girlfriend?) I reckoned I could fall back on ZIP and still earn the
degree.
Staff at Quicksilva obtained early Qdos documentation from Sinclair on my
behalf, and I got a QL from the second batch at the end of May 1984, then
another one which worked (the first lasted only 45 minutes) in June. I made
steady progress, first writing code on my 128K microdrive-based system to
read the tokenised program source from QL memory - then routines to parse the
result and generate corresponding code in the form of calls to intermediate
code and stack operations expressed in Reserve Polish Notation. This text
output was written to microdrive tape and later - once I got onto Metacomco's
Macro Assembler beta-test programme - converted into 68000 machine code by
expanding the text, via assembler macros.
This was enough to prove the symbols table and expression evaluation code,
and get benchmarks compiled and running as standalone multi-tasking
processes, but the generated code was far too verbose to give me any chance
of making the compiled compiler fit on the machine. Like Zip, this was a
four-pass compiler, working from tokenised source in the interpreter's
memory. The first pass collected information about the whole source, to
enable robust error checks later on. The second pass converted the source
into an intermediate code and reported all errors. Only if that worked - and
most programs submitted for compilation fail at this point - were two more
passes used to translate the intermediate code and fix up cross-references to
make a stand-alone code file. The use of compilation from memory made the
extra pre-pass fast, and the separate code-generation phase simplified the
design and allowed the machine code library to overlay the compiler, making
best use of limited RAM and the microdrives - good for large block loads but
slow for sequential filing.
The following spring a demo to my supervisor went well and that and the
report earned me a first class honours for the project. By the time I
graduated I was looking for a publisher, who could turn the compiler into a
product as Quicksilva were no longer interested in the QL and in the throes
of selling out to Argus Press.
Freddy Vachha was setting up Digital Precision as a specialist QL
publisher at the time, and set me up with a 720K CST 5.25" floppy disk
system, 256K extra RAM from Simplex Data, and an advance which I immediately
spent on the HiFi system I'd always wanted but never been able to afford -
Tannoy M20 speakers, a Mission Cyrus amplifier and one of the new-fangled CD
players that were expensive luxuries in 1984 - one of the early 14 bit
Marantz ones, and the only part of the setup I'm not using any more.
It took another year to develop the academic project into a commercial
product - QL Supercharge, £60 boxed with a 100 page manual (written in
Scripsit on my Video Genie, printed with a Juki 6100 daisywheel printer). The
compiler ran overnight for weeks, parsing itself in slow interpreted BASIC,
usually to fall over in the small hours with some unanticipated problem. The
aim was to get it to compile itself, and after weeks of trying it got all the
way to the end and emitted a complete intermediate file. A few weeks later
that assembled into an executable program. It took weeks more to get that to
compile itself, and further weeks to get the compiled compiler to match the
compiled compiled compiler! Compiler bootstrapping is not as simple, or as
easy, as academics often make it seem.
To meet the challenge to get from intermediate to executable code, Freddy
enlisted Ferranti CPU designer and Open University lecturer Gerry Jackson,
author of SuperForth, DP's first QL compiler, to write a custom
code-generator to take the place of the Metacomco assembler. In the process
the design was refined to optimise the speed and size of the generated code.
Memory was tight - it had to run on a 128K computer with only microdrives,
and fit the compiler, its source and intermediate code in RAM (buffered in
screen memory for want of anywhere else) so the third and fourth passes only
loaded, over the top of the parser, if the code was guaranteed correct. It
compiled to an intermediate language which the code-generator could optimise
and convert to either 16 bit threaded code (like Forth) or pure 68K code
selectable on a per-line basis, and then generated a dynamically-built
library to run the threading so the overhead of despatching between templates
(16 bit code pointers) was only two instructions:
move.w (a5)+,d0
jmp 0(a6,d0.w)
Most of the machine-code from the macros could be encoded into a single 16
bit word, followed by any parameters (fetched with move (a5)+ from the
threaded code stream) yet raw machine code could be inserted into the
instruction stream at any point the maximum speed was essential, prefixed
with jmp (a5) to switch out of threaded code, followed by reloading a5 and
restarting the threaded code above when space was more important than speed.
Once Supercharge had compiled itself the overnight runs were reduced to about
20 minutes at first, then trimmed to nine minutes for the compiler to
re-compile itself after optimisation of the code. The code itself shrank from
about 80K of tokens to just 46.5K of compiled code, including the template
library, threads and initialised data - leaving room for 30K of source and 9K
of compile-time data on the unexpanded QL - the other 40K being taken up by
the screen (32K, mostly used to buffer intermediate code during passes three
and four) and the Qdos multi-tasking operating system structures and device
linkage.
Supercharge review in
Sinclair User, March 1986 Supercharge was unveiled in an article in the
October 1985 issue of QL User magazine and went on to earn a 'Sinclair User
Classic' award and sold thousands of copies over the following couple of
years. Some of these sales were gained - and doubtless some lost - by the
revolutionary system of copy-protection built into the product - the infamous
Lenslok.
LensLok
Lenslok, from ASAP Developments, consisted of a plastic holder for a
transparent slatted lens which scrambled the image on screen over which it
was placed, making nonsense of a normal bit-mapped display but shuffling a
correctly pre-scrambled pattern into readable text. The user was required to
read two characters through the lens and type them in at the start of each
compiler run, to prove that they had a genuine copy of the compiler - or at
least a copy of the lens, which was much harder to copy than the unprotected
100K microdrive tape on which Supercharge was shipped.
Lenslok became infamous that year when the programmers who bolted it onto the
Spectrum version of 80s classic game Elite misread the instructions and
generated a pattern which could not be read reliably, with or without the
lens. The QL's floating point scaled graphics and high resolution meant that
the Supercharge patterns were readable and readily compatible with various
sizes of TV and monitor, though after a few days many users learned to
shuffle the rows by eye and live without the lens.
Lenslok was very successful in dissuading commercial pirates from selling
Supercharge, until some ingenious thieves in Belgium found a way to make the
compiler defeat its own copy protection. The rip-off copies of Supercharge
sold by Persoft in early 1986 came with a small program - itself compiled
with Supercharge and hence able to multi-task alongside the compiler itself -
which read the screen memory where the Lenslok pattern was displayed,
re-ordered the data and displayed it alongside 'in clear'.
This was defeated by randomising the position and initial scale of the
pattern in later versions of Supercharge. Eventually a version without the
Lenslok code was produced, for a bundled deal with US QL distributors A+
Computer Response, but by that time Turbo, the inevitable follow-up
product, was on its way....
TURBO, Sinclair QL/CST Thor XVI, 1986
The follow-up to Supercharge. An associated product, Turbo Toolkit, was sold
separately and on ROM to users of CST Thor computers. Both are now
open-source with updates and copious documentation on-line.
Turbo open
source home page
Article in QL Hacker's Journal
More to follow - lots to say!
SpeedScreen, Sinclair QL/CST Thor XVI, Creative CodeWorks 1987
SpeedScreen was a replacement display device driver for Sinclair QL
and CST Thor computers. It made common display operations much faster
and so benefited all users of those systems - even those normally happy
to use just the bundled software supplied with the machine. It taught
me that - after years writing compilers - it was easier to sell speed
by enhancing what people already had, than by giving them new ways to
make fresh and speedier applications themselves. ;-)
SpeedScreen was initially sold on microdrives and 5.25" and 3.5" floppy
discs, priced at £20 with a 16 page manual. Later it was released in ROM
chip form, making the code even quicker (as the ROM was faster than the
DMA-contended RAM in most systems) and leaving more room for applications
- and giving me the chance to sell the same thing a second time to
willing customers, at the same price or £30 for a bundle of both the
ROM and disc or tape versions (which included additional utilities).
SpeedScreen optimised display handling by replacing slow, general-purpose
code in the system ROMs with fast replacement routines. You didn't
need to alter your programs to use it - just load SpeedScreen before
loading€and using your application. The only difference (apart from a
small memory overhead - configurable between 4.5 and 17K) was the extra
speed.
SpeedScreen optimised scrolling, printing in the most common character
sizes, window clearing and cursor operations. The improvement in speed
compared with a standard QL depended on the operation: text output was
typically between four and twelve times faster than normal. SpeedScreen
optimised all OVER and UNDER settings, solid colours and 64 stipples.
By default, SpeedScreen scrolling was at about twice the normal speed,
but a new command let you set higher speeds - up to eight times normal
- for free-scrolling displays such as LIST and COPY, letting users
adjust the rate to control flicker and match their reading speed.
Further new commands allowed extra character-sizes, coloured fonts and
other features that came almost for free out of the code I'd rewritten.
The QL's original display handling code had been written in a great rush
and squashed into a very small amount of memory. So routines were chosen
for their generality, rather than their speed. Thus one routine prints
characters in all CSIZEs and for all values of INK, PAPER, OVER and
UNDER. A single tangled block of code was used to scroll and pan, to
print blocks and borders, to draw and erase cursors and to clear all or
part of any window, regardless of its position. SpeedScreen avoided
those slow routines and uses its own fast code instead.
SpeedScreen emulated Sinclair's OS accurately, despite its speed. Displays
looked just the same, but appeared much more quickly, though pausing and
interruption was supported as before. The code was device-independent and
re-entrant, so one copy of SpeedScreen boosted any€number of windows and
concurrently-running tasks. Apart from a slight tweak to the MODE command
(which changes display resolution) all system commands worked as before.
Features that were not optimised were handled exactly as€usual, at normal
speed, and could be mixed with optimised text or graphics without
restriction. So I only needed to rewrite the bits of the API I could
speed up usefully, and could revert to existing code for all the rest.
SpeedScreen sold thousands of copies by direct mail order and through
dealers in the six months I advertised it. All the duplication and order
fulfillment was handled by student friends of mine, paid generously for
a quick turn-around. Raw material costs were tiny. Soon after, my former
publisher brought out a clone product, heralded by full-page advertisements,
(using a brand name I'd thought up for another product he'd since canned!)
and I moved on. Exploiting good ideas depends upon timing, at the start
and the end, and you have to move fast! As long as you do that you need
not fear copyists, because you'll keep having new ideas and they'll
always be several steps behind.
When HiSoft were in need of a 68K compiler, with the rise of 16 bit home
computer systems in the late 1980s, they licenced Supercharge from me, as the
QL's 68008 processor was binary compatible with the 68000 in the Atari ST and
Commodore Amiga.
My original SuperBASIC parser was ported to the Atari ST by Andy Pennell,
author of MonQL and the 68K versions of Devpac (latterly a lead programmer in
Microsoft's Visual C compiler team). This involved adding support for TOS and
GEM libraries and code to tokenise the input source as - unlike the QL
version - it was not possible to read ready-checked and tokenised source from
the Atari's memory, as there was no BASIC interpreter bundled with the
system. Support for Microsoft QBASIC and MBASIC eccentricities (largely
inherited from DEC BASIC+) was also added, while the Qdos-specific features
like named loops remained in place as they were needed in order for the
compiler to compile itself.
HiSoft BASIC, Amiga, HiSoft 1988
HiSoft BASIC for the ST was subsequently ported to Amiga systems, again using
the parser derived from Supercharge with new tokenisation and codegen
routines and additional support for the custom Amiga hardware and
libraries.
Details to follow
FirST BASIC, Atari Mega-ST, HiSoft 1988
Needing a replacement for the barely usable 'Personal BASIC' (said to have
been cobbled together by a summer intern at Metacomco) bundled with early ST
systems, Atari licenced a cut-down version of HiSoft BASIC for the ST,
repackaged in a nice box with artwork by David Rowe (who produced much of the
classic Quicksilva artwork earlier in the decade). This version lacked the
facility to save stand-alone programs, and a few other features which were
available in the full version. It was bundled with Atari Mega ST systems.
Power BASIC, Amiga, HiSoft 1989
This was an update of the SuperCharge and HiSoft BASIC projects converted
to suit the Commodore AmigaOS. More details may follow.
DIY Toolkit, Sinclair QL/Thor XVI/Emulators, QLW/CGH 1988..1994
Details to follow
Silicon Studio Workstation, Amiga, Silicon Studio Ltd, 1993-2000
I was Technical Director of this company, makers of multitrack digital audio hardware and
software. The hardware was built around 32 bit Zorro III audio cards, each featuring four
128 times oversampled balanced line analogue inputs and four-channel 20 bit outputs
capable of 121 dB dynamic range - top specifications for the early 1990s. Of course
it doesn't take long for top specs to change, and the Amiga hardware failed to keep
up, ultimately leaving Silicon Studio high and dry. But it was fun while it lasted,
and I learned a lot.
Other specifications:
* Standard sampling Rates: 32000, 44100, 48000 and 51200 Hertz
* Typical Signal/Noise Ratio (A weighted) output: 113 dB
* Channel Separation @ 1 KHz : 101 dB minimum, 115 dB typical
* Dynamic Range : 121 dB maximum (20 bit digital data)
The Amiga contributed 32 bit Zorro III slots for one or two synchronised cards, fast async
SCSI hard drive and audio/data DAT tape interfacing, 14..146 Mb internal RAM, display,
MIDI, controller and other interfaces.
System software supported hard disk recording, multi-channel mixing and
parametric equalisation. Less commonplace features, even now, were support
for multiple pointers, flicker-free beam-synchronised displays and
constant-power integrated 'meterfaders' to AES/EBU specifications.
Following the demise of Commodore
and end of compatible Amiga hardware production, the brand was purchased by Silicon Graphics
Inc and our custom Amiga audio development efforts ceased. The associated domain, studio.co.uk,
remained mine until 2004, when it was sold to an eponymous Internet shopping company.
Amiga Desktop Environment, Linux/PC/Taos, Amiga Inc, 2000-2002
Amiga Inc. system software development and documentation.
When Amiga got bought out by former Gateway staff I was initially hired to
document the new Amiga Desktop Environment, a radical processor-agnostic
distributed processing platform built on Amiga and Tao Elate technology, and
edited the 300+ page printed manual for the new SDK on my A4000 computer and
delivered it camera-ready in PDF format within a few weeks. Before long I was
drafted into the tech team developing the replacement for Commodore's
AmigaOS, designing and programming heap memory management tools, taglist and
dataset routines for the Amiga Component Model - a sort of safe,
multi-processor COM, implemented in VP virtual assembler.
As we moved the new
Amiga systems to fresh hardware my Silicon Studio contacts and experience
came to the fore and I was appointed team leader of Amiga Audio development,
and led the implementation of a network streaming MP3 player application
which ran in the AmigaDE, initially hosted on Linux, Windows and Sharp Zaurus
and Iris PDAs.
This
involved managing a team of six people spread around the world. The pictures
alongside show the player's user interface, designed for small (QVGA) PDA
screens - the graphical skins were designed by Kevin Saunders; I coded the
back end with Thomas Wentzel; the GUI was programmed by Davy Wentzler and
Rudi Chiarito.
Much of the
work involved separating the tasks and formalising the communication between
the people and the software sub-systems, to make the development process and
the resultant software scalable and reliable on diverse platforms, such as
multi-processor and distributed computer networks. This remains a key area
for me.
When I joined Attention to Detail in 2002 they were developing a racing game
for toy brick company Lego, to follow up Lego Racers 2, a PC and PS2 title
which they'd recently finished. Drome Racers was known as Lego Racers 3
during development, and themed to tie in with some techie Lego cars.
I arrived too
late to make a significant contribution to the PC or PS2 code, but got
involved in the conversion to the Power PC based GameCube. Ports of the game
for this machine and Xbox were scheduled to follow the PC and PS2 versions,
and benefited from extra development time.
The sad thing about Drome Racers was that - due to publisher interference -
it was a more playable game six months before completion than it was by the
time Lego deemed it fit for release. The management of Lego games seldom
lasted as long as it took to complete a console title, and drew from a pool
of people with little experience of the games industry, which meant
frustrating changes in direction that did not improve the eventual
product.
Despite this, and the problems of the Kaboom group, the Xbox and Nintendo
ports were finished on time, and the Gamecube version of Drome Racers briefly
appeared in the UK top 10 for the platform.
A more ambitious project, Lego Racers 4, was canned after substantial
development effort. This was technically interesting as the design called for
streaming of the entire game world from DVD, allowing much larger and more
intricate play area than earlier Lego games, or most console titles at the
time. The team involved went on to work on Ion Runner, of which more later...
Fatman & Slim, PlayStation 2, ATD/Kaboom 2003
Fatman and Slim started out as a physics demo, built around MathEngine Karma
dynamics library, and was initially funded by Sony. When they passed on their
option Kaboom continued and finished development; the game passed Sony QA at
the end of 2002. By this point the group was running out of money and made
most of the staff at ATD redundant; they were unable to finance the
publication of the game themselves, and sold the rights on to budget
publishers Metro3D in 2003.
Having exhausted the metal-bashing potential of the GameCube I was moved to
the FatMan team late in the development, and given the task of optimising the
code to animate water surfaces, which was taking a large proportion of the
frame time when running in 'optimised' C on the main processor. I reworked
this to run concurrently on the PS2's vector units, using VU0 for updates
(moving the water surface) and VU1 for rendering (stretching the reflection
and adding specular highlights as it caught the light).
Despite the extra specular layer and a tripling of resolution, my optimised
code ran several times faster and imposed very little load on the main
processor, leaving that to concentrate on the physics.
Ion Runner, PS2/GameCube/Xbox/PC, ATD/Kaboom 2003
This grab from the unfinished game Ion Runner, in development at ATD when the
Kaboom group collapsed, includes diagnostic messages showing how it was able
to manage three pools of rippling, specular-glinting water in a single game
level, plus a new heat haze effect streaming from the exhaust of the player's
ion bike.
I wrote the code for these effects, building on routines written for Fatman
the previous year. ATD`s game engine Saracen 2 made great strides during
2003, especially on PlayStation 2 thanks to optimisations by Andy Wright,
till it was comfortably drawing over 100,000 polygons, many of those
'expensive' types to render, at a steady 60 Hertz (over seven million polys
per second, at peak, without dropping frames).
I moved from the Vector Units to the PlayStation 2`s IO Processor and
reworked the ATDIOP sound and data streaming system to improve performance
and reliability.
Two complete levels of Ion Runner were programmed and demonstrated to many
publishers, but there was not time to sign a deal before venture capitalists
3I pulled the plug on the company in August 2003.
Since then the demos have been seen by many in the industry who were
surprised that the project was never finished - but the price, calculated to
refloat the group as well as to cover the development costs, meant any deal
on this new IP was hard to arrange.
This image includes graphics by Chris
Oxenbury, who later found fame as the stand-up comedian Okse and a
lucrative sideline producing comedy-related artwork, and now works for
top children's TV company Ragdoll.
Colin McRae Rally 2005, PS2/Xbox/PC, Codemasters 2004
Brian Lara Cricket 2005, PS2/Xbox/PC, Codemasters 2005
These days I'm working on sound and streaming data systems for leading UK
publishers Codemasters. I made early contributions to several of their
football titles, where my voice codec enabled the 150,000 speech samples
used in the commentary system to fit the DVD distribution without the
quality and efficiency problems caused by standard Windows formats,
and on the latest incarnation of their Colin McRae Rally franchise,
where I worked on the cross-platform game audio and wrote a custom
nine-stream DVD audio player on the PlayStation 2 for stereo weather
effects, Dolby Pro-Logic 2 ambient sounds and co-driver commentaries.
Rally did well in the UK console charts, despite the contention for the
Christmas season, reaching number 6 on PS2 and Xbox soon after launch and
remaining in the top 20 three months later.
I've also picked up credits for audio and streaming optimisation work on a
couple of games Codemasters published in 2005: Worms Mayhem and
Brian Lara International Cricket, both developed for PS2, Xbox and PC.
Brian Lara Cricket spent four weeks at number 1 in the UK all-formats game charts in the summer.
I've since been working on platform-specific audio systems for the new Brian Lara
Cricket and Colin McRae Rally games, and on some unannounced projects.
Oddly enough the head honcho at Codemasters is now Rod Cousens, who ran
Quicksilva twenty years ago when I designed the Magic Micro Mission game for
them, and David Gower (who appeared like me on the associated TV series)
provides commentary for the new cricket game. And the
artist who painted several package covers for my programs in the 1980s now
runs a company developing a radically new type of game based on my proof
of concept and optimised Digital Signal Processing systems (see later). So
while it's a much bigger industry, it seems the company names change much
more often than those of my associates on the UK game development scene.
One of the first things I was asked to do when I joined Codemasters was investigate a proposal
for a PS2 rhythm-action game that worked with the player's choice of music, from CD - a bit like a
cross between Vib Ribbon and Dance Dance Revolution. Within ten weeks I'd coded a proof-of-concept
that could read and replay CD audio using a bunch of threads on the IOP (the IO Processor which
masterminds disc access, memory cards, controllers, and PS1 emulation) and pass data blocks up
to the EE - the PS2's main 128-bit multiprocessor Emotion Engine - for filtering and analysis.
This prototype was able to extract beats and interpolate between them on a select few CDs,
scrolling various views of the track across the screen with beat times overlaid. I demonstrated
this to company founder Richard Darling and Chris Southall, our CTO at the time, and was given
the thumbs up for further development, as a collaboration between Codemasters Audio, Graphics,
QA and Central Tech departments, with one of the third-party firms that are the mainstay of
UK game development. But who could do it? After casting around for developers with relevant
experience, we hit upon Broadsword Interactive (run by Dave Rowe, the artist mentioned above).
Their lead programmer Jim Finnis asked several intelligent questions, and got the commission.
More than two years and many experiments later, Dance Factory was released in Europe, Australia
(where it was still in the PS2 top ten six months after launch) and North America.
I've got two credits - for the Proof of Concept and Signal Processing - and been involved,
along with Jim and his sidekick Steve Rose, who coded the dance generator, in most aspects of the
game design, development, and related patent applications. I ought also to laud the sustained
efforts of producer Dave Brickley, without whom such an original game would surely never have
reached the shops.
I could probably write a book about the development of Dance Factory, but I'm not sure
whether many people would read it - the game is more approachable! However there are lots
of interesting things to say, which reveal special things about the way this game was made
as well as insights into the 21st Century development process. I've deliberately skipped
details about the way the game works, because those are proprietary to Codemasters and
subject to patent protection. Contact our corporate lawyer Julian Ward if you want to
know more, especially if your company is interested in licencing the unique technology.
Testing
With its open-ended support for CDs the developers never heard - including ones unreleased at
the time we wrote the game - Dance Factory required an exceptional QA and testing effort. Each
time a new build of the analysis and dance generation code was available, Dan Flannigan's dedicated
QA team had to dance their way back through our test suite, consisting of more than a thousand songs,
ranging over 40 years and many genres, to check and rate the expected improvements and make sure
those had not introduced problems on any tracks that previously worked well. However big the
test suite, there's always going to be lots we've never tried, so our challenge was to ensure
sufficient variety of coverage to make sure that Dance Factory has a good crack at anything
players throw at it - with the possible exception of "Let's speak Spanish", a language course
one magazine playfully sumbmitted for dance generation - if that's really what you want to dance
to, you'll get what you deserve.
The challenge of testing and refinement explains why Dance Factory spent three years from
concept to release. Within a year or so we had it working reliably on typical modern dance
music with a strong, regular, beat, but we decided this did not live up to the potential of
the concept and went back into a fresh research phase, initially with no limits on the
RAM or CPU time for analysis. To get the dance quality we wanted on classic tracks,
as well as sequenced ones, we deployed all the resources of a Sony T1000 devkit -
originally marketed as a PS2-based super-computer workstation, with four times the
main RAM and IOP (32 bit Input/Output Processor) memory of the stock PS2 - and let
the multiple processors spend twenty minutes processing each song, digging out all
they could about not just the the beats but the structure, patterns and tempo changes
in the track.
I then production-engineered that 'optimised C++' code, rewriting it in machine
code to run across multiple CPU pipelines, shoehorning it into a third the space
and speeding it up to do the same job - and better - about FORTY times faster.
This exploited the parallelism of the PS2 processors - where nine-tenths of the
processing power is in the vector units, rather than the 128 bit MIPS R5900 CPU
that runs generic code ported from other platforms - to the point where Dance
Factory can generate dances at about seven or eight times real-time. So a
typical CD track can be analysed in around half a minute - less than the
loading time for many PS2 game levels - while at the same time Dance Factory
runs the Cubric minigame, with 24 channel music and sound effects. So
players don't have to wait around, even if they want to generate dances -
including optional Eyetoy moves - for a whole compilation album at one go.
Once this analysis has been performed there's no need to do it again; a map
of the album is stored on the memory card, labelled to identify the CD and
recognise it - or another copy of the same disc, parhaps on a friend's PS2
- when you want to dance to the same disc later. So the deep analysis only
has to be done once; after that the memory-card data can be used to generate
a range of synchronised dances with varying difficulty levels and features
like fitness (calorie counter) and creature (dance avatar) modes, within a
few seconds of re-inserting the disc. Even if you don't have the original
memory card, the dances for a given setting are consistent and repeatable
- a requirement established from the start by Richard Darling - so anyone
else with the same CD, a PS2 and Dance Factory can learn the same dances
and compare scores with you later.
The official line is that Dance Factory works only with mass-produced CDs,
but many players have found that it copes just as well with their private
compilations, burned onto CD-R media. Codemasters can't guarantee this,
as they don't control the quality of the media or the recorder, but it can
be a great way to enhance the 'endurance mode' where you dance through a
whole custom album - potentially a seque of dozens of songs, never dropping
a beat. Unlike arcade-based rhythm action games, with their simplified,
cut-down remixes, Dance Factory does not limit the length of a dance. It
copes with whatever you throw at it.
Dance Factory is paradoxically one of the smallest games ever on PS2 - it all has
to fit in memory, which explains the simple background graphics, though those
build up as you play and respond to the beat, unlike simpler light-synthesisers,
and had to be chosen to provide variety without overwhelming the display of
arrows, scores and key information needed to play the game. Graphics also have to
compete for memory with the dance database - the library of varying-length dance
step sequences, customised for each tempo and time signature - and the CD analysis.
Dance Factory includes 29 graphic themes, some of which you see from the start
and others which are unlocked through play. You never need to re-insert the game
disc; we decided that would make the game too fiddly to play. Yet in another
sense Dance Factory is by far the biggest game ever released on PS2 -
with terabytes of 'add on' content available, on tens of thousands of
commercial CDs, not to mention home-made ones. So the unusual features
extend beyond the USP, pervading the game design.
The music player, used in the front end and during the cubric mini-game, runs
entirely on the IOP, leaving all the main memory and 'Emotion Engine' processing
power for analysis and dance generation. It's a supercharged version of the sort
of 'tracker' module player popularised in the 16 bit home-computer days, using
similar techniques to build up tunes from short samples - but this time with
24 voices each positionable in stereo or ProLogic surround, rather than just
four hard-panned left and right, and room for more samples and high sample
data rates than an Amiga could manage even if all its 'chip RAM' were to be
allocated to music. And to make the best of this revived technology, Codies
gave Amiga veterans Allister Brimble and Tim Bartlett the job of producing
the music and sound-effects; the module player is an updated version of
code Sony sound guru Jason Page wrote for the original PlayStation.
Sample Rate conversion
Another key decision involved the handling of audio in the game. Apart from
the optional combo and level change sounds, chosen to fit in with all sorts
of CD track and with their own volume control, it's just your favorite music
that you hear as you're playing the game. So the CD audio replay quality is
crucial. Whereas other games typically hack and compress custom tracks to fit
them onto the game disc, we were determined to deliver the original 16 bit CD
stereo without compromise. In Dance Factory it's the music you choose and love.
CD Audio runs at 44,100 Hertz - 88,200 samples per second, one each for left
and right speakers - yet the PS2 hardware - unlike that of the original
CD-based PlayStation - works at a slightly higher rate, 48 KHz.
Without special processing, the original music would play a semitone or
so sharp, and faster than expected - much as film soundtracks do when
broadcast to a PAL television - on the PS2. Some people might not notice,
but we didn't want to mess with the pitch or the timing of your
music.
The maths gets rather hairy; for every 147 samples that come from the
CD, the PS2 outputs need 160 that follow exactly the same curve but at
a higher rate. The spacing between CD samples and PS2 ones wanders
back and forth 300 times a second, and the ear is very sensitive to
any 'jitter' that results from this variation, muddying the sound.
The PS2 console's own CD player uses the main processor to
resample audio, but it doesn't have to run a game at the same time -
in fact the built-in player animates little more than a single cube. So
another key bit of code I contributed to the project oversamples the
CD audio up to short-wave radio frequencies - over 7 MHz - generating
a precise stream of 32 bit floating-point data containing all the samples
at both the CD rate and the higher (DAT-based) PS2 rate, mapping exactly
between the two formats, for both left and right channels.
Unlike the analysis and dance generation, this is fairly standard
signal processing theory - though the choice of approach to this
quickly sorts out sheep from the goats, among audio programmers
- the challenge is to do it reliably, with high fidelity yet
negligible load on the console, which needs to spend most of its
time rendering and playing the game, not fiddling with samples.
Text entry
Another challenge was to give players an easy way to enter song and
CD names, since there's no text recorded on a standard music CD and
network look-ups don't work for typical PS2 users or any custom CDs.
In theory you can plug a USB keyboard into a PS2, but few players
have one and they require custom driver code and support for dozens
of different key layouts in the world-wide PS2 market. Besides, we
wanted to focus on dancing and gameplay, not peripheral shuffling.
The initial approach to text entry worked like a 'high score' table,
with the arrows on the dance mat or PlayStation pad moving a cursor
over a grid of characters and another press or step confirming each
entry. This is OK for short names, but tortuous for a whole album of
song titles, especially after allowing for punctuation characters,
regional accents, and other glyphs likely to appear in real song lists.
After careful analysis of several tech entry schemes, including the
many variants used on phone dials and keypads, I came up with an
approach that was easy to learn, three or four times faster than
the obvious alphabet-grid, and easy to customise for foreign accents
and punctuation variants.
The steps for some letters match those typically assigned to digits 6,
7, 8 and 9 on a phone keypad, but using the dance mat rather than a
phone pad. Since there's no button in the position where '5' appears
on a phone, the other letters are mapped to the four other dance step
directions, in the same groups - which are simply alphabetic, with three
or four letters to make the whole Latin alphabet fit on 8 buttons - used
in the text-messaging ubiquitous among the target audience. So familiar
sequences of taps - or steps - can be used to enter CD details, as if
they were part of a telephone text message, with the layout adjustment
necessary to suit feet rather than fingers.
Even then, special techniques were needed. The start and select
buttons - the only others on all dance mats - were allocated to
delete and enter respectively. To keep the average number of steps
down - and hence the speed of entry up - pairs of characters were
allocated the same position, when this made sense. In the English
layout you start with an open-bracket symbol; once you've entered
one of those (and are writing text in brackets) the same gesture
generates the matching closing bracket, without using up another
grid position. This compromise precludes entry of song names
with (nested (brackets)) or starting with a closing parenthesis
- ) we decided this was acceptable for songs, though it might not
be for programming!
This is a minor benefit when using the simple unaccented English
alphabet, but very handy for other languages, where the characters
normally used for quoting text are different before and after the
quote, or in Spanish where questions and exclamations are similarly
bracketed. We ruled out the idea of making one grid with all the
characters for every language on it - that would just be lazy -
so the initial choice of language selects a custom set of extra
characters. French players don't have to skip over umlauts to
find the accents they want, and tildes, circumflex accents and
other national variants appear only when needed. Accented
characters are allocated by vowel and diacritical mark to
specific rows and columns in a logical way that makes it
easy to learn (whether you notice the organisation or not).
Other characters are in the same place for all languages.
Again, this involved some compromises - relatively obscure symbols,
such as the Welsh accented 'w' (sorry, Broadsword!) are absent,
CAPITALS and lower-case letters are equivalent (throughout the
game) and if you want to enter a name with characters not native
to your locale you may need to switch language setings to do so
- but I think we've acheived the aim of having a consistent way
to enter all the text most likely to be needed, in a familiar way
that's easy to learn, with no special tricks or extra steps (sic).
Once you've entered the names for a disc you can share the
game save file with your friends, along with the analysis, so
they can get straight on with the dancing!
These details help to make the game viable and fun, but could detract
from the main point - a game that makes fun dances from your own CDs.
Luckily most of the reviewers - apart from a few DDR diehards for
whom any changes from the arcade formula would be unwelcome - picked
up on that, so Dance Factory has had some great reviews:
BBC National Radio 1 (Sarah Cox show, 11:53 am, Tuesday 2006-08-15)
"Dance Factory on PlayStation 2, Now this is brilliant! Dancing games - these ones you
buy the dance mats for - Dancing Stage has been the key series for years. And what you've
never been able to do on it is use your own music.
And this time, for the first time, you can take any CD in your collection, put it in the PS2,
and it generates dance steps for you on the fly, or you can make your own. Now, I've been
trying this out at home, and ... it works really, really well..."
[Cox, giggling]: "Tried Radiohead or something?" [Minkley]:"...I tried it with Paranoid
Android and it threw it a bit, but then I actually went in and I worked out my own dance
steps along to Paranoid Android and it's brilliant! ... You can do your own steps, it will
record it, then you play it back and you're just bouncing around to all the guitar bits
and stuff and it's just superb fun.
So if you've ever liked this type of game before, but you've always felt restricted by the
songs on there, I mean, this opens up your entire record collection ... it's just brilliant,
this is really really good fun."
Veteran games journalist and editor of Eurogamer TV,Johnny Minkley
Full review (MP3 audio format, 350K)
Game Informer (Leading US magazine total paid circulation 1,934,859 in 2005)
I'm going to go out on a limb here and offend a lot of DDR purists and tell you
that this is the dance/rhythm action game you should play this year....
So what's the deal? Dance Factory can take any CD you put into the PS2 and
transfer all or any of the songs to danceable tracks - and I'm not talking
cheap, non-rhythmic versions. The newly created dance tracks firmly match up
with the song rhythms, especially if you find music you'd actually dance to
in real life. The feature works great, and often creates some stellar fun
from music that (gasp!) you'd actually want to listen to! Score: 8/10
The Times (UK national newspaper, September 16, 2006)
Although they are guaranteed to deliver a few laughs and lots of energetic posturing,
the failing of most dance mat games is the dire selection of twangy hits licensed for the
experience. Even Dance Factory comes with just five saccharine offerings, but then turns
the genre on its head quite magnificently by allowing players to import their own CD
tracks for fancy footwork treatment.
It is not an especially fast process, with a four-minute track taking about a minute to
convert for dance mat use, but the options that it brings are limited only by the tracks
in your CD collection....
The package also boasts some nifty secondary ideas to help to extend the title's
replayability, such as a Fitness mode for calorie counters. Meanwhile, the multiplayer
games include a knock-out tournament that can accommodate 16 players in rotation. An
instant classic.
Tim Wapshot Score: ***** (5 stars, the maximum)
Full review
Gaming Age (online magazine)
No matter where your loyalties lie in the DDR world, there is no denying that Dance
Factory is taking the right steps (no pun intended) in designing new ideas that the
group of thinkers at Konami haven't come up with yet.... What Dance Factory brings to the table
is new features that improve the genre, along with recreating already popular and proven
modes for fans of the series.
What has gamers coming back is the music and the basic fundamentals of addicting game
play. Dance Factory will not let you down as this game is every bit as fun and enjoyable
as DDR, but it is the features that will make you go hmm...
Yes, Dance Factory has a solo mode, multiplayer mode with elimination and tournament
rounds, and even a cardio calorie-burning mode for the vain and/or overly sensitive. What
sets this game apart is the track listing. You have five songs to choose from including
"I Like It, I Love It" from Tim McGraw, "Get Down On It" from Kool and the Gang, "I Like
the Way" from Bodyrockers, "Pon De Replay" from Rihanna, and "Don't Cha" from the
Pussycat Dolls. With a track listing like that, how long do you think it will take before
you are sick of these songs? Well fear not true believers, as the developers are not that
lazy or stupid, in fact they are geniuses as they have implemented an option yet seen in
a dancing title until now.
With Dance Factory, you can use ANY music CD as your track listing. Think of it as
Monster Rancher for the Dancing Genre. Your dance beats, backgrounds, and routines
are generated to fit the song you have loaded into the PS2...
If it has a beat, you can dance to it. This allows for the most eclectic soundtrack
known to man, as the possibilies are limitless. Sure, we all know some of these bands
are not really made for dancing, but at least no one can tell you that it CAN'T be done
Brian Peterson Grade: B+ Great
GameSpot.co.uk online review
Finally a dance game where you can dance to your own favorite music.
Dance Factory features a CD recording mode that captures the beat of the song and creates dance
patterns to it. You can use original CDs or your own burnt compilation CDs of your favorite
tracks. It takes about 10 minutes for the software to create patterns out of a whole CD...
It can generate 1/1, 1/2, 1/4, 1/8 and double steps; no 1/16 steps, but you can create 1/16
steps by recording your own dance pattern. However if your chosen
music has a distinctive beat, the created patterns will probably follow it quite strictly....
You can also record your own steps... This is actually quite fun and it works pretty well, you
just let the music play and you jump on the dance mat, making your own patterns... The coolest
part is that you can finally use the dance mat with your own music. Good game, worth a try.
Difficulty: Just Right
Learning Curve: 30 to 60 Minutes
Time Spent: 10 to 20 Hours
"Worth playing"
Other comments from players: "Highly addictive"; "massive replay value"; "THIS GAME IS AWESOME!!!! GET IT!"
Full Review on GameSpot
GamesTM (Imagine Publishing, UK news-stand game magazine, Oct 2006, p.115)
Codemasters delivers the ultimate dance mat package
Dance Factory's rather ingenious USP is that it allows you to put any
CD into your PS2 and it will convert it into arrows for your dancing pleasure.
Simple, but absolutely superb.
And it works. After experimenting with tunes from Rage Against The Machine, Air,
Metallica, Sway and even a bit of classic old-school house, it would seem Dance
Factory cannot be beaten.
Using the same technology that fueled Vib Ribbon, the game picks out beats
immaculately, creating combo opportunities at every turn.
Obviously, not every tune you pick will lead to a perfect 'dance', but half the
fun of Vib Ribbon was finding which tunes worked best, and the same can be said
of Dance Factory.
This is a game that's all about innovation, and this is the only way that
Konami's dancing games could be bettered. Dance Factory is a superb product
that deserves to be noticed, and as such Codemasters should be commended.
8/10, Raises the bar for Dance Mat games
Imagine Games Network (IGN) online review
Codemasters' entry in the dance mat rhythm action genre and a game which does away with the
pointless faff of licensing half a dozen songs so infuriating they make you want to stove your brain
in with the sharp end of your DualShock. Instead, its single, and utterly genius, gimmick is that
you can slap in your own CDs and dance around like nobody's business.
In fact, if you've played and enjoyed any type of dance mat game before, that's probably all you
need to know about Dance Factory - oh, and that it works brilliantly.
CD collection withstanding, Dance Factory is just about the best dance mat game you're
going to find on PS2 - thanks entirely to its impressive track conversion capabilities...
with its potentially limitless song list, you may never need to buy another dance mat game again.
Best of all, it's an incredibly simple process - slot your CD into your PS2 while in the game,
select the track (or tracks) you want to convert and - shazam - Dance Factory's off like the
clappers. It's all very clever and, by and large, works brilliantly. During our rigourous tests, we
threw a veritable smorgasbord of stuff its way. Impressively, Daft Punk, Pulp, Mint Royale, Muse and
Kenickie (okay, we haven't really bought that many CDs since the 90s, but we'll get onto that in a
moment) all magically transformed into perfectly playable dance-offs.
Overall score 8.5/10, Great
Full Review on IGN
SPOnG VideoGames database review
SPOnG was lucky enough to be the first bunch of journos in the world to actually have a bit of a gawp
and a bit of a jiggle around with mind-blowing dance mat game, Dance Factory.
Why mind-blowing you ask? Well, simply because you can insert your favourite CD and the game will
generate dance moves in time to your favourite tracks. Pure genius.
...When we first heard about the Dance Factory concept, "it can't work, surely?" and "nice gimmick!"
and other such phrases were being bandied around the office when the game was first announced...
Well here's the good news - our ingrained northern cynicism was totally unfounded. It actually
works! ... it's the best dance mat game ever developed"
Full Review on SPOnG
BBC Focus magazine, November 2006
"Without hyperbole, this is the best thing to happen in all the universe, throughout history,
since we emerged from the primordial ooze... if you've never danced to Morrisey while having
your PS tell you you're a big fat sod, then you've missed out on one of the definitive human
experiences.
Mark Blackmore
These 2007 releases use my CMStream game audio library for surround sound and DSP effects,
on all four platforms. This is the first outing for cross-platform system programming work
I've been doing since completing CMR5 in 2004. I gave a talk about this at the Games
Developer Conference in San Francisco in March 2007. Follow
this link for a summary of the talk and further links to downloadable videos of what
I had to say (parts three through seven of the 'Cross-platform OpenAL' presentation).
Brian Lara Cricket 2007 combined the PS2 audio and streaming work I contributed
to the previous hit release with new code, built upon OpenAL, for Microsoft game
platforms. It was the first version of Lara with surround sound, using layers of
reactive crowd ambience, as well as positional sounds from the pitch.
A few months later rally driving game DiRT added support for Sony's latest console,
including 7.1 channel sound with Ambisonic panning and full surround reflections,
and went to number 1 in the UK PS3 chart. DiRT got great reviews and attracted
awards for the game in general and the audio in particular.
Over 12,000 readers of German news-stand magazines GamePro and GameStar voted
Colin McRae DiRT 'Best PC sports/racing game' of 2007, beating off the latest
versions of two other long-running franchises: Koanami's Pro Evolution
Soccer 2008 and EA's Need for Speed: Pro Street, and the Spike TV
awards voted DiRT 'Best Driving Game'. Specifically in audio and regardless
of genre DiRT was pipped into second place (alongside Marty O'Donnell's Halo 3)
in EDGE magazine's annual 'Best Audio Design' category, losing out to Mario
Galaxy on the Wii - which indeed has stunning audio, though very different
in style. I'm proud to have worked with Stafford Bawler and Adam Sawkins,
lead audio designer and game audio programmer respectively, on that game.
This is the latest outing for CMStream and scales the tech developed for DiRT up from
intense single-car racing to a full grid of 20 cars, involving up to a dozen human players
at once. I'd contributed to the audio on TOCA RaceDriver 3, mainly on codec and DSP
aspects of that game, but was not much involved in the game programming. GRID builds on
the code I wrote for DiRT and Cricket, substantially extending it to include streaming
features which were in the original CMStream for PS2 and Xbox1 (developed with Jon
Mitchell) but had not previously been necessary on later consoles with far more RAM
and more effective codecs.
Since random access to spiral-recorded optical discs is not much faster on PS3
and Xbox360 than it was on the previous generation (or older CD consoles, for that
matter) it's harder to justify nowadays, especially when games like GRID also stream
high-resolution graphics from the disc as they run. But with eight-layer interactive
music and a vast speech database, any phrase of which could be triggered at any time,
GRID could not fit all the main game audio into RAM even on a half-gig console, and
so CMStream introduced reams of extra code to bring streaming up to scratch on new
game systems. This time I was assisted by two other experienced audio programmers,
recruited from companies spun off from the former EMI Central R&D labs - Aristotel
Digenis and Pete Goodwin (no relation).
So Codemasters Central Tech Audio is now a team of three, rather than a one-man
band, and we are working on new DSP, tools and related systems for Codemasters
EGO game systems, the latest incarnation of the Neon cross-platform engine and
the tech behind several games now in development. Watch this space...
Meanwhile, here's some in-depth information about GRID audio
GRID takes the advanced audio systems used for single-car rally racing
in DiRT and extends those to model 20 vehicles racing at once - mixing
760 sound sources for the cars alone, PLUS music, collisions, damage,
crowds and many other ambient sounds.
GRID plays several banks of interactive music, eight layers deep,
positioned in surround around the player, adapting to their performance
and position in each race. It also tailors the crowd sounds on the fly
to cheer or boo depending upon what you and other players have recently
done (whereas the 'interactive crowds' in Colin McRae 2005 only varied
from one stage to the next, depending upon championship performance).
As well as more than an hour of sounds instantly-accessible in memory
and mixed on the fly - extending the intricate system used in DiRT - GRID
seamlessly streams context-sensitive speech and music, as well as graphic
data, from disc as you play the game, squeezing yet more varied audio
from the console or PC hardware.
GRiD uses well over 100 simultaneous audio filter and reverberation
effects to further tailor each sound to its context and player activity.
This ensures that the game sounds vary as you play and the differences
can make a difference to how you play, by telling you more about what's
going on in the race, especially and most importantly off-screen.
GRID audio systems use sub-bass Low Frequency Effects and controller
shocks together - what we call 5.1.1 sound - for crushing impacts and
rumble strip feedback that you can really feel as well as hear!
GRID now uses Ambisonic techniques for immersive surround on Xbox360 as
well as PS3. Ambisonics were developed by Oxford mathematician Michael
Gerzon in the 1970s and have since become the focus of 3D surround sound
research worldwide; Gerzon's original work was funded by the UK NRDC
(National Research and Development Council) and the trade mark and
patents (now lapsed) were bought by classical music recording company
Nimbus. But like Alan Blumlein's pioneering work on stereo at EMI in
the 1930s, it has taken decades for hardware makers to catch up, and
games - rather than cinema - appear to be the 'killer application'
where precise surround - rather than vague ambience - is crucial.
In brief, Ambisonics means all the speakers work together to create
realistic soundfields, rather than just picking the nearest one or two
for each direction - a difference that really has to be heard to be
appreciated - once you've heard Ambisonic surround, typical cinema and
game panning just sounds fake (which it is).
Almost all the sounds in GRID on PC are in uncompressed PCM format - so
at last players can hear the sounds at the full quality of our original
recordings (especially with X-Fi advanced mixing and effects). Even so,
close collaboration between Codemasters and Creative Labs, developers of
the most often-used OpenAL drivers, mean the sound systems in GRID are
far more efficient than those in DiRT and the full audio design runs
even on minimum-spec PCs without significant impact on the frame
rate.
Yet PC specs march on, and GRID is one of the few games that takes
full advantage of quad-core systems and the latest multiple GPU
configurations. So if you've got all the latest hardware - necessarily
including an X-Fi with the EMU20K DSP chip and good headphones with
CMSS 3D or 7.1 speakers - the PC version of GRID can now outperform
the current generation of consoles. In practice they're all more often
limited by the listening environment and speaker systems than by the
audio tech in the game - but if you really care about sound we've done
the work that'll make your system sing - and you can be the conductor!
© Simon N Goodwin, Warwick 2005..2008, and reviewers
Link to the top of this document
Link to the article index