Editor's Note: This article is reproduced from Issue 66 of Xcell Journal with the kind permission of Xilinx.
This project started as a way to hang out with my 16-year-old son, Alex. "Dad, Guitar Hero rocks. We've got to get one" — simple words that would unknowingly set me on a quest to play that perfect game of Guitar Hero myself. Simple, I thought, because on and off, I've had a guitar in my hands for upwards of 45 years. How hard could this be? Surely I was capable of pressing a plastic fret button and a plastic strum button on a plastic guitar.
Well, although my son and I started at the same level, it wasn't long before he had moved up the difficulty scale and placed his initials on the top of the "high score" display of every song. Try as I might, there was just no way I could get my four fingers to the right place, at the right time, and play those five buttons on that plastic fret board anywhere close to the speed my son was able to do it. A quick search of YouTube confirmed my suspicions. Thousands of kids could beat me in their sleep.
There was only one way I was going to beat Alex at this game — I was going to have to cheat. I was going to have to put my engineering background to work to build my surrogate.
My first thoughts about a system to conquer Guitar Hero on my behalf were simple. Some kind of light sensors stuck to the front of the TV, connected to some kind of microcontroller-based computing platform, driving some kind of solenoids to actuate the physical buttons on the guitar. Rube Goldberg would have been proud.
Many of my projects start as a kludge and get ... well, let's say refined over time. This one was no exception. It didn't take long for my friend Steve to say: "Just look at the composite video signal and electronically operate the buttons," quickly followed by another piece of advice: "Use a Xilinx FPGA as the computing engine."
"It's like building a project the old-fashioned way," Steve told me. "You go into your box of TTL parts and wire them together into any function you need, except you do it on your computer and you have an almost unlimited number of gates," he said. "You want a 13-bit shift register, make one. You want a 5-bit adder, make one. Rewiring the project takes about 30 seconds. And everything works at gate speeds — no more counting cycles to see if you can get a task done in a certain period of time."
Steve, you see, is a video engineer who was responsible for building one of the first nonlinear editing systems in the 1980s. No self-respecting video guy would let anyone build a kludge system like the one I was describing.
After doing some research, I found that not only can you build arbitrarily complex logic, but you could download a microprocessor core with code into the FPGA and get the best of all worlds. Long ago, gates were my crayons. But gates were expensive. They were packaged in their own plastic case with their own leads and in need of external connection, which was provided with a wire-wrap gun and a handful of Kynar-covered wire. It was time-consuming and error-prone. Changing the design was painful. Unwrap, wrap, unwrap, wrap.
This was going to be different. Write some code, compile it, download it to the part and try it out. Need an 11-bit counter? Just write a few lines of code. Problem with the design? Redo it. Want to extend it? Don't move it from the test bench to the prototype area, just download new code one more time. A full loop takes a couple of minutes.
It's not like this capability hasn't been available for years — it's just that I hadn't tried it. I've been a microprocessor guy. Well, now I've tried it and I like it — a lot.
Soon the system design was starting to take shape. Composite video in, a little analog processing and level shifting, an FPGA-based computing engine and drivers for the buttons.
I know, I know — it's a completely ridiculous project. Why waste time building a computer to play a computer video game? The enormity of commitment of both resources and time was baldly apparent. So as I have done countless times in the past, I simply disguised the exercise as a learning opportunity. Not knowing much about the inner details and intricacies of either composite video or FPGAs, I decided this was my kind of project. Not to mention, I'd get the chance to melt some solder.
What is Guitar Hero?
It's an insidiously simple game that runs (in this case) on a Nintendo Wii. Guitar Hero has been a huge commercial success. The game comes with a plastic guitar that has only five buttons on the neck and a plastic bar on the guitar body that you use to "strum" the instrument. When you start the game, you're presented with a list of songs. After you select one — say, "Purple Haze" — a vanishing-point guitar neck appears down the center of the screen. Around it swirl animated graphics and a scoreboard.
As you cross a line at the bottom of the guitar neck, the player's job is to press the correct button or combination of buttons and hit the strum bar. Success gains you points at an ever-increasing multiplier, failure gets you an annoying sound and a multiplier reset. A whammy bar augments your score during sustained notes, and shaking the guitar at certain times during a song increases the point multiplier even further.
It takes consistency to build big scores. Miss enough notes, and the game delivers a notice of failure along with degrading boos from the (virtual) crowd. There's nothing like a game of Guitar Hero to keep you humble.
Sizing up the design challenge
The Guitar Hero game is, in concept, a simple one. Video is presented on a monitor in two basic sections. By using a DVD recorder I was able to capture, frame-by-frame, a game being played. Upon review, it was easy to see the step-by-step progress the game makes.
In general, there are two areas of the screen (see Fig 1). Down the center is the guitar neck, starting small at the top of the screen and getting progressively larger at the bottom, presented in just the same way as a vanishing-point drawing exercise you might have done in elementary school. On the left and right, graphics add excitement to the game, but they are extraneous and can be disregarded. Frets start at the top of the neck and travel down the screen, getting longer horizontally as they make their trek.
1. As the pucks move down the screen they expand, giving the graphic impression of coming toward you. I found scan line 198 was about the right place to look for pucks; notice the green puck passing through the scan. By having five instances of the puck locater running in the FPGA, the computer effortlessly found and stored the presence or absence of a puck. Its "highlight" signal generated the highlighted line.
Overlaid on the neck, and traveling at the same speed as the frets, are colored pucks that look like cream-centered doughnuts, tilted in perspective. Designed to signify necessary button presses, these colored pucks start from the top of the screen as small circles and get wider and wider as they move down, spreading out and expanding in diameter, to give the illusion of moving toward the player.
