Google Apps

Google Apps allows you to set up your own suite of Google-driven applications, for free – giving you shared documents, e-mail, calendars, and wikis. If you have control of your domain’s DNS records and haven’t already set up any MX records for another service, I would highly recommend Google Apps for your e-mail – I’ve been using the service for the last 6 months on a number of side projects, and haven’t had to deal with any headaches or downtime. Also, a 99.9% uptime guarantee is great if(like me) your core competency is development instead of e-mail.

Google Ajax APIs

Google also makes available a large number of Ajax APIs for developers – which lets you build things like Google Maps into your game, for free. One of the more useful APIs that they make available is their Ajax Libraries API – which means that you no longer have to worry about hosting your own copy of the core libraries for the javascript framework you’re using. The benefit of using Google’s Ajax Libraries API comes from caching, primarily – if users have visited a page that used the Google Ajax Libraries API before they visit your site, the javascript will be cached – which means that’s one piece of code their browser won’t need to fetch again when they visit your page. In the end, this results in a speed boost for your site – and even if the user doesn’t have the library cached yet, Google’s servers are configured with optimal performance and cachability in mind, so you don’t need to worry about doing that yourself.

Those are just two of the services Google offers that are useful to browsergames and not every developer knows about; are there any other Google tools your game is using?

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.

Possible Applications

1. Mobile Phone

   There 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.

2. GUI Application

   If 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.

3. 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.

Porting your game to Facebook, however, is not an easy job to do, especially if your game is deployed on multiple servers.

Browser Based Games found a solution for this. By using Browser Games Hub data and an OpenID provider, they provide players an easy way to play browser games with their Facebook or OpenSocial capable (Orkut, MySpace, Netlog, …) account.

OpenID?

This application requires OpenID support. OpenID is an open source system that enables users to use one identity across the web. Using one OpenID you can login to hundreds of websites without remembering all those passwords and logins.

Depending on how your game is written, OpenID is fairly simple to install. There are a lot of libraries in multiple languages and a rather extended quick guide can be found here.

On a sidenote, if your game supports OpenID, it will also support GalaxyNews ID, which is based on the OpenID technology.

Note: in order to add your game to the BBG application, your login script must receive the openid_url in GET, not in POST.

Adding your game
Next issue on the list is adding your game to BBG application. Since it uses the information provided by Browser Games Hub, you will have to add your game to the hub (see previous article). The most important section in your XML will be the servers element. If this section is invalid, your game will not appear in the application.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<browsergameshub version="0.1">
	<servers>
		<server group="Pool A">
			<id>Server ID</id>
			<name>Server 2</name>
 
			<version>0.123</version>
			<game_url>http://link-to-your-game-server/</game_url>
			<openid_url>http://link-to-your-game-server/openid.php?openid_url=%s</openid_url>
			<players>2504</players>
 
			<status>open</status>
			<descriptions>
				<description lang="en">speed 1x</description>
			</descriptions>
 
		</server>
	</servers>
</browsergameshub>

Let’s take a closer look at the element openid_url:

			<openid_url>http://link-to-your-game-server/openid.php?openid_url=%s</openid_url>

This element should contain a direct link to the action of your OpenID login form. The GET variable declared in openid_url=%s will be populated with an OpenID. The Browser Games Hub will throw an error if it’s not working.

And next?

That’s it, really. Your game should now appear in the Hub with a lightning symbol, showing that your game supports OpenID. The application is only updated a few times a day, so it might take a while before all those facebook users start joining your game