The Quicksilver Blog

The Quicksilver Story: Chapter 9

Fri, 24 May 2024 08:00:00 -0700

Welcome to Quicksilver!

This is the ninth post about the story of our company. You can jump to the beginning here: The Quicksilver Story: Chapter 1 and to the previous chapter here: The Quicksilver Story: Chapter 8–>

Our story is four decades long, and still going strong. It involves more than 50 games for numerous different publishers, and a number of military training apps that leverage our game-design and educational-game background. Here we will cover the second part of that story: our award-winning logistics training software.

Military Applications: Distribution Management Cognitive Trainer

Our largest and most successful military software project was known by the delightful acronym DMCTI: the Distribution Management Cognitive Training Initiative.

Pretty much every military trainer we did had an alphabet soup of a name, but this was a real mouthful.

The goal here was to train logistics specialists. An army needs supplies in order to fight, and logistics personnel see to it that they have what they need when they need it. It’s a critical and complicated job, but not always immediately rewarding. It involves reading reports, finding available transports, monitoring road safety and closures, and dealing with sudden changes in requirements. The Army developed standardized planning and reporting software, so we had to replicate its key functions in our app.

A quick observation: one of the most jarring aspects of this project, for us, was the visual aspect of the Army's logistics software. It was truly ugly: garish in color, brutalist in layout, awkward and overly difficult to use. Coming from the perspective of an industry that prides itself on visual excellence, we were somewhat taken aback by the screens that we saw. Not to say that DMCTI is as pretty as a video game. It's not. But the contrast between the app's screens and the simulated reports is pretty dramatic.

How do you make this subject fun? That's quite a trick. Moving pallets of toilet paper, bottled water and artillery shells is not exactly gripping material. It's also a high-pressure, low-reward job, where folks only get noticed when they make a mistake. Stakes are high -- not getting bullets to the front line could have serious consequences. But how could we make our trainees want to learn how to do it?

Games are storytelling, at a fundamental level. We’re creating a world, weaving a compelling tale, and inviting the player into that world. As designers, therefore, we look for the story in any situation. We look for ways to weave the subject matter into a coherent and compelling tale where participants are eager to see the next chapter. We’ve talked previously about how we turned a series of typing lessons into an adventure in Type to Learn 4. Military trainees have a different approach than elementary school kids, so first we had to learn to think like they do.

Military personnel like to demonstrate that they’re good at what they do – whether it’s combat or logistics. So we turned our training lessons into puzzle-solving exercises. We challenged the trainees to show off their ability to fix situations that had gone sideways and to avoid traps that had been laid in front of them. Could they still get everything where it needed to go when a bridge was blown up? Or when a sudden additional need arose at one of the forward bases? We put them in the middle of interesting stories, and they eagerly competed to find the best solutions.

DMCTI is a great example of taking an ostensibly “dry” subject and breathing life into it. We’ll see another example later, when we talk about The Game of Tradeoffs that we did for the Naval Postgraduate School. In this case, we had a great deal of help from our Army SME (“Subject Matter Expert”), who absolutely loved telling us stories of his many exploits in various combat theaters around the world. We eagerly listened to many hours of tales about operations gone awry, troublesome people and crises averted. He brought a deeply personal depth to the content that would not have been evident at all from the Field Manuals and reports alone.

How do you add engaging videos to such a product?

This tool needed to be able to be used "on laptop on a mountaintop in Afghanistan" -- in other words, on a minimally capable device, running on battery power, in a place where there was no outside connectivity. The laptops used by the Army at that time were very basic Lenovo/IBM business laptops with zero 3D graphics capability. We couldn't do pretty, interactive videos.

We used a trick we’ve used several times before: we did pre-rendered videos instead. We were able to use all of the advanced tools in desktop rendering packages (smoke, particles, and excellent lighting) by spending many hours rendering and then compressing the videos at an appropriate resolution. We made numerous variations of the videos to match the options that the user selected (time of day and number and types of trucks in a convoy, for example). Then we simply looked up the video that matched the scenario and played it back at the appropriate time. It worked perfectly, and looked great even on a low-power machine.

One of the first things our team did was travel to a training base where we learned how the Army’s logistics software, called BCS3, worked. We took an accelerated course because we just needed to know the reports, but didn’t need the “buttonology” – which buttons to press to make it work.

That’s an important lesson. Trying to simulate everything about a given process is impossible. The designer has to choose carefully what is to be included and what can be abstracted away. In Full Spectrum Command, we abstracted the combat mechanics. We didn’t simulate every bullet; we literally rolled dice to determine combat effects. For this product, we decided to replicate the BCS3 reports, but to simply let the user press a single button and get the report that would require a sequence of commands from the real software. We had to focus on reading the report, not on the buttonology of how it would be obtained.

Similarly, we had to decide how much of a simulation would be required in order to make our lesson plans work. We decided that, since the typical logistics cycle is 72 hours, we would need to replicate events during that time, and therefore needed at least a semblance of real-time tracking for each vehicle. This was made even more necessary by the possibility of random events causing changes in plans.

Still, there had to be limits. This is where our game design background helped again. There are tricks for making a user feel like they have complete freedom while actually constraining their actions to a subset that you want to allow. We sometimes describe this as “building a foot-think plexiglas wall in the world.” We make it look like the world goes on forever, but in fact you can’t get beyond certain hard limits.

In this simulation, we had to prevent the trainees from just “calling in the helicopters” when a road got blocked; that’s not always a solution, and we wanted to make them do it the hard way so they’d be prepared when the situation cropped up in the real world. So we grounded all of the aircraft. Similarly, we limited which bases would get resupplied from outside the theater of operations, both to keep our design simpler and to prevent Captain Kirk’s solution to the Kobayashi Maru scenario (non Star-Trek fans: look it up. He cheated).

Likewise, there are too many different commodities for us to be able to simulate all of them. Besides, we don’t need 100,000 different items to teach lessons about planning, coordination, and how to read orders carefully. So we chose a small subset, ranging from several kinds of ammunition to bottles of water and, of course, toilet paper. This actually makes sense to logistics personnel, because there are separate “desks” that handle specific commodities, so we just explained that the trainee was assigned to a desk dealing with these specific items. Piece of cake.

There was an additional twist: the software had to not only simulate behavior, but also monitor the trainee’s actions and score them based on whether they solved the puzzle correctly. After that, it also needed to recommend specific sections of the Field Manual to review for remedial help. In effect, we needed to put the instructor inside the machine somehow. The solution to this was quite complicated, but it worked perfectly:

Define every possible skill that the logistics trainee needed to learn. This turns out to be easier than it sounds, because our incredibly talented SMEs had already done this as part of their classroom work. We modified their list, trimming it to the subset of actions we needed to train, and ended up with a list of about 100 “Terminal Learning Objectives” (like “Leadership”) and “Enabling Learning Objectives” (like “Understand Radio Frequency Identification Device (RFID) Systems, capabilities and employment”.
Working with the SMEs, define a set of ten scenarios that would each highlight just a few of these TLOs and ELOs. Make sure the language is authentic. Then prioritize them so we could pick just a few and build a good story around them. And be sure to note which supporting documents contain descriptions of the task.
Again, with SME input, list all of the tasks the trainee should be performing to accomplish this mission. Draw a one-page flowchart depicting the order in which the tasks need to be done. Some can be done in any order (review three reports), but you can’t assign trucks until you first check to see if they’re available.
Here’s the cool part: now we assign Learning Objectives to each task in the flowchart, so that we know what skills are required to complete the task correctly. If the trainee fails to perform a task in the right order, that’s a failure, and we can score it accordingly. Plus, since we’ve defined which pages in the Field Manuals apply to each task, we know what reading material to recommend – no “AI” needed.
But it gets better: we designed the scenarios very carefully, so there were only one or two viable solutions. Then we hid the best option by providing additional information that looked helpful but in fact closed off certain options (trucks available, but on the wrong day, for example). We therefore knew for sure that the trainee would have to choose either ten or twelve trucks from this one base to get the commodities where they needed to be, and any other option was a failure. So we could grade the result reliably and automatically – again, no “AI” needed.
The result of all of these careful design decisions was that we could create a customized, actionable evaluation of the trainee’s performance, complete with a printable list of review items, if any.
The trainee could “drill down” and see details of each item that either passed or failed.

Designing simulation-based scenarios isn’t simple, especially when complex timing relationships are involved. We had to create an entire simulated world with several forward bases, several supply bases, and a network of roads between them, some of which were unsafe, dangerous or simply unavailable. Then we had to define which commodities were needed at each location and create pre-existing convoys that were already taking those items to them. We tested these to see if they actually worked. Then we “broke” them by closing bridges or changing requirements so they could be used as the basis for our lessons.

Managing this much data was a huge challenge, so we created a spreadsheet to structure all of the details. For each scenario, we created, in addition to the items discussed above:

a list of the simulated reports that would be available
lists of routes with distances and statuses
lists of commodities and their locations
lists of available vehicles (with times)
a list of all active convoys (typically about 50)
a list of transportation movements that had been requested
and a number of smaller, supporting tables

We are tool builders. And we believe in the “lazy programmer” theory of software design: the best programmer is one who wants the machine to do all of the work and invents time-saving tools to avoid tedious manual efforts. Naturally, we designed this entire spreadsheet (1,000 lines x 100 columns per scenario) to be exportable to data files that could be used directly by the code. Visual Basic is a strange and quirky language, but it worked great at converting our complex tables into data files in XML format.

The first scenario took six months to build. The second one took three months, and the third one a single month. The other seven were done in about a week apiece. Because we’d laid out such a powerful framework, constructing the later lessons simply required permuting some of the earlier ones and tightening down the challenges.

D E S I G N N O T E

Easter Eggs

One of the fun traditions of the video game business is adding "Easter eggs" to games -- clever, often amusing hidden features. Management is often aghast at such things; people have lost jobs because they put Easter eggs into their games. Mattel Electronics was very guarded about employees, including their names, so they had very strict policies against adding Easter eggs to cartridges. Nevertheless, some did slip through
When it came time to create videos for DMCTI, we couldn't resist adding an appropriately themed Easter egg to the software -- one that would add a little levity to the training. One of the scenarios involved a missing Humvee, so we decided that it had not in fact "gone missing" but had instead been abducted by aliens. We rendered a movie (which we won't show here) of the UFO flying up to a vehicle on a dark road at night and "beaming it up" before zooming away. It was hilarious.

Modern publishers and clients are more accepting of the practice of incorporating Easter eggs into products. However, they do expect to be notified of their existence. And that's perfectly reasonable. We had a formal meeting to discuss this with our Army representatives, explaining the meaning of Easter eggs and then showing the specific one we'd designed for the game.

They saw that it was indeed tasteful, appropriate and even integrated into the story, so they approved it.

The last scenario was designed to be the true test of the trainee’s ability. It involved sending multiple classes of supply from multiple supply ports to a forward base. But there was an extra twist: the obvious and simplest solution wouldn’t work, because it would disrupt convoys going elsewhere and get the goods to the base too late. A very careful reading of the mission orders was required in order to discover the proper solution.

We sat down in a conference room at ICT headquarters with our Army SME and the main Army procurement officer. We set a laptop in front of them with the final scenario set up, and walked them through the briefing. Forty-five minutes later, they had worked out a plan that they proudly announced would break our scenario. Great job, team. We then had them start the real-time simulation. Two simulated days later, they got a big, red error box – the necessary supplies had not been delivered when needed. They flunked! They were shocked, until we explained their mistake: they’d misread the reports and sent the right stuff to the right place on the wrong day, falling right into the trap that we’d set for them.

They approved the final milestone with no changes.

DMCTI won the 2008 Army Modeling and Simulation Award for Training. In its announcement, the US Army said:

"The Training Modeling and Simulation Award for 2008 is awarded to the Distribution Management Cognitive Trainer Project Team. The Team is commended for developing a Personal Computer, game-based training tool, that is being used to train US Army logistical planners on exploiting the capabilities of the Battle Command Sustainment Support System, the capabilities of logistics information management systems, and training the key principals of Distribution Management to improve the analysis, mission planning, and decision making skills of tomorrow’s logistical leaders.

"This effort demonstrated how to effectively design, develop, and use game technology to enhance training opportunities for Soldiers. It has been successfully integrated into formal Distribution Management training courses and was fielded to Battle Command Sustainment Support System users Army-wide beginning in 2008. The project demonstrates that modeling and simulation tools can be used to support training in institutional, operational, and self-development domains. The efforts of the Distribution Management Cognitive Trainer Project Team reflects great credit on themselves, RDECOM Simulation & Training Technology Center, and the United States Army."

Coming Up Next: Chapter 9 – Going Mobile

While our Army work was going strong, we also realized that a major new technology was reaching the public and would have a dramatic effect on game development. We decided that it was time to enter the mobile game market.

Looking For a Top-Notch Team to Solve Your Impossible Problem?

Let’s talk! We love to take on new challenges. Tell us what you need and we’ll let you know how we can help.

You can reach us here: https://www.quicksilver.com/contact.html#contact.

For more information:

You can find us on the Web at www.quicksilver.com.

The Quicksilver Blog: Careers Part 1

Mon, 20 May 2024 08:00:00 -0700

Welcome to the Quicksilver Careers Blog!

Let’s talk about careers in the video game and independent software development business.

Are you dreaming of an exciting career developing video games? Or being part of a rocket-ship of a technology startup that’s sure to change the world? Or starting a company to pursue your own vision?

Before you spend a lot of time and money training for such a career, consider carefully whether it’s the right fit for you. Being part of a high-tech company, whether small or large, can be exciting and rewarding. But it can also be a miserable, demoralizing and financially damaging experience. It’s a challenging business. If you’re looking for a steady, comfortable 9-5 job, this isn’t it.

In this career-focused series of posts, Quicksilver’s president and founder, William Fisher, will discuss in detail what the business is like and how to know if you’re a good fit for it, and tell stories from his decades in business to highlight key points along the way (you can find out more about that in The Quicksilver Story: Chapter 1).

The Business of Games

The video game business can be brutal. Projects are extremely complicated, expectations are through the roof, and time is always the enemy. On top of all that, the hardware is never powerful enough to do what you want. Sound scary? It is.

That’s not to say that it’s a terrible way to make a living. It’s just that you need to be realistic about expectations. Don’t expect everything to be coming up roses. Know what to expect, and you’ll be better prepared for what ends up happening.

Here are a few key observations about how the game business works:

it’s not all fun and games. If your idea of being in the game business is that you’ll be playing around all day, think again. There’s serious work involved. It’s often fun to do that work, but it’s still hard work and sometimes it can be really tedious.
along those same lines, it’s a lot harder than whatever you did in school. The problems are far more complicated, and the consequences for failure are far more dire. School projects usually exist within safe “walled gardens” in which real-world complexities are abstracted away. In the real world, you’ll need to deal with communication errors, corrupted databases, oversized audiovisual assets, and any number of other issues that will take time and careful analysis to resolve. And a bad design could cost you or your entire team months of rework. So the stakes are high. A simple architecture diagram for an online game might look like this:
resources are always insufficent. We can speak to this with confidence, having started out on a machine with an 800 kHz CPU and sixteen colors, then graduated to numerous generations of PCs, consoles and mobile devices. Expectations rise as hardware power increases, and expectations are almost always far more ambitious than they are achievable. This is the fun part of game development for many people – making do with whatever resources are available, and delivering amazing experiences anyway.
the development environment is sometimes chaotic. It’s not uncommon for design concepts to be incomplete or keep changing after they’re handed to the development team. Likewise, upper management doesn’t always schedule resources properly or completely, so gaps can suddenly develop and require emergency resolution. These projects are so complicated that we humans simply can’t anticipate everything in advance.
work is often deadline-driven. In a perfect world, code and graphics and sounds would be done when they were perfected. In the real world, a certain amount of work needs to get done in a very specific amount of time. Deadlines are often tied to trade shows or holidays, and those aren’t going to move. The result is “crunch time” – the need for the team to spend far more than 40 hours per week to get it all done. Some teams handle this well. Some don’t. This can lead to poor work-life balance and burnout.
work is also often project-centric. Teams are assigned to a specific game. When it’s done, they’re done. The company can’t afford to keep large numbers of people on board while it decides what to do next, so furloughs are common. In the game business (as in many of the performance arts), jobs are often short-lived. This makes planning for the future a big challenge.
it’s amazing when the public finally gets their hands on your work of art. Sometimes they love it. Sometimes they hate it. And most of the time it’s both at the same time. Learn to accept the praise and learn from the criticisms. There are few professions that can give such powerful feedback. Enjoy it when you can.
there may be a buildup of “technical debt” on the project. This term describes a situation in which the team has created something that works, but just barely, or just in certain situations, and that isn’t as robust or generalized as it really should be. We were actually hired once for the express purpose of reducing technical debt on a very large game. Six people spent a year making improvements. We did fix a number of things, but there were still many more left un-done. This is a real quote from another project we were hired to finish:
management isn’t always in touch with the teams and their needs. They’re often driven by forces outside the company – forces that don’t make sense to the team but nevertheless influence what they do. The net result is that management may make seemingly arbitrary or poorly informed decisions. Perhaps they’re not, but perhaps they’re indicative of a real failure at the top. We’ve seen cases where a company leader commanded that a certain goal be met, despite being told that it wasn’t possible. The results were as ugly as might be expected.

We’ve focused here on the dark side, because it’s important to be realistic about what happens in game development. It’s often frustrating and not entirely satisfying. But there are rewards, too. Game designs or individual systems come together in amazing ways. Fans love a product and buy even more copies than expected. Reviewers are thrilled and sequels are ordered.

It’s a roller-coaster ride. If that’s what you want, then read on. If not, best get off the ride before things actually get crazy.

Choosing a Game Career

So – after hearing what this business is like, you’re still eager to plunge ahead? Great! Now let’s talk about whether your background, skills and interests are a good match.

As in any career, you’ll be happiest when you dedicate your time to things you’re good at doing and enjoy doing. But this business demands even more. To be successful, you need to stand out from the crowd – to offer a unique set of skills that make people want you on their teams. And that’s where things get interesting.

1. Depth

Have you watched the original Star Trek shows? Those classic episodes include ship’s engineer Montgomery Scott, who was so dedicated to his job that he enjoyed reading technical manuals in his free time. Scotty may have been intended as a caricature, but in fact he’s an excellent example of the sort of personality that does best in a highly competitive business. You might just find that such an obsessive level of attention to detail can make or break a project, as shown in the real-world examples below.

First, though, let’s define what this means, in a practical sense. When we talk about having “depth,” what exactly are you supposed to do in order to achieve that? And why should you go through all of that effort? A few examples:

as a graphic designer, you learned Photoshop and Illustrator in school. You can make an image that looks pretty good. But: do you know more than just the basic features of these programs? Do you know how to use all of the effect layers in Photoshop? Do you really understand how layer masks work, and how all of the different blending modes work? You should know all of these things – because your co-workers probably do.
as a programmer, you know a few languages. That’s fine – but having a long list of “known” languages is not necessarily better, if all of your knowledge is superficial. Anyone can write the easy stuff, especially nowadays, with lots of samples on the Web and AI assistants who can provide entire functioning modules in moments. But do you understand advanced concepts like asynchronous functions/promises? How about memory allocators and garbage collection? About how to properly set up a database?
as a sound or music creator, does the tool define what you’re doing, or have you learned to imagine the sound that you want and then found a way for the tool to create that for you? Are you dreaming of amazing soundscapes, or just dialing it in and hoping it’s good enough?

Now let’s look at some real-world stories – how true depth of understanding, or lack of it, caused problems in projects we’ve done or seen:

Let’s start with an example of a failure to understand important aspects of how a Web-based server works.

T R U E S T O R Y

Junior programmer collides with asynchronous Web server

We had a project that required saving images to a Web server in the cloud. This involved potentially multiple uploads from different devices at the same time, and also needed to support editing of the gallery, including deletions.
Implementation of this feature fell to an intern programmer. He was smart but inexperienced, as are many folks still in school. He wrote a functional system on both client (Android) and server (PHP). Pretty good. And, superficially, it worked, so the first client demos went well.
However, when we did an internal technical review, we identified weaknesses in the design. First, the programmer had failed to consider the asynchronous nature of the Web server. Multiple requests can come in at the same time. If two uploads happen close together, then the code that assigned image numbers would generate two images with the same number, causing one to be lost.
Second, his mechanism for deletions involved removing one image and then renaming every subsequent file on the server. This wasn't practical. It would take a long time. Plus, it would cause cached images to break, since the cached data would now be completely different from the current image. Finally, it would explode in a huge mess if a new upload happened during the renaming process.
The root cause here was that he didn't really understand that the Web-based server was multithreaded and that many things could happen at the same time. He was thinking in a purely linear manner -- a common failing among newer programmers. He assumed, incorrectly, that all sequences of operations would complete, without errors or interruption, before others could take place.

Lesson: Modern systems can be really complicated. They may appear to be simple, but they sometimes hide subtle issues that don't show up in early testing, such as what happens when more than one event can happen at the same time.

Next, let’s switch to a class of artwork-related problem that we’ve encountered more than once.

T R U E S T O R Y

Artist missing fundamental technical understanding

We were working on an old-school phone project. Storage was at a premium, so compression of bitmaps was important. Also, this particular device had a very limited graphics subsystem using a color lookup table, and we only had a small number of color slots available for the background image.
So far, so good. We asked our artist to create a background image for a scene, with the requirement that it use no more than 32 colors. That should have been enough, but it wasn't.
The artist did not understand the concept of color depth. What we got back was a very pretty RGB888 gradient. It looked great on a PC, but was completely useless on the actual device. Because this artist did not understand the concept of a lookup table or of "bits per pixel", the entire effort was wasted, and we had to go back and do it again.
While it's true that artists are not programmers and therefore not technical by nature, it's essential that they still understand how their tools work. Not every system has RGB888 or higher color depth, even today, and that will remain true in the future on certain low-end systems or when creating complex textures for a 3D renderer. It's no different than recognizing why charcoals differ from watercolors.

Lesson: Just as a race car driver needs to understand the extremely technical nature of how power gets to the wheels and when to shift gears optimally, every artist needs to understand the extremely technical elements of their tools, including everything from bit depth to color gamuts to resolution.

There’s a related tale of error propagation in JPEG images, but we’ll save that for another day.

Moving on to another classic problem, here’s we look at why it’s important to understand what happens behind the scenes in your app, instead of just assuming that it’s magic.

T R U E S T O R Y

Garbage collection -- worst-case scenarios

Award Maker Plus was a beautiful product in its day (the late 1980s). It could print very pretty awards and certificates, including those gorgeous borders, on just about any printer. That was painful, because every printer was different. But what was even more painful was trying to squeeze high-resolution bitmap graphics into the teeny-tiny RAM footprints of the machines of that day.
What's the #1 thing you see on a typical certificate? A gigantic banner that says "Congratulations" or "First Prize" or some such, and right below that some more really big text with your name in a fancy font. By today's standards, those things are all tiny. But on a DOS computer with 640K of RAM, it was another story entirely.
Those graphics were so big that they didn't fit in memory all at once. We had to chop up the page into strips and draw each strip onto the physical paper one at a time, loading only the bits that we needed and then dumping them as quickly as possible to make room for what was coming up next. In theory, the magical C-language "allocate" and "free" functions would do this for us and manage all of the details.
Nope. Without going into excessive detail, it turns out that the standard C functions would gradually get "gummed up," chopping free memory into ever-smaller pieces that eventually became too small for us to load anything at all. They were not at all magical. They were killing the app (but only after we printed about three pages, so it took five or more minutes for the bug to show up).
Fortunately, we had a very detailed understanding of how such systems really work, and we were able to identify the issue. We simply had to use a different memory manager. What's hard about this one is that our code was not incorrect. It just didn't work.

Lesson: There is no such thing as magic. Everything in software happens for a reason. And sometimes it takes a deep understanding of the system in order to figure out the true reason.

We’ll tell another related story, this time about audio, because audio is often under-appreciated.

T R U E S T O R Y

Failure to Anticipate: a hidden time-bomb

Castles II was an exciting project. Finally, we would be able to leverage all sorts of high-quality graphics and sound effects on the latest machines. We dove in, and wrote long scripts with detailed story lines spoken by professional actors. These would then play back based on the player's actions in the game. Some were quite complicated, and after days in the recording studio we ended up with many hours of tapes to process.
So far, so good. Production quality was top-notch, and we were able to get all of the raw data on digital tapes (DAT) at very high quality levels. But when we tried to digitize the audio, we realized that we had failed to consider the limitations of the audio hardware on the computers. Sure, they could handle some digital streams. But in order to get the files to be reasonable in size we needed to use 8-bit audio.
Eight-bit audio has only 256 volume levels, versus the 65,536 levels available in the typical 16-bit audio on a CD-ROM disc or DAT tape or most modern computers. And professional actors like the ones we hired are great at modulating their voices so some passages are soft and others very loud. With only 256 levels, the soft parts get really noisy and hard to understand. They sound really awful.
We spoke to our publisher, and they felt that every piece of the audio would have to be adjusted individually. This would cost a fortune. Being tool developers by nature, we had another idea. Surely, we could write some code to do the work. In short order, we had a working tool that compressed the dynamic range of the audio and made it sound better, at least as far as we were concerned.
Not so fast -- the publisher's audio team didn't want us taking any cheesy short-cuts if the resulting audio still sounded bad to them. So we decided to do a "bake-off." We played several versions of two audio sequences: one that was done manually, and the other that was done by our automated process. Which sounded better: "A" or "B"?
Their audio engineers chose "A". That was our version. Once we had proven that our tools were good, we were able to use them to process all of the recordings in just a few days, instead of hiring a team of audio engineers to spend weeks on the task.

Lesson: Unknowns can kill an otherwise perfectly good project. Take the time early in development to ask hard questions about every step along the way, and try to imagine every possible way that things could go sideways.

Let’s end with a highly technical story that’s one of our favorites.

Bill Fisher says: “when I started at Mattel, I devoured all of the documentation that we had, including the PDP-11 operating system manuals and the detailed data sheets for the CPU, graphics chips and sound generators in our console. I learned how every feature worked, including some of the oddball ones. This came in handy when we were trying to finalize our voice game, B-17 Bomber. I had one last bug and eight hours to fix it, test it and put the ROMs on an airplane.”

T E C H N I C A L N O T E

(you'll really want to read this anyway)

There was no space left in the cartridge to make the fix. We'd been optimizing for months, and we'd pulled all sorts of tricks to squeeze down every possible piece of code and data. But I had to find more room, and fast. One particular piece of code was gnawing at me. When the game ended, the code entered an endless loop, with the score displayed on the screen. The single instruction for that loop took up three decles (like bytes, only 10 bits wide). It seemed so wasteful, especially since its entire purpose was to do nothing at all.

I took a mental step backward. Was there another way to get the same thing done? To loop indefinitely while still allowing the automated screen blanker to run (TV sets could get "burn-in" if a video game were left on for a long time, so our console automatically blanked the screen after several minutes)?
I then had a crazy idea that relied on a unique feature of our CP-1610 CPU: it had eight registers, all the same in every way except that R7 was the Program Counter, which kept track of which instruction would run next (no other computer I've used, before or since, was like that). If the registers all supported EXACTLY the same instructions, then it was possible to decrement R7 just like any other register. And decrementing the Program Counter would basically say "go back one step", which just so happened to take it right back to that same instruction again. In other words, it would create am endless loop.
It seems crazy and nonsensical that a machine would have an instruction whose entire purpose was to crash the currently-running code. But, knowing the details of the design of this particular chip, it would actually make less sense if they'd disabled such a feature, because it would have required extra transistors, and those were very expensive. So, what's the harm of leaving a feature in the CPU that nobody in their right mind would ever use?
As it turns out, the Decrement R7 instruction does indeed exist, and does indeed leave the screen-blanker enabled. It works exactly the same as the three-decle "jump" instruction, but in only one decle. Squeezing down this single instruction allowed me to fit in one more line of code that fixed the final known bug. We tested the game for about an hour (no, really), burned the ROMs, placed them in a plastic anti-static tube, and handed them to the person who would then fly to Scottsdale, Arizona in time to keep the manufacturing line running and let the product hit the shelves on time.
At the end of the day, therefore, a tiny, seemingly irrelevant and unimportant technical fact became the key to shipping a product on time -- all because someone took the time to understand the system in depth.

Coming Up Next: Part 2: Curiosity

In our next careers installment, we’ll talk about the power of curiosity, and why a ceaseless curiosity is vital to success in the game business.

But, for now, we’ll dive back into Quicksilver’s history with the tale of an epic (award-winning) military training simulator that we developed for the US Army.

The Quicksilver Story: Chapter 9

For more information:

You can find us on the Web at www.quicksilver.com.

Read all about our company history starting here: The Quicksilver Story: Chapter 1

The Quicksilver Story: Chapter 8

Fri, 17 May 2024 08:00:00 -0700

Welcome to Quicksilver!

This is the eighth post about the story of our company. You can jump to the beginning here: The Quicksilver Story: Chapter 1 and to the previous chapter here: The Quicksilver Story: Chapter 7

Our story is four decades long, and still going strong. It involves more than 50 games for numerous different publishers, including some where we were delighted to revisit old classics. This is the story of two such classic game projects.

Next-Generation Classics: Star Trek: Tactical Assault

We were thrilled to work with Interplay in the 1990s to create the real-time combat game Star Trek: Starfleet Command, based in the “original” Captain Kirk era (“The Original Series”, or “TOS”) and leveraging the popular board game Star Fleet Battles. We were excited once again when we were contacted by Bethesda Softworks to produce a new mobile game also based in the TOS universe. This would be targeted at the Sony PSP and the Nintendo DS.

This would be a big challenge for us -- a first working with both Sony and Nintendo and the unique challenges of getting approval for their highly controlled platforms. We knew that this is one area where PC developers often fumbled, so we studied the console manufacturers' processes very carefully and instructing the team on what they needed to do in order to smooth the process. In the end, we were delighted that the approvals went through very quickly, with only a few "you have to be joking" moments.

T E C H N I C A L N O T E

(ignore if not interested)

Having a strong understanding of cross-platform development was a huge help here. Since we'd done so many Mac-PC games and other products, we were used to the concept of abstracting platform-agnostic functionality and "wrapping" the platform specifics into conditionally compiled sub-modules. Knowing from the start that we needed to support two very different devices made it easy to just design the code from the start with all of the necessary cross-platform hooks.

Writing the code in C++ was also very helpful, since the language naturally provides good ways of conditionally compiling code when needed.

One of the best parts of the project was initially a big problem: we had trouble getting smoothly-lit ship textures on the PSP. Our 3D artists knew that the very small ship models would look a lot more sophisticated if we could just give them more than the simple default lighting. But the PSP's processing tools didn't seem to have controls for that. However, one of our technical artists was also a skilled programmer. He deciphered the XML-based format used by the Sony tools and found a flag that turned on an advanced lighting mode but which didn't exist anywhere in the documentation. The Sony execs were floored when they saw the game for the first time, because it turned out that our game was one of the first to employ such techniques.

While combat would be a key element of the game, we knew that story also needed to play a big role. The unique capabilities and personalities of each Star Trek race play a large role in the series, and we wanted to be sure that carried over to the game as well. Fortunately, we had previously developed some very nice story management tools that were based on Excel spreadsheets. Modifying and expanding those for this title was a straightforward task. The tools were able to export complete stories that could be used in the game, a huge time-saver that ultimately proved critical to the quality of the game.

Star Trek has a long history, and a large canon of officially approved information. But knowing exactly how a Klingon captain would behave in a branching storyline with several possible outcomes was still very tricky and required a master storyteller. So we were thrilled to be able to work with one of the true masters of the TOS universe, author DC Fontana, who personally wrote some of the best of the TOS episodes we knew and loved. Working with her and her writing partner was one of the highlights of the project, and definitely made it a better game.

We decided to create two unique gameplay tracks: one where the player is a Federation captain, and the other a Klingon. Each would have about 15 unique scenarios of varying complexity, and would feature a unique user interface, just like we had done with Starfleet Command. Much like Starfleet Command, we created new, custom ships for specific situations to add depth and color to the universe.

The game also featured wireless two-player combat mode, so in addition to the scripted content we also had to contend with the usual complexities of local-area wireless communications.

R E V I E W S & A W A R D S

“…an outstanding simulation, and easily one of the better Star Trek titles available."

– Nintendojo

“Star Trek: Tactical Assault does a fantastic job with giving the player a feel of the Star Trek universe and what the commander of a starship had to go through in the shows."

– Gaming Age

"Where the PSP version of Tactical Assault really shines is its graphics. From the first menu screen (a faithful recreation of the USS Enterprise-A's bridge) to the detail and smoothness of each ship, I was just amazed by the game's ability to fit so much detail onto the handheld."

– Game Vortex

"Star Trek: Tactical Assault from Bethesda Softworks brings the Star Trek license to the handheld format. However, instead of just being another half- baked title with a license thrown on it, Tactical Assault is shaping up to be a very deep space-sim, putting you in the role of a Starfleet Commander and all the assets therein."

– GameZone

"Controls in this game are a big shining point as Quicksilver seemed to pay attention to the small little details of the Trek universe. The layout feels genuinely Trek-like when you glance down and look at the display."

– Nintendo Gal

Next-Generation Classics: Master of Orion III (MOO3)

Master of Orion is one of the great, classic PC strategy game franchises. We were very excited to be offered the opportunity to create an ambitious new chapter in the Master of Orion series.

We had a stellar team working on the game (pun intended), including designers who had assisted in the creation of Master of Orion II, and a powerhouse 3D and 2D art team. So we knew we were in good hands.

We also had an expansive vision for the game – both the visuals and the gameplay. We would add far more races, much greater detail, extensive space combat and even a sophisticated trade interface. The game would have numerous AI assistants that would allow players to delegate some tasks and focus on the parts of the game that were most interesting and fun to them.

As a CD-ROM title, we also had the opportunity to compose a long, very high-quality soundtrack that also included voices for each one of the planned 16 races in the game.

Many pieces were in place for a first-class production. Many of the final elements were very cool and worked exactly as we wanted. But, overall, the game fell short of what we wanted. This is one of those projects that served as a valuable lesson on what not to do in creating a top-tier strategy game. We’ll show off the many great features of the game here, but we’ll also share the equally important lessons that we learned, and talk about how this game has made all of our subsequent titles far better.

Some of the limitations we faced would prove to be more limiting than originally anticipated. Chief among these was the decision early on to make the game run on as many computers as possible, including those with limited or no 3D graphics capabilities. This influenced every aspect of the design, sometimes artificially limiting creativity.

Why are we sharing less-than-perfect news in this blog? It’s simple: by doing this, we make it clear that we are humble enough to admit when we fall short, and that we can learn from our mistakes. What we learned from this project has significantly affected future projects. We won’t make these mistakes again. And that process of learning and growing is exactly how top teams stay on top of their games, so to speak.

The following sections will delve deeply into game design and project management details; some readers may wish to skip them.

MOO3: What Went Right

D E S I G N N O T E S

Galaxy Modeling

Early in the project, this title was handed off from one publisher to another. This significantly delayed production startup, but it gave us a unique and valuable opportunity to design the galaxy in unprecedented detail. During an otherwise-quiet winter season, our design team created a massive (for its day) Excel spreadsheet that created entire galaxies full of stars, planets and moons based on mathematical models derived from astrophysics (the Hertzsprung-Russell Diagram, for example). Here's what two of the several dozen tables looked like:

Is this "overkill"? If we'd stopped there, yes. But we didn't just say "it's accurate, therefore it's good." Instead, we used this model to generate a playable universe -- one in which the habitability for each race was carefully balanced in order to ensure that the game was differently fun for everyone.
Cool tools are fun, but it's critical never to lose sight of why you're building them. What matters is creating a good experience for the player. And in other areas of this project, that's where we fell down.

Diplomacy Visuals

We're really proud of the way the diplomacy module turned out. Given the severe platform constraints imposed on the project, we were limited as to the techniques we could use to animate the various characters. We could not do real-time animations synchronized with audio, as would be done today in 2024. Instead, we fell back to the techniques we successfully used in the past, pre-recording and pre-rendering the sequences.

But we didn't want the animations to be simplistic. We wanted them to convey emotion, even when using made-up languages, and to be unique based on the player's specific situation. So we created a series of short segments, each with different emotional tone (and a few variants of each), which we could then string together to make an applicable short animation.

AI Players

MOO3 had one of the largest AI teams for a game of its class -- four programmers, in total. And that doesn't count the designers backing them up, who provided extremely detailed and carefully tuned tables of capabilities, technology trees and dependency diagrams needed in order to make the AIs smart enough to play the game effectively. Together, the team created roughly two dozen separate AI modules that handled everything from ship design and production to individual planet management to trade and diplomacy. They could play an entire game on their own. Amazing, but so good that they became a problem.

Depth of Simulation

One of the hallmarks of previous Master of Orion games was the elegance and simplicity of their gameplay at different levels. Planetary production was easy to manage, and the technology tree offered useful choices without being overwhelming. One of our early design choices involved deepening this significantly, with far more choices for technologies (including social and governmental developments) and management of planets on a region-by-region basis (so a watery planet's land mass worked one way, but the oceans had different parameters).
This was cool, and it worked. Players had far more ability to make choices for designing and optimizing their worlds, building unique ships and exploring vast numbers of interesting and believable planets.

Multiplayer Functionality

In this era, online multiplayer capabilities were just beginning to mature. Network connections were slow and unreliable (our office had a single ISDN line operating at 64K bits per second, and that was considered top-of-the-line for its day). So, in addition to offering real-time play, we offered a turn-based model in which players could send games out in round-robin fashion via email or other messaging and play whenever it was convenient for them.
Making this work was extremely tricky; if the games ever got out of sync, disaster would follow as each player had a different idea of the state of the galaxy. We wrote a sophisticated system in which the random-number generators relied on pre-arranged "seed" values, so every game running on every machine (even MacOS versus Windows) would get the same answers. This meant that we had to use fixed-point math for everything, since floating-point calculations differ slightly on different hardware.

Visual Style

MOO3 has a huge number of unique screens that enable management of everything from movement to planetary production. We established a very clean visual style that enabled us to display extremely complex data in a clean and understandable manner. We used a "drill-down" approach in which summary panels showed the numbers most likely to be important to the player but which could pop open and fill the screen with additional detail, if needed.

Note that this once again comes back to playability. It's not just about having tons of cool numbers floating around. It's about clearly understanding which numbers matter most in decision-making and putting those in the most prominent and clearly represented form so the player can make smart decisions easily. This exact same philosophy of design is the reason we landed future projects such as our medical device work -- we know how to make complicated things seem easy.

MOO3: What Went Wrong

As noted earlier, MOO3 was an incredibly ambitious project. We wanted to do every aspect of predecessor project Master of Orion II in a manner that was better than before – deeper, subtler, more visually compelling. And we succeeded at much of that. But, at the end of the day, the game fell short. It lacked a feeling of coherence, and it was hard to play well because players sometimes didn’t know what they should be doing.

Here, we’ll delve into some of the key reasons for this, and the key lessons that we learned.

D E S I G N N O T E S

Overly Ambitious Design

We wanted to set the bar high, but we set it too high to be achievable. The Game Design Document ultimately reached more than 200 pages and featured large numbers of complex data tables for numerous game subsystems. But every game has a budget and a schedule, and it became apparent after months of design and early production that we would never be able to do everything that we wanted. Unfortunately, we waited a little too long to pull the trigger on reducing scope and scale.
For example, the original design called for 32 and then 16 unique races. But due to the many production elements required, including large numbers of ships, aliens and audiovisuals, we needed to reduce that scope to eight races -- still plenty for a challenging game, but far less than the first "vision" documents proposed.
Likewise, there was originally an extremely complex hierarchy of personnel, each of whom could have loyalties to particular factions. That could have been the basis for an entire game on its own. It also turned out to be very tedious and uninteresting when actually played, so we had to kill it off after a lot of code had been written.

Lesson: The game isn't done when you've put in all of the features that you want. It's done when you've removed all of the features that you don't need.

Not Fun. "Plays Like a Spreadsheet"

This is a real killer. The simulation aspects of the game were very detailed and produced very interesting results. But they were so complicated that simply overseeing things like planetary production became tedious and boring. There were simply too many numbers to manage easily.
We designed the user interface screens to optimize what was displayed, and that helped a lot. But, too often, the player still had to dig down into some element or another and make an adjustment, which felt like debugging an Excel financial model.

Also, it was very easy to delegate many functions to the AI. Sounds like a great idea. But, in practice, what it meant was that the player lost a feeling of being connected to the game and felt that the game was playing and having all of the fun by itself.

Lesson: A simulation is not a game -- the player needs to feel that they are given interesting choices and that those choices will have a predictable effect on the outcome of the game. If they lose that connection, then it's no longer fun.

Hard to Know What to Do

This, too, is a lesson that we've incorporated into every following product. Whether it's a game, a restaurant ordering system, or a medical device, it's important that the user always knows what to do next and what to expect from such actions. Super-popular console games like the Mario series have this principle down to a science.
There are a couple of key pieces to this. First, choices need to be meaningful. If I do "X" instead of "Y", but I get what looks like the same result, my actions have no real purpose. With simulation-based games, it's easy to think that simply having the ability to control parameters will create interesting results, but that's not always true. In the case of this game, some decisions had such opaque or seemingly random consequences that the players felt that they had no purpose.

Second, the game needs to explicitly help the player know what to do next. Don't just put in a huge number of control panels and "let them explore." Give them specific guidance about which subset of actions will be meaningful. We actually did some of this in the final version of the game, providing direction by highlighting issues that were important and creating a "sitrep" (situation report) screen to summarize key events each turn. That helped a lot. But it's hard to completely fix a fundamentally overcomplicated design.

Lesson: Start FIRST with what you want the player to experience each turn. Then build the simulation (or rules without a "real" simulation) to support that user experience.

AIs Are Too Useful

The original concept with the AIs for this game was to give the player the ability to choose to focus on certain parts of the galaxy while delegating details of the "boring parts" to AIs. Thus, every player could chart their unique path while not getting lost in the details of parts that didn't interest them.
In practice, though, the AIs were so good that players found they could largely just run their entire empires via AI and watch what happened, because the AI choices were at least as good as their own. Net result: the players lost the vital experience of being needed.

Lesson: Decide what's best to automate and what's best left to the players. Design the game so they have plenty of interesting choices that actually affect the outcome, then design AI players and other game mechanisms to make them feel like they're in control and that their decisions matter.

Technical Compromises Driven by Platform Requirements

Our publisher wanted the game to work on as many platforms as possible, including relatively low-end PCs and Macintoshes. This was a laudable goal. But the threshold was ultimately set too low -- so low that it meant we could not rely on having access to useable 3D graphics hardware, and had to fall back to software-only rendering even for the real-time combat playback. We had a superb solution for this: a custom voxel renderer that we'd written. But using real 3D would have been better, in retrospect.
This also meant that we had to stick with a single, moderate screen resolution of 800x600 pixels because that's the best that some machines could offer, and we had no way of scaling the visuals (and the fonts) for larger screens. As a result, on top-end machines, the visuals looked rather blocky and the fonts were far less clean than the otherwise would have been.
We spent a very large amount of time implementing the turn-based play-by-email mechanism. It worked great, but it imposed a number of complex constraints on development and required a mid-stream rewrite to remove floating-point math calculations, which was time-consuming. It would have been nice if we could just rely on more modern, real-time connectivity.

Lesson: Design your product to support as many platforms as practical, but, if your platform choices begin dragging down the design and usability, push back and change to a better minimum performance requirement.

Make Backups!

Even the best backup plans can fall short. We stored all of the master art assets for this project on a large RAID5 array in our office. This dedicated unit had eight high-capacity drives, with not one but two hot spares in case of failure.
One day, about two years after the project was completed, we came into the office to see blinking warning lights on the control panel. The array was rebuilding itself because of a drive failure. Then, the worst-case situation happened: not only had two primary drives failed, but during the reconstruction a third drive went offline.

Apparently, the night before, there had been a severe thunderstorm near the airport. Our office was a short distance away. There were several lightning stikes, and we believe that one of them hit close to the office, sending huge spikes that blew through our power protection systems. We lost the entire array, and almost all of the original assets like these for the game.

Lesson: RAID5 arrays are great, in principle, but don't assume they'll never fail. Make at least two backups of your critical assets, storing one of them off-site.

Master of Orion III sold over 300,000 units. It wasn’t a disaster, and many people enjoyed it a lot (see the many positive reviews, below). But it still wasn’t what it should have been, and it taught us important lessons that have made subsequent projects far better.

R E V I E W S & A W A R D S

"With years in the making, Quicksilver Software has taken its time to enhance and streamline its powerful game system. With a fresh new look, tons of new options and a host of new races, MoO3 is set to rock the strategy genre once again and show gamers that space IS the final frontier."

– ActiveReviews

"I absolutely adore Master of Orion III. The gameplay is so addictive, I often found myself saying, "Okay, just one more turn", 267 times in a row. This game is immersive, richly detailed and full of strategy. Furthermore, multiplayer support is quite fun when friends are involved. All in all, Master of Orion III is a turn-based strategy fan's dream."

– Inside Mac Games

"Diplomatic AI has never been anywhere near as clever as in MOO3... Combat has never been so strategically focused. Colony development has never been so detailed and intensive, and computer opponents so well-balanced that literally any of them could win. Galaxies are much bigger, available researches are more extensive, and there's far more information to track than in any previous 4x space game."

– IGN

"MOO3 certainly has a legacy to live up to, but from what I saw it will have no trouble satisfying or even surpassing expectations. The game has been in the hands of testers for about a year and the Quicksilver team has had constant feedback and support from a beta community that they couldn't praise enough. "[We've] often had a new build out every three days to our beta team," I was told, "even recently... We want this game to be solid." It certainly seemed solid -- which is good as the game will be going gold any day now and should start hitting store shelves just in time for the holiday rush. Which is also good as I now have a Christmas present for my alien masters."

– GameSpy

– Gamespot

– Amazon.com

Coming Up Next: Chapter 10 – An Award-Winning Military Project

But first we’ll take a side-trip to talk about our other great passion: career development. What does it take to get into the game business? And is it something you’d actually want to do? Find out here:

The Quicksilver Career Blog: Part 1

Looking For a Top-Notch Team to Solve Your Impossible Problem?

Let’s talk! We love to take on new challenges. Tell us what you need and we’ll let you know how we can help.

You can reach us here: https://www.quicksilver.com/contact.html#contact.

For more information:

You can find us on the Web at www.quicksilver.com.

The Quicksilver Story: Chapter 7

Tue, 14 May 2024 08:00:00 -0700

Welcome to Quicksilver!

This is the seventh post about the story of our company. You can jump to the beginning here: The Quicksilver Story: Chapter 1 and to the previous chapter here: The Quicksilver Story: Chapter 6

Several themes show up repeatedly over the years:

Synergies between projects spanning very different markets
The amplifying power of great tools and proprietary engines
Relationships that pay back years or even decades later
The importance of asking the right questions and solving the right problems
Coming to the rescue of projects in trouble
The value of hiring the right people for the job
Copy Protection, and Security by Design
Sophisticated AI across all product lines
Always learning new skills

Military Applications: Cognitive Training

It’s easy to imagine how computer-based military simulations could train basic skills such as marksmanship. There are plenty of modern combat games that provide focus on realistic first-person combat experiences. Such simple combat skills have already been a part of training systems, so there’s no new ground to be broken there.

But the military isn’t just about shooting guns. Strategy and tactics are important skills for leaders at all levels. This is where “cognitive training” comes in.

For example, a company commander in the US Army is in control of as many as 200 personnel. Some are front-line combatants, and others are in supporting roles. How should they be organized? How should they be deployed? How can supplies be provided to them as the battle continues? It’s been said that “no plan survives contact with the enemy.” How can leaders adjust their strategies when conditions on the battlefield change?

Around the year 2000, Quicksilver connected up with the newly-created USC Institute for Creative Technologies, a DoD-funded organization focused on bringing cutting-edge research and Hollywood-style production values to military training programs. The ICT, as it was known, needed to supplement its academic staff with experienced game and AI development teams to realize its visions. This led to a long, multi-year relationship during which we created a series of sophisticated training products for the US Army, Marine Corps and Naval Postgraduate School.

Note: for those who are wondering, none of the projects here used classified or secret information. Most were based on readily downloadable documents such as US Army Field Manuals. In fact, nobody on the team had a security clearance. Although the products were used in classified settings, none of the data created for those settings was made available to the development teams. Nevertheless, the images shown here have been carefully selected and selectively obfuscated.

Military Applications: Full Spectrum Command

Our first project with ICT was a company commander training simulation. The goal was to develop a full range of command skills and to allow the commander to explore alternative solutions in a manner that would not be possible with real-world training.

The software would let the commander define the organization of the units (there's never just one way to do that), make a plan, and then oversee the execution of the plan in a real-time 3D graphics simulation.

Rendering the 3D simulation was going to be a huge challenge. This was the era of the GeForce 3 video card – far less powerful than even a current-day mobile phone. We looked at game engines such as Unreal, but Unreal would never have been able to handle 200 individual humans. At the time, it was limited to 32 of them active at any given time. Due to the nature of what we were doing, there would be situations where all 200 might be visible at once (think aerial viewpoint). And there was no easy way to work around that.

We went back to what we usually do – we created our own custom engine that was designed specifically to render only what was needed. We knew that the graphics quality wouldn’t look like the top video games of the day. Character models would be less detailed, textures would be very simple, and there would be no shadows cast on the ground. But we’d be able to animate 200 unique objects at once while maintaining a reasonable frame rate.

The second challenge was AI. The simulated soldiers in our app needed to execute their orders in a manner consistent with the TTPs (tactics, techniques and procedures) defined in the Army FMs (Field Manuals). We needed to teach an AI how to move across terrain, take cover, breach rooms, and clear entire floors in buildings properly. We had a top AI programmer working for about a year to make this happen.

One big issue with the AI was revealed during development: it’s not enough for the simulated soldiers to execute orders as written. They also need to know what to do when conditions change. If they’ve been told to advance to a given position, but they come under fire, they need to either take cover in nearby low-lying terrain or switch to “bounding” movement mode where one group provides covering fire while another moves. And they had to follow reasonable adaptations of the TTPs in order to accomplish that. This required a bit of careful thought and structuring of the code to prioritize a hierarchy of potential actions.

We traveled a couple of times to an Army training base and to our local Marine base at Camp Pendleton to watch training exercises and understand the nuances of the terrain (for example, exactly where to I need to be in order to hide behind the slight rise in the terrain?). We walked these “MOUT” (military operations, urban terrain) facilities, climbed the stairs to see the fields of view, and so on.

One of the things the Army liked most about this product was the way it allowed lessons to be taught without deploying 200 real soldiers in red-blue team live-action exercises. Those are expensive, time-consuming and dangerous, so soldiers seldom get to participate in them during their years in the service. With software, on the other hand, they can play through dozens of scenarios in a single course. We delighted in creating “trick” scenarios where commanders had to discover weaknesses in the deployment; in one, the mortar team was easily ambushed. But no real soldiers had to die in order to teach the lesson.

Full Spectrum Command was a success, so much so that we were asked to do a special version for the Singapore Armed Forces. Then we were brought in again to do a platoon commander app.

Military Applications: Advanced Research: Explainable AI

Artificial Intelligence has been “the next big thing” for decades.

Around the turn of the century, computers were just beginning to become powerful enough to run good game and training AI software. Surely, the age of super-powerful AI was right around the corner.

But AI had a huge problem. With the technologies of the day, such as Neural Nets, it was almost impossible to understand WHY an AI made a particular decision. With enough training data, and with clearly-defined performance targets, early neural net systems could produce very interesting results. But the best that researchers could do to explain their output was to point at the core mathematical equations driving these systems. They could not walk through the decision process following by the network; although the network produced human-usable output, it didn’t think like a human and could not explain its own reasoning process.

One of the researchers at ICT got funding to demonstrate that it was possible to design an “explainable” AI system that would be able to describe in human-useful terms what it was doing. He enlisted Quicksilver to write a custom version of Full Spectrum Command that would record and play back its actions, along with specific explanations of how the units decided what to do. For example, a unit could explain that its orders were to breach a given building but that it was taking cover because it was under fire from a nearby building. It could then show the enemy lines of fire in a fully traversable 3D world with a “flying camera” that could see anything in the scene.

When the software was completed, the academic team used it to prepare one of the earliest Explainable AI papers, “An Explainable Artificial Intelligence System for Small-unit Tactical Behavior,” with two Quicksilver team members as co-authors. The full paper is available here: Explainable AI Paper

Military Applications: Full Spectrum Leader

In the Army, a Company is made up of a headquarters section, several platoons, and sometimes other specialized units. In Full Spectrum Command, we enabled the company commander to specify orders for multiple platoons or other units, which would then be carried out via AI. The company commander is not typically “out front,” but instead is in a central location monitoring events and giving orders, as needed. Our user interface design reflected this primarily high-level view of the battlefield.

The platoon leader’s experience is very different. Commanding several squads of eight or nine people, the platoon leader is in the thick of the action, directing forces from a first-person view of the action. This necessitates a completely different style of control that’s basically “pointing and gesturing” rather than plotting lines on a map or moving pieces around on a sand table.

For our new product, which would be known as Full Spectrum Leader, we created a radial menu overlaid on the first-person view, with an inner circle of primary categories and a second set of wedges outside that circle with the specific commands. It was very elegant and easy to use, and well-suited to the fast action of a combat game.

We also refined and enhanced our AI. In our previous product, we were able to abstract some of the behaviors of units smaller than platoons (i.e., fire teams, as they are known). But in this game, the platoon leader needed to give orders to each fire team, and also needed more refined control over what happened when some of the soldier were killed.

Full Spectrum Leader was delivered about a year after our first training simulation.

Military Applications: Patriot Missile Battery Deployment

One of the most interesting parts of our military application development efforts was learning about how military organizations and their weapons systems work. We certainly learned a great deal when we were sent to Fort Bliss, TX to design a training tool for the deployment of Patriot anti-missile defense systems.

We’ve all seen photos of the Patriot missile launcher trucks. These distinctive flatbed-style vehicles feature large, boxy launch tubes that tilt upward when deployed. It’s tempting to think that the Patriot system is just that single vehicle. But that’s far from the case. A full Patriot battery includes more than two dozen vehicles, some weighing as much as 30 tons. Moving from place to place requires massively complex planning and logistics, and laying out all of the trucks in a functional formation is quite complicated. We won’t go into detail here about how that all works.

Our training product focused on a few key aspects of the deployment process: planning, movement and final deployment. Planning requires deciding exactly which vehicles will be included. Movement is complicated – the convoy is more than 1/4 mile long and needs to move through potentially crowded urban environments as a single, cohesive unit. Handling of threats requires careful thought, and the “obvious” answers are not necessarily correct.

When we visited the base to deliver the final product, we were brought into a classroom to see it in action. The instructor took an interesting approach. He had the soldiers create a reasonable plan and then watch it play out interactively. When an event occured during the movement phase, he asked the soldier to make a choice, but stopped him and made him choose the “wrong” answer. He did this specifically to show what would happen (loss of equipment and personnel) and experience viscerally what NOT to do. This is the power of simulation. In the real world, nobody would ever make that wrong choice just to see what happened. But when it’s just a simulation on a projector in a classroom, it’s safe to make the dangerous choices and really learn about the consequences.

Coming Up Next: Chapter 8 – Next-Generation Classics

The Quicksilver Story: Chapter 8

Looking For a Top-Notch Team to Solve Your Impossible Problem?

Let’s talk! We love to take on new challenges. Tell us what you need and we’ll let you know how we can help.

You can reach us here: https://www.quicksilver.com/contact.html#contact.

For more information:

You can find us on the Web at www.quicksilver.com.

The Quicksilver Story: Chapter 6

Fri, 10 May 2024 08:00:00 -0700

Welcome to Quicksilver!

This is the sixth post about the story of our company. You can jump to the beginning here: The Quicksilver Story: Chapter 1 and to the previous chapter here: The Quicksilver Story: Chapter 5

Our story is four decades long, and still going strong. It involves more than 50 games for numerous different publishers, and some very interesting educational products. This is the story of one of our largest educational projects.

Rich Dad’s Cashflow 101

We are big fans of board games. But making electronic versions of these types of experiences is not simple. Many times, the rules just don’t quite translate to an online setting, or there are fundamental design conflicts between the turn-based nature of most board games and the tendency for online games to be real-time focused. In the early 2000s, we were challenged to build an ambitious online game about financial literacy. Wikipedia says:

"Rich Dad Poor Dad is a 1997 book written by Robert T. Kiyosaki and Sharon Lechter. It advocates the importance of financial literacy (financial education), financial independence and building wealth through investing in assets, real estate investing, starting and owning businesses, as well as increasing one's financial intelligence (financial IQ).

"Rich Dad Poor Dad is written in the style of a set of parables based on Kiyosaki's life. The titular 'rich dad' is his best friend's father who accumulated wealth due to entrepreneurship and savvy investing, while the 'poor dad' is claimed to be Kiyosaki's own father who he says worked hard all his life but never obtained financial security."

Wikipedia also notes that the book has sold over 32 million copies.

But Kiyosaki and Lechter didn’t stop there. They knew that playing games was a great way to drive home lessons. That’s how we became involved. They were also savvy enough to realize that it was also a great way to make money.

Together, they created a game called Rich Dad’s Cashflow 101. The board game taught basic financial literacy, including how to understand a balance sheet and an income statement, how to evaluate rental properties and stocks, and how to become a business owner. It was like the famous “Game of Life”, but with lots of numbers. They sold large numbers of copies at seminars – for $195 a copy. But they wanted to expand and enable people to play even if they were not all around the same table, so they explored building an online game.

Soon, we were reading the books, playing the board game and flying out to Scottsdale to meet the team in person. They wanted a first-class product, which meant having superb graphics, plenty of animations, and of course rock-solid gameplay. Most of the elements of the board game worked well, but some required careful thinking and planning.

For example, the easiest way to address the manual math required in the board game would be to have the computer do all of the work. But that goes against the design philosophy of the game, which challenges players to get close to the numbers and work hard to understand how they affect one another. We came up with a solution: we required players to manually enter certain numbers related to a given purchase, but we gave them an in-game calculator that let them quickly total things up.

Explaining the context of the game was important, so we also created an elaborate introductory video sequence, complete with animated characters based on those in the board game, plus detailed in-game help and even videos of Robert explaining key points. Given that this was in the early 2000s, the tools were fairly rough and computers barely up to the task of rendering the necessary images. We could not render the sequences in real time, for example. We had to pre-render the videos and then play them back. Otherwise, too few people would have been able to play the game.

Another challenge was the back-end hosting. Again, in this era, modern “cloud” systems like Amazon AWS, Google Cloud and Microsoft Azure simply didn’t exist. We had to rent space in a hosting facility, purchase servers and configure them to play the game. Then we had to write special code to implement the real-time turn management via TCP/IP from a standalone Windows/MacOS app, since the browsers of that day could not provide the necessary user experience. Technically, this required a lot of work, but with our proprietary cross-platform engine and our deep understanding of computer networking, it wasn’t actually very hard at all.

AI opponents needed to be part of the picture for the game, of course. Not everyone would have access to enough human opponents, and we wanted the game to be playable at any time. Once again, we were able to leverage our extensive past experience in AI design to come up with credible opponents. We never short-cut the AIs in our games. We don’t just slap together random moves. We write code that understands the rules and knows how to leverage them to its advantage. Our test of AI is always this: is it so good that we need to “dumb it down” to make it feel fair to normal players? If so, we’ve done it right.

Soon, we had an amazing game up and running and a ton of animation sequences. One especially memorable meeting took place at our offices. The Rich Dad team pulled up in a 40-foot limousine (which barely fit in our parking lot) and sat down for a review of all of our artwork. They were thrilled – it was better than anything they had expected. The characters really did come to life, the humor was just right, and the game design decisions were exactly what they had hoped for. Following this major checkpoint, the game was delivered a few months later and we entered a long-term maintenance phase of operating the servers and reporting activity.

When this game was ready for the market, the Rich Dad Organization invited us to a special meeting of their closest business partners at a top-quality resort in Scottsdale. We drove from California to Arizona with servers in the car, because we didn’t want to take a chance on flaky hotel Internet connectivity. We ran demos of the game using a dozen computers in a very fancy hotel ballroom. It worked perfectly, and folks were very complimentary (unlike the other demo that day, which was done via Internet and crashed due to the poor hotel Wi-Fi).

Rich Dad’s Cashflow 202

The Cashflow 101 E-Game, as it was known, was good enough that the Rich Dad team then wanted a sequel. They had also created a second board game, Cashflow 202, with much more sophisticated rules about all sorts of investments, such as stocks. During the next year, we produced this game as well, and included an even-more-elaborate and ambitious intro video sequence.

We were now managing servers for both games, usable on Windows and MacOS X, from our dedicated hosting facility.

The highlight of the Cashflow 202 E-Game was the rollout, which took place on the back-yard tennis court at a home in Scottsdale. Dozens of celebrities were in attendance, and we went on stage to demo the game live. After the demo, one person approached us and asked for our autographs on the box. We learned later that he was an NFL player for the Denver Broncos! It’s not every day that a sports figure asks someone else for their autograph.

We continued maintaining the system for a number of years and enjoyed periodically connecting with the team again.

Coming Up Next: Chapter 7 – Military Trainers

With the increasing capabilities of personal computers around the turn of the century, the US military became increasingly interesting in ways to leverage computers for training – not just basic skill development, but what’s known as “cognitive training” (teaching people how to think). Our extensive game experience and our ability to develop powerful time-saving tools served us well in our military work.

The Quicksilver Story: Chapter 7

Looking For a Top-Notch Team to Solve Your Impossible Problem?

Let’s talk! We love to take on new challenges. Tell us what you need and we’ll let you know how we can help.

You can reach us here: https://www.quicksilver.com/contact.html#contact.

For more information:

You can find us on the Web at www.quicksilver.com.

The Quicksilver Story: Chapter 5

Tue, 07 May 2024 08:00:00 -0700

Welcome to Quicksilver!

This is the fifth post about the story of our company. You can jump to the beginning here: The Quicksilver Story: Chapter 1 and to the previous chapter here: The Quicksilver Story: Chapter 4

Our story is four decades long, and still going strong. It involves more than 50 games for numerous different publishers, including some that we published ourselves. But we haven’t just done entertainment products. We’ve used our game design skills to create a number of educational titles.

Expanding into Educational Games

We often say that writing video games is the hardest type of software development, because it requires mastery of so many different skills and demands that programmers push the each machine to its limits to create the best possible experience.

Coding games requires not just technical skill but also a strong aesthetic sense and an instinctive understanding of how to present complex information clearly and concisely. Games also impose very high standards of usability. Gamers aren’t going to read a manual to learn how to use the app. They need to be able to pick it up and learn as they go. There’s a certain magic there.

These skills transfer very effectively to other technological fields, as will be seen in many of the stories here. Quicksilver has been very successful in applying its game design skills in fields ranging from military training to business tools to restaurant menus to breast cancer surgery. In every one of these cases, our game background was cited by the client as a major reason why we were brought on board. And in every one of these cases, we delivered experiences that were so good that they often remained in active use for more than a decade. That’s an eternity in the software world.

In this section, we’ll talk about our many educational games.

Davidson: Kid Keys

Davidson and Associates was a legendary producer of early educational software. The company lasted for many years and had a broad catalog of games for the top machines of the day, such as the Apple ][ and early IBM PCs.

Quicksilver connected up with Davidson to create a keyboard awareness application for very young children. We hired one of our favorite cartoonists (who also happened to be a Mattel alumnus), and together we created a keyboard full of cute, friendly animations with accompanying sound effects.

Kid Keys was simple but quite endearing. And the successful delivery of a title for a major educational publisher then opened many future doors for us.

CORD: Math at Work

“CORD” is the abbreviation of the Center for Occupational Research and Development, a curriculum developer based in Waco, TX. They focus on practical, applied science and math and have an excellent philosophy about how to teach math in an easily understood and non-intimidating manner.

CORD approached Quicksilver with a challenge: to build a series of five simulation games that would teach specific mathematical concepts ranging from basic budgeting to calculation of areas to vector addition, and do it in a way that was accessible to folks who might otherwise be afraid of math (“math is hard,” right?). We loved the challenge, and over the next two years produced a total of five games:

Cybersnacks – a hot dog cart simulator that taught basic budgeting
Gearing Up – a bike race that taught angles
Pooling Around – a swimming pool contracting game that taught area estimation
On the Fly – a smoke jumper simulation that showed how vectors work
Train Reaction – a train crash simulation that taught volume computations

As just one example, here are some screens from On The Fly:

For these games, we were able to leverage our cross-platform game engine to quickly design and build games that worked on both IBM PC and Macintosh computers.

The games were sold and distributed by CORD for many years, and Quicksilver also did some direct sales. As with many of our products, they required virtually no ongoing technical support from our team. They just worked.

Sunburst: Type to Learn 4

Sunburst is another well-known publisher of educational software. Teamed with an author who had written a successful book about developing advanced keyboarding skills for computers, they needed a game-focused team that could bring this very staid subject to life.

Type to Learn 4 was a research-based online typing program with a focus on keyboarding proficiency. Sunburst's educational experts designed it to align with local, state and CCSS standards for typing, which is why it was used by schools nationwide. The game-centric content ensured that students were engaged, teachers had the right tools to teach proper touch-typing, and administrators could get the reports they needed.

The development of this product was a massive undertaking. There are five unique typing games, over 100 lessons (including special remedial lessons at every level), and a sophisticated over-arching story line that carries through all of the content. Every lesson includes:

Home row reinforcement
Warm-up exercises
Review of previously learned keys
Demonstration of new keys
Practice exercises
Testing

There are different levels of content specifically tailored to different educational levels (grades K-2, 3-6, and 7-12). Age-appropriate content includes:

Historical documents
Passages from iterature
“Quick-blends” commonly found in English
Original writing tasks, in later sections

The 3-D hand animations appear on a virtual keyboard in order to show correct fingering for new keys offer hints when incorrect keys are pressed. This took quite a bit of back-and-forth brainstorming with the team and client. We fine-tuned the appearance until it was helpful and intuitive without dominating the visuals on the screen.

The game includes sophisticated, networked class- and student-management tools. These help teachers individualize their students’ keyboarding experience to fit their specific needs. There is an assessment at the beginning which places students in the most appropriate lessons. The assessment is repeated every six lessons to identify progress and set new, reachable speed and accuracy goals.

Type to Learn 4 was a big success for Quicksilver and was actively sold by Sunburst for many years. It’s common for us to speak with folks who went to school in the 2000s or have kids who did, and to learn that they all used the product. The design lives on now as a cloud-based product (which we did not build, but which retains many of the same elements).

Quicksilver’s Autism Projects: Zody

One of the joys of developing educational software is seeing the effect that it has on those who use it. We are helping develop skills and making people’s lives better through our technology. With games like those just described, we can see the improvements every day.

A chance meeting at a conference led to a long and ongoing collaboration. Our founder and president arrived very early one day at a conference center after a red-eye flight. By chance, he struck up a conversation with another early arrival. After a few conversations following the conference, the two met up with a psychiatrist specializing in autism spectrum treatments and decided to start a company focused on autism-related products.

The new company, SymPlay, decided to explore the creation of a hardware-software hybrid system designed to encourage social interactions. They used RFID-enabled objects and a sensor device with colored lights to prototype a system that could turn a playroom into an interactive experience. The hardware proved too complex to implement; the devices of the day were not quite ready for the level of interactivity required.

But, as so often happens in the technology field, the team pivoted toward another approach and ultimately developed a charming, animated game called Zody's World. This interactive title, designed for the Apple iPad, placed two people in very close physical proximity and challenged them to play a cooperative game together.

The goal was to help children on the spectrum become more comfortable interacting with other people – either counselors or other kids. We created a set of friendly, approachable characters and built detailed back-stories to drive the game design. We even created a simple comic to explain the story at the start of the game; here are the first two frames:

Our goal was to build fun, engaging games that encourage autistic kids to connect with adults or peers in a variety of ways: action games, puzzles, and social problem-solving situations. Our research paired autistic and neurotypical kids and showed that Zody was much better at connecting kids in a fun way than commonly-used art activities or even building with Lego® bricks.

The game was available on the Apple App Store for a number of years, but was no longer maintained after the company closed down. Quicksilver subsequently purchased SymPlay and its assets, including the Zody property.

Quicksilver’s Autism Projects: Connection Coder

Following the development of the Zody game, Quicksilver continued working with the SymPlay team on other targeted projects in the medical arena. The team identified an important need in the autism space: a means of objectively evaluating the results of specific types of therapy. Autism occurs on a broad spectrum; each case is unique, and one style of treatment does not work for everyone. Therefore, it’s important to be able to measure whether a given approach is helping and make changes, if necessary, to the treatment plan.

One key measure of autism-related behavior is what’s known as “engagement” – how well the patient interacts with others. At one end of the scale, the patient is completely disengaged from any interaction with other people, playing alone and not responding to prompting. At the other end, a high level of engagement involves engaging in cooperative or collaborative activities with smooth and responsive timing and often with meaningful eye gaze.

The tricky part here is how engagement is measured. Traditionally, it’s done through an observational session in a clinical setting. One person, typically a therapist, joins the patient in a room with a one-way mirror. The interaction is captured on video for analysis by trained coders. The coder then produces a formal report for review by the therapist and other interested parties. The process is cumbersome and expensive.

SymPlay’s team decided that there had to be a way of achieving similar results without requiring the elaborate laboratory setting. Working with Quicksilver, SymPlay’s psychiatric and developmental psychology advisors created a coding scheme that could be implemented and tested on any iPhone or iPad, and could be used by anyone completing an online training program.

SymPlay demonstrated in a formal scientific study in collaboration with a Ph.D. program that the results from the “Connection Coder” app were comparable in quality to those acquired through formal observational studies. The app is now in active use by other students for their Ph.D. work, and is being considered for large-scale deployment in an international setting.

Coming Up Next: Chapter 6 – Rich Dad’s Game

Educational software doesn’t often intersect with the world of finance, but there are always exceptions. Next up, we’ll tell the story of how we developed a large-scale educational game to teach financial literacy.

We’re not afraid to take on “boring” topics like finance or military logistics, as will soon be revealed.

The Quicksilver Story: Chapter 6

Looking For a Top-Notch Team to Solve Your Impossible Problem?

Let’s talk! We love to take on new challenges. Tell us what you need and we’ll let you know how we can help.

You can reach us here: https://www.quicksilver.com/contact.html#contact.

For more information:

You can find us on the Web at www.quicksilver.com.

The Quicksilver Story: Chapter 4

Fri, 03 May 2024 08:00:00 -0700

Welcome to Quicksilver!

This is the fourth post about the story of our company. You can jump to the beginning here: The Quicksilver Story: Chapter 1 and to the previous chapter here: The Quicksilver Story: Chapter 3

Our story is four decades long, and still going strong. It involves more than 50 games for numerous different publishers, including some that we published ourselves. This is the story of a game development relationship that came out of a project that we did in a completely different market: CD-ROM drivers.

An Unexpected Connection

One of the projects we did for Western Digital involved writing a custom CD-ROM driver for a large company that wanted to use Western Digital’s state-of-the-art controller hardware in their new consumer-oriented computer. We were very familiar with the chipset, since we’d helped Q/A it and write the testing systems used in Western Digital’s labs.

In approximately ten weeks, we delivered fully operational code for the computer, which passed testing with flying colors and was shipped shortly thereafter. But, apparently, there was a kinda-sorta bug.

Certain products were unable to play audio properly on this computer. One high-profile product was a popular game, The Manhole, an early “multimedia” title. The game was developed by a small company known as Cyan, Inc., which would later become famous for the game Myst. Cyan developed a CD-ROM version of the game in 1988 and published the PC CD-ROM version through Activision.

One day, we received a call from the vice president of technology at Activision, who reported the bug to us. We ended up having to chase the issue all the way to the programmer who wrote Microsoft’s MSCDEX CD-ROM driver software and wrote the documentation. Apparently, even though we had correctly followed the API documentation for the product, there was an ambiguity in the way it was written. We had chosen one interpretation, but it turned out that a conflicting section later in the document provided a different and ultimately “official” interpretation.

We patched the driver, and the bug was fixed. But that wasn’t the end. It was, in fact, the beginning of a long relationship that continues to have echoes to this day (2024, to be exact).

Activision: Digital Video in Return to Zork

Activision’s VP of Technology was intrigued to find out that the CD-ROM driver had actually been written by an accomplished game developer. He figured that, if we could be trusted to do development for this computer company, we could be trusted to write some very critical code for Activision.

One of the company's most ambitious projects was a graphical re-imagining of the famous text-only game Zork. It was called Return to Zork, and it was to feature full-screen digital video -- something that was nearly impossible on the limited computers of the late 1980s. But Activision had created its own digital video file format that was incredibly space-efficient, and felt that it could be used for this purpose if it could just be optimized to run quickly enough. Unfortunately, the versions that they had were far too slow to be usable.

A game developer that knew how to write complex, high-speed graphics code on personal computers was an ideal fit for this problem. We were challenged to take the existing design and make it work well enough to be usable in a game. That meant making the existing code at least 4X faster.

Activision’s “FLEX” file format was a clever meta-block compression scheme that was comparable in some ways to the JPEG and MPEG compression schemes developed afterward, except that this scheme did not require the complex and demanding mathematical transformations required by those formats. Similar to those formats, the FLEX format was highly asymmetrical. It took a lot longer to compress the frames than to decompress them, which was important since they were being used for digital video.

In short order, we tore apart the existing C-language code and rewrote it in optimized assembly language, in a way that was far faster than the original and that more than met the criteria for use in a game. We then wrote tools that could be used to encode the video for the game by Activision’s production team. These would end up running for overnight many times to compress the large volumes of video data needed in the game.

According to Wikipedia, “in 1994, PC Gamer US named Return to Zork as the 26th best computer game ever. The editors wrote that it ‘masterfully … balances the traditions of a classic gaming series with cutting-edge graphics and CD-ROM technology.’”

Activision was impressed. Soon, they had another project in mind for us – a “multimedia” CD-ROM game using large numbers of animations plus digital video. And that’s how a bug in a CD-ROM driver ended up giving us a huge new game development relationship.

Activision: The Shanghai Franchise

Activision had seen great success with the game Shanghai, a clever solitaire game of matching Mah Jongg tiles laid out in various configurations on the screen. It was unique, addictive and very popular. They wanted to do a new version that would include clever animations for each tile, and numerous completely new tile sets built around various themes. They also wanted a digital "host" to appear on the screen, and had hired Rosalind Chao for that position.

This new game would be called Shanghai: Great Moments. It would have so many assets that it would need to ship on CD-ROM, and needed a team that could handle digital video as well as large numbers of animated assets. This was clearly right up our alley.

Shanghai: Great Moments was released in 1995 for Windows 95 to solid reviews. It was welcomed as a major update to the franchise, with plenty of features to please fans.

According to Wikipedia, “Next Generation gave four stars out of five for the PC version of the game, and said that ‘this game is destined to be a classic’”. Shanghai: Great Moments sold enough copies that a sequel was clearly warranted.

Activision asked Quicksilver to develop an ambitious new game, Shanghai: Dynasty, which was released in 1997 and included a host of new features ranging from multiplayer online support and new tile sets to several entirely new modes of play.

In a nod to Quicksilver's increasing reputation in the game industry, our logo appeared on the front of the box.

One major upgrade was the ability to play real Mah Jongg. Activision also wanted to release the game on both Windows and Macintosh platforms. This was another perfect fit for Quicksilver, since we had developed our own internal game engine that was cross-platform and could handle both operating systems. Most developers in that era needed to use their own engines, since no general-purpose engines existed, especially ones that could handle multiple platforms from the same code base. That was a huge time-saver.

Quicksilver developed the new game, Shanghai: Dynasty, which was released in 1997. It featured new gameplay modes such as Pandamonium and Dynasty, which pit the player against multiple AI opponents, and online connectivity that allowed players to link up with others via modem and Internet, which was a very new thing for a game. Dynasty also included a Shanghai for Kids mode that helped teach the concepts of the game. It even included custom tile/layout functionality – another Quicksilver specialty.

Our AI opponents played pretty credible games. Leveraging our past experience with complex game AIs, we were able to put together automated systems that gave our players just the right level of challenge.

Three years after the release of Shanghai: Dynasty, Activision and Quicksilver released an updated version of the game. This version featured new tile sets (more than 50 in total), new layouts and additional game modes.

One of the key additions was American Mah Jongg, which has a number of unique gameplay elements not found in Chinese or Japanese versions of the game.

R E V I E W S & A W A R D S

"Classic Game of the Year"

– Computer Games Magazine

"5 Stars"

– Computer Gaming World

Quicksilver to the Rescue

By the company’s tenth anniversary in 1994, Quicksilver was becoming known as a team that could solve the most difficult problems. When talking to publishers, they would frequently offer us several projects but then steer us to the one that was the hardest, figuring that, if anyone could rise to the challenge, we could.

This, of course, was true.

For example, in 1996, Activision had the opportunity to bundle their game HyperBlade with video cards from several manufacturers. This would be a massive win -- a way to get huge distribution and a reputation for creating a game whose mere existence showed off the best features of modern 3D graphics cards. But they had a problem: the game wasn't ready to release, and it wasn't looking like it would get done on time.

Activision’s producer called on Quicksilver to help get it done, with a tasty cash bonus if we succeeded. We set up a “war room” in our office where our team worked side by side with a number of Activision personnel. There were many late nights, and some frustrating times integrating the code that was coming in from the other developers.

Working with Microsoft’s new DirectX graphics APIs was not easy, since they were not always as well documented as one would hope. But the team got it done, sliding just under the deadline and releasing a game that did indeed get bundled with millions of video cards. And we did get that bonus check….

Experts in Data Wrangling

Because of our work on CD-ROMs and DVD-ROMs, and our strong focus on tool development, Quicksilver also become known for its ability to deal with unusually large data sets. Back in the mid-1990s, this meant gigabyte-sized projects that often required multiple CD-ROM discs.

We helped Activision with two such games. These are not games we developed; we simply helped coalesce multiple CD-ROMS onto single DVD-ROMs. We leveraged our deep knowledge of optical disc formats, and our ample supply of readers and hard disks, to make quick work of these projects.

These are gorgeous games. Even though we didn’t produce the artwork, we’re delighted to have been able to work with products of this caliber, so we want to show a few examples of what they looked like on the screen.

Coming Up Next: Chapter 5 – Educational Games

We’ve always been interested in schools and instructional software. A background in games helps a lot when trying to make fundamentally dull topics like algebra and keyboarding into interesting and compelling challenges. Over the years, we’ve created a number of such projects, both for the school market and for military customers.

The Quicksilver Story: Chapter 5

Looking For a Top-Notch Team to Solve Your Impossible Problem?

Let’s talk! We love to take on new challenges. Tell us what you need and we’ll let you know how we can help.

You can reach us here: https://www.quicksilver.com/contact.html#contact.

For more information:

You can find us on the Web at www.quicksilver.com.

The Quicksilver Story: Chapter 3

Tue, 30 Apr 2024 08:00:00 -0700

Welcome to Quicksilver!

This is the third post about the story of our company. You can jump to the beginning here: The Quicksilver Story: Chapter 1 and to the previous chapter here: The Quicksilver Story: Chapter 2

Our story is four decades long, and still going strong. It involves more than 50 games and many more non-game projects that frequently cross over in surprising ways. In this chapter, we’ll explore a number of those projects, including several that are hardware-related.

Non-Game Projects: High-Technology Consulting

The mid-1980s were a brutal time to start a software company. Interest rates were at record highs, and some sectors of the technical market, such as video games, were retrenching and fighting for survival. It was in this environment that Quicksilver launched, on May 1, 1984.

Fortunately, we were located in one of the hottest technology development regions in the world. In those times, Southern California was home not just to massive aerospace companies but also to a large number of hardware companies such as Printronix, JVC and Western Digital. And we had friends at several of these companies.

Even better, consulting for these hardware companies paid very well. We pursued these hardware relationships and landed a number of interesting projects that helped keep us in the green while we developed our far more speculative game business.

One key early customer was Western Digital. They needed skills that we had, along with a group of other local consultants. We were all very experienced with assembly language programming and with the way hardware worked. Some had EE degrees, nicely complementing our computer science expertise. Our previous game work, which required the creation of our own versions of DOS, also helped here. We understood a lot about the way computers accessed their data, and about the IBM PC “BIOS” – the low-level code that ran when the machine booted up.

We got very good at making the most of devices like the ones shown here, such as this Adaptec SCSI board and old-school 5.25” Seagate hard drive – so good that we were asked to develop the complete code for several SCSI “host adapter” boards for IBM PC hard drives by Western Digital and another local company, Rancho Technology, which had the distinction of having built the world’s fastest hard disk controller, clocking in at a whopping 1.2 megabytes per second.

One of the highlights was working on the CD-ROM driver that went into a computer made by a very large company that shall remain nameless, but whose machines looked a lot like this internally:

This helped cement our reputation as experts in storage media, and led to several more years of work with Western Digital, ranging from hard disk design to maintenance of their internal testing tools to advance development on some top-secret projects in one of their labs. We even had Western Digital business cards and an office in the building pictured above.

Most interesting, though, is that this project led directly back to the game business and set in motion one of our major relationships of the 1990s, with Activision. That story will be told in our next chapter.

Non-Game Projects: Cutting-Edge Multimedia

The 1990s were big on “multimedia”. Activision even briefly changed its name to Mediagenic (that didn’t last). And a company down near San Diego, Compton’s New Media, claimed to have invented and patented the concept of multimedia. They sued everyone in the business, including us, demanding a percentage of every company’s revenues. We banded together, located plenty of prior art, and pushed back so hard that the US Patent and Trademark office actually revoked their patent.

In spite of that short-lived challenge, the multimedia business thrived. We developed a CD-ROM version of our hit game, Castles II, with half an hour of color digital video courtesy of a special video driver written by Interplay. We did a multimedia version of the game Shanghai for Activision (more in the next chapter). And, in our most ambitious multimedia project, we signed on to create an interactive digital version of a nine-hour video series called Heritage: Civilization and the Jews, produced by Thirteen-WNET in New York.

We had a super-cool CD-ROM burner back then; looked a lot like this, except it was a foot tall and included a full-height 5.25” hard disk that could hold up to 1 gigabyte of data! It cost us $10,000, and the blank discs cost $50 each. So getting involved in a project like this was a big deal:

Once again, with Heritage, we were in the midst of a technological revolution. We started working on the project by demonstrating how desktop computers could display high-quality, broadcast-quality video using special add-on hardware adapters that decoded the brand-new MPEG-1 data file format. Unlike today, when computers can easily handle digital video, this was an extremely demanding task and required not only super-fast hardware but also gigantic – for that time – hard drives as large as 1 gigabyte in size. Even storing copies of the videos posed problems on our development machines.

WNET put huge resources into the project. They had an office in New York City with 30 artists, map-makers, multimedia personnel and researchers who painstakingly built high-resolution digital maps of the world with overlays showing 5,000 years of history. The production quality was top-notch; any of these maps could have appeared in National Geographic or in a coffee-table book.

But, as usual, there was a catch: WNET’s producers wanted to create large amounts of enhanced, interactive content. After all, interactivity was one of the core precepts of multimedia. They needed a way of scripting these interactive elements. And they also needed a way of ensuring that the resulting data files were extremely small; although the video files were large, they were going to be streamed by the computer, so they didn’t need to stay in memory the entire time. The interactive elements, by contrast, had to be loaded from the CD-ROM before use and had to remain in memory, which was a challenge since the computers of that day typically didn’t have a lot of RAM.

We considered using some of the popular formats of the day, but they were clunky, slow and produced huge output files. So we designed our own format. Leveraging some existing tools. and adding our own custom scripting language on top, we were able to develop a user-friendly system that WNET’s team could use, with minimal supervision and almost no daily interaction with the programmers on the other coast, to create more than 100 unique interactive sequences for the product. The resulting “Heritage Engine” became a key Quicksilver technology (to which we owned the rights, as part of our development agreement with WNET).

Heritage was an epic endeavor. Production – almost all of it in New York – required literally years of work. The legal clearances alone cost more than $250,000. Started in the mid-1990s, the product didn’t officially release until 1999, with two expansions released in the years following. By then, DVD-ROMs had supplanted CD-ROMs, so the product ended up shipping on a single dual-layer DVD-ROM, one of the largest software products ever developed at that time: 8.7 gigabytes of data.

We were proud that Heritage was featured one year as the premium for the annual fundraising campaign of Thirteen-WNET -- one of the most successful premiums ever. Schools featured the app in their curricula, and it remained a popular seller for years afterward.

One important element of this project that’s worth highlighting: we built a custom tool that could then serve us in the future. This has been a common theme throughout the company’s long life: the creation of custom technologies that save time and amplify our abilities. Whether graphics editors, custom operating systems or custom app frameworks, all of these pieces of software have become valuable to us and to our customers because they make our development efforts faster, less expensive and more reliable.

Non-Game Projects: Desktop Publishing

During the 1980s and 1990s, another first-ever concept entered the mainstream: Desktop Publishing. With the advent of the Apple LaserWriter printer in 1985, at a price of $6,995 (almost $20,000 in 2023 dollars), businesses were for the first time able to generate their own "print-quality" documents on their computers.

Quicksilver first met Baudville at the inaugural conference of the Software Publishers’ Association in the fall of 1984. We were debating which new computer would survive the test of time: the Commodore Amiga, the Atari ST or the Apple Macintosh. We took the position that Apple would win this battle, and backed it up by buying one of the very early models: the 512K Macintosh. Baudville’s founders wanted to get into the Macintosh business, so they tapped us to develop a series of products in a relationship that ultimately lasted for 35 years.

Some of our first products included a series of desktop publishing apps. We started with the complex challenge of porting the company’s Apple ][ Award Maker product to IBM PC and Macintosh, which was tremendously complicated, since every dot-matrix printer of that day required custom low-level code to control the platen and ribbon, and had different numbers of dots per inch. Worse, the pixels on the printers were not even square, so all sorts of adjustments were needed in order to make the output come out correctly. Fortunately, our extensive experience with low-level programming (sometimes known as “bit banging”) came in very handy, and were were able to produce the first generation of products for these newer machines fairly quickly.

We then had the pleasure of traveling to Baudville’s headquarters in Grand Rapids, MI and then on to an off-site brainstorming session in lovely Traverse Bay, where we pitched the concept of a high-resolution laser-printer version of Award Maker. This was clearly an idea whose time had come. Laser printers were far, far easier to control than the old dot-matrix models, and produced beautiful pages at the then-amazing resolution of 300 DPI – and, with SQUARE PIXELS! Although the output was only black and white, that wasn’t a problem, because Baudville’s side business involved selling pretty paper stock for certificates. It was an ideal match.

We consider one of our big design strengths in these products to be the way we anticipated user needs and designed the user experience to make it as easy as possible to achieve good-looking results with minimal effort. For example, we set up templates for all sorts of content and all typical variations (e.g., number of signatures) so the resulting document would always be aesthetically pleasing. Then we built “wizards” to walk users through all of the necessary steps. This is harder to do than to just provide a general-purpose document editor, but the end result is much more satisfying for everyone.

Non-Game Projects and The Dot-Com Boom

The late 1990s were a time of intense activity as the Internet became more and more intertwined with daily life and companies began spending heavily on technologies like email, Web sites and online ordering. Money flowed into sometimes-dubious ventures, spawning jokes about companies that went after “eyeballs” at all costs, or promised that “we’re losing money on each sale, but we’ll make it up in volume.”

It was during this time that Quicksilver sent what would become known as the “million-dollar Christmas card.” One of our contacts (a former client who’d moved to a new company) was looking for a team to build a very specialized application that required complex programming skills but also good knowledge of graphics formats and an ability to architect a high-performance server system using the relatively weak processors available at the time. He realized that these challenges would be a perfect fit for a game company.

We helped pitch the concept to prospective business partners, and one of them enthusiastically decided to fund the new venture. In the next nine months, we built one of the very first online coupon delivery systems, featuring a popup application for Microsoft Windows, a highly secure delivery mechanism using what was then very advanced encryption, and special encoding tools that could download and display attractive coupons with very little network bandwidth. This was important, because many people still used slow modems or ISDN connections to access the Internet.

The project paid well, and we even earned shares in the new company, Save.com. Unfortunately, the company closed down less than a year after we launched because they were unable to attract enough of a user base. At its peak, the app had more than one million users signed up, so from a technical and design perspective it was a hit. But the business side wasn’t able to capitalize on this base; we were a little too early.

Coming Up Next: Chapter 4 – An Unexpected Connection

We landed our next big game-industry job as a fluke – the result of a bug in the CD-ROM driver that we’d written for that un-named big computer company.

The Quicksilver Story: Chapter 4

Looking For a Top-Notch Team to Solve Your Impossible Problem?

Let’s talk! We love to take on new challenges. Tell us what you need and we’ll let you know how we can help.

You can reach us here: https://www.quicksilver.com/contact.html#contact.

For more information:

You can find us on the Web at www.quicksilver.com.

The Quicksilver Story: Chapter 2

Mon, 29 Apr 2024 08:00:00 -0700

Welcome to Quicksilver!

This is the second post about the story of our company. You can jump to the beginning here: The Quicksilver Story: Chapter 1

Our story is four decades long, and still going strong. It involves more than 50 games, a half-dozen military trainers, several educational packages, a restaurant and even a device to assist with breast cancer surgery. Games, and especially original titles, have always played a central role. A few short years after we started, we landed several original game development deals that evolved into long-lasting relationships.

Chapter 2 – Original Game Development

PC game development in the mid-1980s was tremendously challenging. Machines were not very powerful, and their graphics capabilities were starkly limited. Unlike even the first-generation consoles, these computers had no built-in graphics acceleration that developers could rely upon. Everything was done by writing pixels as quickly as possible to a raw frame buffer, whose format depended on the video mode that was selected.

This is where Quicksilver’s strengths made themselves evident. Games like Karnov were built for arcade machines that had hardware scrolling and advanced moving object support. In the case of Karnov, the background maps were as large as 30 screens of data. Heavy Barrel posed even tougher challenges. At times, combat scenes could include as many as 100 separate moving objects.

Writing mostly in assembly language, since higher-level languages were too resource-heavy, we came up with clever techniques such as relying on wraparounds of the Intel 8086-series “segment registers” to give us an effectively infinite drawing canvas. This trick saved us from having to copy pixels from one place to another when scrolling, and also allowed us to simplify the inner copy loops, speeding the rendering of every frame.

We ultimately created 28 game ports for Data East. When they exited the PC arcade game market, we did another four games for SNK, including one of our favorites, Prehistoric Isle.

The Interplay Years

Our work on Heavy Barrel attracted attention from Brian Fargo, head of local publisher Interplay Productions, which was rapidly growing and already building a reputation for first-class PC games. Brian saw the power of our custom game engine and approached us with an idea for an original game where players would build a castle and defend it against attack, with the working title Castle Builders. We worked very closely with Interplay’s team, who provided tons of superb advice as well as various game assets, and in 1991 released our first original title, now known as Castles. The game went on to sell over half a million copies and get selected for their 10th Anniversary compendium.

Castles was followed by an expansion set, Castles: The Northern Campaign, and then by a full sequel, Castles II: Siege & Conquest, which featured an entirely new strategic level to the game, more combat options, many more story lines, and fact sheets about each castle. Then, because we had worked on a number of CD-ROM projects for companies like Hitachi and JVC, we were able to leverage our expertise to create a cutting-edge CD-ROM version of the game that included full-screen, full-color digital videos about castles.

The digital photos in the game were edited on what was then a state-of-the-art Macintosh Quadro with a whopping 24 megabytes of RAM and one of the earliest versions of Adobe Photoshop. We used the “clone stamp” and “blur” tools to erase telephone lines, roads and a tennis court from the modern-day photos of the castles.

The success of the Castles franchise opened the door to vastly larger opportunities with Interplay. From 1994 to 1996, in addition to assisting with some specialized projects, such as a high-resolution version of the game Battle Chess, we started work on our most ambitious title to date: Conquest of the New World.

This epic turn-based strategy game was a finely balanced blend of exploration, expansion and empire building, with two clever, original land-combat and sea-combat sub-games. It was the first of our games to ship in multiple languages, including German, French, Portuguese, Spanish and Italian. Japanese and Chinese versions followed.

We once again leveraged our coding skills to create a beautiful random terrain-generation engine that worked great even on the relatively modest 80386 and 80486 computers of the day. Interplay’s artists created gorgeous graphics for the homes, factories, hospitals, churches and other elements in the game, and used relatively new 3D animation tools to create entertaining animations (a bear chasing the settler around the cabin, for example). There was even a “high-detail” version of the game that was able to keep extra-large versions of the objects in an AST Rampage RAM card if one was inserted in the machine (in those days, that was a big deal).

One of our most impressive achievements in this game was the creation of smart AI players who played very well and posed a significant challenge. A memorable moment came when a player emailed us that the land-combat AI was clearly cheating and that no human could beat it. We were able to explain that, in fact, the AI cheated very slightly (+1 on a 20-sided die) in favor of the player, and then show them how to have a chance to beat it (which the player subsequently did).

Our AI also played a critical role in getting the game out on time. Interplay was counting on shipping the game before the end of April, 1996, for financial purposes. That meant we had to deliver final code to manufacturing by then. During the final week, we were making last-minute patches and testing what we could, but we were able to turbocharge our testing by setting up a room in the office with a dozen computers playing against one another in several parallel games. We left in the evening and returned early the next day to find all of the machines still running, so we gave the green light to ship the title on time. It went on to sell about 430,000 copies and get featured on the front cover of Computer Gaming World magazine.

R E V I E W S & A W A R D S

"a title that is both addictive and entertaining."

– GameSpot.com

"...a rare gem that not only captivates, delights, and entertains, but offers a truly immersive experience..."

– San Francisco Bay Guardian

"4 1/2 Stars"

– Computer Gaming World

And Then There Was Star Trek!

What could possibly be more exciting to a true sci-fi fan than a chance to work on a major TV/movie franchise? We were thrilled in the later 1990s to be able to work together with Interplay's internal teams on an ambitious Star Trek strategy game. This would be different from the existing and very successful story-centric Interplay titles. Our new title, Star Trek: Starfleet Command, would be a strategy game with deep, complex, multiplayer game mechanics at its core. It would be based on a well-known board game license, Star Fleet Battles, though the game ultimately would require our game design expertise to translate the turn-based original into a playable real-time game.

Making a game about space combat is a lot trickier than it sounds. In movies, battles are intense, visually exhilarating and always fought at very close quarters. Ships appear gigantic on the view-screens of the bridge, and even the backgrounds are usually rendered in glorious color. “Real” space combat (based on actual physics) would be far more similar to modern naval combat: a game of slow, methodical maneuvering and long-distance weaponry, fought across huge expanses of emptiness. In short, it’s plodding and not very exciting.

“But will it be fun?” was the dominant question when we started work on the game. What will players spend their time doing? How can we balance fast combat action with nuanced, complex decision-making? Months of preparation work went into the creation of our first combat simulations on what were then the latest video cards. And there was magic. What we discovered was that we could adjust the simulated speed of the combat, ignoring “real time,” such that players were constantly maneuvering and at the same time tasked with one too many critical decisions about how to allocate energy to shields, weapons, engines and more. With the excellent design base provided by the board game, we were able to create a carefully balanced experience with many ways to win – a sure recipe for repeat play.

Additionally, we learned a key metric for measuring the appeal of a game: will users want to play with the user interface of the game, even in an unfinished state, simply because it’s fun to use? We discovered to our delight that players wanted to fly the starship through the animating starfield even though all it could do was bank smoothly left and right. We’d play with it while having conversations, transfixed by the simple and responsive visuals. We knew that, if we could keep that appeal as we added real gameplay functionality, we’d have a winning combination.

One of the ways that the new game was going to stand out from the crowd was that it would allow players to choose ships from many different races, ranging from Federation, Klingon and Romulan to lesser races such as the Gorn. Each would have its own, customized appearance for the user interface. This posed a massive design challenge. How could we lay out and process all of the numerous visual assets for each interface, and keep them straight in production? It was a frighteningly complex task, because no commercially available tools existed that could handle the task.

The development team hit a wall with this user interface issue. Creating a tool to do this would take at least six months, which meant there would be no way to produce even the first game-usable assets for months after that. That would blow up the schedule and make the game impossible to develop. Fortunately, one of Quicksilver’s other projects came to the rescue. We had been developing a massive video-based product for Thirteen-WNET New York called Heritage: Civilization and the Jews, which was an interactive history app based on the video series of the same name. Quicksilver had developed its own user interface design and scripting system using a commercially available product; we were able to read their file format and extract graphics data, optional settings, naming and script details from the data files generated by this tool. By using our system (which we owned), we were able to provide the technology needed to get the work done.

But there was another problem: the Heritage engine was a 2D graphics system. It was not compatible with the 3D graphics modes used in Star Trek, and modifying that huge code base would be time-consuming as well as risky. The team was uncertain how to proceed. We held a large company meeting to discuss the alternatives, and came up with an idea: we could simply isolate the Heritage 2D engine in a 2D-only part of the app that would draw bitmap-based textures that could then be rendered by the 3D engine in the game when and where needed. By doing it this way, the Heritage code would not need to change at all, and we would be able to work independently on the game without delay. We called this the “Chernobyl Box” because, like the Soviet nuclear reactor, we poured a giant concrete box around the old system to keep the scary bits inside. It worked like a charm. Interplay was able to deploy a team of artists to use our tools and work in parallel on every version of the user interface while the game development team focused on gameplay. Star Trek: Starfleet Command would go on to become one of the all-time classic Star Trek titles because of its depth of gameplay.

R E V I E W S & A W A R D S

"Starfleet Command is undoubtedly the best combat-oriented Trek game yet."

– PC Games

"... enough eye candy to keep the most die hard Trekkies happy."

– wewp.com

"Boldly playing better than any Star Trek game has played before."

– CG Online

"The game looks phenomenal...Better still are the game’s effects..."

– pc.ign.com

"Starfleet Command is the first truly excellent adaptation of the Star Trek franchise to a game."

– kickass.com

"With Starfleet Command, the curious and not wholly ignoble history of Star Trek computer games finally has a product worthy of Kirk, Spock, and the rest of the classic crew…. 4 1/2 stars. Editor's Choice"

– Computer Gaming World

But Wait – There’s More!

Quicksilver’s versatility landed us some fun, smaller projects with Interplay over the years. Our teams developed some excellent contacts in the audio production and voice-over fields. We were one of the first game shops to hire professional actors in our productions like Castles II CD-ROM.

Company founder William Fisher has always been interested in literature and live theater. He wanted to minor in English, but his combined Math-Computer Science curriculum at UCLA did not allow enough time for the required intensive series of classes. So he focused on specific topics, such as Shakespeare. One of the highlights of his undergraduate schooling was when he talked his way into a senior seminar for English majors only, taught by two actors from the Royal Shakespeare of London. The interpretive skills of these world-class actors impressed upon him what a difference their training could make, and led directly to the company’s approach to voice-overs.

We drew resources from a local repertory theater with a world-class group of actors (which is bigger and better than ever right now). We had the pleasure of being able to work with them to fine-tune their voices instead of struggling with lesser talents just to get something usable. They were usually able to do excellent renditions of all of the audio on the first or second take, which meant that we could move very quickly through even the longest scripts.

Our success in producing audio for Castles led to the opportunity to help Interplay and Infogrames with the production of audio for the Lovecraft-inspired game Shadow of the Comet. They needed a team that could find the talent and manage the live sessions at a local recording studio, and do it quickly. The producers were going to come from France and stay in town for the week required to record the audio for the English-language CD-ROM version.

We drew on our theater connections again and ran such a smooth operation that the recordings were done two days ahead of schedule. The Infogrames team was stunned; based on their past experience, they were expecting to spend a full week of long days struggling to get useful content. They ended up spending their final two days enjoying the California beaches instead. Even though the artwork isn’t ours, we’d love to show off the unique style of this title:

One of the highlights of the production was getting the actors to recite several lines in Cthulhu during the summoning scene. In those days, this was a very exotic request; fortunately, we were able to provide them with a pronunciation guide.

Quicksilver was also sometimes contracted to do art and animation design work. One of our favorite art projects was the high-resolution version of Battle Chess.

This was in the early days of “multimedia”, when computers first began to support 256-color graphics and “high” resolutions such as 640x480 mode. Interestingly, company founder William Fisher was working at the time as a member of the Multimedia PC Working Group of the Software Publishers’ Association. He was charged with helping maintain high performance requirements for the official “MPC-1” designation, and leveraged his detailed understanding of CD-ROM hardware and software to push for uncompromising standards for CD-ROM speed. He was not necessarily a popular person at some PC manufacturing companies due to his insistence on “real” performance and not just paper specifications.

At the same time we were working on our breakthrough first original title, Castles, we were also working with Interplay to turbocharge the visuals for their hit game Battle Chess. Fujitsu wanted a 256-color, 640x480 version of the game to show off the capabilities of their new machine, which would also be released later as Battle Chess Enhanced CD-ROM under the MPC-1 certification.

We were asked to brainstorm and create elaborate hand-animated sequences for all of the captures in the game. This was a ton of fun, and our art team did an amazing job of bringing all of the sequences to life.

Interplay’s art department always liked to leave something unfinished or not-quite-right in each deliverable, so that whoever was reviewing the work would always have something to say. Sometimes, for example, they’d put a little rubber ducky into a scene. So we followed this practice. The first version that we presented for the Rook-takes-Queen capture sequence had the rook eating the piece and then spitting out a rubber ducky instead of the queen’s crown (we had the real one in reserve, of course). Ever since, “it’s great, but lose the duck” has been one of our favorite catch phrases.

Coming Up Next: Chapter 3 – Non-Game Projects

One of Quicksilver’s strengths has been our unique portfolio of games and non-game projects. Despite the different markets we’ve addressed over the years, there’s frequent crossover between entertainment and more serious projects. In fact, we’ve landed several substantial non-game projects specifically because we are a game company that can mix highly creative design with hard-core, high-performance software development work.

In the next chapter, we’ll explore a number of the most prominent and most interesting non-game projects we’ve developed over the years.

The Quicksilver Story: Chapter 3

Looking For a Top-Notch Team to Solve Your Impossible Problem?

Let’s talk! We love to take on new challenges. Tell us what you need and we’ll let you know how we can help.

You can reach us here: https://www.quicksilver.com/contact.html#contact.

For more information:

You can find us on the Web at www.quicksilver.com.

The Quicksilver Story: Chapter 1

Sun, 28 Apr 2024 12:00:00 -0700

Welcome to Quicksilver!

Our story is four decades long, and still going strong. It involves more than 50 games, a half-dozen military trainers, several educational packages, a restaurant and even a device to assist with breast cancer surgery. But, all throughout, games have always played a central role. In fact, virtually all of our non-game projects came to us specifically because we know about games, user interfaces and usability.

Several themes show up repeatedly over the years:

Synergies between projects spanning very different markets
The amplifying power of great tools and proprietary engines
Relationships that pay back years or even decades later
The importance of asking the right questions and solving the right problems
Coming to the rescue of projects in trouble
The value of hiring the right people for the job
Copy Protection, and Security by Design
Sophisticated AI across all product lines
Always learning new skills

It All Began Here: Mattel Electronics

In this series of posts, we’ll explore the history of our studio, starting with our beginnings at the legendary Mattel Electronics in Hawthorne, California – home of the Mattel Intellivision game console – and how we created our new company out of the wreckage of the Great Video Game Crash of 1983.

Interesting tidbit: look at the color of the sky in that photo. It’s not that way because of the age of the photo. In the 1980s, in Los Angeles, the smog was so bad that the sky was often bright orange in color during the day. It’s much better now. But this is what it really looked like on many days.

That was the beginning of the era of programmable video game consoles. The Intellivision, seen here at bottom center in this photo from the National Video Game Museum, was the first 16-bit console, sporting a powerful (for its day) 880 kHz General Instrument CP1610 CPU and a custom graphics chip that could display eight simultaneous moving objects and play sounds on three independent channels.

Ours was a world of firsts. Virtually everything we did had never been done before. Sports games with the ability to control any of the players on the field. Strategy games playable on a TV set. Several different takes on space combat. And even human voices in games, like in the popular title B-17 Bomber.

The cover art was fanciful and in no way represented the games within. Some pundits insisted that these new “video games” were just a fad, no more lasting or important than Cabbage Patch Kids. Little did we know just how much of a tectonic shift in society was about to take place.

The following Intellivision games were all written by some of Quicksilver’s founders (B-17 also included the legendary John Sohl, author of the mega-hit game Astrosmash). B-17 was the largest of the lot, weighing in at a massive 12K, 5K of which was dedicated to voices.

The team that would later found Quicksilver became experts at rescuing projects that were in trouble.

Both Space Spartans and B-17 Bomber ran into production issues, and needed a focused team to get them out the door. Both were highly ambitious, overly complex in some areas, and not fun to play.

For Space Spartans, the game tried to be a full 3D galaxy navigation and combat game. We still have copies of the original EPROMs that were burned just before we took over the project. This rare photo shows the interior of a "T-Card" used for development, with the four EPROMs containing the 8K of game code (Intellivision games used an unusual 10 bit wide format, so two EPROMs were needed for each 4K bank).

Here is the original game being played. Navigating the galaxy in three dimensions was tricky and tedious. There was scoring or "leveling up" in difficulty, and there was no enemy AI, so the game felt "flat. Our team scrapped the full 3D galaxy and focused on a dual-layered game with both strategic and tactical elements. Then we added polished combat and clever enemy AIs that could even fly their ships in formation to attack the player.

These changes worked very cohesively, especially with the addition of the carefully constructed voices. We had a variety of voices so it was easy to tell them apart: female, male and robot (we did a few status voice prompts, such as the end-game “the battle is over” in a robot voice because we could use a lower bit rate and therefore save space in the cartridge).

B-17 Bomber similarly featured a series of gorgeous technical achievements in search of a game. There were numerous different camera views, including the beginnings of code to handle attacks by enemy fighters. There were even top-gunner and bottom-gunner views.

But the code base was huge and could never fit in 12K as required. Some super-cool features, like the rolling altimeter readouts and the top-gunner, had to be scrapped. Then we needed to tune the flight parameters so that they made an interesting game and required interesting tradeoffs – how much fuel vs. how many bombs, for example.

Fitting the game into the cartridge required some exceptionally difficult optimization of the code and voice data. We had to play some pretty strange tricks with the assembly language of the console’s 16-bit processor in order to jam in the last few fixes and get the title out the door. We shipped the ROMs on an airplane via courier, making the deadline by a matter of hours.

Autographed copies of these games still appear and are sold at “classic game” and “vintage computer” events. For example, this happened at the Vintage Computer Festival in February, 2024:

The source code listing for Space Hawk still exists. It’s now archived at the National Video Game Museum. Not only is it one of the few existing examples of early video game code, but it also contains at the end of the listing a complete day-by-day diary of what was done on the game during development, beginning in August of 1981. This is a short excerpt of the printed paper listing (the full document is a 1”-thick book, printed on 11x14” line-printer paper – a true relic of that era).

Those with sharp eyes will notice that the original working title of the game was “Space Hawks,” which changed at some point along the way to “Space Hawk” by the time it was released.

Personal Computers: Apple ][ and IBM PC

Our people were some of the first to develop games for personal computers such as Apple ][ and IBM PC, starting in 1982-1983 at Mattel.

Mattel wanted to expand onto other platforms, and two of the most popular in that day were the Apple ][ and the IBM PC. Mattel actually formed a deal with IBM to gain early access to some of its newer computers, such as the PCjr, so we could develop games that took advantage of their special capabilities, such as enhanced video modes. In-house, we had people working on Apple and IBM versions of Night Stalker, Lock ‘N Chase and Data East’s BurgerTime. A few of these, such as Apple ][ BurgerTime, actually made it to the market.

We even expanded our team by collaborating with Mattel’s partner in Taiwan, creating Mattel Electronics Limited, Taiwan (MELT) to work on Apple and IBM products. Quicksilver’s William Fisher was tapped to hire and train the Taipei-based team, and spend the summer of 1983 there to make sure operations spun up smoothly. The team there ultimately had 18 people writing games.

These titles gave us our first taste of the copy protection and computer security work that would become a significant part of Quicksilver’s future business. For example, we worked with our team to analyze various mechanisms for preventing the copying of floppy disks, even traveling to the manufacturing sites to see their production facilities in action. We celebrated our ability to “crack” supposedly secure systems, and ended up writing our own system to protect Apple ][ BurgerTime. One of the highlights of that project was a special Apple BASIC program called “SHUFFLE”, which would take a file containing assembly language code and “shuffle” it like a deck of cards while maintaining the same functionality, effectively rendering the code untraceable.

When Mattel Electronics officially folded in early 1984, Quicksilver ended up doing over two dozen Data East arcade game conversions to personal computer platforms.

The Great Video Game Crash of 1983

The year 1983 began with visions of endless expansion and opportunity in the game business. Much has been written about those times, so there’s no need to delve into detail here except to say that structural factors in this new business exposed some fatal weaknesses that ultimately took all of the players off of the table. Major companies lost money and went out of business. Mattel Electronics lost so much money that it almost took down Barbie and Hot Wheels when it crashed in early 1984.

Just like that, the entire Intellivision crew lost their jobs in several layoffs, ending with a final closure on January 20, 1984. Several of us didn’t want the party to end, so we gathered together and decided to start our own company. Ultimately, three of the Mattel programmers became founders of Quicksilver Software, Inc. We originally wanted to call it “Blue Sky Software,” but that name was taken.

It’s good to have friends. Within months of kicking off the new company and buying ourselves several now-surplus Apple ][ computers from Mattel, we landed two excellent projects: one to help develop a state-of-the-art lighting console, and a second to develop what would turn into a series of nearly 30 arcade game adaptations for Data East and SNK. This was the first of a long string of extended customer relationships that became a key contributor to our long-term success. We have since had many customers who worked with us for more than a decade.

The Data East projects were technically challenging. Because the personal computers of the time were only modestly powerful, and because their graphics capabilities were very limited, we had to work hard just to get things to show up on screen at all. The most challenging were the low-end IBM PC-compatible machines, which sometimes had only 320x200 graphics in four “CGA” colors: pink, cyan, black and white. Creating playable games with so few colors was quite a trick.

The Apple ][ won the prize for the weirdest graphics mode. Their “HIRES” mode had eight colors, but two of those were different versions of black and white, so in reality there were six colors: black, white, orange, green, purple and blue. And sometimes colors of one type were not allowed to be next to colors of a different type. As Wikipedia points out, this was weird even by the standards of the 1980s; it was a side effect of designer Steve Wozniak’s efforts to minimize chip count in the machine (chart courtesy of Wikipedia).

We were also tremendously limited when it came to computer memory. These machines frequently had only 32K or 48K of available RAM, including space for the operating system, so we had to squeeze out every last byte. One way we did this was to create our own disk operating system (DOS) to replace MS-DOS and Apple’s OS. We called this Quick-DOS (tm) and used it as a fast and very small bootloader for almost all of our personal computer games. This would open up some interesting opportunities in completely different markets a couple of years down the road.

We also started discovering the value of creating our own tools to support development efforts. For example, for these games we created a custom “tile” editor that allowed our team to create the levels of the games quickly and reliably. This was extremely important for large titles like Karnov. We designed the editor to handle multiple different graphics modes, and to save data files in an extremely compact form that was ideally suited to the computers of the day. The editor was used many times in the coming years, over nearly 30 titles.

Soon, we were busy, expanding and setting up our first office in Costa Mesa, California adjacent to Red Hill Avenue. Every one of our later offices ended up next to that same street – not because we planned it that way, but because we kept finding great places around the airport.

Soon, in addition to our game projects, we were working on all sorts of interesting hardware/software hybrids, like the Prestige Series of theater/TV lighting control consoles that we helped develop for Lee Colortran. And we began working with companies like Western Digital, Hitachi and JVC on various high-technology projects like the brand-new CD-ROM drives. Interestingly, all of these hardware projects added a great deal to our game development projects, since we were one of the very first game studios to develop expertise with operating system drivers and optical media.

Coming Up Next: Chapter 2 – Original Game Development

Porting games from arcade to home was good business in the early 1980s. But original game development is where the real action is, and our work on porting soon led to breakthrough relationships with original game publishers.

The Quicksilver Story: Chapter 2

Looking For a Top-Notch Team to Solve Your Impossible Problem?

Let’s talk! We love to take on new challenges. Tell us what you need and we’ll let you know how we can help.

You can reach us here: https://www.quicksilver.com/contact.html#contact.

For more information:

You can find us on the Web at www.quicksilver.com.