Solar2D Asset Packaging Guidelines

The Solar2D Plugins Marketplace accepts plugins built for Solar2D, app and game templates built in Solar2D, and any form of generic asset intended for app or game development such as music, sound effects, icon packs, texture packs, spritesheets, and models. You can list your assets for free, for a one-off payment, or for a subscription fee.

These guidelines explain how to package your asset appropriately for distribution via this marketplace, subject to the type of asset you're uploading. If your asset is a plugin it's assumed that you've already followed the Solar2D documentation on creating Lua, Native, or Hybrid plugins and that your plugin is already working and ready for distribution. Creating plugins is not covered by the scope of these guidelines.

Plugins

Lua plugins

If you've followed the Solar2D documentation to create your plugin, you should already have an appropriate folder structure consisting build.settings, config.lua, main.lua, and a plugins subfolder containing your actual plugin code. Your main.lua file should already be a test project and one level above these files should be build.sh and build.bat files.

When you've completed adequate testing and you're ready to package your plugin for release to the Solar2D Plugins Marketplace, run the build.sh executable in a terminal on Mac, or the build.bat executable in a command prompt on Windows. The build process should create a new Zip archive containing a compiled bytecode version of your plugin code. This Zip archive is ready for submission.

Plugins should be well documented. You must at the very least include usage instructions within the description area when submitting to the Solar2D Plugins Marketplace. Complex plugins might warrant more comprehensive documentation which should be provided as a url during submission.

When ready, visit your account dashboard, follow the link to submit a new asset, select the Plugin type and attach your Zip.

Native and Hybrid plugins

If you've created a plugin using native code or a hybrid of native code and Lua code, you'll need to download our native plugin submission template and add your compiled .jar and/or .so files into the appropeiate device folders. Edit all metadata files accordingly, as per the comments and examples that they provide, and rename + edit the plugin_PLUGIN_NAME.lua files within each *-sim folder to contain the same functions that your native code provides.

All instances of PLUGIN_NAME throughout file names and file content should be replaced with the name of your plugin, in the same format that the .jar or .so files are named but retaining the plugin_ prefix.

As per the examples, these Lua stubs can simply output console messages or return dummy data. The basic idea is that a plugin built in native Android Java code for example, can still be simulated on devices that don't run Android. If you really don't want your plugin to be used on a particular device, remove the content of that folder but leave the folder itself in place.

Package the resulting files in a single Zip archive. This Zip archive is ready for submission.

Plugins should be well documented. You must at the very least include usage instructions within the description area when submitting to the Solar2D Plugins Marketplace. Complex plugins might warrant more comprehensive documentation which should be provided as a url during submission.

When ready, visit your account dashboard, follow the link to submit a new asset, select the Plugin type and attach your Zip.

Templates

Game and app templates must be provided with a complete Solar2D project structure, including build.settings, config.lua, and main.lua files, packaged into a single Zip archive. If you're providing other resources with your template, such as Photoshop design files for editing UI elements or instructions on how to use your template, you should provide these outside of the main template folder but within the same Zip. For example the root of your Zip archive could contain an instructions.txt file, a resources folder containing these additional resource files, and a project folder containing the project template itself.

Templates should be well documented. Make use of in-code comments as much as possible and provide at least a readme file within your template archive, or usage instructions within the description area when submitting to the Solar2D Plugins Marketplace. Complex templates might warrant more comprehensive documentation which should be provided as a url during submission.

When ready, visit your account dashboard, follow the link to submit a new asset, select the Template type and attach your Zip.

Other assets

To distribute any other type of asset via the Solar2D Plugins Marketplace, such as graphic or sound packs, simply include all appropriate files in a single Zip archive structured in a way that you feel is logical. For example if you're providing a large number of icons in a variety of sizes, it might be appropriate to split those icons into categorised folders within the archive and then within each folder, provide a separate spritesheet for each size variation. E.g. potions/256x256.png.

We don't impose strict rules on how generic assets are bundled, we just ask that you structure them sensibly. When ready, visit your account dashboard, follow the link to submit a new asset, select the Asset type and attach your Zip.

The submission process

Asset review

Unless you're identified as a seasoned vendor, all of your submissions will enter a review process where we aim to ensure your package is well structured, of high enough quality to be useful to others, and free from malicious content before it goes live on the Solar2D Plugins Marketplace. At our discretion we may identify some accounts as belonging to seasoned, trustworthy vendors who we no longer feel obliged to review submissions from. Submissions by seasoned vendors will be made live on the Solar2D Plugins Marketplace immediately but if it is found that such vendors are abusing our trust, this status will be revoked and all of that vendors submissions will enter the review process again.

QWeb Ltd reserves the right to accept or decline any submission without explanation. We will however endevour to provide explanation and advice where possible.

General restrictions

Contents that you do not hold the proper rights/license to resell or redistribute will be rejected.

Copying/redistributing the content that you downloaded from an open source domain are not acceptable.

The content must not use any trademarks/logos/brands that you do not own.

The content must not contain anything that may be deemed inappropriate. Overly sexual, violent, gruesome, hateful (race/religion/gender/identity/etc.) submissions will be rejected.

Content which attempts to perform any negative actions that are not anticipated from the user will be rejected. Negative actions may include:

  • (i) Tracking a user's data without prior approval.
  • (ii) Attempting to install any malicious programs, virus' or noncritical background services.

Content must be usable "out of the box", or with minimal set-up requirements, and must not require any special additional software or service to be operational unless its requirements are innately understood. It is reasonable for example, for 3D models to require the installation of 3D modelling software capable of creating renders usable within a Solar2D game.