Ok, thanks. LiveMove does look cool! The performance/footprint is really impressive. Even for $2500.

On the other hand, I wasn't completely wrong, as movements seem mostly modeled through learning and recognition. There's very little "advanced" calculus going on. You should get rough motion speed from how long it took you to accomplish the move and little more. Orientation "on hold" is pretty easy too, and location isn't really used beyond pointing, which is accomplished with the camera.

that chart cost is way too high on breaking even, its basically saying all ps3 and a majority of x360 game lost millions of dollar because only a few game sell over a million.

 charts like that are ohh so subjective.

Alot of the cost is the game engine that will be used on most of the games the studio makes, do they take into account that most of the ground work is alreat done for future games ? that game engies can be leased to smaller devs that cant affored to create one them selfs.

 It been said it takes +500k sales to be profitable on the PS3 

I think the calculus is more for the Wii to understand what the motion is not for the programmers.  They don't need calculus but I imagine that while brute force record as many points as possible (ƒ(v)=∑ⁱ_n=0 a_n and then ƒ(x)=∑ⁱ_n=0 v_n) would work its a lot easier to just tell the wii that if ƒ(v)=∫ a dv, then ƒ(x)= ∫ v dx would be used by the Wii to determine if a particular shape was made by the Wiimote.  A simple example is waggle right, if they want you to move the Wiimote right 1 inch for it to measure then the Wii would check if amount of acceleration over whatever length of time solves some form of the equation 1/6*a³|₀^t > 1.  Now switch to 3 variables, possibly polar coordinates, and complex shapes like a figure eight and it's starting to sound like those programmers were having a blast .  Now I'm mad, they were paid to solve what I had to pay OSU to let me solve.

 I'm not sure if LiveMove uses calculus or if it simply records a ton of points but either way it's a lot quicker than what the devs had to do before.  We could debate to no end how advanced the calculus is since that would be different for everyone.  Unfortuantely I've had several years of math past calculus so multivariable isn't terribly advanced to me but to someone with a BA even pre-calculus is advanced.  For software programmers I'm not sure.  At any rate, sorry if you know this, I wouldn't want anyone to think I'm just making up the equations bit.   Also sorry my last post sounds snarky, I thought it sounded sarcastically humorous but it doesn't when re-reading it.

Anyone with a degree in computer science should have at least taken linear algebra, multivariable calculus, and differential equations. Do you need to be well-versed in Calculus to write software for the Wii Remote? Probably not. Would it help you write better software for the Wii Remote? Absolutely.

I dunno, when I took DiffEq, there was no curve. I got an A, btw. :)

But most universities have a policy that you can't just pass all your classes to earn a degree, and if your GPA drops below a 2.0 (C average), you're put on academic probation the first time, suspension the second. At Virginia Tech, you need a C or better if it's an in-major requirement, and you need a C or better in all prerequisites. You also need an in-major GPA of 2.5 to graduate.

Either way, game companies don't just hire any old college graduates. Working with these consoles to create games is a bit more involved than being someone's code monkey at Initech. :) Serious development teams ought to have at least one programmer who has made Calculus his or her bitch.

Not that I disagree entirely -- it is rather disheartening listening to so many students complain about their grades after putting in all those hours studying.  But you might be surprised how many of these students either don't graduate, or switch to a less technical major.  Good engineering programs often have extremely high attrition rates.

As its already been said - many game budgets are already set, and their devs are building the engines for the games. I do believe, however, that for PS3 devs wanting PS3-exclusive games under the assumption are realizing that with such a small user base, it's difficult to make a profit, therefore multi-porting to the 360. The primary issue is this: If I am a dev, what would I rather do: 1. Dev for the 360 or PS3, and port to the other console, only having to modify the code to work on the CPU/GPU, ect to move the game to another console for under $500k USD. 2. Dev for the 360/PS3 and port it to the Wii, which would require quite a bit more work due to having to scale back textures, add in new devkits for the WiiMote (as stated), and pay quite a bit more, maybe $1m. Which is more economically feasable? IMO, its the 360/PS3 route. Despite complaining and general N-fanboyism, the PS3 and 360 are still the lead consoles to dev for. There's a 13m user base on both systems. The 360/PS3 base is staying steady in the US vs. Wii, increasing vs. Wii in Europe, and losing in Japan. Look at Trusty Bell for 360. Will it make money on 360 alone? Probably not. However, adding the PS3 in there, will make the game quite profitable. A good example is Enchant Arm. It sold good on the 360 (not great), had 50k in Japan, and another 150k in the US/Europe or more. Probably around 200k units. Once it got ported to the PS3, it's sold around another 75-100k. Easily worth porting, and taking a game that maybe broke even, to actually make From Software a few bucks. The same can be said for AC4 - it sold 90k on PS3 in Japan, another 25k on 360, and 100k+ on both PS3/360 in the US. There's no way just deving on the Wii would of made the game more profitable. Honestly, it'll take 2 YEARS of the Wii selling as good as it is to even get anywhere near the level that would be required for a major dev to say "lets move our big name franchise to Wii-exclusivity, or make the Wii the lead console". It just won't happen. Has the Wii's succuess garnered more software sales for Nintendo systems than in the past? Absolutely, but still, the 360/PS3 are the lead systems to dev for.

No problem, my posts don't all sound that nice either, I guess.

You're not the only one. I probably wouldn't go as far as paying to work, even in something this interesting (then again... maybe), specially knowing someone would profit from it, but I do envy the guys who got to do it. If only all software eng. work was as interesting as this.

Well... I know which one I'd choose, and it's not because of fear of calculus, but I can't really argue about which one is better, or anything. And it's obivously easier to have it done for you, as long as it works.

I guess my point was more that I don't think the absence of the tool should excuse game developers doing a sucky job. I mean, I can understand the amazement of some journalists about the complexity of all this, but I personally expect a little more from the developers who work for publishers that are allowed to see the dev kit before the system is even released.

There are other much better excuses. Unfamiliarity with the system, working with prototypes that might not exactly match the final versions, lack of imagination to find acceptable uses, time constraints to publish on the launch window, etc.

The calculus required for Wii development (IMO) is rather trivial.

The Wiimote is all about handling series of discrete values - its not about taking some conceptual function (entered by the player), and trying to determine its integral or differential.

Performing a discrete differential is extremely trivial (much simpler than something like a FFT, which has its own uses) - you are in effect just working out the difference (over time) between each set of points.

In the end, the whole purpose of this would be to (roughly?) determine the shape of a gesture. From memory, you could perform a double differential, end up with a number of turning points (or points of inflexion), and based on the rough location/magnitude of these, work out which gesture has been made.

...

It does depend on the game, and how demanding/accurate you need the Wiimote input to be. I suspect we'll end up seeing a lot of games use basic "gesture" control, rather than trying to approxmate 1:1 control. The exception is in games such as Golf (WiiSports), where you expect the player to only make one type of gesture - and you can focus on reading the magnitude/position of the gesture (rather than working out the type of gesture as well).

(note - I sort of remember most of my calculus... it was one of my stronger math subjects, and math was always my best subject at school/uni, scoring in the 90's. But in 20+years of game programming, pretty sure I have only ever used calculus 2-3 times. Once was for a fairly complex collision system, otherwise it usually reduces to  the standard physics equations - where calculus is not really needed. I hope I get to code some Wiimote input at some stage in the future, it sounds like an interesting challenge!).