1. Melee Mapping contest #3 - Poll is up! Vote for the best 4v4 melee maps!
    Dismiss Notice
  2. The 30th edition of the Modeling Contest is finally up! The Portable Buildings need your attention, so come along and have a blast!
    Dismiss Notice
  3. We have a new contest going on right now! Join the 11th Music Contest! You are to make a Cinematic modern sound-track for this contest, so come and compete with other people for fun.
    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

    HIVE

    Joined:
    Jun 30, 2016
    Messages:
    58
    Resources:
    2
    Tutorials:
    2
    Resources:
    2
    [​IMG]

    • 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.