Slashdot Mirror
Game Devs Weigh In On Windows Phone 7
The mobile games industry has exploded over the past few years, driven largely by titles built for iOS and Android. The Guardian's games blog decided to investigate the pros and cons of Windows Phone 7 as a game development platform while it struggles to catch up to its predecessors.
"... the easy portability of code between WP7 and Xbox, plus the wealth of online tutorials, libraries and community support, is a massive advantage, especially for smaller and less experienced teams. ... As with Xbox Live Arcade, the console's downloadable games service, Windows Phone 7 offers a curated experience, which means Microsoft controls the quality of games appearing on the device. ... [Steven Batchelor-Manning of Nerf Games says,] 'The App Hub offers a good peer review system, where other developers are asked to check over your game. This helps filter out both low quality and bug-ridden titles. We are always given a particular quality to aim for. Once it's got past this stage there is also a chance that Microsoft will veto against your game going on the platform. Ultimately, this prevents the market being swamped, but above this, there seems to be a layer of games by big publishers (EA, etc) that just step past the smaller developers in the queue. This is the biggest drawback of the system.'"
I mean, I remember all the shovelware crap that had the "Nintendo Seal of Quality" on it back in the day.
And their remark about EA is spot on. They're responsible for most of the boring shovelware crap that clogs up the Live Marketplace today and makes it hard to find where the good stuff is hiding.
Once it's got past this stage there is also a chance that Microsoft will veto against your game going on the platform.
This sounds different but similar to Apple's review process. Meet the new boss, same as the old boss.
So many Win7 stories.
So many positive Win7 comments.
Please ./ moderators (below I don't know, 180,000?), MODERATE!
... the easy portability of code between WP7 and Xbox,
How come i get the feeling they have NEVER programmed at all?
Be seeing you...
It's not "easy", but it's much easier than other platforms. Porting between, say, Xbox 360 and iPhone is pretty difficult if only because the programming languages are completely different. Indie Games on Xbox 360 and WP7 both use C# and XNA, and if you have an Xbox 360 project it's literally just a couple of clicks and it compiles and runs natively on WP7.
Your game won't be *usable*, of course, since your game will be designed for a controller and not a touch screen. But it'll work.
... the easy portability of code between WP7 and Xbox,
How come i get the feeling they have NEVER programmed at all?
I don't know, it doesn't make much sense for you to get that feeling based on the passage you quoted.
To me the article read like a blatant fanboy story, but maybe I'm just jaded.
And then I got to this: "As with Xbox Live Arcade, however, Microsoft is set to run its own games promotions, to help market promising titles. The project kicks off this spring with a Must Have games season, which features six Windows Phone 7 titles, including Angry Birds, Doodle Jump, Hydro Thunder and Plants vs Zombies. "
Sure, those are promising titles - after all, they're already big hits on iOS and Android. But how the heck is this tied to the article's repeated meme regarding Windows/XBox-specific tools, and easy cross-development between XBox Live and WP7? It's certainly unlikely any of them were written in C#.
#DeleteChrome
Slightly off-topic
Recently there had been several stories about MS / WP7 and many comments are, kind of knee-jerk reactions against MS.
Before someone screams astroturfing, let me say that I use whatever tool is right for the job. Mostly I do data-driven applications (WinForms, PHP, MVC, Java, whatever) against the database server that will deliver the most bang for the buck (my client's buck, not mine) so I have used Firebird (the OS incarnation of Paradox), SqlLite, MySQL, Postgress, MS SQL and (gasp!) even Oracle!
Now, I don't think MS gets, even now, how that works. Calling stored procedures in MS-SQL from any VisualStudio framework is a royal pain in the ass. They tout DRY but I can't think why you have to jump through loops to get stored procedures to work in their frameworks; I have many complex queries in SQL to list records, why would I want to repeat the same SQL statements in an MVC app and in a WinForms app against the same database? The surest way to achieve DRY is to use stored procedures and let each app handle only the presentation of the data.
Having ranted against MS, I kind of like MVC 3 and the new Entity Framework, not quite up to speed on it, but so far I kind of like it and that has predisposed me towards looking at WP7 and see what has MS learned from past failures, which last year I would not have thought about at all.
Now, in a site supposedly rife with developers of all kinds, shouldn't we be more open about investigating and then adopting or rejecting new technology?
Please don't construct this as an advertisement for WP7, I'm simply saying, maybe one should look at it before dismissing it out of hand. I did some work in Symbian and (the pain!) Objective-C, so I don't think my eyes will pop-out if I look at WP7.
Be very, very careful what you put into that head, because you will never, ever get it out. - Cardinal Wolsey
As a WP7 app/game dev, I think the platform is stellar. For apps, it's trivial to make things smooth and impressive that integrate well with the look and feel of the rest of the phone. And that look and feel is miles ahead of what I've seen on Android and even a lot of iPhone. It's also trivial to go crazy with it and make something really unique that doesn't integrate at all, though that would probably be harder to get through the app verifiers.
Games are different. You're forced to write them with .NET and the XNA framework. For most of the casual games you play on phones this isn't really an issue, and writing with .NET can actually reduce dev time. But if you plan on writing anything really impressive that pushes the envelope like we've seen happening on iPhone and Android, you're probably going to be out of luck. The inefficiencies of .NET really start to add up, and some common things like memory mapping just aren't possible with it. I predict this will change in the future -- they just won't remain competitive without loosening up and allowing native code.
The gaming platform itself is pretty great. It's very easy to port games between PC/360/WP7 -- if you make it on one platform, you might as well make it for all of them and increase your sales. Your games can integrate with Xbox Live, so you've got all your friends and achievements right there which can be a huge factor in drawing in users.
I don't understand why they focus so much on developers porting XBLA games, when they should be caring about iPhone or Android developers porting their games and applications to WP7. I can understand that they will not run Java on their system to avoid problems with oracle, but nothing avoids them from offering C++ / ObjC, which are both available on Apple and Google platforms. This allows a much larger amount of developers (and middlewares such as Unity) to offer the same on WP7 as everywhere else. .NET , I think developers will just keep writing their code in wathever is supported by the market leaders (Java, ObjC and C++), as they will not ditch their entire codebases to please Microsoft.
By forcing everyone to use
Your game won't be *usable*, of course, since your game will be designed for a controller and not a touch screen.
I think that's the point. Who cares if you can port between two things that don't run the same kind of software? It's not like you're going to be playing Crysis on your phone. It's like having easy portability between Solaris and Android -- OK sure, but why?
Just like back in the day when Nintendo limited the number of games any one developer could have on the market at once, I suspect Microsoft wants to limit the number of titles (so that the money consumers spend on games gets spread over fewer titles, thus more profit per title). I suspect they also want to keep a lid on the number of free/near free titles (the more free options there are, the less likely it is that people will buy the expensive premium titles since the free ones give them enough things to play)
I'm looking at getting rid of the iPhone later this year and going to Android, but if MS increase services through XBL I may go with that.
I already have a lot of games on XBL, plus use it for Movies & TV, if any of those services can be used on my phone I'd probably be persuaded to go with that.
Currently though the models of phones don't really excite me.
Out of curiosity, wouldn't the game just crash then considering that you'll be creating objects to respond to input methods that don't exist? I don't know C# nor am I familiar with XNA beyond knowing about both of them, so this is a legitimate question.
Windows = Keyboard + Mouse
XBox = Controller
WP7 = Touchscreen
I don't see much code being reused on quality apps, but it should lead to lots of mediocre games. Each game will work best on the platform targeted by the developer, and the quality of the ported versions will vary widely, but online tutorials are unlikely to have a positive effect.
The US government have made it clear that we have no inalienable rights; any we do not defend vigorously will be taken.
"Professional" mobile games (i.e. by commercial dev companies) are almost universally written in straight C/C++ with minimal ObjectiveC / Dalvik wrappers to get to the phone hardware.
If you have a hit title, do you -really- want to have to rewrite the whole thing from top to bottom to port it to other platforms?
I spent several months a few years back working hard to convince my employer (a certain US carrier) that going ahead and launching a J2ME-based mobile platform (in the last 00's - this is post-iPhone, people) was would elicit nothing more than mockery (and, at best, shovelware) from the developer community. My employer subsequently canned the idea, and I like to think that my steely knives helped kill the beast.
My main argument was that forcing developers to rewrite significant portions of code almost guarantees you won't get major titles, regardless of your hardware lineup.
One of the smartest things Google did with Android was the NDK; I recently ported a top-10 iPhone 3d game (written 99% in straight C/++) to Android NDK and including my getting-to-know-you time I was done in 3 weeks. Was scorchingly fast on the Galaxy Tab compared to iPad.
The frank reality is that iOS is very obviously the largest mobile platform for developers, and others (Android, WP7, WebOS etc) must make it as easy as possible to port titles over. ;-) but it appears they were smart enough to provide a plain-vanilla C++ and OGLES environment for games.
Google did a marvellous job of adding this capability; NDK gives you plenty enough bare metal to port easily from other platforms.
I've not looked at WebOS
Android and iPhone can handle running native code apps just fine. If WP7 can't make itself a viable (easy!) porting target like Android, it's going to be spending a lot of Saturday nights at home watching TV waiting for the phone to ring.
[FrLz]
Just because you can't port a control scheme doesn't mean you don't want to be able to bring over your engine.
"In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson
Windows = Keyboard + Mouse
XBox = Controller
WP7 = Touchscreen
I don't see much code being reused on quality apps, but it should lead to lots of mediocre games. Each game will work best on the platform targeted by the developer, and the quality of the ported versions will vary widely, but online tutorials are unlikely to have a positive effect.
Why? Angry Birds (which is available on the desktop and on touchscreen smartphones) simply has the most basic interaction changed to work with a mouse instead of touch, other than that the functionality is the same. If this were porting between WP7, XBox and Windows then very little code would need to be changed.
Any well-designed game is going to benefit from having the physical-platform-agnostic code (i.e. AI, animation, game logic, etc...) not having to be changed at all when you go between platforms.
Actually, "simple" programs using the XNA Framework port across almost automatically. Especially if you use one of the compatibility profiles that limits what you can call to things all platforms have in common. In-fact, using the compatibility profile almost grantees that what you write will work on PC, Phone, and Xbox without changes.
How the fuck did they do that? And why?
I swear MS seem awfully stupid, and this just blows that away to an even more awfully stupid level!! What comes after awfully stupid? That's what MS is.
Well golly gee. Seems like all kinds of folks have been doing it wrong all along. Thanks for setting us straight with your mountains of expertise and knowledge and your 30 seconds of reasoning.
Out of curiosity, wouldn't the game just crash then considering that you'll be creating objects to respond to input methods that don't exist? I don't know C# nor am I familiar with XNA beyond knowing about both of them, so this is a legitimate question.
Well it wouldn't build if you ported it directly since the interaction code would call into xbox-specific methods to deal with the controller. So your interaction code would have to be re-written depending on the device.
Any good engineer would abstract out interface to api calls, and map them that way. Hell, any game that allows you to have a custom or mutable control scheme would function like that, which applies to just about any game out there today. That means core mechanics and behavior remains unchanged regardless of what superficial control scheme you plaster on it. And btw, the code related to controls makes up a rather tiny portion of a game's code. In other words, you would be reusing the vast majority of the quality code.
Now what could impact how good a game is making sure your game works well for the given control scheme. That is the only part that will have an impact on a game's quality.
What comes after awfully stupid? That's what MS is.
Probably something along the lines of thinking that windows 7 is the same thing as windows phone 7.
Actually, "simple" programs using the XNA Framework port across almost automatically. Especially if you use one of the compatibility profiles that limits what you can call to things all platforms have in common.
Microsoft wants you to stay investing in their own platforms. It's just as proprietary as everyone else.
Maybe they could also mandate for some things.
With inner snarky addition!
That's what I was thinking, but couldn't be sure being unfamiliar with Windows development environments. Honestly, I've only coded on Linux and Mac OS X. It's not that I have something against Windows, it's just I never had a reason to code on Windows. Maybe I might pick up a C# and and XNA book this weekend.
Right, because everybody knows that 90% of a game's code is in its UI and input system. Things like the game engine, AI, logic controlling elements in the game, resources, and netcode are completely irrelevant, right?
To be fair, WP7 doesn't support much in the way of netcode right now, and it's certainly not trivial to shift UI paradigms. However, that doesn't mean that the ability to use XNA, and resuse a lot of code as a result, isn't still quite valuable.
There's no place I could be, since I've found Serenity...
Nope. XNA is designed to be compiled on multiple platforms. The controller input APIs are "available" in WP7, but don't do anything. So with the same codebase, you can run on pc, xbox, and WP7 without any changes.
The video game crash of 19843/84 was caused by a flood of buggy bad games on the market by shady vendors. They would also take other publishers work and copy them onto cheap cartridges. The seal was there by Nintendo because they forced everyone to license their games, and be produced by Nintendo. At least you knew the game was 1st market. Also they did everything they could to market the NES as a system that wasn't junk to separate it from the consoles and games mothers had got burned on before. http://en.wikipedia.org/wiki/North_American_video_game_crash_of_1983#Long-term_effects
Did you really just try to refute the statement - I don't see much code being reused on quality apps, but it should lead to lots of mediocre games. - by pointing at Angry Birds?
That's freaking hilarious.
Say what you want about Angry Birds (I liked it better when it was called Boom Blox), but he's right. Most professional games will modularize the UI as much as they can.
A friend of mine ported one of the launch titles for the Wii, and they didn't have to change much outside of the UI and rendering code. Their biggest problem was Nintendo suddenly demanding that all launch titles have the "safety strap splash screen" put in about a week before the deadline. That meant actually having to dig into the code to insert it.
I laughed at the situation, and then promptly flubbed the controller into the (expensive) Wii prototype box.
For games, not really, but for other apps it can be quite useful. I like being able to run all the Linux networking tools on my n900.
...so I'll burn a bit here :)
I am an indie game developer working mainly with XNA. I have published a few XBox Live Arcade titles, plus a few WP7 ones. The ease of portability is really high. The only difference (granted, this is not necessarily trivial to implement) is the input devices, which are the first thing I wrap away because for various reasons it is useful to have a game that works well in Windows with kb + mouse. When porting to wp7 no additional code is required. Usually lighting and shaders will be toned down (not much to do, just set different techniques in the stock shaders) and models and textures must be reduced in detail, both for storage and rendering performance.
In the end this is the reason why our games will keep ending also in the wp7 marketplace even though sales are not as high: the development costs for porting are so low that even few sales result in a gain...
My book: Friendly F#, fun with game development and XNA; my game: Galaxy Wars by VSTeam; my gamedev language: Casanova.
To solve this problem, you can just create a "clone" of the project for a specific device (in practice it's a sort of symbolic link) and make a few changes to the classes that handle the interactions. You can also put in conditions for the compiler, but that's just personal taste.
I think that's the point. Who cares if you can port between two things that don't run the same kind of software?
erm.. isn't that the point of "easy portability" - you can take one thing and make it work on both platforms. that's what they're touting here after all.
Windows Phone 7 offers a curated experience, which means Microsoft controls the quality of games appearing on the device
Microsoft curates, Apple stifles
Did you really just try to refute the statement - I don't see much code being reused on quality apps, but it should lead to lots of mediocre games. - by pointing at Angry Birds?
That's freaking hilarious.
Well you can define 'mediocre' however you want but it's certainly one of the world's most popular games. And if you really want a XBox to WP7 example have a look at Full House Poker.
Windows Phone 7 offers a curated experience, which means Microsoft controls the quality of games appearing on the device. Microsoft curates, whilst Apple stifles ;-)
Jerry
You're forgetting about Kinect. A touch screen phone or Kinect and a big TV are similar interfaces. Apps and game could possibly run on both. If a phone with a controller comes out, tons of games could be ported pretty quick. With better hardware in the future, perhaps all the games will be able to be ported.
This is absolutely correct. In fact this is already a solved problem as even different consoles (eg, XBox vs Wii) have very different input systems. This is why game developers typically abstract away the front end so that it's easy to have a different version for each console and input systems are often layered such that only the first layer or two need to be replaced for a different input system. The largest lump of code in many games, at least the games I worked on, was game play, AI and graphics/animation which are largely reusable with a few changes between systems, even systems as different as the Wii (No shaders, OpenGL like API) and the XBox (DirectX with shaders). With WP7 you would have even fewer difference making even more shared code.
If you're using object oriented programming and the Windows development enviroment the way it's intended to be used your code will have all three of these proporties (not juts portability):
Portability/re-usability (at least between Microsoft platforms)
Encapsulation
Modular code
If your game code is modular and the user interface is well encapsulated, you can write a new user interface and couple it to the existing game code. Then you're just a recompile away from native support for your new platform. If you had the foresight to build your interface with a scripting language (and your target platform can handle the associated performance hit) you wouldn't even need to recompile.
By contrast if you wanted to port your game to iOS and you didn't happen to develop in Objective C using Apple's APIs you'll have to not only build a new interface module, but also finesse the old language into the new (could be anything from additional compilation steps, to a lengthy find/replace, to a complete rewrite).
Now if your wrote your Mac game in Objective C porting it to iOS should be comparably trivial. But there are many more developers looking to port XBox and Windows games to a phone than there are Mac game developers.
From a technical standpoint, it isn't hard to architect a system with swappable inputs. The XNA system makes that especially easy. A good architect is going to separate input, rendering, game state, etc. anyway. I have built up a fairly large code library that runs on both without modification, so the idea of sharing code between them much more easily is very valid. On the flip side - the biggest issue is game DESIGN. From the get-go you have to design a game that's control scheme could be ported between both. (Controller-touch screen) Like any system you have to have your targeted platform(s) in mind when you design the application. Not all game types will be easily ported but it isn't because code re-use is an issue. Some games are easily ported. (I ported a card game from xbox to WP7 in a couple hours).
Yeah, just like many publishers already do and they end up with half ass games.
I can't count the number of games that were "dumbed down" for the console (fewer skills on screen/overall because the controller has less buttons) or they completely ignore common conventions on the PC because they are console developers (Final Fantasy Online anyone?)
Or you can go the other way and develop a game for the PC then take out something essential like jumping because you have to assign the buttons to other tasks like switching weapons, etc.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
Have you ever actually used XNA? Your comment doesn't make much sense in the context of it, whilst the platforms have some minor differences the quote is dead right- porting between WP7 and XBox is incredibly simple, particularly if you're choosing to write a game that can happily target the Reach profile from the outset- something like Angry Birds for example would happily fit under that category.
Full House Poker
I kind of wish I had one of those when that show was out. I suppose you'd use it to poke your eyes out?
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
It doesn't matter how much you abstract. You are still designing the game for the lowest common denominator (ie: the phone) and making a half ass game on the other systems.
You begin by cutting some feature because it would take too much RAM or increase the download size. You then decide to reduce the graphics engine so there's less modification between versions... then it all goes downhill until you are making flash games for all three devices and everyone begins to complain about how there are no more high quality games.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
Right, because everybody knows that 90% of a game's code is in its UI and input system. Things like the game engine, AI, logic controlling elements in the game, resources, and netcode are completely irrelevant, right?
To be fair, WP7 doesn't support much in the way of netcode right now, and it's certainly not trivial to shift UI paradigms. However, that doesn't mean that the ability to use XNA, and resuse a lot of code as a result, isn't still quite valuable.
PC = powerful X86
Xbox = mediocre PowerPC
Win Phone 7* = Weak ARM v7.
That's going to put a serious kink in your plans for code portability, not to mention art assets that need to look reasonable on a 22" 16:10, 36" 16:9 and 3.7" 5:3 (or 3:5) display.
You're not going to be able to reuse much of the code, even a lot of the art assets.
* Not calling it WP7 for the sake of the whining Word Perfect fanboys and yes, I'm getting off your lawn.
Calling someone a "hater" only means you can not rationally rebut their argument.
"The mobile games industry has exploded over the past few years, driven largely by titles built for iOS and Android."
No this isn't true, it has been driven almost exclusively by iOS. Leave it to /. to have to throw Android in there.
You can write XNA and Silverlight apps in C++, if you like.
But not the standard C or C++ that you may have used on PC, iOS, and Android NDK. One must use the verifiably type-safe subset of C++/CLI (/clr:safe), and its syntax for arrays, pointers, and references is incompatible with that of standard C++. If you want to compile one program, such as the logic tier of your game, both as standard C++ and as verifiably type-safe C++/CLI, I have been told that it would take a buttload of arcane template wizardry.
If a phone with a controller comes out
It was tried before; N-Gage crashed and burned. So I don't see it as likely to happen any time soon, except for Sony's Xperia Play that 1. may not be available on your favorite U.S. carrier and 2. is from the same company suing Geohot.
So your interaction code would have to be re-written depending on the device.
But that doesn't mean your game's logic tier would necessarily have to be rewritten. Only the control portion would have to be forked, unlike the complete rewrite needed when porting between a .NET-only platform, such as Xbox 360 XBLIG or WP7, and a platform without a practical CLR, such as iOS.
XNA is designed to be compiled on multiple platforms.
How many non-Microsoft platforms are among them? Is it possible to target Mac OS X, Android, and iOS on the one hand, and Xbox 360 and Windows Phone 7 on the other hand, without a complete rewrite of everything including the physics and AI tier? I could live with rewriting the control and graphics, but I want the physics and AI to be bit-perfect across platforms, so that if a player can make a certain jump on WP7, he can make the jump on iOS, and vice versa.
With WP7 you would have even fewer difference making even more shared code.
But is there any language that compiles both for Windows Phone 7 and for platforms without a CLR? I want to reuse the logic tier that implements "game play, AI and graphics/animation", and I don't want to have to maintain C# and standard C++, or verifiably type-safe nonstandard C++/CLI and standard C++, versions in parallel and worry that they would fall out of sync.
It's too bad Google haven't gone that extra inch and allowed / encouraged apps to target LLVM bitcode
What advantage would LLVM bitcode have over JIT compiled Dalvik bitcode?
XNA games can be written in C++
Unless it has changed recently, the kind of C++ that can be used with XNA is not standard C++, as I explained in another comment.
It should be noted that things like "resources" and "netcode" are dramatically different between the three platforms in question. File handling semantics maybe similar across platforms but the details are a bit different with the side effects that are dramatically different where in particular permission is wildly different. What kind of network resources you have are dramatically different between all three platforms where on WP7 it may cost the user money to access it.
I don't think anyone doubts that Microsoft does an excellent job with the tools making their systems portable between hardware and software platforms but they are still different hardware and software platforms. This isn't a Microsoft thing where any software engineer that has done porting knows that even if all features port cleanly there is still details buried in platform errata that make behavior different and need to be addressed manually.
Just because people rush bad ports of games to market does not mean that this cannot be done properly. It is done all the time outside of the gaming world and people often do a better job because they intend to continue selling the product for more than 6 months and might have to maintain the code to make new versions so there is more incentive to do a good job.
"In America, first you get the sugar, then you get the power, then you get the women..." -H. Simpson
First of all, using the XNA.Framework.Input.Keyboard class when compiling for XBox pretty much just gets ignored, it doesn't crash. Likewise, the GamePad class on Windows will work when you plug in a wireless gamepad, but otherwise it would act as if the GamePad was turned off when running in Windows. When I'm dealing with control schemes that are different from Windows and XBox, I generally have two classes that implement the same interface (IInputHandler for example), and at one point use the #IF XBox directive when instantiating the object that I want to use. In reality you can write one class that handles both, but for performance reasons I do it this way.
If I can just reach out with my words and touch a butthole, just one, it will all be worth it.
Yes, you're right, because the indie games scene on XBox Live and the WP7 app hub is where I go for quality games. Real XBox 360 development companies use the XBox Developer SDK and do not write in XNA.
If I can just reach out with my words and touch a butthole, just one, it will all be worth it.
I wonder how much separates Dalvik in LLVM, if there is scope to merge both concepts.
Chrome OS has Google Native Client, a way to deploy applets compiled to a verifiably safe subset of native code so that they run in a web browser. (Think ActiveX, except far safer.) It's also working on a successor called PNaCl, which does the same thing with LLVM bitcode. I imagine that as Google continues to cross-pollinate features between Android and Chrome OS, Android too should gain an LLVM execution environment.
How do people mark this comment as insightful? Re-using a high percentage of your code is good, it would probably take a company less than a week to create a new control scheme for a mobile game. Side scrollers, turn based games are all rather easily ported. Yes, you're probably not going to play crisis on your phone successfully, but fpses aren't the only games on xbox live arcade.
There was a sample casual game MS showed that ran on PC, Xbox and WP7 that shared ~90% of the same code.
If you code it in XNA and actually follow proper design patterns (completely disconnected UIs with Models and Views), you can code 90% of your app for both phone and xbox. The last 10% is UI formating and input events. This is XBox live stuff. We're not talking Battlefield 2 here.
I think that's the point. Who cares if you can port between two things that don't run the same kind of software? It's not like you're going to be playing Crysis on your phone. It's like having easy portability between Solaris and Android -- OK sure, but why?
Take a look at the titles available on Xbox Live Arcade. Out of the top 10, eight of them have simple enough controls that they could easily be played on a phone. If I was the developer of any of those games I'd be seriously looking in to adapting it to touch input. If that's all it takes to open up a new market for one's title, why not?
I used to get high on life, but I developed a tolerance. Now I need something stronger.
I've never had a problem converting native C++ to managed C++.
When I fix a defect in the logic of a program in managed C++, I want the fix to automatically propagate to the unmanaged C++ version, or vice versa. This is most practical when both the managed C++ and the unmanaged C++ are generated from the same source code file. Can you recommend an easy way to do this? Or are you referring to converting unmanaged C++ to managed C++ in a separate branch, never to be merged back to mainline, and somehow trying to keep fixes to both branches in sync?
I'm sure you could easily port NetHack and SuperTux to Android from *nix as well, but how much of a draw will that really be for the platform? The point isn't that there are zero XBOX games that could sensibly be ported to a phone, the point is that the platforms are very different and even if the code is portable, the format is likely to be very different. If the XBOX game is CPU or GPU hungry, it won't run well on a phone (or will kill the battery). If it includes gigabytes of graphical content, you won't be able to economically distribute it over the cellular network or store it on the tiny flash they put in phones. On and on.
It seems to me the problem is that phone-type games might run OK on an XBOX but "real" XBOX games won't run well on a phone. And the market for phone-type games running on XBOX is pretty small in dollar terms, both because the installed base of XBOX isn't really that big of a market when you're only making $1/pop and because people buy a console to play console-format games -- if you're going to buy a non-console game then you want it on your phone or laptop because it's more portable.
Since you seem to know so much about development for the Windows Phone you probably already knew that the touchscreen events you use as input on your phone are the very same mouse events you use on a computer. Porting your XNA apps from phone to a computer takes very little effort. Porting your non-XNA apps takes no effort at all.
It's worth noting that since I haven't personally done any XNA coding, I can't speak to how input is measured - but since it's all .NET in the end I assume it's very easy to port over.
Finally, since you are also probably an expert coder, you already knew that changing input methods when your programs are coded correctly should take very little effort as well.
So, what you should really be saying is:
Windows = Keyboard + Mouse
WP7 = Keyboard + Mouse
XBox = Controller
Tard.
Mono for Linux and OSX, MonoTouch for iOS, and MonoDroid for Android. XNA is a library that deals mostly with graphics and input and the like; it doesn't actually have anything to do with your actual game logic (eg. physics and AI). XNA isn't available on platforms like iOS or Android, but that should be okay because you'll be ripping out the graphicsa nd input stuff anyway. Although you'll have to rewrite your graphics and input for each platform, it's possible to have a single C# codebase that runs on all major platforms.
That's the tip of the iceberg, it's the 1st smartphone with a controller. More will follow
It's funny that you mention this because I remember Tengen producing some of the best arcade to NES ports only to have Nintendo sue them because they didn't get a cut.
Thanks for giving me the useful information. I think I need it. Keep up your work. Thank you - friv4.info
since when do nerds equate popularity with quality
You're forgetting about Kinect. A touch screen phone or Kinect and a big TV are similar interfaces. Apps and game could possibly run on both. If a phone with a controller comes out, tons of games could be ported pretty quick. With better hardware in the future, perhaps all the games will be able to be ported.
Would it be possible for the smart phone to be a controller.
An iPhone4 has GPS (not much use indoors), gyroscope, compass, LED, cameras, vibration, onboard memory, Bluetooth, touchscreen, two way audio and doesn't need a clear line of sight to a receiver if using Bluetooth/WiFi
I'm sure others have similar capabilities.
Maybe you can plug some sort of device into it with buttons.
What did i write that gave you any idea i would know anything about that?
You claimed that established companies would have access to "native code development", in other words an unmanaged or otherwise "unsafe" (in .NET lingo) environment, on Windows Phone 7. But Microsoft hasn't published any information about giving access to an "unsafe" environment to established companies on Windows Phone 7 the way it does on Xbox 360. So I assumed that you might have access to information still under NDA. Let me reiterate that I don't seek such NDA information at this point. But I further assumed that any company that already has access to NDA information would be aware of best practices for taking a video game developer from 0 to established.
Besides, others could have answered too.
Would it be possible for the smart phone to be a controller.
The phone would be a controller, but connected to what console? Or are you talking about having the controller cover up the view of the game?
An iPhone4 has GPS (not much use indoors), gyroscope, compass, LED, cameras, vibration, onboard memory, Bluetooth, touchscreen, two way audio and doesn't need a clear line of sight to a receiver if using Bluetooth/WiFi
None of these input methods offers tactile feedback, unlike a physical directional pad or physical analog stick and physical buttons that make it easy for the player to tell when he has pressed a button. On-screen buttons make it difficult for the player to know over which buttons his thumb hovers. If this has been solved, what are the best practices for providing a D-pad-like experience on a touchscreen handheld? Otherwise, whole genres will get excluded.
Maybe you can plug some sort of device into it with buttons.
Good luck selling such a device to everyone who buys a copy of your game. A $5 game is an impulse buy; a $20 piece of plastic, not so much.
MonoTouch for iOS, and MonoDroid for Android.
Those might be suitable for an established company, but both appear costly for someone trying to build a business with sweat equity by running it as a hobby until the first product is finished. Even if you already own a Mac and a copy of Windows to run in a virtual machine, the price per seat for MonoTouch, MonoDroid, and their dependencies appears very expensive. From the MonoTouch web site:
From the Mono for Android web site:
From the Microsoft Visual Studio pricing page:
What's the best way to justify this cost to other people in the same household before a hobby-turned-business starts to have some sort of revenue?
its absolutely possible to refactor a C++ codebase to compile both native and managed for the bits of code that need to be shared.
How is this possible, if the syntax for pointers-or-handles differs between unmanaged and managed code? The * in native code becomes ^ in managed code, & becomes %, etc. Using the managed syntax on a native compiler or vice versa causes the compile to fail. Must one create one's own higher-level language that compiles both to standard C++ and to verifiably type-safe C++/CLI?
Just as there are bits that would have to change in native Win32 C++ vs iOS vs Linux
At least native Win32 C++, iOS, and Linux all use the same syntax for pointers.
It does if you're trying to compile with /clr:safe, which is required for Xbox 360 and Windows Phone 7. Native pointers (the *) cannot be used; only handles (^) can. From the Wikipedia article: "the .NET reference types are accessed through a 'handle', with the new syntax ClassName^ instead of ClassName*." Using a pointer in /clr:safe will prevent compilation, and using a handle in a standard C++ compiler will prevent compilation.
I don't even have to be a touch device dev to know that's got a serious problem with it. One of the biggest issues with porting to touchscreen right now is that a mouse allows you to move or hover over something with or without the button down. A touch screen's lack of "mouseover" is the #1 headache in converting flash based games, since the vast majority of them use hover extensively. (and all of them require click) The ones that use drag extensively are frequently never ported.
You have to come up with a way to differentiate a drag from a hover with the touch screen. There's several different approaches to this, including holding down a button somewhere else on the screen with a different finger, (costing valuable screen real-estate) but no matter what you do it's going to at least slightly affect game mechanics. For example, with a mouse, there's no way to get the pointer into a box without it moving over one of its sides.
Second problem: Touch displays natively allow the pointer to teleport anywhere on the screen. That alone breaks a lot of games. Again there are game mechanic changes you can make like "if the mouse tries to teleport, move it slowly from the old position to the new and make sure it doesn't run over/into something we need to process along the way", but just that by itself is a significant change/addition to the code.
I work for the Department of Redundancy Department.