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.
... 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
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.
Hey, it's nice to read some good news about an evil empire every now and then. Who wants to constantly read: Android Good! iOS Bad! Maemo Good. Nokia Bad. Freshen up the room a bit; no one wants to smell Apple's farts and Google's belches every day. Furthermore, you're an AC. Man up and post with a user name.
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.
Microsoft has always been great at building developer tools, and the Windows Phone 7 SDK is yet another example. Silverlight is a natural fit for apps, and XNA works well for games (modern games haven't gone straight to the hardware for at least a decade -- the power comes from hardware acceleration, and the phone provides that).
That said, not all is well in Windows Phone 7 land. The SDK has some very arbitrary limitations, like not allowing you access to the camera except through a task that spawns the stock camera app. No AR apps for Windows Phone 7 Series Phone Smartphone phones. Barcode/tag scanning apps are still possible, though inefficient, as they have to spawn the camera task, wait for you to take a picture, wait for the app to resume, and then process the saved picture. I could scan five barcodes on an iPhone or Android phone in the time it takes WP7 to scan one.
No doubt the SDK will get better, but that's too little, too late. WP7 was already so far behind, it couldn't afford to launch without parity with iOS and Android in areas like direct camera access. These are things that are simply expected to be available these days, and not having them is a huge limitation that will prevent developer adoption.
And just a quick note on the games front -- independent developers only get XNA access, but major third-party developers can write native code (and access Xbox Live, just like Indie vs. Arcade games on Xbox). In other words, Unreal or RAGE tech on WP7 is just as possible as it is on iOS or Android. It's just that it's not going to come from the 14 year old programming in his room upstairs.
"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.
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.
You can do anything at Zombocom. Anything at all
I would think about it but I haven't been given mode points in what seems like forever, did the rules for getting them change?
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.
Who wants to read the truth constantly? Probably a lot of people.
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.
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.
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.
Technically Microsoft do not have to pay for product placement on slashdot (and it seems unlikely that they would have done so and even more unlikely that this traditionally anti-Microsoft site would have acquiesced). Favourable articles about Windows 7 results in a large number of posts, and this translates into more ad views. Like it or not, Slashdot makes money by being controversial.
That said, the pro-Windows 7 comments (at least for the desktop version) are in keeping with the positive reception of the platform all over the net and is reflected in the increased sales of the OS compared to Vista. For this reason, claims of paid product placement and astroturfing seem highly unlikely. Obviously the recent douche who made incredibly obvious pro-Microsoft "astroturfings" under a variety of new accounts is the exception. But that was so blatant that it had to be a troll, rather than a real shill.
As for Windows Phone 7 (back on topic), often the people who have actually used it seem to report favourably on the platform. But like me, most people haven't even tried it and just assume that it will not be very good. I suspect that this is due one incredibly stupid mistake, and that was to not support copy and paste.
This was such a major (and publicly derided) problem on the first version of the iPhone that the lack of the feature in Microsoft's product just screams that the platform is unfinished. Whoever made that decision at Microsoft should be hung, drawn and quartered - and then sacked.
As with the original iPhone, it will be worth waiting for the next version of Windows Phone 7 before buying. Myself, I'm going to wait until Windows Phone 7 version 3.1 - that was the right strategy in the past!
The truth? You can't handle the truth! If we were speaking truth it would be thus: Apple is run by a control freak, Android is fragmented to hell and one of several products the parent company plays fast and loose with the rules for, WinPhone is dead last and will probably stay there, WebOS is nowhere to be seen ATM, and RIM is dead, they just don't know it yet!
In actuality you'll get "Android is teh shit because it is teh FOSS and thus is good (though not really, just the kernel and even then Google hasn't released the latest version) and isn't nor has it ever been fragmented (ignore those 4 versions on the shelves!)" "iOS invented everything and Steve is a God, never an asshat (ignore the arbitrary rules that don't seem to apply to itself) and their prices are NEVER high and are competitive with the other products (if you don't count the 60%+ profit margins that is) and is great!" and of course "WinPhone is a completely new idea and thus will take time (ignore all those WinCE versions behind the curtain!) to find an audience (who will run over WinPhone to get the latest iShiny) who will appreciate its ease of use and synergy (Oh God, if we don't get Halo running on this thing we're fucked! Is my resume up to date?) and like previous products simply needs to build momentum (like Zune) and find its niche (like Kin)" and finally RIM "We're not dead yet! we feel better, we really do! we feel happy, we feel happy" (bashes in back of head and throws on the cart)
So as you can see, reality and fanboyism and bullshit rarely do meet in the middle. So expect praise of the latest iShiny, Google Honeycomb Hideout, and WP7 which like WinCE will later be known as WiPe, as in you wipe your ass with it before finding an iPhone.
ACs don't waste your time replying, your posts are never seen by me.
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.
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.
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.
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
Thanks for giving me the useful information. I think I need it. Keep up your work. Thank you - friv4.info
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.