Head Tracking on the Wii

0_0

😮 That's mind-bendingly awesome.

THIS IS THE SINGLE GREATEST THING I HAVE SEEN IN MY ENTIRE LIFE!

Now just to wait for it's implementation, and done correctly.

It was originally going to be included as a bonus feature in Boom Blox, but EA pulled it out at the last minute, the bastards.

Someone at work showed me the whole set of videos by this guy several months ago. He really has some nice unintended uses for the wiimote, the head-tracking thing being the most interesting.

This is just too amazing!

rock_nog wrote:It was originally going to be included as a bonus feature in Boom Blox, but EA pulled it out at the last minute, the bastards.

Yes, EA are pretty big jerks. Seriously. I'm testing of their games, and we found this MAJOR issue. ...They said they're not fixing it. My whole team WTF'd.

...not moention I found another major bug that could be fixed by deleting ONE WORD from the tutorial. ...Are they fixing it? NO!

Yeah, I know the release date isn't too far away, but COME ON! How hard is it to delete one word?!?

Aegix Drakan wrote:Yes, EA are pretty big jerks. Seriously. I'm testing of their games, and we found this MAJOR issue. ...They said they're not fixing it. My whole team WTF'd.

...not moention I found another major bug that could be fixed by deleting ONE WORD from the tutorial. ...Are they fixing it? NO!

Yeah, I know the release date isn't too far away, but COME ON! How hard is it to delete one word?!?

A good change control process means that before any changes to requirements or features are made, they are proposed to a change control board. If the board decides the change is acceptable and can be made, it gets made. Criteria used here are things like:

• How many users will encounter the bug?
• How catastrophic is the bug?
• How much effort would it take to fix the bug?
• What kind of scheduling impact will the fix have?
• Will there be changes to the test process? (This is always yes -- you have to test that the bug is fixed!)

A good test process takes a looooooong time to complete. The first step is unit tests: tests that run automatically during every build. These basically test the API of the software for sanity ("What happens when I tell the game to give me -1 of an item?" etc.) If you change something, you need to make new unit tests or change old ones so that the change is tested. The next step is manual tests: this is tests for things that can't be done automatically and I believe for video games the developers don't really do this. The final step would be user testing, where you let people actually play the game and see what happens.

Let's say you make a really simple game and there's 10 unit tests. You're localizing the game for 3 regions, so you have to test 3 products; that's 30 tests. You're making the game for the 3 major consoles, so that's 3 different units to test that come in 3 localized flavors, 10 tests per unit: 90 tests. Once the unit tests complete, you need to let the testers play with it; let's say 20 hours per unit is acceptable. That's 20 hours for 3 consoles, each console has 3 languages, so you need to handle 180 man-hours of testing: 7.5 days if you have slaves you can push 24 hours; in reality this is 22.5 8-hour days.

For the teensiest, tiniest change, a good process will require that you rerun the entire test suite. Let's discuss what happens when you delete just one word from the tutorial; this is what the change control board would think about. Don't think a small text change can matter? If the game is written in a low-level language, the programmers might be aware of the memory address of all text strings. Deleting a word modifies all of these memory addresses, so any hard-coded addresses must be changed. Software engineers call this risk. First, a developer has to change the text of the tutorial and update any unit tests, then do a quick sanity check on a build to make sure it works. This is probably 30 minutes for the change and 2-3 hours minimum for a build and check. Then, localization has to be notified to make sure that the other 2 versions don't need updating as well; it might take 2-3 hours to get everyone in the loop (if the time zones are aligned), 30 minutes for them to change, and 2-3 hours for new builds to test. We're done with phase 1 and it's been 5 hours; only 3 hours left in the business day.

Now the build has to be given to the testers; we require 180 hours of testing, so it's 23 days from change to validation for just a little bitty text change.

Now think about what might happen if your issue is something major that would take a lot of effort to fix: 3 developers for a week. There's a 22-day cost for the testing phase; do you hold up the release for a month and spend 120 man-hours of effort for this, or let people go to gamefaqs.com and find out what to do when they get confused?

I'm not saying EA's justified, but I am explaining why occasionally I find easy-to-fix bugs in our software and my boss tells me we aren't fixing it for a while. I've got a list of 3 bugs that look very simple from a customer viewpoint, but fixing them will require me to rewrite huge portions of mature code and risk changing behaviors on which our customers depend; each of these three bugs will require an entire release cycle to fix, which means I can't work on any other features while I fix them. Sometimes, it's just not worth fixing things.

I was much more impressed when I saw this:
http://www.youtube.com/watch?v=5s5EvhHy7eQ&feature=user

Or course that was also a few months ago. Still think its awesome.