Submission Checklist

Before you submit your game to us for approval, here is an integration checklist that should be completed. After you make sure that your game meets all of these criteria, feel free to contact us and request that we run a quality assurance pass on it to make sure it’s ready to go for publishing. This is the same checklist that we use when verifying your game, so if your game doesn't pass an item, we will ask you again to make sure it does before we can approve it for publishing.

📘

Note:

Please make sure before submitting your game for approval that it is uploaded to the account that you wish to publish the game under.

Kreds Purchases

  • Players can make a purchase in the game.
    The purchased item should show up quickly following the completion of a purchase.

  • Purchase prices match between the UI and the server prices.

  • The game checks for uncredited purchases on start-up.
    Basically, each time the game loads, you should call the same function that you use after a purchase is made to check for items in the user’s Kongregate inventory. This helps reduce problems from network errors and allows the user to refresh the page if a purchase fails, cutting down on support emails.

    The best way to check for this is to start a purchase, open up the first Kongregate purchase window, confirm the purchase, but then don't close or continue on from the confirmation purchase window. Instead, refresh the page - this will cause the game to not notify your local callback function of the completed purchase, even though the item was paid for (thus simulating a network/computer glitch). The item should still be credited to the player upon loading the game again.

    Note: If you are using the dynamic item purchasing API this will not apply to your game.

Authentication

  • The game correctly identifies a user.
    If the user logs out and logs in as a different user, the game correctly switches over to the new user. (You can contact us to add permission for multiple users to access the test version of your game: just tell us which usernames you wish to have access.)

  • The game protects against hacking by manipulation of the authentication URL.
    This one is a little more complicated, but basically we want to make sure that you’re protecting against hack attempts by changing the authentication URL parameters. As long as you’re using the full authentication API and not just reading and trusting the userID passed in via the URL, you should be fine.

Statistics

  • Initialized stat is being submitted.
    We strongly recommend submitting a stat to us called "initialized" or "loaded" that sends a "1" each time the game loads successfully. This must be done early, generally at the title screen after the game has loaded, or no later than character selection/creation (if that happens first thing) - it cannot be post-tutorial or after the first level. We can use this stat to ensure that ratings for the game are by people who meet the game's minimum system requirements. It generally is not as important for Flash games, but if you use an unusual plugin/technology like Unity3D, Java, or HTML5, or are Windows-only, this will help give you a more accurate rating and is highly recommended.

    Let us know if you have set up a statistic like this so we can set it up as a filter. We also strongly encourage you to use the Statistics Client API to submit this statistic as opposed to the Server API, as it makes testing this statistic a lot easier for both you and us, allowing us to approve your game faster!

    Note: As this may modify the game's rating, any games using this service will be excluded from monthly contests.

  • Other statistics are working and submitting scores.
    This is optional, but implementing statistics such as player level or PvP ranking are a great way for players to compare their progress against one another. Perhaps more importantly, if your game later qualifies for badges we'll need the Statistics API to implement them.

    If you end up adding statistics into your game, make sure they are submitted when or soon after their specific event occurs, and also make sure to resubmit them every time the game loads. That way, if a player has connection issues, the next time they load the game their score will still be updated!

Other points

  • Guest landing page.
    Players that come to the game but aren't signed in to a Kongregate account should see a guest registration page, hopefully with some sort of cool art and explanation of the game that would make them want to register. There should be a “Register” button somewhere on the page that calls kongregate.services.showRegistrationBox(). The game should listen for login events and automatically log in when one occurs.

    Note: In order to test as a guest, get your guest access URL by adding /api to the end of your game's URL.

  • The game functions in Internet Explorer.
    If it does not, this is usually indicative of not setting P3P headers correctly.

  • The game functions in Safari (optional).
    If it does not, this generally has to do with attempting to set cookies from within a cross-domain iframe. Safari’s security policy is set very high by default, but there are a few workarounds that can let your game function.

    If you cannot support safari, please detect the browser type and display a message suggesting Firefox or Chrome to the player.

  • No outside referral links.
    While we are happy to have friend referrals in the game, they need to be URLs that point back to Kongregate. You can preface URL parameters with kv_ (ex. ?kv_foo=bar) to have them passed in to the iframe.

    When all of this is completed and you've submitted your game, we'll also do a quick play-through to make sure the UI is functioning, there aren’t any dead/incorrect links, or anything else that stands out as non-functional in the game.

Marketing Assets

  • When uploading the game you will be asked for a game icon which will be used throughout the site. This should be 250x200px. It can be larger, but we'll resize it down to that (and sometimes smaller for smaller placements). We'll also make it match that 5:4 aspect ratio, so you should keep that in mind to avoid stretching or squishing of the image.

    Example:
    You also will have an opportunity to submit game screenshots. These are optional but will be visible for when players hover over your game listing. They should be 300x200px or larger, and again we'll resize and match that 3:2 aspect ratio.

    Example:

  • After we approve the game for publishing, we'll ask for some marketing assets to promote the game on the site. Our virtual goods games are given complimentary spotlight ad impressions when they launch to help build your audience. These ads come in two sizes. The first are the smaller spotlight ads found throughout the site, including below the fold on the homepage and all game pages. For these, we'll need a 66x66px icon (no special border needed), as well as a short (roughly 50 characters, including spaces) description of the game.

    Example:

  • The second is the larger game browser spotlight that appears in the various game browser pages. This one uses a 171x137px icon (again, no border) and can have a couple more words than the smaller version.

    Example:

  • In addition to sending us these two icons and descriptions for ads at launch, if you have additional general marketing assets that we could potentially use in future promotion we'd be happy to get those as well. Layered .psd's are often best, but we can work with most anything. Please feel free to send us anything else in a zip or as an ftp link. We're not guaranteeing additional promotion, but if we are able to do some it is helpful to have a cache of assets for the game.