Dawn of the Geeks

The next game I decided to go with from the original Elmo game is the Feed Dorothy game. The object of this game is to move Dorothy so she catches the food. In my version you feed her cookies. In the original version the object is to feed Dorothy fish food. Bleck.

From a technical standpoint this demonstrates some additional game programming concepts. The cookie comes from the fish food container. The fish food container moves around and shakes. Dorothy is actually animated to look like her tail is waving. A 2D image of a goldfish was progressively modified with the “bulge” filter in Paint.Net (a free and excellent image editing tool for Windows). The fish object then progressively rotates through the frames of animation. “States” are used extensively to keep everything in sync. Also, both the fish food and Dorothy face the direction they are moving.

We’re no longer simply moving around static images like the Soccer Game.

The next game to be implemented is the Alphabet Game where Elmo must dodge obstacles and collect one letter at a time. I found a couple examples of Elmo saying the alphabet on YouTube. One is a rap song. The other is a skit with Grover where Elmo says every letter except one. I’ll see how I can best use those in the Alphabet Game.

For Christmas I picked up Sesame Street Elmo’s World My First TV Fun & Games because it was only $5 at a store that was going out of business. My daughter is only 21 months and likes to play with the Nintendo DS because she can use the pen and make it do things. I figured that since this thing has all of three giant buttons she might be able to make use of it.

Here’s a sample screenshot:

She enjoys it because it has Elmo. However the graphics are dreadful and it features no actual music or sound effects related to Elmo. The graphics are primitive NES quality. Worse than Super Mario Bros 1. So I’ve decided to remake the games using the Wiimote and the XNA Game Studio.

It’s coming along nicely. The soccer game is mostly done. I’m just hunting for my Elmo sound effects. For as popular as he is there is a distinct lack of Elmo media on the net. I guess when most of your fans are still in their diapers you can’t expect too many fan sites to pop up.

On top of being something that my daughter can actually do (she likes swinging the Wiimote around and seeing Elmo move) it’s a good demonstration of how to put together a game using the Wiimote and XNA Game Studio.

I like my software rendering stuff because I’m doing a lot more. But the XNA Game Studio is my choice for this project. The focus is less on learning graphics programming and more on making games with the Wiimote. It’s ridiculous how easy the XNA stuff is to learn. There is no shortage of sample code to do anything you want. It even integrates with Visual Studio Express so you can get started making 2D or 3D games with little to no effort. And best of all, no cost.

Sesame Street really should look into releasing games for the Wii and DS. Parents would love it. There are so many educational games out there that just have terrible graphics and/or require sub-par gaming systems and there’s no reason for it. My parents didn’t have video games. These days kids are growing up with parents that played and still play video games. Parents today are going to have an XBox, Playstation or Wii. Why require that they buy yet another console or handheld system when they already have one or five?

I’d rather buy an educational title for a system we already own than have to buy yet another console just to have educational titles. With Nintendo’s expandable Wiimote it would be ideal for companies that not only want to create simple games but also have simple controls. I’d happily pay $15 for a Wiimote extension with 3 giant buttons for a toddler to use if I could get simple games for her to play as well. That makes more sense than $5 for yet another game system that she’ll quickly grow out of.

In the meantime, I’ll have to stick to making use of my talents to create my own educational titles for my kid to play.

One of the early mistakes people made in understanding how the Wii works was thinking that the Wii Sensor Bar actually did anything. After all it plugged into the Wii with what looks like a USB cable and you must have it on or the Wii Remote doesn’t work. Turns out that it’s essentially just a flashlight with infrared LEDs. You can put two candles on top of your TV and play the Wii.

The second misconception seems to revolve around what the Wii Remote actually does. I e-mailed Brian Peek who wrote the Managed Wiimote Library and he was apparently unaware that there was anything missing in his library. He was under the impression (as are a lot of people) that the points returned by the Wiimote for the infrared sensors indicate where the Wiimote is pointing. He didn’t realize that you can’t use those values by themselves to use the Wiimote as a pointing device.

It appears to work in some cases but once you start rotating the Wiimote (you know, twisting your wrist) things don’t work anymore.

Those values are actually where the infrared points appear in the camera. They do not by themselves indicate where the wiimote is actually pointing.

There’s a very good reason for that: the Wiimote is a collection of sensors that reports back the raw data to the Wii. It is not a computer. The individual sensors are not communicating with each other. The camera finds the x and y coordinates of its light sensor that are activated by the infrared light that hits it. The accelerometers measure their respective g-forces. There is also circuitry that indicates what buttons are being pressed. All of those parts feed their data into a bluetooth transmitter.

The reason that the Wiimote is not doing calculations is because it would add additional cost to the controller for no good reason since there is a perfectly good computer sitting on your entertainment center. All that raw data is feed to the Wii and the Wii crunches the data and spits out usable information that games can make use of. The Wii takes the positions of the infrared points of light that the camera sees and combines it with the data from the accelerometers and generates the X and Y coordinate indicating where on the screen the controller is pointing.

If the remote were to do that it would require some sort of CPU and memory and custom software, etc. As it is the Wiimote is not a programmable device. All it does is take data from the sensors and feed it through a bluetooth transmitter for more sophisticated hardware to deal with. It’s genius in its simplicity.

Anyway, the point is that the Managed Library is a great start but like the Wiimote, it only gets you the raw data. You still have to do calculations to realize the full potential of that data. The biggest missing piece is being able to use the Wiimote as a pointing device. I’ve got a good start on that as I’ve mentioned in previous posts. I’ve started work incorporating my pointer code into an XNA project to create a few sample games using the Wiimote as the pointing device.

Yes, that’s right, I’m using a game programming library intended to be used to create XBox games to create Wiimote based games. My software rendering library I wrote from scratch is nice and all and is fun to work with but it’s not going to cut it for making the types of games I want to create now that I can make better use of the Wiimote.

Hopefully I’ll have a release of some games this weekend. The games I’m currently working on are designed for a 21 month old. Perfect for demoing the capabilities of my Wiimote code without burying it under complex game code.

This is a higher resolution of the sample Wii Pointer app in action.

You can download the app from
wiimote_pointer.zip

Everything is precompiled and ready to go. All the source code is also included. Just follow the directions at Brian Peek’s blog to get your Wiimote connected to your PC. You must have a sensor bar for this app to work properly.

Hit “+” on the number pad to increase the resolution (not the “+/=” key). You can also drag the corners of the app to change the resolution.

common\input_buffer\wiimote_class.cs contains the logic for figuring out where the Wiimote is pointing.

I updated the code to be able to approximate the location of the pointer when one of the IR sensors goes out of range. It works best when you stand several feet back from your computer monitor.

I’m sure there are some potential improvements that could be made but it is an excellent starting point for using the Wiimote as a pointing device in your own games. The sample app uses software rendering so you don’t need DirectX or OpenGL to try it out.

I’ll have some sample DirectX games created in a week or two that make use of this library.

In my previous post I simply checked the orientation of the two IR points to determine if the Wiimote is upside down. After playing around a bit I noticed something strange. If I moved the Wiimote off the screen and then back on the screen sometimes the two points would reverse and the pointer image would flip upside down. Apparently the order of the IR points depends on which one the Wiimote registers first, not how they appear on screen. So you can hold the Wiimote perfectly horizontal, move it down off screen and back up and (what are the blue and red indicators in the above screenshot) will flip position.

So that method doesn’t actually work. What does work is even simpler: the roll angle is the atan of the z acceleration and the x acceleration. The pitch angle is the atan of the z acceleration and the y acceleration.

In C# that’s simply


//WiimoteLib.AccelState acc passed into the method
roll = (float)(Math.Atan2(acc.Values.Z, acc.Values.X) * 180.0 / Math.PI) - 90.0f;
pitch = (float)(Math.Atan2(acc.Values.Z, acc.Values.Y) * 180.0 / Math.PI);


I subtract 90 degrees so that horizontal is 0 degrees. I think the pitch could use a fixed adjustment as well but I haven’t made use of it yet so I haven’t looked into it. I use degrees in my code in various places but you could just leave it in radians.

Now the hard part is figuring out what the Wiimote is pointing at. I finally downloaded and tried out the head tracking demo that became very popular on YouTube. I was very disappointed to find that the IR values were being used as pointer position values directly. What that meant is that the demo only seemed to work because the sensor bar was kept horizontal. If you rotated the bar the motion was no longer correct. In other words, it was clever but the hard part was glossed over.

So let me make this clear: the IR values cannot be used directly as the location that the Wiimote is pointing at.

Hunting around on the internet I found a lot of references to triangulation and doing rotations but nobody had any equations. There’s a mouse demo out there were if you hold the Wiimote still but roll it slightly the cursor shoots across the screen. The reason is because it’s misusing the accelerometer data. Rotating the Wiimote in any direction doesn’t not necessarily imply acceleration: and the Wiimote knows this if you do the math right.

So what is the math?


position = new point_class((1.0-ir.Midpoint.X) * (double)sx, ir.Midpoint.Y * (double)sy);


If you’ve looked at the Wiimote Library test app you’ve seen something that looks like that. It’s basically unchanged except for one “minor” detail: the x-axis is flipped.

And you’re not done. That equation gives you the midpoint of the two IR sensors with the x-axis flipped. That doesn’t give you where the Wiimote is pointing just yet.

To finalize the equation you move the position point to the origin. In my code you subtract the point in the center of the screen from the position. You then rotate that point using the value of Roll. Now, add the center of the screen point back to position.

Done. That’s it. That’s the secret of using the Wiimote as a pointer.

Is it perfect? No. You can’t get all the way to the edges because this method requires that both IR sources be visible. It also may not be getting the exact spot on the screen that the Wiimote is pointing at but it’s close enough that I can’t tell. If I point the Wiimote in the upper left corner and roll the Wiimote the pointer stays in the upper left hand corner and so on with the rest of the quadrants.

So it’s a very good start. The basic thing to keep in mind is that input has to be simple. The equations for processing input have to be simple and fast otherwise you’re wasting CPU cycles that should be used for graphics and game play. So there was no reason for me to believe that you have to be doing complex 3D equations to get the pointer going.

Maybe that’s ultimately what Nintendo is doing, but you don’t have to. I’ll have the full code and download available soon so you can try it out yourself and maybe find ways to improve it.

One of the things the Wiimote doesn’t know by default is whether or not it’s upside down. This presents a mild problem when using the Wiimote Library and you want to rotate the pointer most every Wii game does.

The trick is realizing that the Wiimote is calculating the angle based on the two outer points. To know if you’re upside down you simply check to see which point is to the left of the other. You then invert the angle if the points are flipped.

The angle given by the Wiimote is from -1 to 1 so you subtract the angle from 2 when the remote is upside down. You multiply the given angle by 90 degrees to get the 0-360 degree angle.

In Wii-Land the x axis is pointing into the screen so we use the x axis rotation to determine how to rotate the pointer on the screen.

You can see in the code below that the x pos is flipped. That’s because 1024 is the left side of the screen and 0 is the right side of the screen according to the Wiimote. I flip that as well to simplify things.

This is all part of the work I’ve been doing with software rendering. I finally got a wireless Wii sensor bar to use with my computer so I can start making games that make use of the Wiimote and other Wii controllers.


if (ws.IRState.IRSensors[0].Found && ws.IRState.IRSensors[1].Found)
{
remote.rot_x = accel.X;
remote.rot_y = accel.Y;
remote.rot_z = accel.Z;

if (ws.IRState.IRSensors[0].Position.X < ws.IRState.IRSensors[1].Position.X)
remote.rot_x = 2.0f - remote.rot_x;

remote.pos_x = 1.0f - (float)ws.IRState.RawMidpoint.X / 1024.0f;
remote.pos_y = (float)ws.IRState.RawMidpoint.Y / 768.0f;
}

I decided to start up a Team Fortress 2 dedicated server at tf2.dawnofthegeeks.com. That’s hardly unique. What is unique is that it is running a very verbose stat generating plugin.

The plug in is a modified version of the N1G-TF2-RANK plugin which out of the box as given is pretty much trash. The plugin is supposed to generate the MySQL tables automatically which it does but incorrectly. So no stats get logged until you manually add default values for everything in the table structures. The biggest problem is that it only does cummulative stats and doesn’t tell you player v player stats. What that means is that you can’t see how well players fare against each other and you can’t view improvement (or lack thereof) over time.

So what I did is whip up an “action_log” table which collects raw data from the modified plugin. The modified version simply feeds the action log with things like “bob killed steve” and even tells me what weapon was used.

The result is that eventually the above listed web-site will be displaying some pretty interesting charts.

The one good thing about the given plugin is that it supplies a very good skeleton for plugging your own database queries into. So if you want to run a Team Fortress 2 server and have some good stats get the source for the above plugin and edit it to generate the stats you want. It took me only about two hours to get it generating more useful stats. With some more time I could clean up the code even more. There are some places where I think the code could be simplified.

The original plugin also allows you to see the top 10 players in game. I broke that with my modifications. Future feature, once data is being collected and charts being generated, is to put that back in. Although I don’t see the point of having that in game. What might be useful is telling the player who to avoid and who to go after based on previous encounters.

The possibilities are endless but I think I’ll give it at least a month of getting the basic stat collections taken care of before jumping in too far.

Free Ringtone Heaven is currently being purged and reloaded. It’ll probably be an hour or two before it’s back up. The biggest change is to the file and directory structure both on the server and in the database. Previously all stats were tied to file ids. Now they’re tied to the file hash. What this means is that in the future I can do some reorganization on the files without having to take the whole site down. And no stats will be lost.

The next step is to separate the physical file location from the virtual directory structure. That will make it even easier to adjust the location of files without having to reupload all the ringtone files. With all the current changes, that switch should be transparent and require no down time.

Free Ringtone Heaven.com is getting a redo. When first designing a web-site you tend to whip things up quickly and get them out there to see what happens. Then over time you tweak it here and there and maybe add a feature or 10. And eventually the site becomes stale and ugly.

That’s when you get to go in and force yourself to do things right. It’s time to clean up the code, apply better code design practices, update the interface, tweak the database, etc. And finally when it’s all done you get to tear down the old site and replace it with the brand new one.

In the case of Free Ringtone Heaven there is myMobile which users could use to upload their own files. However, it was so poorly implemented I’ve decided to just tear it down. People weren’t really using it anyway. So there will be a brand new myMobile launched. So when the new myMobile launches you will need to create a new account.

In that sense, I got lucky. There’s nothing about the old site I have to save. Except for the ringtones of course. I’ve got the backend pretty much complete with far more intelligent usage tracking. myMobile will have a password recovery feature finally. I’ve also cleaned up the ringtone directory structure a bit which should make it easier to find what you’re looking for.

The coming changes are too numerous to list them all. My goal is to have the new version launched sometime this weekend. FunkyCatz.com is my other ringtone web-site which I used to try out some things that are now being applied to Free Ringtone Heaven.

There is an old saying “if it ain’t broke don’t fix it.” Well technically Free Ringtone Heaven ain’t broke but it certainly has a lot of room for improvement. My main goals are to fix some of the stale aspects of FRH with the new download tracking and improve myMobile.

Sometimes it’s good to go back deep into the code of a site you built long ago and give it a redo. You’ll discover things you could improve, simplify and maybe even learn more for your next project.

One of the nice things about being able to run a server off your home internet connection is that you can do whatever you want. You can build the server you want, install the software you want, run the web-sites you want. The downside is that home internet connections aren’t always reliable. They’re also much slower than you can get with a hosting company like GoDaddy.

However, they are a good way to test out web-site concepts before spending the money on hosting them somewhere else. There used to be a lot of misconceptions about the cost of running web-sites and they probably still exist. The biggest misconception is what hardware is required. A “server” is just a PC. My home server is a run of the mill dual core Intel processor running at 1.7Ghz per core. The motherboard and the CPU cost less than $100 combined. In addition I have four harddrives (OS, website files, database files, log files) although one would suffice if you’re just getting started. Everything is contained in a standard mid-tower case which cost around $35.

You can purchase more expensive computers that are designed to handle high volume traffic. But you don’t need to. I think the misconception about what hardware is needed comes from what server computers typically look like; long and flat. That’s because they are typically stored in a rack and every unit of rack space costs money. A lot of money. With a home server you don’t have to worry about saving money by not having to pay for space to store your system. It can be as bulky as you want it to be. That means you can buy whatever parts you want. You don’t have to buy expensive parts designed to fit into a confined space.

So now you know that you don’t need special hardware to run a web-server. You can build from parts or buy a pre-built desktop system. The next misconception is the software. The software is really what separates a server from a home computer. A lot of people will probably tell you that you should run Linux because it’s “faster” or “more secure.” Both things are essentially false. If you happen to like Linux and want to use it then great. But more than likely when you bought he system or built it, you put some version of Windows on it. You can leave Windows on it. I would actually recommend it. There’s enough to learn about the actual server software that you shouldn’t subject yourself to a foreign operating system.

When people talk about “Linux” being faster or more secure in the context of web servers, they’re not talking about the operating system. They’re talking about Apache and IIS. Even professional highly paid writers who specialize in technology often can’t tell the difference between an operating system and applications. IIS is the web-server application that comes with professional and server versions of Windows. Apache is a lightweight web-server application that was originally made for Linux but, guess what, it also runs on Windows. Apache is just as fast and just as secure on Windows as it is on Linux.

I prefer Apache although I also develop for IIS. Apache is free and will run on anything. I once handled over 1 million requests in a month with Apache running on Windows Millenium. The simple fact is, the operating system doesn’t matter. It’s the software that runs on top of it that matters.

The typical software that people use to run hobby web-sites is Apache, MySQL, PHP and Subversion. All the software is 100% free and runs just as well and just as securely on Windows as it does Linux.

The security of Apache comes from the fact that it does the bare minimum. It only serves up web-pages. The lack of security for IIS (or the difficulty of making it secure) comes from the fact that IIS does a lot. If IIS only did what Apache did it would be just as secure out of the box.

What makes the operating system secure is only having the ports open that you want people to use. Namely, the port that Apache is using to serve up web-pages. Typically that’s port 80. A $30 router will lock down your network as well as anything.

So you can see that running a server may involve a bit of education on your part. But it doesn’t require a lot of money. The software is free. You can use any old computer you have lying around. And then you can go to town making whatever web-sites you want to make. If a web-site becomes very popular then you can look into other options for how to host the site. But until then, don’t waste your money.