if I want to build a game for web, facebook, and iphone, do I need to build 3 completely different versions? I know there is a new company that is "build once, launch anywhere," but I'm asking about current best/practice and methodology in doing this.
|
|
This really depends what type of game that you are making. If your game is a simple text based game, then you can build the same interface in HTML and use different CSS to make it look good based on where the game is being accessed from. More realistically, your game is highly interactive, and it would be best to build the web/facebook version in Flash/Silverlight or another browser plugin. Then port it to iPhone in Objective-C. (Or, if you're more proficient in Objective-C start there and port to web/facebook.) The main issue that you'll probably run into is that on iPhone the input scheme will be different which could impact gameplay. The bottom line, is that you will need to, at a minimum, build a different Rendering and Input scheme for each platform you wish to deploy to. Facebook, is really just a normal web deployment, inside the facebook site, so the design would be the same for facebook or any other web game. edit A few things I'd like to point out, based on your comments. First, HTML5 is probably NOT a good place to start, it has poor browser support (thought getting better), I'd stick with HTML4 and/or XHTML 1.1 and CSS2, these will work in almost all modern browsers; however, if you require any animation, I'd recommend using Flash or Sliverlight to build the game, and use their associated ability to call web services to save state to a server. Second, HTML is just the presentation, if you don't go the plugin route, you would likely need PHP or ASP.NET on the server to manage your game state and persist it to a database. |
|||||||||||
|
|
There are platforms that could enable you to minimize the amount of porting work you'd need to do -- Unity, for example, which somebody apparently managed to integrate into Facebook with at least some success. It's certainly technically possible to build a product that more-or-less seemlessly compiled and deployed to multiple distinct platforms like that, but there are problems that are nontechnical in nature that you'd have to overcome -- such as how to design a game that functions well in the wildly different contexts of all those platforms (some of which have very different input styles). |
|||
|
|