The Quicksilver Blog: Careers Part 1
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