Putting a game on AGNow

What AGNow does with your game

Your game runs on our server, not on the player's computer. We send them the sound and we send your game their keystrokes. They can play from a browser, from one of our apps, or from a phone, and they install nothing.

Windows games run under Wine on Linux. Native Linux builds run directly. A game does not need to know any of this, and most need no changes at all.

Knowing you are on AGNow, and who is playing

Every session sets these in the game's environment:

• AGNOW=1
• AGNOW_USER_ID is the player's account number, for example 300
• AGNOW_SESSION is this one session
• AGNOW_GAME is the game's id here
• AGNOW_HOST is which AGNow, for example agnow.brynify.me

The same values are in a file, for toolkits that cannot read the environment. Windows games get C:\AGNow\session.txt. It is one key=value per line, with the AGNOW_ dropped and the names in lower case:

agnow=1
user_id=300
session=4f1c9a02
game=yourgame
host=agnow.brynify.me

The file is in the Wine prefix, not in your game's folder, so it is never part of the player's saved data and never appears if your game lists its own directory. Native Linux games get the same file at the path in AGNOW_INFO.

The account number is all we give you. It does not change when the player renames themselves, which is what makes it useful for banning. We do not pass their username or email address, and if you want a name to show, ask the player for one.

How much to trust that number

Inside a session on our machines, we set these values and the player cannot change them. Anywhere else, they are whatever the program says they are. If your game runs on somebody's own computer, it can claim to be any AGNow account, so do not let an AGNow number by itself grant anything on your server.

The same applies to a player streaming your game from their own computer through AGNow. The game is on their hardware and none of this is set.

If you need something your server can verify, say so. We can sign a short assertion that you check against a public key. Nobody has needed it yet, which is the only reason it does not exist.

Speech

Both of the usual ways work, and whichever you already use needs no changes.

The NVDA controller client. nvdaController_speakText and nvdaController_cancelSpeech reach the player's own screen reader, in their voice and at their speed.

SAPI. There is one voice installed, called AGNowRelay, and it is the default. Instead of synthesising audio it forwards your text to the player's screen reader, so it comes out in the same place as the line above. A game that calls Speak works as it stands.

Because that voice makes no sound of its own, two things behave differently from a real synthesiser. Setting the rate, pitch or volume is accepted and then has no effect: what the player hears is whatever their screen reader is set to. And a game that asks SAPI for the audio rather than asking it to speak, by rendering into a memory stream or a file and playing that itself, gets silence. If your game does that, tell us before you submit it.

Text you draw on screen is not read. Nobody is looking at the window.

What is saved between sessions

When a player stops, we save every file that changed during their session from:

• your game's own folder
• C:\users\<name>, which is where %APPDATA% and Documents live
• C:\ProgramData
• the registry under HKEY_CURRENT_USER

All of it comes back next time, for that player only. Two people playing your game never see each other's saves. You do not need to do anything for this to work, and any of those four places is fine.

What is not saved: anything outside those paths, and anything your installer put in C:\Windows. If your game needs a runtime or a set of OCX controls registered, tell us and we install it into the session instead.

Saved data cannot contain programs. We do not restore executables or scripts from a player's saved data, because that would be a way to run something we never looked at. If your game updates itself by downloading a new binary into its own folder, it will not survive a session. Talk to us instead.

The machine it runs on

• 64-bit Linux, with Wine for Windows games. Both 32-bit and 64-bit games work.
• There is a real X display, so a window can exist. Nobody sees it.
• The internet is reachable, so an online game works normally.
• One session is one process tree of yours, with its own Wine prefix and its own copy of your game's folder.
• Your game starts from its own folder, so relative paths work.

Sound

DirectSound, WASAPI, SDL and OpenAL all work, and we mix whatever your game plays and send it to the player. Latency to the audio device is about 15 ms, which is as low as the hardware goes.

Compressed formats are decoded by GStreamer rather than by Wine. Ogg, MP3 and WAV are fine. If your game plays WMA or uses XNA's sound banks it needs an extra codec which we install per machine. A missing one usually shows up as your game's own error message, so if a build works for you and dies here, that is worth checking first.

Keyboard and controllers

Keystrokes arrive as real key events, so anything that reads the keyboard works. That includes DirectInput.

If the player has a controller, your game sees a real gamepad for as long as they are connected. If they do not, there is no gamepad at all.

If your game downloads its own content

Plenty of games ship a small program and fetch the sounds on first run. That works here, but it means every player downloads the same gigabytes into their own saved data, which is slow for them and large for us.

Tell us and we will keep one copy on the server instead, shared by everyone playing. We check it against whatever list you publish, so it stays exactly what you shipped. We already do this for games whose sound packs run to several gigabytes, and no player downloads one of them twice.

What we need from you is a list we can check: a file per line with a hash we can compute. Both of the shapes we already support are fine, and if yours is different we will read it.

Getting your game listed

1. Ask us for a developer account, or for an existing account to be given upload rights.
2. Upload a zip of the game exactly as you would ship it, from the Manage games page.
3. Tell us anything it needs: a runtime, a setup program to run first, a COM class to register, a configuration file it will not start without.
4. We try it, fix whatever the Wine side needs, and an admin approves it.

You keep control of your own game: only you and an admin can replace its files, and you can take it out of the library whenever you like. Playing your own game here does not use your play time.

A re-upload replaces your game's files. Anything we patched inside that folder to make it work goes with it, so tell us when you re-upload and we will put it back.

Letting players download it

You can offer a copy of your game for people to take away, from the Manage games page. There is nothing to upload: switching it on offers the game exactly as it is here, zipped, for whichever platform your build is for.

If you would rather players got a different file than the one we run, an installer, or a build for another operating system, attach that for its platform and we send it instead. Each platform is separate, so you can update one without touching the others.

Switching it off stops the download for everybody, including anyone who kept the link.

Things that catch people out

• A game that waits for a key before it draws anything looks like it hung, because the player hears nothing.
• A game that writes to its install directory is fine here. A game that writes to C:\Windows is not.
• A game that quits silently is usually missing a dependency it has always found on your machine. Send us the build and we will find it.
• Filenames inside your zip that are not ASCII can arrive mangled. We can fix that, but it is worth knowing.
• A game that polls the message queue as fast as it can will work, and will cost a lot more than it needs to. If you have a sleep to spare, spare it.

Asking

Email bryn@brynify.me. We would much rather hear from you before you spend an evening on something than read about it afterwards, and we are happy to try a build and tell you what it needs.