Build an API for the Browser Game
It might not make sense from the perspective that most browser games require that players access the game from the browser. Actually, in most cases, it is the only way available to the player, even if you do build the API. If done correctly, the API will add additional incentive to play your game, but it won’t make your game.
The concept is simple, through either REST, XMLRPC, or SOAP, you allow external access to the game. This might only be limited to read-only access, where players can display their stats on their web site. It could also be expanded to include full management of the game from buying supplies to attacking other players.
If the browser game is well established with a large player base, you can imagine it being moved in either two directions. The first is where you, the developer, use your API to build a client which has better graphics and interfaces with the statistics of the browser game. The second is where another player, who is also a developer, or team of players decide to build their own client to better manage their game. Whether the client is another web site or a Windows application is totally up to the developer.
Well, there are latency issues with HTTP, so it won’t be like you will be able to build a 3D real-time based system. You’re never going to build something that robust without building an actually server not dependent on HTTP protocol. You can still build a client for smart phones, iPhone, etc, which doesn’t require that much real-time involvement.
The concept is to have the external API available for when it is needed. If no one does anything with it, then you the developer of the game can.
- Mobile PhoneThere mobile phones that include APIs for building applications directly for the phone. These applications aren’t plain web pages in most cases and have a lot of low level power. You could reach an entire expanded audience, if the game was made available to those who have these phones.
- GUI ApplicationIf you wanted to expand the game universe to either a 2D or 3D world with full interactivity and community, then pulling from the web based game world for stats would be easier. Given the latency, it might be better to create an client-server application on the server for the specific protocol that has less overhead than HTTP in this instance. If you only need a subset of the game information, then HTTP should be fine in the beginning.
- Expanded universes in other PBBG based off of your game.You allow others to create services which can expand on your universe or populate information on battles and inform the player at that service that an attack is going to happen or has happen, so that the user can pick up information from many games in one location.
Cool and New Factor
While by no means an justifiable argument, you could be one of the few PBBG that allow for this service and be labeled cool and innovative. What this means to players would have to be decided by applications that use the API.