Interested in creating a Blueprint? Need to know what you need to include in your Blueprint? Then this is the page for you.

• Example Game
• The File Structure
• The Readme File
• Preloader
• Clearly Commented Code

Example Game

A Blueprint is designed to be a barebones example of a working game made in Kiwi. So the game needs to be working and as bug free as possible.

The game itself doesn’t need too huge or large in scale/complexity, but should be enough to show off all the core game mechanics that would be expected of that particular type of game you are creating/have created the Blueprint for.

The File Structure

When you are creating a Blueprint its File Structure has to be consistent as the outlined below. This is the way we think makes the most sense when creating your games and a consistency across Blueprints will make it easier for other people when switching between projects to know where everything is located.

Web Root

• index.html – Main HTML File, your example game should be viewed on this page.
• assets/ – Any assets in your game, or on the HTML file should be contained within this folder.
  • img/ – Where your images should be stored.
  • audio/ – Where any audio file should lie.
  • data/ – Any data files (e.g. JSON) that the Blueprint uses.
• lib/ – External Libraries that are required/used should be contained here. This includes Kiwi and Plugins.
  • gl-matrix.min.js
  • kiwi.min.js
  • plugins/ – Any Plugins that are used.
• src/ – Source JavaScript files used in the game/example.
  • GameObjects/ – Any core GameObjects that have been extended would be contained here.
  • States/ – All States used in your Game.
  • Utils/ – Folder containing any Utility Methods/Objects.
  • game.js – The main JavaScript game file.
• docs/ – Contains any extra documentation about the Blueprint.
• readme.txt

The Readme File

Each Blueprint is required to contain a readme file. This readme document can be formatted in anyway that you think is best but it should at least contain the following points.

• Name – The name of your Blueprint.
• Current Version – The current version of the Blueprint.
• Author/s – Who is the author of the Blueprint. Can be a team/group of individuals.
• Support Website – (optional) A website that people can visit when looking for support/documentation on the Blueprint.
• Latest Kiwi.js Version Tested – The last version of the Kiwi.JS that was successfully tested with the Blueprint.
• Description – A brief description about the Blueprint.
• Version Log – Documentation of the differences between versions. What was added/removed with new versions.

Preloader

The Blueprint your create should contain a preloader, or a documented space for one. You game may contain multiple preloaders across various game states which is fine, as some games do require that.

Clearly Commented Code

All code that you write should be clearly commented. We aren’t talking about commenting every single line, but just at the top/start of methods/functions and classes are fine. But if a method is rather long, or you think what you are doing at a point is complex then a little comment about what’s happening can make all difference.

When commenting just think if that would have made sense to you when you were starting out

Example