Game Design: Checking for object intersection or getting values from accelerometer

I'm currently developing an iPhone game where the player needs to tilt the device to do something. The game is somewhat of a memory game with the four corners of the screen being possible targets. The object of the game is to remember the order and then move the device to the right place.

My question is more about the design of the moving mechanic. The two options that I thought of were to get the value开发者_开发技巧s from the accelerometer directly and when the are greater than a specific value return whether that was the correct place to go (ie the right corner for the given instruction). My second idea is that each corner would have its own CGrect and the accelerometer would move an other CGrect and when the two intersect it would return whether the move was right or wrong.

In your opinion which one would be best? I think that the accelerometer data would be quicker but it might be affected by sudden movements while the other way might be slower but more accurate. Let me know what you think.

---

I think you should try both, test each of them on players, and see which works better. Drive game design decisions from user testing whenever possible.

My speculation is that you are going to need to damp or accumulate the accelerometer data somehow, since it is noisy; and if you are integrating that data into a moving average, then you should show where that moving average is with eg an onscreen sprite.

You probably don't even need to use the CGRect's intersection -- if you're just trying to determine whether <x₀,y₀> is within r units of <x₁,y₁> then you can do it via a simple Pythagorean distance. But the important thing is that if there is some internal state in the algorithm calculating what the accelerometer data has integrated to, then you need to show that state onscreen to feel responsive.