What is required to make a game portal friendly?

[Nemesis]

This question is not about what constitutes a portal-friendly game in terms of concepts and gameplay.. I think we've had enough of those with flames and rants following suit!

This is more of a techie question in the sense of what is required to make a game architecture that meets the tech specifications of the major portals?

I get the impression that portals such as RealArcade and Bigfish require you to integrate a portal library of some sort with the game code - I assume that these libraries include functionality to display splash screens, reg key management, link-backs to the portal site, and the like.

[ggambett]

Some of these use wrappers which wrap and compress your EXE - for that cases, your EXE shouldn't read itself (ie don't append data to it) and that's it.

Others have the option of using a SDK, to show in-game buy buttons, for example. In that case, if you can call an extern function with C calling conversion, you're OK.

We had a problem using ActiveMARK (Trymedia's wrapper) with EXEs built by MinGW32 - they all crashed when calling the SDK. Switching to the freely available Visual C++ Toolkit (the command line compiler) did the trick. So we are now using MS tools from the Linux command line, yay :)

[Nemesis]

Did you ever figure out why compiling with MingW was an issue.. calling conventions perhaps?

I was wondering about the most convenient way to organise the build variants for each portal since obviously there is no standard yet. Given that portals are essentially competing against each other, I think the situation is unlikely to change. Perhaps setting up different projects / makefiles for each build would do the trick, with conditional compilation being an alternative.

[Coyote]

Use a single executable - dual executables can cause problems.

Your game should be a disabled full version - don't split your game into two completely separate distros.

Obviously, you should make it trivially easy to switch DRM solutions on your game - including none whatsover (for wrappers that do that themselves).

Links to your site should be in an easy-to-change, no-recompile-needed file, since many portals demand that you scrub out any direct links to your site.

I managed to get the LAST ONE right on my first release --- I wish I'd thought ahead on the first three. Also - remember that there are exceptions to every rule. IIRC, I think GarageGames actually prefers separate distros for the trial vs. the full version.

[James C. Smith]

For downloadable game it is very rare to be required to use an SDK or add any special code. As long as you have a full version of the game (non-demo) with no links to your web site you can give it to 98% of the distributors without any code changes. They will wrap it in their DRM and you are done. But some have the option to use an API to detect if you game has been purchased or is in trial mode. You may want to detect trial mode so you can disable some features or display addition up-sell messages in-game.

You usually don’t have to make separate code changes for each distributor. But there are a bunch of things you may have to change if you have never used any distributor. There are things that were already mentioned like no linking to the web, no data in your EXE, no compression of the EXE, and no EXEs launching other EXEs. In that last one I mean that you should not have a launcher program that configures the game setting and then runs the game.

Many distributors will want you to add “branding”. In other words, they want you to put their logo in the game. As a general rule, the distributors want their logo any place your logo is. If you have a logo on the splash screen, then they want one there. If your logo appears on the main menu or game play screen then theirs must be there as well.

If you make a web browser playable version of your game (such as Java, Flash, ActiveX) it is a whole different ball game. Many web game portals such as MSN Gaming Zone have an API you must implement in every game. This handles things like high scores, advertisement display, and loyalty rewards point.

[ManuelFLara]

Some of these use wrappers which wrap and compress your EXE - for that cases, your EXE shouldn't read itself (ie don't append data to it) and that's it.
Does including an icon resource break that restriction? If so, it's up to them to set an .ico (that you provide them) for their wrapped exe?

[Nemesis]

This is definitely some interesting info as I'm sure many developers approaching portals have had to go through some sort of rework (and hassle?) to get their game application portal-compliant. Thanks for sharing the info guys!

James, you made a mention of web links.. does that include not having an online hi-score? I've recently played Iggle Pop and noticed that it does feature online hi-scores despite being a portal distribution.

[James C. Smith]

Not every distributor has the same rules. But in general, they would prefer that the game does not direct players to any web site and you absolutely must not direct players to a web site that has games for sale. For example, many unacceptable games link back to the developer’s web site and that web site has games for sale. Most distributors would make you remove this link. Most “portal friendly” games that have Internet high scores lists do it all in-game. For example, in Crimsonland you can post and view Internet high scores without ever going to a web site in your browser. Some portals allow some web based high scores lists as long as the web site doesn’t link to anything else and has nothing for sale. But they are still nervous about it because you could change the contents of your web site at any point in the future.

If you want to do Internet high scores it is beast to do it in the game and not on a web site.

[Nemesis]

That's true.. one's got to deal with posting and parsing data, handling failures gracefully, and rendering the online hiscores in-game, to name a few. Although I definitely believe that online scores are attractive to the prospective gamer, I am seriously debating wether it is worth the hassle!

[ggambett]

Did you ever figure out why compiling with MingW was an issue.. calling conventions perhaps?
No idea. Since these wrappers intercept system calls and probably do low-level undocumented stuff, it's quite possible that they depend on something that Visual C++ does to their EXEs that MinGW doesn't. I really don't know.
I was wondering about the most convenient way to organise the build variants for each portal since obviously there is no standard yet.
I have one source tree that builds for Linux, Mac and Windows, including 2 or 3 wrapper SDKs, and separate full/demo versions. Most of the differences are encapsulated somewhere where the different cases are #ifdefd.
James, you made a mention of web links.. does that include not having an online hi-score? I've recently played Iggle Pop and noticed that it does feature online hi-scores despite being a portal distribution.
We have an online highscore table for Betty's Beer Bar, and except for one publisher, we reached compromise solutions with the others, such as having the link to our site but without other navigation, and/or including their logo below ours. See http://www.mysterystudio.com/bbb_highscore.php and http://www.mysterystudio.com/bbb_highscore.php?nonav
Does including an icon resource break that restriction?
No. What you can't do is fopen()ing your EXE and reading from it, because it will probably be compressed, encrypted and otherwise different to what you expect.