Can't the current customer play the iPhone version on the iPad? That is the piece of software they paid $7 for. Any development costs money, and to stay in business, a dev needs to make that money back somehow. As most games are $1-$2, devs need to sell a significant amount of copies every day, to even break even, let alone make a profit. Customers expect ridiculously low prices, free updates, and now, free iPad versions. That model does not pay the bills for the majority of developers. Making a great game creates brand loyalty too. Make a great iPad version, and the loyalty will continue, AND you won't go out of business. Did you give away the CD, vinyl, and MP3 if they only paid for one of them? CD and vinyl are different experiences. The iPad and iPhone are different experiences. What's great for the customer is not necessarily great for the business. Your scenario suggests that you are willing to devalue the specific work done to make the PS3 version, and you're willing to eat the cost of distribution for it as well. If a customer can get the PS3 version for free, by buying a different game, then you've lowered it's perceived value in the eyes of the customer. Absolutely not. What you'd get is lowest common denominator games, because there would be no point (or profit), in developing for the specific features of a device. Create once, using only the common features across all devices, and you get the worst version possible. Do you really want your PS3 games to look like Wii games?
yes. the ipad plays iphone applications without modification. the big question is, if as a developer, you will write a version optimized for the ipad - use higher resolution graphics, different input styles due to it's size etc. from what has been said; it is a 768x1024 display; pixel doubling an iphone application will use 640x960 - and then put a black border around it. the good news is that open GL should do this directly - so, there should not be any performance issues. apple also allows users to transfer a purchase to up-to-five devices.
I think you're going to find that devs will take this opportunity to design specifically to the strengths of the new device, and cater to the older demographic.
From what we've gathered after taking a look at the emulator and the UI requirements, plus with some prototyping we've done so far, there's no way that a game which is optimal for the iPad is at the same time at its best on the iPhone as well. If you don't want to compromise, separate apps is the right way, for both development and business. Those customers who don't want to invest in an experience that's tailored to the different device can still run the iPhone version in pixel-doubled mode.
Programming an XBox 360 game is almost identical to programming a PC game. Programming an iPhone game is almost identical to programming an OS X game. From a programming language point of view that may be true. Sure, the technical differences aren't that much different. The work comes in when you actually leverage the different hardware. How can you make use of the extra screen real estate or the extra processor power? What about how the user interacts with the game? A PC game will usually let you pick your graphics resolution, something you never have to worry about on the XBox 360, but there is work involved there. For an XBox360, the UI has to be readable on a standard def TV even though the PC version could be run at super high resolution on a computer monitor and never have that problem. There are design considerations to fit both platforms. Art has to be tailor made for both versions. That takes time and money. It is NOT trivial. User interface and interaction on a tiny device is going to be very different than on a large device. Things that were designed to work well in a tiny cramped space may not scale up. Look at NOVA running in pixel doubled mode. Swiping to look around on a small iPhone works great, but it's awkward and uncomfortable on a large device. Control schemes will need to be re-imagined and implemented and UI changes need to be made to accommodate that. There is a tremendous amount of work to make the "simple port" even if you aren't doing anything drastically different. Just making things work well and look good on a larger device is a challenge for most games. Maybe some games will be lucky and not need these kinds of modifications to work well on a large device, but in general I don't think that will be the case. Edit: From this point forward I do expect people to plan for both platforms when starting to design a game, but even though that will reduce the overhead of making it work on both platforms (like using high resolution art from the start) all the other sticking points remain. It is more work (and more expensive) to support two different platforms. There's no getting around that.
I suppose it changes from game to game. The game we're currently in development for, the gameplay cannot fundamentally be changed in any way to work on a larger screen, so it will only be scaled up to work on the iPad, with higher-res graphics, and some slightly smaller text and on-screen controls. I believe those to be very minor modifications to make, and the fact we're doing the art assets in HD from the outset, I don't see the work as justified for charging for — We're going to include iPad development costs into the overall development costs, as we're treating iPad support as a necessity going forward. In the future, if my company did create something like a line-drawing game, and then make a special iPad version that is drastically different, with more features, and completely different gameplay, I believe we would charge separately for that version, but that's because I would consider it a completely new title. But I think those situations, where a developer creates an entirely new game, will not be the norm. And anyone who creates a game today, with no intention to create a separate iPad version, could easily create the art assets in HD at the start, and just make those active when the game is running on an iPad - I think that's fair not to charge for that. But maybe some developers will disagree, but I guess we'll see.
I guess I didn't find your comment that clear the first time. I wasn't sure how you made a distinction between "bare minimum effort" from "time and effort"
As I understand it, the emitter/base receives the signal from your iPhone via your wifi network. So anywhere in the house where you have wifi coverage. You should be able to control everything in the room where the emitter is. Similar to the RF remotes that "work through walls", except universal to every IR component in your stack.
