So I thought apps were supposed to be tombstoned in the background....?

It shouldn't that's the point.
But you can try it out yourselves. The games are definitely killing the battery from the background.

I get this too. And it's not just games. E.g. a flashlight app.

You have to close out apps before hitting lock (off/standby button) else they can really chew through the battery.
 
As someone else mentioned, audio and navigation apps have special privileges to do work in the background and may not be suspended like other applications. Check your settings for the Nokia Drive and Gas Buddy apps, as they may be constantly using the GPS in the background which will cause the battery to drain faster. The Nokia Drive app has a battery saver option to disable the constant GPS usage.
 
10% in an hour... that's 10 hours of battery life. Is that really bad? I don't think I've ever gotten 10 hours out of my Lumia 900...
 
its pretty simple Direct X games/apps do not get deactivated by the system they use "real" multitasking. So games which use Direct X still fully run in background. I wonder why no one has known about that. oO
 
Is there any way to disable all background data? Or do you have to go into each app and do it that way. I have just been turning data off all together when I'm not using my phone. Just wondering if there is a way to disable background data with a single setting on the phone.
 
its pretty simple Direct X games/apps do not get deactivated by the system they use "real" multitasking. So games which use Direct X still fully run in background. I wonder why no one has known about that. oO

I can't say whether you are wrong or right, because although I've written native software for WP8, I have yet to setup a native dirextx app. However, I have a hard time believing that claim. On MSDN I can in fact find examples showing the precise line of code where a WP8 directx game becomes suspended!

One difference between native/directx and managed apps is that the former requires the developer to do all the work of transitioning their apps in and out of the various app states (suspended/running, visible/covered, etc). I haven't yet found the time to profile a directx game to see exactly what is going on, but I find it far more likely that the developers are just screwing up, largely due to native apps being a lot more complicated to code and developers not understanding all the state transitions they need to be on the lookout for. But like I said, I can't be sure.

Do you have anything to back that claim up with?
 
its pretty simple Direct X games/apps do not get deactivated by the system they use "real" multitasking. So games which use Direct X still fully run in background. I wonder why no one has known about that. oO

I find this hard to believe. Do you have any references for this statement?
 
Yes..... I don't know the mechanism, as I'm not a game developer, but I was once playing one of the Angry Birds franchise, and locked the phone without leaving the game to answer my wife's beck and call, and when I came back a half an hour later I'd lost more than 50% of my battery level.

As for the Voice Butler, I haven't used that app, and I may not be following you correctly, but I can confirm that waitthereimaWP is correct, and apps that have timers, alarms or the like, do not use background agents the way many other apps do. When it comes to voice control, I do have an app with Voice Command functionality, and that does not require a background agent at all. It is surprisingly simple to create an app that uses voice commands, too. To give you an idea, tap/hold the start button, then press the question mark, and swipe from the right to see the list of apps you have installed that can use voice commands. You'll be surprised at how many there are, I suspect.
 
There can certainly be issues with games/apps that don't know little details:

XAudio2 Performance and Battery Considerations for Windows Phone 8

Yeah, I suspect it's problems like this (but directx related instead of audio related) that are causing peoples gaming/battery woes. While the app developer may have done a poor job, it is also poor API design on Microsoft's part. Any action that must be performed for the system to behave as intended, should be on the OS' shoulders to perform, not on the app developer's.