[blat], we have standards here.

First, the conventional solution, i.e. a RO/Sin Eps type solution, where you have to install and register your game with the Steam client. Factors this has going for it are that it’s pretty much the status quo, and that I think using Steam means the publisher gets a discount on their Source license, so I can see them weighing up the risk of annoying their customers by bundling the rather intrusive Steam client against the decreased costs for the engine.

Second, the hybrid solution. I was having a poke around in the Source SDK GCF to see if I could find anything interesting, and one of the items in there is the Steam v3 API. I think it includes all the header files necessary to link against the steamclient.dll and possibly steam_api.dll, but I’m not a C++ expert by a long stretch, so I’m not sure. Anyways, it looks like the API exposes functions that are usually only supposed to be used by the SteamUI itself; the implications are that any external app (including games) could act like a Steam client itself, and connect directly to the Steam service. I’m not sure if it’s possible as it stands, but I’d say it was a possiblity in an update. Also note how servers possess a steamclient.dll for getting at the auth functionality without the Steam client being running.

As a sidebar, oddly enough the Steam v3 API doesn’t seem to include any of the filesystem stuff.

Personally, I hope it’s the hybrid solution. I can see advantages to Steam being resident and living in the taskbar, but I do think there would be advantages in it being more of a transparent service.

It’s kinda like how I see offline mode; at the moment it’s incredibly tacked on, an afterthought. Offline mode is a special case of online mode, just with all the online functionality switched off. I think this is the wrong way to think about it, online mode should be the special case of offline mode.

When you start up Steam, it should start immediately, and then begin trying to connect to the Steam service in the background, then once it connects, it enables all internet-based functionality. It’s a more reliable approach. Especially in the early days of Steam there were a lot of problems with the UI not responding because it was waiting for the Steam service to respond. The service was bogged down, and that had a knock-on effect on the UI because they were too closely coupled. If you engineer with the assumption that the internet is not availiable or when it is, is incredibly unreliable, you’re going to get a better experience because you’ll build something more fault-tolerant.

If there’s a Steam update, it should download it in the background, then prompt for a restart. There should be different authentication classes. At the moment, if Steam can’t find any logon information when you start in offline mode, it simply refuses to start offline, rather than allowing me to play free games like demos or Codename Gordon. You should be able to simply register your CD-Key with Steam offline and be allowed to play offline, at least for some games, depending on how secure you want to be against zero-day piracy.

The point is, Steam-based authentication for if I’m allowed to play or not play a game is great because it’s easily portable and whatever, but at the same time it’s more heavy-handed than it should be, and too based upon the mindset of Steam being the gatekeeper to which you must prove youself before you can get in, and not as flexible as it could or should be.

only the copys bought off of steam

I doubt that you’ll need Steam for the retail copies. If Ubi aren’t putting Steam first in pricing, they won’t be putting it first at installation either. Like I hinted in the post though, this could be when Andy S’ idea of inline Steam code appears.