1. The Aftermath has been revealed for the 19th Terraining Contest! Be sure to check out the Results and see what came out of it.
    Dismiss Notice
  2. Melee Mapping Contest #3 - Results are out! Congratulate the winners and check plenty of new 4v4 melee maps designed for this competition!
    Dismiss Notice
  3. The winners of our cinematic soundtrack competition have been decided! Step by the Music Contest #11 - Results to check the entries and congratulate the winners!
    Dismiss Notice

Spell Submission Rules

Discussion in 'Rules & Information' started by Hive Workshop, Feb 20, 2013.

Thread Status:
Not open for further replies.
  1. Hive Workshop

    Hive Workshop


    Jun 30, 2016

    • Submissions must have an adequate resource description. A changelog must be present in either the resource description or the trigger viewer.

    • Spells must provide an in-game screenshot. Systems do not need an in-game screenshot, but their preview image should be related to the resource.

    • Submissions must be useful. Concepts that do not have a clear purpose, or are extremely simple might be rejected (e.g. a "remove unit on death" system is too simple).

    • Submissions must be leakless. To find out more about leaks, click here.

    • Spells must mimic in-game mechanics (e.g. damaging spells must give bounty when they kill enemies).

    • Submissions must be MUI or MPI, meaning that they can be casted by multiple units or players without bugs.

    • Systems must be as instance-able as possible (instance-ability will often depend on the type of system).

    • Submissions must have decent performance. Unnecessarily repeating function calls, repetitive group enumerations, overuse of special effects, or other useless overhead, should be avoided to prevent a performance drop.
    • Under no circumstances can a resource modify Unit User Data (Custom value) with the exception of Unit Indexing systems.

    • The documentation must at least contain a listing of the API, external library requirements and importing instructions.

    • No overloading the test map with bulky, unneeded custom models and icons. If you really do need to use a lot of imported content, link to it in your description.

    • Submissions must be easy to import. Strive to require as few changes as possible when importing (e.g. use variables to store object editor data such as abilities and unit-types).

    • Submissions must be made using vanilla GUI (aka triggers), JASS, vJASS, Zinc, or Wurst. Using other third party languages, including UMSWE GUI, or similar, is prohibited.

    • GUI resources must strive to follow common GUI convention set by GPAG.

    • JASS resources must strive to follow common JASS convention set by JPAG.

    • All submissions must follow the General Resource Rules.
    Last edited by a moderator: Dec 26, 2017
Thread Status:
Not open for further replies.