Game Requirements for Enginesis Integration

All online games built for Enginesis properties and affiliates must follow these integration rules:

• Games may be built in any supported technology, preferably HTML5/JavaScript or Unity (webGL). We accept Flash or Shockwave for browser-based games but fewer players will load these plugins.
• The game must load the Enginesis SDK first and if the SDK cannot be loaded the game should fail with a user-friendly error message. The specific details about how to load the SDK are included in the source code samples.
• All game components must reference subordinate assets relative to a dynamic path determined at runtime. This is because the component is loaded from a content management system originating in a different folder than where the invoking file resides. We provide a function to help determine the path to your game folder: Enginesis.getBaseDir(null); For example, if your game needed to access the file gamesettings.xml and expected that file to be in the same folder as the loaded game file (i.e. the current directory), then your code is required to do the following:

      var myFile = Enginesis.baseDir(null) + "gamesettings.xml";
      

  Note the function supplies the trailing /.
• Start-up parameters are communicated into the game from the server from the CMS. How this happens is different based on the plug-in technology. We cannot support game-specific items passed into Flashvars or the URL to the game. It is best to use external files (JSON or XML) or HTTP requests to drive parameterized initialization data.

Please note: all requests for all files and external data must originate and terminate on Enginesis servers. We do not support references to external servers.

• All games larger than 1 megabyte must provide a file pre-loader that loads the game files with some animation indicating load progress.
• Games may not reference any resources on external web sites without the consent from the Enginesis game producer.
• We do not support any server-based services other than those described in this document. If your game requires specific services or data access not provided by Enginesis it must first be approved by the Enginesis tech team. We will not deploy any CGI, php, Java etc. or databases developed by third party developers.
• All references to external assets should be parameterized as is best suited to the game such that URI references can be changed without rebuilding the game. All externally referenced assets must be stored in the same folder as the first file loaded or a sub-folder therein. For example, store parameters in a JSON, XML, or a plain text file.
• Game tracking functions must be called in every game. Consult the Enginesis producer to determine where the proper calls are to be placed and the required data values. Game tracking functions are found in section Game Tracking on page 8.
• Stage sizes should target a 800x600 or smaller format for compatibility with the most sites. If your online game must be larger than this please verify your size requirements with your site producer.
• All games must provide user sound control such that all sounds may be muted and unmuted.
• All string data intended for the GUI must be separated out into separate string tables and loaded by the game code. In-line code containing text is not acceptable if you hope your game will be useful to a global audience.
• All graphical elements with embedded language, including text movie clips or graphics with embedded language, must be collected together in the library under a folder designated by the country code. All of our games are targeted to multiple countries and we need to make the job of localizing as simple as possible.
• All source code and necessary components to build a game must be delivered with the final release delivery of the game. Enginesis will not sign off on a completed project until the game can be built by Enginesis staff.