Zephyr Contest #14 - Results

[IcemanBo]

Unique Summoning
Create a spell that summons one or many units in a unique way.
Eventually consider implementing a specific unit/s behaviour after summoning.
A good example is Tinker's Pocket Factory.

<< View all Entries >>

FinalScore = (30*PollVotes/POLL_VOTES_TOTAL) + (70*JudgeScore/JUDGE_SCORE_TOTAL)

Judgement

Anitarf - Code Criteria - Readme

When judging the spells, I have decided on a list of 11 judging criteria, grouped into 3 general sections: calibration, usability and performance.

Calibration (6 points)

- Description (1): The code for each spell should start with a brief description of what the spell does. This is not the same thing as the tooltip - it should be more technical. It is meant to give users an overview of what the code that they are importing/configuring does. If a spell had some kind of a description at the start of the code, it would be awarded one point here.

- Setup instructions (1): Similar to the description above, except it doesn't explain what the code does, but how to get it to work in another map. Spells that had such instructions got one point here.

- Calibration constants (3): This is where I judged how much and how easily a spell can be configured. Having a proper calibration section would earn a spell two points here, with up to one extra point available for spells that offer extra configuration options that are not even used by the default spell. If there are some values in the code that are not configurable in the calibration section or if some values are difficult to configure, I would subtract points here, and spells without a dedicated configuration section would get 0 points.

- Calibration documentation (1): While it's good to give calibration constants descriptive names, that is not always enough. Each configurable value should be accompanied by a description of what it does and spells that would lack this would loose a point here.

Code usability (6 points)

- Instanceability (2): Spells that can be cast by any number of units (MUI) get 2 points, spells that can get cast by up to one unit per player (MPI) get 1 point and spells that are not multi-instanceable get 0 points. There's one extra caveat: spells that don't use any persistent data structures achieve MUI by default, but since it didn't take any effort to achieve it they get only 1 point for it instead of 2.

- Code documentation (1): When writing code, it is considered good practice to document what the code does. Spells that have code without any documentation would loose a point here.

- Encapsulation (2): Proper use of private members in vJass and prefixes in JASS and GUI helps avoid naming conflicts and makes it easier for users to import the spells into their maps. I would subtract points here for any practices that could lead to naming conflicts.

- Library use (1): It is good practice to delegate routine work to external libraries instead of writing the same code all the time. Spells that don't use any external libraries and have bloated code as a result would loose a point here. I would also penalize other library-related missteps such as using an excessive number of external libraries or using non-standard libraries when standard libraries are available.

Code performance (8 points)

- Leaks (3): I would subtract up to one point for each memory leak I would find, depending on the severity of the leak.

- Errors (2): I would subtract points here if I noticed something that could potentially cause an error in the behaviour of the spell.

- Efficiency (3): I would subtract points here if I noticed things that could be done more efficiently, the amount subtracted would depend on the severity of the inefficiency.

For "Final Score" have a look into the results table above.

Almia - Summon Devourer

Result

Score

Concept

Code

Visuals

Poll-votes:	3/32
Judgement:	34/40
--------------	------
Final Score:	00/100

Concept:	7/10
Code:	17/20
Visuals:	10/10
----------	------
Score:	34/40

Who doesn't love summoning spiders? That spider was pretty amazing. Absorb hit points to live longer, drain mana to do a strong AoE, and send out a swarm for some cone-damage!

As for the concept, they were all really cool ideas. All the effects encouraged being proactive--you can eek out the most value by timing it in big swarms. And his effects were not just "do X damage" stuff--it had a lot of neat moving parts!

My main critique is that the effects weren't too coherent. As a player, it took me a long time to grasp all the features of the spider, and pretty much everything was affected by the level-scaling, which made it even more complex for the player. Too many moving parts can needlessly complicate a great spell--I would've condensed the features a bit, e.g. sticking to absorbing HP and mana (following an "absorb" theme), and just removing the swarm. I'd also consider removing some of the scaling in damage/movement/attack-speed, especially since all the other features are already impacted by leveling the spell.

But other than that, I really loved it! It was an enjoyable spell and the summon was great for mowing down swarms of enemies.

Score: 7/10

Code score: 17 points

Calibration 5.5/6
Description - 1
Setup instructions - 1
Calibration constants - 2.5
The spell has a very large number of calibration constants. Some more flexibility regarding what mana and life storage can do would have earned full points here.
Calibration documentation - 1
Code usability 5/6
Instanceability - 2
Code documentation - 1
Encapsulation - 2
Library requirements - 0
The code uses several small snippets that could easily be inlined, while large tasks that should be outsourced to external systems are instead inlined using textmacros.
Code performance 6.5/8
Leaks - 3
Errors - 1
The way I understand the description of the spell, the devourer should store health if units loose it while in range of the aura. As the code is written, life lost outside the range of the aura will also be counted if the unit was in range before and after the life loss. Also, missile-target collision detection depends on GetLocationZ, which could lead to a desync.
Efficiency - 2.5
The aura code could be a bit more efficient, it could cut down on the number of checks for target validity by keeping track of which units were already checked.

Animation Quality: 5/5
Channeling Transition: 5/5

Perfect score. Animation was very smooth, I felt this was stood out as the best visual summoning experience in the competition.

Chaosy - Alchemist Creation

Result

Score

Concept

Code

Visuals

Poll-votes:	1/32
Judgement:	20.5/40
--------------	------
Final Score:	00/100

Concept:	6/10
Code:	10.5/20
Visuals:	4/10
----------	------
Score:	20.5/40

This was definitely one of the memorable spells. I really like the idea of recipes, and I haven't seen too many spells involving it. It definitely has a fun-factor to it!

There were a few issues I had, though. For starters, it wasn't clear what combinations would warrant a recipe and what wouldn't. Without this stuff being well-defined, a user can easily get flustered trying to put in particular items.

Next, the spell itself had very few combinations. You made a pretty sweet system for users to add their own options, but it didn't seem like there were that many options in the demo map (and that is what we're judging on).

Other than that, I like the way it was designed (the cauldron + item interplay), and the floating text + RNG definitely were neat additions. Great spell!

Score: 6/10

Code score: 10.5 points

Calibration 2.5/6
Description - 0
Setup instructions - 1
Calibration constants - 1
Some constants are properly grouped into calibration sections, but the code is still littered with values that should be calibrateable, most notably the contents of various floating texts.
Calibration documentation - 0.5
The spell does have documentation for its calibration values, however it is structured in such a way that it might cause confusion. It seems like the values are declared next to the comments but they are in fact a part of the comment, with the actual value being declared elsewhere.
Code usability 3/6
Instanceability - 1
Code documentation - 0
Encapsulation - 1
Some constants are declared outside the libraries, there's also a GUI sound variable used, the names ItemRecipe and Modification are too generic, they should be more specific to the system.
Library requirements - 1
The spell does not use an excessive number of libraries, most of the ones used are optional.
Code performance 5/8
Leaks - 2
GetItemOfTypeFromUnitBJ can leak an item handle reference. Since found items are typically removed, this results in a couple of handle address leaks on each use.
Errors - 2
Efficiency - 1
Looping through all recipes is not a very efficient approach, since the recipes are pretty much the core of the spell I'd expect more effort to be put into the recipe search algorithm. Furthermore, due to the order of the structs in the script, the code uses a trigger evaluate for each recipe checked. The approach to linked list loops has needless redundancy in the form of the for loop counter.

Animation Quality: 2/5
Channeling Transition: 2/5

Reason for reduced score: An oversized text tag with jittery movement. The one special effect is a simple "raise dead" animation. I felt as though the object being summoned (Footman) did not deserve the awesome looking item that was traded for it.

crabas sakti - Summon Ectoplasm

Result

Score

Concept

Code

Visuals

Poll-votes:	0/32
Judgement:	21/40
--------------	------
Final Score:	00/100

Concept:	8/10
Code:	7.5/20
Visuals:	5.5/10
----------	------
Score:	21/40

Definitely a cool summon. At first, it was a bit confusing (especially the tooltip). But it was definitely fun once I got an idea of how everything played together!

Neat choice in making it cost life. Those sorts of decisions add a lot of depth to when players cast spells.
And it is pretty fun to be able to morph into a unit of your choosing. Sometimes you'll want a strong guy, and others you might want to just grab a quick small fry for a big detonation.

The interplay with Aghanim's scepter was also cool. Nice touch.

Score: 8/10

Code score: 7.5 points

Calibration 0/6
Description - 0
Setup instructions - 0
Calibration constants - 0
Calibration documentation - 0
Code usability 2.5/6
Instanceability - 1
Code documentation - 0.5
Encapsulation - 0
Library requirements - 1
The spell is simple enough that it doesn't need external libraries.
Code performance 5/8
Leaks - 1.5
The second dummy is created facing the position of the first, that position is never cleaned up. ReplaceUnitBJ leaks handle references to the old and new units. GetUnitsInRangeOfLocAll leaks a group handle reference.
Errors - 1.5
When taking a new form, the new unit will be added to the owner's selection regardless of whether it was selected before, the selection of other players is ignored.
Efficiency - 2
There's no need for two loops when an ectoplasm dies, a single loop could handle both the damage and the damage over time.

Animation Quality: 3/5
Channeling Transition: 2.5/5

Reason for reduced score: The pentagram appears off-centered and a missile doesn't make sense considering the pentagram is already there. It looks incomplete.

DD_legionTN - Elemental Chaos

Result

Score

Concept

Code

Visuals

Poll-votes:	3/32
Judgement:	34.5/40
--------------	------
Final Score:	00/100

Concept:	8/10
Code:	17/20
Visuals:	9.5/10
----------	------
Score:	34.5/40

The spell's name certainly fits the description: elemental chaos.

I felt like Neptulon with all the elementals out there. First off, great job in orchestrating the spell. The phases were very clear and distinct, and the final transformation was a great choice to make this spell a memorable summon. I like that the user has a lot of options: you can either explode the elemental or try to absorb it for the final summon--it definitely allows for some creative play.

The main issue I had with the spell was the complexity in level scaling and the spell's phases. When every aspect of the spell changes as you level it up, the spell becomes less intuitive--and you have to relearn how the spell works for every level. I would've kept some things static between the levels, e.g. the number of missiles, the elemental life time, etc.

Nonetheless, that was the only issue I had.

Score: 8/10

Code score: 17 points

Calibration 5.5/6
Description - 1
Setup instructions - 1
Calibration constants - 2.5
Calibration constants should use seconds instead of timer timeouts as a unit of time.
Calibration documentation - 1
Code usability 5/6
Instanceability - 2
Code documentation - 1
Encapsulation - 1.5
If the code used a timer in addition to the timed life, it could avoid having to store whether a unit is absorbable and the public method for setting it.
Library requirements - 0.5
Linked list and timer code could be delegated to an external library.
Code performance 6.5/8
Leaks - 2
In sphereMissile-onPeriodic, the local variable u is not set to null which can leak a handle id when spawning the first summoned unit. In onCast of EnergyExplosion, the local variable u is not set to null which leaks a handle id if DummyRecycler is not present.
Errors - 1.5
There is a potential, although unlikely, error with the linked list implementation because nodes only get recycled once there are no active instances, so if the spell gets cast consecutively so that there are always some instances remaining the code will run out of array index space.
Efficiency - 3

Animation Quality: 5/5
Channeling Transition: 4.5/5

Nearly-perfect score: A very close second with the visual winner, for its own reasons.

Emm-A- - Chicken Rage

Result

Score

Concept

Code

Visuals

Poll-votes:	0/32
Judgement:	29/40
--------------	------
Final Score:	00/100

Concept:	6/10
Code:	15/20
Visuals:	8/10
----------	------
Score:	29/40

This spell gave me a good laugh. I love anything that involves chicken.

The choice of using a "safe word" was definitely a unique mechanic (I don't think I've seen too many text-based spells). The spell was cute and there were a lot of cool morphing interactions to switch between chickens.

The spell was rather difficult to use, though. Lots of chicken were required--usually more chicken than I could reasonably keep alive. Even though the safe word mechanic was cool, it took me a really long time of trial and error to get it to work.

Nevertheless, this spell was memorable and fun! Cool effects. I loved sending my chicken swarm to go peck baddies.

Score: 6/10

Code score: 15 points

Calibration 4/6
Description - 1
Setup instructions - 0.5
No explicit instructions on how to import the spell, some aspects are covered in other parts of the documentation.
Calibration constants - 1.5
The calibration section is a bit inflexible, for example having more than 3 levels requires users to add new constants and then edit GetSpellLevel*Type functions that are technically outside the calibration section. Some values are used in the code that are not configurable, such as unit RGB colour and game message text strings.
Calibration documentation - 1
Code usability 4.5/6
Instanceability - 2
Code documentation - 1
Encapsulation - 1.5
The CR prefix is not needed on private variables and constants. The chicken merging ability could be a seperate scope.
Library requirements - 0
The spell uses unique support libraries instead of generally accepted standard libraries.
Code performance 6.5/8
Leaks - 3
Errors - 1.5
Using the unit custom value of the summons could conflict with other systems.
Efficiency - 2
IsCharAllowed could use StringHash and a hashtable lookup instead of a linear search. Linked lists are more efficient for periodic looping than unit groups.

Animation Quality: 3/5
Channeling Transition: 5/5

Reason for reduced score: The bouncing up and down is a nice effect, though it should have been faster and moved on more than one directional axis to simulate the person actually trying to nudge the cage.

Empirean - Call of the Damned

Result

Score

Concept

Code

Visuals

Poll-votes:	2/32
Judgement:	28.5/40
--------------	------
Final Score:	00/100

Concept:	9/10
Code:	14.5/20
Visuals:	5/10
----------	------
Score:	28.5/40

This spell reminded me of the final level in the undead RoC campaign. I like that there was a positioning requirement--it leads to some nice micro trying to get your acolytes into position to help the summon along.

Concept-wise, this spell was very clear and intuitive. I didn't have any difficulty learning how to use the spell, and there was a good amount of user interaction.

The only thing to note is that it could use some form of cast time indicator. For long casts such as this one, it would definitely be useful. How you would do it is up to you. Other than that, great job!

Score: 9/10

Code score: 14.5 points

Calibration 4.5/6
Description - 1
Setup instructions - 1
Calibration constants - 1.5
Some values, like the crow form ability id, are not calibrateable.
Calibration documentation - 1
Code usability 4.5/6
Instanceability - 2
Code documentation - 1
Encapsulation - 1.5
Th CD prefix on the variables is a bit too generic
Library requirements - 0
The spell does not use any libraries and has to do everything on its own.
Code performance 5.5/8
Leaks - 2.5
When deindexing an instance, the values of the last instance overwrite it, however they are also retained in their original index. Unless that index gets reused, the handles stored there will not get recycled.
Errors - 2
Efficiency - 1
Looping through all instances ever cast to find the currently active instances is not efficient. Looping through all the secondary instances to find the ones belonging to the current primary loop instance is even less efficient. You don't need a separate boolean to determine whether a rotation is clockwise, just use negative values for that. You could store the position of the summoning circle for each instance instead of getting it anew when updating each secondary instance. Using locations at all is less efficient than using coordinates.

Animation Quality: 3/5
Channeling Transition: 2/5

Reason for reduced score: A portal sits in the middle of the target area until a long, undeterminable summoning time has passed. There is no visual indicator showing how long the summoning will still take.

Flux - Aerial aid

Result

Score

Concept

Code

Visuals

Poll-votes:	5/32
Judgement:	35/40
--------------	------
Final Score:	00/100

Concept:	10/10
Code:	17/20
Visuals:	8/10
----------	------
Score:	35/40

Incredibly well-designed spell! The spell is clear and straightforward, but amazingly fun and interactive.

The spell indicators are fantastic, as are the phases of the spell. I love the concept of parachuters coming in, and it was implemented very professionally (I love that they are firing before they even land, lol).

Also, great touch allowing cliffs to be used as barriers against the spell. Those kinds of features often go unnoticed, but they make spells interactive on both sides--which I think is super important for any game.

Side note: I love when users include little mini-games in their demo maps. It just makes things funner for the reviewer. I don't grade on demo maps, but I just wanted to give you kudos for that!

Score: 10/10

Code score: 17 points

Calibration 5/6
Description - 1
Setup instructions - 1
Calibration constants - 2
Some values are not configurable like max height of bullet, max bonus.
Calibration documentation - 1
Code usability 5/6
Instanceability - 2
Code documentation - 1
Encapsulation - 2
Library requirements - 0
Inlining system code is not a good method of making requirements optional. Linked list and timer code could be delegated to an external library, as well as bullets.
Code performance 7/8
Leaks - 3
Errors - 2
Efficiency - 2
It would be enough to update gun targets on each shot instead of each iteration.

Animation Quality: 5/5
Channeling Transition: 3/5

Reason for reduced score: The channeling transition is bumpy as the plane doesn't appear for quite some time, giving me the impression that the spell wasn't working at first. If the plane was visible or some kind of visual indicator was immediately apparent upon casting, this score would be higher.

KILLCIDE - Ice Anomaly

Result

Score

Concept

Code

Visuals

Poll-votes:	7/32
Judgement:	35/40
--------------	------
Final Score:	00/100

Concept:	10/10
Code:	16/20
Visuals:	9/10
----------	------
Score:	35/40

A beautifully designed spell. This spell has quite a bit of complexity to it at first glance, but it actually plays out intuitively. The phases are clear and their is ample time to familiarize yourself with the summon--it only took me one spell cast to get a good feel for the spell.

The thing I love about this spell is the amount of interaction on both sides of the field. It is almost like a race to charge the orb vs. enemies attacking it. And as for the beam--the caster can strategically place it in big traffic whereas the enemy has to move out of it. Most spells neglect including any means of counter-play, which is pretty important in games in general.

All in all, this spell is fun, creative, and very memorable. Great job!

Score: 10/10

Code score: 16 points

Calibration 4/6
Description - 0
Setup instructions - 1
Calibration constants - 2
Calibration documentation - 1
Code usability 5.5/6
Instanceability - 2
Code documentation - 1
Encapsulation - 1.5
The IA prefix on the variables is a bit too generic
Library requirements - 1
The spell uses external libraries where appropriate.
Code performance 6.5/8
Leaks - 2.5
GetUnitsInRangeOfLocAll leaks a group handle reference.
Errors - 1.5
Units that get knocked back do not always match the units highlighted by the targetting cursor.
Efficiency - 2.5
In most phases, the orb doesn't really need a periodic update trigger, it could have used a timer and a death event trigger instead.

Animation Quality: 5/5
Channeling Transition: 4/5

Reason for reduced score: The introductory animation for the Ice Anomaly should have been faster. It felt like it was knocking back units in slow motion, which interrupted the experience.

Kyrbi0 - Mother's Love

Result

Score

Concept

Code

Visuals

Poll-votes:	1/32
Judgement:	15/40
--------------	------
Final Score:	00/100

Concept:	7/10
Code:	6/20
Visuals:	2/10
----------	------
Score:	15/40

First off, I'm glad you submitted, even if just for fun. Even though there were a lot of bugs, the spell's odd quirks made the demo map really interesting. I ended up getting an insane amount of golems because they were perpetually spawning off of each other. I know that wasn't intentional, but it was pretty hilarious.

I actually liked the idea a lot. It is the only pure passive, iirc, and it had a clear concept. The main critique is that the golems should be limited (I assume that was mostly just a bug), and considering the sheer number of golems, it would be really useful for the summons to passively assist/attack whatever the hero is attacking. It is tough to micromanage them all when they're being summoned and desummoned every second.

The spell may have been buggy/incomplete, but you should know that I had a lot of fun with it and it was certainly memorable!

Score: 7/10

Code score: 6 points

Calibration 0/6
Description - 0
Setup instructions - 0
Calibration constants - 0
Calibration documentation - 0
Code usability 3/6
Instanceability - 1
Code documentation - 0
Encapsulation - 1
Library requirements - 1
The spell,simple as it is, doesn't need any libraries.
Code performance 3/8
Leaks - 0
No effort was made to prevent leaks, some of them can be quite heavy.
Errors - 1
Telling frindly units to attack the hero and then immediately telling them to stop before the attack lands can still trigger the spell, generating the summons without the hero taking any damage.
Efficiency - 2
Using a generic attack event results in a lot of unneccessary trigger evaluations.

Animation Quality: 1/5
Channeling Transition: 1/5

Reason for reduced score: Definitely has no discernable animation nor channeling.

Loner-Magixxar - Stone Integrity

Result

Score

Concept

Code

Visuals

Poll-votes:	0/32
Judgement:	26/40
--------------	------
Final Score:	00/100

Concept:	10/10
Code:	11.5/20
Visuals:	4.5/10
----------	------
Score:	26/40

This spell was a cool passive + active combo. Definitely reminiscent of Earth, Wind, & Fire (one of my all-time favorite spells). However, your spell is cooler because of all the combinations you can make.

I really liked the interplay between HP, damage received, and the rocks. It literally felt like I was taking a chunk of my hero and putting it into a summon, rather than pooping the summon out of nowhere.

The spell was very easy to follow and the summons had their own cool bits of flavor. The merging is one of my favorite features, since it was the most interactive--you can quickly merge back to the core/to another summon towards the end of the summon's life to deny xp/save a unit.

I don't have anything to critique on the concept of this spell. Great job! It was fun!

Score: 10/10

Code score: 11.5 points

Calibration 2/6
Description - 0
Setup instructions - 0.5
No explicit instructions on how to set up the spell, some of it is covered by other parts of the documentation.
Calibration constants - 0.5
The spell has a calibration section but many of the settings require the editing of other triggers. Some aspects are not fully configurable, for example the scale of the core.
Calibration documentation - 1
Code usability 4/6
Instanceability - 2
Code documentation - 1
Encapsulation - 0
The SI prefix on the variables is a bit too generic, triggers have generic names without any prefixes.
Library requirements - 1
The spell does not use any libraries, but I can't really think of any that would help.
Code performance 5.5/8
Leaks - 3
Errors - 1.5
If a stone or golem gets removed without dying the caster looses life permanently. The stones really should use proper parabolic movement instead of a segmented linear approximation.
Efficiency - 1
Storing all data in hashtables is less efficient than using arrays, group loops are less efficient than array loops, locations are less efficient than coordinates, case selection is done through loops and if-then-else chains instead of direct array lookups.

Animation Quality: 2.5/5
Channeling Transition: 2/5

Reason for reduced score: The rocks appear randomly, and the effects are a thunderclap and a Charm. The transitions between the rocks coming to life and merging with the caster are not well-pronounced.

Meatmuffin - Demonic Ritual

Result

Score

Concept

Code

Visuals

Poll-votes:	1/32
Judgement:	33.5/40
--------------	------
Final Score:	00/100

Concept:	9/10
Code:	16/20
Visuals:	8.5/10
----------	------
Score:	33.5/40

Who doesn't love raining down flames at your enemy?

The interesting thing about the summons in this spell is that they auto-followed and auto-attacked. Since there could be potentially a LOT of them, I really liked this design choice--and it worked quite well!

The spell itself wasn't too interactive, but it was very intuitive and positioning the circle to hit units is a nice. One note: it was a bit difficult to differentiate the two types of spirits when there are enough them (even if they are going in opposite directions). But I guess that is more of a visual effects critique thing.

Overall, solid spell with an intuitive concept.

P.S. Nice choice for the summon model--the orc warlocks have one of the coolest cast animations, next to Archimonde of course.

Score: 9/10

Code score: 16 points

Calibration 4.5/6
Description - 1
Setup instructions - 1
Calibration constants - 1.5
The per-level calibration is limited to linear improvements.
Calibration documentation - 1
Code usability 4.5/6
Instanceability - 2
Code documentation - 1
Encapsulation - 1.5
The DR prefix on the functions is a bit too generic.
Library requirements - 0
The spell could delegate some of its work to outside libraries, such as projectile movement.
Code performance 7/8
Leaks - 2.5
In the DR_Loop function, the local unit u is not necessarily always set to null before the function terminates.
Errors - 2
Efficiency - 2.5
The minion attacks could have been normal unit attacks or spells instead of triggered missiles, since they don't do anything that would require them to be triggered.

Animation Quality: 5/5
Channeling Transition: 3.5/5

Reason for reduced score: The lack of a duration indicating how long the user must wait for the channeling time is a factor. The orb spins around the caster and seemingly-randomly turns into a Lava Spawn.

Rheiko - Hellfire Orb

Result

Score

Concept

Code

Visuals

Poll-votes:	3/32
Judgement:	28.5/40
--------------	------
Final Score:	00/100

Concept:	8/10
Code:	12/20
Visuals:	8.5/10
----------	------
Score:	28.5/40

This spell definitely has some great eye-candy. It is pretty fun to throw around and just watch the fire ele's plop out.

As for the critique, the ability itself is very succinct and has a really intuitive design. Great job--I had no issues understanding the spell/getting used to it. I think the only issue is that the summons themselves aren't too exciting--they don't feel like the focal point of the spell.

Still, the spell is rock solid in all other aspects, and the summons themselves can be interesting positioning-wise because of their passive immolation.

Score: 8/10

Code score: 12 points

Calibration 2.5/6
Description - 0
Setup instructions - 0
Calibration constants - 1.5
Some aspects of the spell are not configurable, such as the duration of the orb before it summons a minion.
Calibration documentation - 1
Code usability 4/6
Instanceability - 2
Code documentation - 1
Encapsulation - 1
The HO prefix on the functions is a bit too generic, some variables do not use the prefix.
Library requirements - 0
The spell could delegate some of its work to outside libraries, such as projectile movement.
Code performance 5.5/8
Leaks - 1.5
GetUnitsInRangeOfLocAll leaks a group handle reference, EnumDestructablesInCircleBJ leaks a rect handle reference. In phase 3, Point1 can get overwritten before it is removed.
Errors - 2
Efficiency - 2
Locations are not as efficient as coordinates.

Animation Quality: 3.5/5
Channeling Transition: 5/5

Reason for reduced score: The animation feels jittery at points, and the portal fracturing at the end looks like it was meant to be in 3-D but looks odd in 2-D.

Tank-Commander - Nano Plague

Result

Score

Concept

Code

Visuals

Poll-votes:	4/32
Judgement:	37/40
--------------	------
Final Score:	00/100

Concept:	10/10
Code:	18/20
Visuals:	9/10
----------	------
Score:	37/40

First off, the whole theme of the demo map definitely was befitting your name.

Really cool concept. Definitely one of the most unique ones. I had a lot of fun swarming demolishers with tons of nanobots.

I really like the mechanical interaction--it adds a nice little nichéness to the spell that really emphasizes that mech theme. The fact that they're stronger in numbers is a great design choice as well, and gives an incentive for keeping those little critters alive.

Being able to cast it while moving was a great addition as well. Considering how many moving parts (heheh) there are in this spell, I was surprised at how intuitive it was! Great job, I love it.

P.S. Great demo map!

Score: 10/10

Code score: 18 points

Calibration 5.5/6
Description - 1
Setup instructions - 1
Calibration constants - 2.5
Calibration documentation - 1
Code usability 5.5/6
Instanceability - 2
Code documentation - 1
Encapsulation - 1.5
The NP prefix on the functions is a bit too generic.
Library requirements - 1
While more work could be delegated to external libraries, the amount that is delegated is acceptable.
Code performance 7/8
Leaks - 3
Errors - 2
Efficiency - 2
Using loops to find an instance is less efficient than using a hashtable, using a generic attack event results in a lot of unneccessary trigger evaluations.

Animation Quality: 5/5
Channeling Transition: 4/5

Reason for reduced score: The firey effects don't seem to fit well to the theme of a mechanical plague. I felt like the fire should have spawned elemental minions. Either the summons or the effect could be tweaked by the user in a future spell, but the current score of these given visual effects is negatively affected.

xxdingo93xx - Void undertow

Result

Score

Concept

Code

Visuals

Poll-votes:	2/32
Judgement:	34/40
--------------	------
Final Score:	00/100

Concept:	9/10
Code:	16/20
Visuals:	9/10
----------	------
Score:	34/40

Awesome spell, from the concept down to the execution. The voidwalker on my back reminded me of Banjo-Kazooie, only much more warlocky.

I like the concept of draining to have your minion live longer. It adds a layer of interaction where you actually have to be conscious of your cast to get the most value out of it.

The minion is autonomous, but the fact that it is literally attached to you leads to some cool plays. You can use it to kite--just run through a pack of mobs and your void-bro will fire away.

Some subtle things that I liked:
- The orb accelerates. If I could out-run it, it would've been a pretty big design flaw (common pitfall), but the acceleration prevents that. Good job.
- This isn't really relevant to my concept review, but the timed-life indicator is awesome.
- The minion is non-invasive.

While it isn't too interactive on the minion's side, there are a lot of really cool selling points to this spell. You executed far better than I would've. Awesome work!

Score: 9/10

Code score: 16 points

Calibration 4/6
Description - 0
Setup instructions - 1
Calibration constants - 2
Calibration documentation - 1
Code usability 6/6
Instanceability - 2
Code documentation - 1
Encapsulation - 2
Library requirements - 1
Code performance 6/8
Leaks - 3
Errors - 1.5
The odds of spawning a drain orb are approximate and thus difficult to configure.
Efficiency - 1.5
The order in which code is written leads to some unnecessary trigger evaluations, using a timer per instance is less efficient than using one timer to run all instances, using a generic attack event results in a lot of unneccessary trigger evaluations.

Animation Quality: 4/5
Channeling Transition: 5/5

Reason for reduced score: The animation felt a bit too jittery. I felt like this would have been better with a smooth float to the caster.

Contest Thread | Poll

 

[IcemanBo]

Thanks everyone for so much participation (!) and sorry again for the results delay.
Also I want to thank the three judges who invested their time to review all submissions.

Have all a good day!

 

[Emm-A-]

wooow it is out! What a nice surpise

Congratulations to the winners - and the poll results even mattered!

I would like to thank the judges for these detailed judgements on all spells, it was very interesting to browse all entries again.

You mods could maybe mark the winners in the post more clearly like in other contests..

Have all a good day!

same to you!

 

[Empirean]

Hi, thank you so much the result is here. Congratulations to the winners.

 

[Loner-Magixxar]

Finally, it's out! Congrats to the winners. I just hope we haven't been waiting this long time for those 2 lines of judging for the visuals.

 

[Empirean]

Code performance 5.5/8
Leaks - 2.5
When deindexing an instance, the values of the last instance overwrite it, however they are also retained in their original index. Unless that index gets reused, the handles stored there will not get recycled.
Errors - 2
Efficiency - 1
Looping through all instances ever cast to find the currently active instances is not efficient. Looping through all the secondary instances to find the ones belonging to the current primary loop instance is even less efficient. You don't need a separate boolean to determine whether a rotation is clockwise, just use negative values for that. You could store the position of the summoning circle for each instance instead of getting it anew when updating each secondary instance. Using locations at all is less efficient than using coordinates.

hi, im sorry but i dont quite get it when you said there was a leak in the deindex as this is usually how i deindex on my other submissions. Also can you suggest of any other way to work with this other than loops cause i got nothing? I dont mean to be rude and all i just wanna improve my code since i plan to upload it in the spells section thanks.

 

[Loner-Magixxar]

hi, im sorry but i dont quite get it when you said there was a leak in the deindex as this is usually how i deindex on my other submissions. Also can you suggest of any other way to work with this other than loops cause i got nothing? I dont mean to be rude and all i just wanna improve my code since i plan to upload it in the spells section thanks.

I agree on this matter. I think the judge has done a very very lazy job (considering the amount of time he had) and assumed that everyone is a coding expert here, unlike the previous judge who pointed every mistake and offered a solution for them (I mean Bannar). Though I know how Anitarf is popular around here, still my suggestion is to leave him out of next Zephyrs. No offense!

 

[IcemanBo]

You mods could maybe mark the winners in the post more clearly like in other contests..

Yes, first places could be highlighted in the statistics. Will change it for next time. Thanks.

I dont mean to be rude and all i just wanna improve my code since i plan to upload it in the spells section thanks.

It's not rude at all. If you have questions you of course can ask the respective judge for clarification.

Edit:

Uploaded table with colors.

 

[xxdingo93xx]

Finally
Congratz to every1.

 

[Meatmuffin]

Thanks for the high rating, there were a lot of fantastic contenders, was happy to be among you all!

 

[Kyrbi0]

Great to see the results for this Contest! Thanks to the Judges & the Host for writing all that up. I knew I just threw 'whatever' into this, so my score is unsurprising and doesn't bug me in the least. : )

Coupla quick questions:

1) So who were all the Judges & what did they Judge (separately or together)? Anitarf did Coding, aaaaand... I ask in part because there's "Code", "Concept" and "Visuals", and the last two don't sound like they're written by Anitarf.

2) @IcemanBo , I believe Emm-A- was talkin more about the big "Contest Winners" bit (ala the bottom of this post). Or even just some writing.
The colored table is a good first step, though, thanks.

3)

No effort was made to prevent leaks, some of them can be quite heavy.
Errors - 1
Telling frindly units to attack the hero and then immediately telling them to stop before the attack lands can still trigger the spell, generating the summons without the hero taking any damage.
Efficiency - 2
Using a generic attack event results in a lot of unneccessary trigger evaluations.

- Yeah, leaks. I just didn't care/ran out of time.
- Yeaaaaaah... That's a pretty game-breaking bug I failed to think about, lol. Will have to put a "matching: not allied" clause in there. Thanks.
- What would be the alternative to the generic attack event (i.e. "Unit is Attacked")? Even in (v)Jass wouldn't you have to wait & catch an attack of some kind?

4)

Animation Quality: 1/5
Channeling Transition: 1/5

Reason for reduced score: Definitely has no discernable animation nor channeling.

- Yeah I was frustrated that the animations/SFX I tried to make work, didn't. No big deal.
- "Channeling Transition"?? And what's this about animation during Channeling?? I don't know what that means & I didn't see anything about that in the Contest Rules...

5)

First off, I'm glad you submitted, even if just for fun. Even though there were a lot of bugs, the spell's odd quirks made the demo map really interesting. I ended up getting an insane amount of golems because they were perpetually spawning off of each other. I know that wasn't intentional, but it was pretty hilarious.

I actually liked the idea a lot. It is the only pure passive, iirc, and it had a clear concept. The main critique is that the golems should be limited (I assume that was mostly just a bug), and considering the sheer number of golems, it would be really useful for the summons to passively assist/attack whatever the hero is attacking. It is tough to micromanage them all when they're being summoned and desummoned every second.

The spell may have been buggy/incomplete, but you should know that I had a lot of fun with it and it was certainly memorable!

Score: 7/10

- Lol, glad you had fun. : )
- Yeaaaah... IRL I'm pretty sure that that is waaaay too much spawning. If I was making this for the real game (which I plan on doing), I fear the balancing would be too hard; too many 'levers' to jiggle.
- Actually, that is definitely a bug, and a worrying one; I basically just used the hidden "Factory" ability to passively spawn the secondary golems. And somehow, it appears that even when the primary (Factory) golem dies, the passive Factory ability somehow works beyond the grave, continually spawning secondary Golems for some time. That's really bad for my future usage of that trick. :<
- Passive assistance/attacking? Hm, not a bad idea. I bet I could get it working by simply ordering the golem to Right-Click the attacked hero, following her around (I found Follow lets Priests still cast Heal & warriors to Attack). Perhaps throw a modded Tornado Wander on them so they follow more closely (& wander around aimlessly for kicks ;P)
Thanks!

 

[Anitarf]

I was the last judge to submit my reviews, so most of the delay was entirely my fault. For that I apologise. I thought I could do the judging if it was just code but I overestimated the amount of free time I'd have.

I'm also sorry if my comments were not sufficiently detailed, I tried to keep them short to make them easier to read. If any questions remain, I am of course available to clarify, either in this thread or via private messages.

hi, im sorry but i dont quite get it when you said there was a leak in the deindex as this is usually how i deindex on my other submissions. Also can you suggest of any other way to work with this other than loops cause i got nothing? I dont mean to be rude and all i just wanna improve my code since i plan to upload it in the spells section thanks.

what I mean is, when you remove an instance at index X, you take the data stored at the highest index and move it to index X, thus replacing the removed instance. However, you don't just move the data, you copy it. The data still remains stored under the highest index, even if it is no longer used. If that index gets reused later, then that data will get overwritten at that point, but if not then that data will remain stored there and any handle addresses referenced by those variables will not get recycled. It is a very small leak (not a full handle leak, just their addresses, and it does not increase over time), so I only subtracted half a point for it, if there were other leaks I wouldn't even count this one, so you don't really have to fix it. If you want to, then to fix it you would have to set all variables of handle types (units, groups, locations...) to null after you are done using them, so when you take a unit stored at the highest index and store it to a lower index belonging to a previously deindexed instance, you could set the highest index to "no unit" afterwards.

When you do a search using a loop, you are usually looking for an instance that matches to a specific unit. There are ways to associate instances to units directly, so that when you have a unit, you don't have to look through all instances to find the one that is pointing to that unit, but instead your unit is already pointing to its instance. In our case, each instance represented by a unique array index. It is also possible to represent each unit with a unique index. One option is to use a unit indexing system, in which case we can simply store the instance index into an integer array, using the unit's index as an array index for that array. Another way to get a unique id for each unit is the GetHandleId function, however these ids are too large to be used as array indexes, so we need to use a hashtable instead. The principle remains the same, though, once you get your unit you use its unique id as a hashtable index to read the instance index stored in the hashtable. Keep in mind that the way you do your instance deindexing, the index of the last instance will change when you remove another instance from the list, so you need to make sure to update it in the hashtable whenever that happens.

What would be the alternative to the generic attack event (i.e. "Unit is Attacked")? Even in (v)Jass wouldn't you have to wait & catch an attack of some kind?

There is no simple solution. One possible approach is to rethink the design - simply not make the spell depend on such a CPU demanding event in the first place. The other option is to use some sort of system that can consolidate your events. If each of your spells uses trigger with a frequent event, that is less efficient than if you only have one system that uses that event and the system then runs additional code for individual spells only if the specific unit involved in the event has that code attached to it.

A good example of this are the various spell event libraries. For example, if you have a map with 25 heroes, each of whom has 4 different spells, then if you code those spells normally you'll have 100 triggers running whenever any hero casts any spell. With a spell event library, though, only 1 trigger runs, which then checks the spell id of the spell being cast and runs only the trigger registered to that spell id, so you end up with two trigger evaluations (and a hashtable lookup) instead of a hundred.

An attack event library would be slightly more complicated, since a unit might have multiple codes attached (in the spell event example, each spell id only maps to one trigger) and they would likely get attached and removed dynamically, but the principle remains the same - reduce trigger evaluations by making sure your code only runs when the correct unit is attacked, rather than when any unit is attacked.

 

[Kyrbi0]

I was the last judge to submit my reviews, so most of the delay was entirely my fault. For that I apologise. I thought I could do the judging if it was just code but I overestimated the amount of free time I'd have.

I'm also sorry if my comments were not sufficiently detailed, I tried to keep them short to make them easier to read. If any questions remain, I am of course available to clarify, either in this thread or via private messages.

Hey, it happens.

There is no simple solution. One possible approach is to rethink the design - simply not make the spell depend on such a CPU demanding event in the first place. The other option is to use some sort of system that can consolidate your events. If each of your spells uses trigger with a frequent event, that is less efficient than if you only have one system that uses that event and the system then runs additional code for individual spells only if the specific unit involved in the event has that code attached to it.

A good example of this are the various spell event libraries. For example, if you have a map with 25 heroes, each of whom has 4 different spells, then if you code those spells normally you'll have 100 triggers running whenever any hero casts any spell. With a spell event library, though, only 1 trigger runs, which then checks the spell id of the spell being cast and runs only the trigger registered to that spell id, so you end up with two trigger evaluations (and a hashtable lookup) instead of a hundred.

An attack event library would be slightly more complicated, since a unit might have multiple codes attached (in the spell event example, each spell id only maps to one trigger) and they would likely get attached and removed dynamically, but the principle remains the same - reduce trigger evaluations by making sure your code only runs when the correct unit is attacked, rather than when any unit is attacked.

Hm. So some-thing, some line of code is still catching an event firing off (i.e. an attack) & using conditionals of some kind to determine stuff about it & whether or not to run the trigger... But using the native game functions to do that is costly in some way, while using this "event library" concept is... less so?

Hm. That is important since I plan on having a lot of "Unit is Attacked" and "Unit Starts Effect of an Ability" triggers in my works... I wonder, is it any better (faster/more robust/etc) if you concatenate all of the various triggers of that kind into one physical trigger (i.e. instead of a dozen "A Unit is Attacked" triggers, have one "Unit is Attacked" trigger with a dozen IF/THEN statements)?

 

[Empirean]

@Anitarf thanks so much for the response. I like the idea of a unit indexer i just dont know how to use it. Maybe on the next contests ill use one.

@icemanbro thanks for moderating

 

[DD_legionTN]

First of all, congratulates to all winners and also all of the participants to make this contest wonderful . And also thanks to judges for taking their free time for judging this contest.

My question toward the judges judgement :

The main issue I had with the spell was the complexity in level scaling and the spell's phases. When every aspect of the spell changes as you level it up, the spell becomes less intuitive--and you have to relearn how the spell works for every level. I would've kept some things static between the levels, e.g. the number of missiles, the elemental life time, etc.

I made the spell to be as dynamic as possible as some user might want to have control over all of the spells, possible every aspect of it. I don't know if it is "over dynamic", hopefully you could clarify me about, how should the spell configuration be "exactly dynamic"

Calibration constants should use seconds instead of timer timeouts as a unit of time.

I personally don't matter toward the constants's unit as long as user is told about what unit the constants are using, probably because seconds is the standard of time, I will avoid it next time and using standardized units.

If the code used a timer in addition to the timed life, it could avoid having to store whether a unit is absorbable and the public method for setting it.

I'm not really sure what you meant. Timed life is used as to display the current life time of the unstable elemental. How timer+time life could be related toward "avoid having to store whether a unit is absorbable"?

Linked list and timer code could be delegated to an external library.

You're right toward this. But because I personally never used linked list/timer libraries, so that the reason I'm not including it in optional list. Will do it next time.

In sphereMissile-onPeriodic, the local variable u is not set to null which can leak a handle id when spawning the first summoned unit. In onCast of EnergyExplosion, the local variable u is not set to null which leaks a handle id if DummyRecycler is not present.

As the spell developing, I realized I start to forget that I need to null local variables (Happened recently for me). Not sure why is that happening, probably I'm too focus on spell aspect, thanks for pointing them out!

There is a potential, although unlikely, error with the linked list implementation because nodes only get recycled once there are no active instances, so if the spell gets cast consecutively so that there are always some instances remaining the code will run out of array index space.

I did notice this, but I retain it. As it is "impossible" to go beyond the array index unless user abused it. Though i can't deny it is a possible flaw. Since you pointed it out as an possible error, gotta fix it too.

Animation Quality: 5/5
Channeling Transition: 4.5/5

Nearly-perfect score: A very close second with the visual winner, for its own reasons.

Never expect I would obtain such high scores . Anywhere, what does "for its own reasons" mean?




Overall, I'm really glad that the contest turns out well at the final moment.

personal expression

I've got my first real code review!!! yaaaa

 

[Anitarf]

Hm. So some-thing, some line of code is still catching an event firing off (i.e. an attack) & using conditionals of some kind to determine stuff about it & whether or not to run the trigger... But using the native game functions to do that is costly in some way, while using this "event library" concept is... less so?

The goal is to avoid those checks entirely. An if statement by itself is not particularly costly, but if you want to have a general solution then any custom check needs to be run through trigger evaluate, which is about as slow as having separate triggers with the same event was in the first place.

Usually, those checks look for specific unit types, or units with specific abilities or buffs. If you maintain a list of callbacks for each specific unit, then you can just update this list whenever a unit gets/looses a buff, and then you no longer need to check for that buff every time your event occurs - if a code needs to run for a unit on your event, then that code will be on the list.

Hm. That is important since I plan on having a lot of "Unit is Attacked" and "Unit Starts Effect of an Ability" triggers in my works... I wonder, is it any better (faster/more robust/etc) if you concatenate all of the various triggers of that kind into one physical trigger (i.e. instead of a dozen "A Unit is Attacked" triggers, have one "Unit is Attacked" trigger with a dozen IF/THEN statements)?

Yes, such a solution would run faster. You'd still be doing checks for each type of code that uses this event, but those checks would not need a trigger evaluate each. The downside of such a solution is that it's less modular and thus limits the possibilities of code reuse.

I personally don't matter toward the constants's unit as long as user is told about what unit the constants are using, probably because seconds is the standard of time, I will avoid it next time and using standardized units.

The main advantage of seconds is that they always stay the same. If you make all stats second-based, then users can easily modify the spell update period (to make the spell either run more smoothly or make it less CPU intensive) without it changing how the spell works.

I'm not really sure what you meant. Timed life is used as to display the current life time of the unstable elemental. How timer+time life could be related toward "avoid having to store whether a unit is absorbable"?

I'm not sure anymore either, let me look at the code again... Ah, I see. If I understand correctly, you detect if a summoned unit has expired by using a death event and checking if the killing unit is null. The assumption here is that if the unit dies prematurely, it will have been killed by another unit, in which case killing unit would not be null, so if it is null then that means the dying unit wasn't killed but instead its timer expired. However, there is one more way for killing unit to be null, and that is if the dying unit was killed by triggers, so you had to add a public method which allows such triggers to mark a unit to no longer be absorbable before killing it.

You could instead use a timer to detect when a summoned unit's timer expires. Just start a timer when you create the summoned unit with the same duration as the summoned unit, then stop the timer if the unit dies. If the timer finishes without being stopped, then the unit lived out its time to the end. This allows you to also detect when the unit is killed by triggers, so a public method would no longer be necessary.

As the spell developing, I realized I start to forget that I need to null local variables (Happened recently for me). Not sure why is that happening, probably I'm too focus on spell aspect, thanks for pointing them out!

It happens. Sometimes you think you're being clever when you notice that the variable gets reused later and you think you don't need to null it before that, you just need to null it afterwards, but you miss the fact that it gets reused inside an if statement and so if that statement isn't true, then the variable doesn't get reused and nulled. Another example would be that you use a FirstOfGroup loop and the only way for it to end is for the unit variable to become null, so you don't null it again afterwards, but then you add another conditional way for the loop to terminate before the variable becomes null and forget that you now have to null it yourself after the loop. So sometimes I just null stuff automatically, without checking if I really have to, to avoid such errors.

 

[Kyrbi0]

Yes, such a solution would run faster. You'd still be doing checks for each type of code that uses this event, but those checks would not need a trigger evaluate each. The downside of such a solution is that it's less modular and thus limits the possibilities of code reuse.

Ah, well that's no issue for what I have in mind. Awexome.

~~~

So Anitarf, did you write the rest of the Judging/reviews? Specifically the visuals/concept parts?

 

[Anitarf]

So Anitarf, did you write the rest of the Judging/reviews? Specifically the visuals/concept parts?

• Anitarf (code)
• Bribe (visuals)
• PurgeandFire (concept)

 

[Kyrbi0]

Thanks (duh, shoulda checked).

4)

Animation Quality: 1/5
Channeling Transition: 1/5

Reason for reduced score: Definitely has no discernable animation nor channeling.

- Yeah I was frustrated that the animations/SFX I tried to make work, didn't. No big deal.
- "Channeling Transition"?? And what's this about animation during Channeling?? I don't know what that means & I didn't see anything about that in the Contest Rules...

@Bribe

 

[Bribe]

Animation FX

How else should a channeling spell be judged visually? There were zero effects and there was no clear moment of "this golem came from somewhere" - the things just appeared. If the golems would at least have had a quick animation, for example their "birth" animation or even something silly like falling from a sky with "Animation - Set height of unit" that would have been merit for a higher score.

I woukd find it intuitive that in every single case of a Blizzard channeling spell they have a clear and fluid visual means of getting the summon on the board. With a PASSIVE there isn't a way of animating the summoner like one does in an active summon scenario, so in your case you owuld've needed to get creative, and I would have judged yours differently had it worked. But it didn't work, there were just a bunch of randomly-spawning golems and it would not have been fair to give that higher marks just based on it being a passive summon.

 

[Kyrbi0]

How else should a channeling spell be judged visually? There were zero effects and there was no clear moment of "this golem came from somewhere" - the things just appeared. If the golems would at least have had a quick animation, for example their "birth" animation or even something silly like falling from a sky with "Animation - Set height of unit" that would have been merit for a higher score.

I woukd find it intuitive that in every single case of a Blizzard channeling spell they have a clear and fluid visual means of getting the summon on the board. With a PASSIVE there isn't a way of animating the summoner like one does in an active summon scenario, so in your case you owuld've needed to get creative, and I would have judged yours differently had it worked. But it didn't work, there were just a bunch of randomly-spawning golems and it would not have been fair to give that higher marks just based on it being a passive summon.

Oh no no, I fear you misunderstand.

I am/was not debating the score you gave me whatsoever. That's what the first bullet of my reply meant ("yeah, SFX & animations didn't work out..."). I submitted a garbage spell (& at least aesthetically & functionally) & I knew it. : )

No, what I'm talking about is the second bullet point (hence all the question marks). You have (in your Judging and then bolded twice in your reply above) used the word "Channeling", seemingly interchangeably, with "Summoning". They are two entirely different things* & the former ("Channeling") doesn't appear anywhere in the Contest thread, Rules or Guidelines. Hence my confusion as to why that seemed to be, somehow, an expectation of your Judging.

*

As I understand it, Channeling spells exist, such as Starfall, Blizzard, Tranquility, etc. Each of these feature, generally, some kind of caster animation (often just 'Spell', looped, but sometimes a separate 'Stand Channel' or 'Spell Channel').

Summoning spells exist, such as Summon Water Elemental, Feral Spirit, Force of Nature, etc. Each of these tend to feature, in some small way, 'entrance' animations (usually just scaling up from nothing w/ SFX) for the summoned creature (& generic 'Spell' caster animations as well, being active-cast spells).

There is even a Channeling Summon spell; Tornado. It has both of those things (looped 'Spell' anims on caster; simple 'Birth' animation entrance by the Tornado).

~

So the contention is that I could've at least had the latter ('entrance' animation) for the Golem(s). Fair enough, though on that note I'm curious; as I'm sure you noticed when you checked, I did have "Play (last created unit) Birth animation" in there, and it just didn't work. Thoughts?

Secondarily, despite it being a passive spell (no cast = no animations), it's feasible I could've played some kind of caster animation on successful trigger-firing (e.g. 'Stand Hit' or something), since that part was triggered. At the very least some kind of caster SFX... Which again, if you'll notice, were there but ineffectual. Thoughts?

Really, it's a question of "what were the Criteria", and while I recognize a Judge's right to interpret things to a point, it's vital that each Judge consistently follow at least a modicum of the proposed & agreed-upon Criteria. Speaking of which:

How does the whole spell procedure look? Is it overloaded with special effects? How explanatory is the tooltip/description of its functionality?

Three things:
- "how does the spell [procedure??] look?"
- "too many SFX?"
- "good tooltip?"
Now I'll be the first to admit that "this needs work". It doesn't really cover all the bases, like "too few SFX" (*cough*), doesn't explain what "procedure" means (kinda weird in that setting), etc.

But you graded us on "Animation Quality" & "Channeling Transition"... What? No mention of my tooltip being good/bad (IIRC that's the one thing I did right ;D), no talk of SFX (folding it into "animation quality" or "channeling transition" somehow?)...

I didn't make that post, nor this one, with the intention to pull you down, or lambaste your no-doubt tedious & difficult & appreciated work as Judge; however it kinda turned into that when I really began to compare what you did with what the Contest 'said' you would do.

I would like to reiterate again, I do not seek an adjustment of my score in the slightest. 'Garbage in, garbage out' as they say ;P. But can you clear up this discrepancy?

 

[Bribe]

I do apologize the rules were not an exact match. It was my first time judging a Zephyr contest and I honestly wasn't even looking at tooltips. To be honest I often forget they exist as well. This was something that I was simply unaware of, and for that I am sorry. I clearly did not do as well as I should have with the judging process that I've overlooked something which was actually spelled out in the contest thread itself.

As for the criteria, there does need to be a pre-determined, objective structure to follow for judging visual effects. I believe the spell makers - most of the time - follow and meet that criteria without it needing to be demonstrated clearly. But in the future, we as the judges should agree on the specific criteria before starting the contest.

 

[Kyrbi0]

I do apologize the rules were not an exact match. It was my first time judging a Zephyr contest and I honestly wasn't even looking at tooltips. To be honest I often forget they exist as well. This was something that I was simply unaware of, and for that I am sorry. I clearly did not do as well as I should have with the judging process that I've overlooked something which was actually spelled out in the contest thread itself.

As for the criteria, there does need to be a pre-determined, objective structure to follow for judging visual effects. I believe the spell makers - most of the time - follow and meet that criteria without it needing to be demonstrated clearly. But in the future, we as the judges should agree on the specific criteria before starting the contest.

Hey, it happens. I appreciate your concession.

I think that while it might seem silly, explicitly spelling things out (for everyone, really; users, mods; hosts, contestants, judges) really saves everyone a lot of time & drama. Having Rules we can quote & point to just make things a lot clearer, resolving loopholes before they are exploited.

 

[IcemanBo]

Visuals is pretty much it:

• Does the spell process fit the theme and concept
• Are effects nicely placed, and not too overloaded for example?
• Quality of tooltip.

And that's pretty much what's stated in contest.
Details like if there is a buff for example, that it also needs a good tooltip is common sense. Also that the icon should fit the theme.

"too few SFX" (*cough*)

That is obvious and clearly common sense. If you are serious I don't even know what to say.

doesn't explain what "procedure"

The procedure depends on your submission. If you make a channel spell for example, it should have channeling effect/animations, e.g. We can not rule out each minor detail just that people don't have to use their brain anymore. And that would not work out well, too.

Bribe, that you "did not look on tooltips, forgot often that they exist" is clearly your fault.
Look at contest description and our private Conversation, I don't wanna go in details now.
But, what would you suggest to change exactly? Could you phrase something new? Maybe it can be helpful for next time.

 

[Kyrbi0]

That is obvious and clearly common sense. If you are serious I don't even know what to say.

I was talking about myself. It was just a little self-referential joke.

...
But, what would you suggest to change exactly? Could you phrase something new? Maybe it can be helpful for next time.

If you are talking to me still, I would indeed re-phrase it; perhaps something like this:

Aesthetics

How well the chosen visuals & presentation complement the created spell. Informative, standardized tooltips & buffs, appropriate special effects, appropriate animations; mastery of these will result in a good score. Poorly-written/non-existent tooltips & buffs, special effects & animations that are either too plentiful, too lacking, un-fitting or buggy; these will result in a poor score.

Covers everything, explicitly defining the bounds by which a good & bad "visual" may be considered, in a manner which is both clear & yet vague enough to not 'box anyone in'. Could be yet improved by making a little 'sub-list' inside for organization purposes, I suppose.

 

[IcemanBo]

How well the chosen visuals & presentation complement the created spell.

"Visuals" can't be explained with using "visuals".

Informative, standardized tooltips & buffs

That "buffs" also should have descriptive tooltips is common sense. (but would not be harmful to note it, okay)

appropriate special effects, appropriate animations;

Already coverered, just other words.

mastery of these will result in a good score. Poorly-written/non-existent tooltips & buffs, special effects & animations that are either too plentiful, too lacking, un-fitting or buggy; these will result in a poor score.

Totaly common sense that "good -> higher score" and "bad -> lower score".

 

[Deleted member 219079]

I think this is relevant now; roughly 2 months ago I designed my own review template. To fight irrationality, I included a lot of statements in the template which the submission must fulfill. This leaves less room for far-fetched conclusions.

For reference, here's the template:

CODING
Evaluated code will include all of the code written solely for the entry. Dependencies will therefore be excluded. Act of including a resource that is not publicly approved or is namely excluded in the rules will be considered as a loss of points. This said, code can be spread into multiple triggers/files, but must clearly be separated from dependencies.
Conventions and standards, spell submission rules and rules specific to the contest must be fulfilled. Namely writing conventions include JPAG. Note that spell submission rules require MUI and leak-free code.
In order to classify as a spell, execution of code must start from an event listener provoked by in-game ability object event. Separate initialization may be included as offered by JassHelper/Map initialization event, but can not extend into game-time.
It must be clear how the spell proceeds. In order to achieve this, variables and functions must be named sensibly, and potentially confusing part of code must be commented.
Further investigation of the code will be greatly submission-specific.

CONCEPT
The in-game effects of code must fulfill the description included in the rules of the contest. Unclear relation will result in loss of points. Values must be present in the premise of the spell, premise being the in-game description of the spell. Ideal length for the description is the average Warcraft III length for abilities. Extended description may be included in the post that includes the final submission.
Unclear connection between the description and actual in-game effects results in loss of points.

VISUALS
Visuals include the in-game investigation on the visuals of the ability object itself.
Visuals include the evaluation of the objects used for the submission. Only one ability object must be used, as the rules clearly state that only one spell is to be submitted.
Visuals include the evaluation of the outlook of the effects used. Visuals must be used appropriately in quantity in order to classify as an equivalent of a standard spell for Warcraft III. Visuals must be clearly related to the premise. Not using the publicly acclaimed dummy object where it could've been used results in loss of points.

The current template (coding 20pt + concept 10pt + visuals 10pt, judges arrive at scores with their own methods) demands less from the host and adds to the excitement aspect I guess, as entrants can't start reasoning out their score with "does it fulfill this statement?", but in the other hand publicly seen review template could result in higher quality submissions as the entrants fulfill the statements to the best of their skills before final submission. Now if the quality would increase, we could shift coding by -10pt and double concept's scale, because concept is the one with creativity as a factor, and that should be the one which is being judged: an idea.

 

[Loner-Magixxar]

I think this is relevant now; roughly 2 months ago I designed my own review template. To fight irrationality, I included a lot of statements in the template which the submission must fulfill. This leaves less room for far-fetched conclusions.

For reference, here's the template:


The current template (coding 20pt + concept 10pt + visuals 10pt, judges arrive at scores with their own methods) demands less from the host and adds to the excitement aspect I guess, as entrants can't start reasoning out their score with "does it fulfill this statement?", but in the other hand publicly seen review template could result in higher quality submissions as the entrants fulfill the statements to the best of their skills before final submission. Now if the quality would increase, we could shift coding by -10pt and double concept's scale, because concept is the one with creativity as a factor, and that should be the one which is being judged: an idea.

As far as I witnessed, and talked against it as well, the motto of the Zephyr contests is to leave the other contestants in the dark and it is considered a strategy, which almost all of the entrants are in favour of. Of course, if I knew what would be evaluated in the coding section, I would try to do it. e.g. the leaking part, which I didn't know anything about it until the previous Zephyr and I learned it through the results, but being aware of it, I got a perfect score on that criterion in this Zephyr.

Obviously, the enterants who have a complete understanding of the codes would get almost a perfect score, but people like me who are beginning to code, would have no chance! Hell, when I pointed two flaws in other entrant's works, I got scolded that I shouldn't have done that. So we return to square one, which is: Don't inform the entrants as much as possible, so that they could lose points.

I myself thought that if I don't get a high score it would be probably due to visuals and maybe concept, but I've got burned in the coding section over things that I'm only beginning to get a partial grasp on and mostly unaware of and I still try to figure out what they mean.

Edit:
As an example for what I wrote here, consider this:

About the description criterion. I totally forgot to include an overall description of the spell, and it is mostly because there is no reference board or a checklist of some sort to return to. It is quite unfair that I lost a whole point because I forgot to include something that was a criterion of the coding section.

And this whole thing returns to the moderation part and lack of proper communication between judges and the host and of course the entrants, if and only if, the motto of leaving in the dark is not the core component of the contest in the first place!

Stream the lava of hate at me all you want, but to make an omelet, you have to break some eggs, which in this case I am the eggs!

 

[Kyrbi0]

"Visuals" can't be explained with using "visuals".

Sure, but "Aesthetics" can; I took the liberty of changing the name of the section because really, it's not just visuals; it's the whole aesthetic package of visuals, presentation, etc. You did read that, right?

Already coverered, just other words.

Um, yeah. I mean I wasn't trying to say that the original had nothing; it obviously had important stuff to incorporate.

Totaly common sense that "good -> higher score" and "bad -> lower score".

I find that 'common sense' isn't all that common. But the phrasing was simply there to express the important stuff; perhaps a list would do better.

I think this is relevant now; roughly 2 months ago I designed my own review template. To fight irrationality, I included a lot of statements in the template which the submission must fulfill. This leaves less room for far-fetched conclusions.

For reference, here's the template:


The current template (coding 20pt + concept 10pt + visuals 10pt, judges arrive at scores with their own methods) demands less from the host and adds to the excitement aspect I guess, as entrants can't start reasoning out their score with "does it fulfill this statement?", but in the other hand publicly seen review template could result in higher quality submissions as the entrants fulfill the statements to the best of their skills before final submission. Now if the quality would increase, we could shift coding by -10pt and double concept's scale, because concept is the one with creativity as a factor, and that should be the one which is being judged: an idea.

I might argue that yours is a little too long, but then again when you subscribe to the @Softmints school of thought (where the idea is to get all the silly/dumb/common sense stuff out of the way explicitly so that "entries are graded on what's really important), that's what you get.

As far as I witnessed, and talked against it as well, the motto of the Zephyr contests is to leave the other contestants in the dark and it is considered a strategy, which almost all of the entrants are in favour of. Of course, if I knew what would be evaluated in the coding section, I would try to do it. e.g. the leaking part, which I didn't know anything about it until the previous Zephyr and I learned it through the results, but being aware of it, I got a perfect score on that criterion in this Zephyr.

Obviously, the enterants who have a complete understanding of the codes would get almost a perfect score, but people like me who are beginning to code, would have no chance! Hell, when I pointed two flaws in other entrant's works, I got scolded that I shouldn't have done that. So we return to square one, which is: Don't inform the entrants as much as possible, so that they could lose points.

I myself thought that if I don't get a high score it would be probably due to visuals and maybe concept, but I've got burned in the coding section over things that I'm only beginning to get a partial grasp on and mostly unaware of and I still try to figure out what they mean.

Edit:
As an example for what I wrote here, consider this:

About the description criterion. I totally forgot to include an overall description of the spell, and it is mostly because there is no reference board or a checklist of some sort to return to. It is quite unfair that I lost a whole point because I forgot to include something that was a criterion of the coding section.

And this whole thing returns to the moderation part and lack of proper communication between judges and the host and of course the entrants, if and only if, the motto of leaving in the dark is not the core component of the contest in the first place!

Stream the lava of hate at me all you want, but to make an omelet, you have to break some eggs, which in this case I am the eggs!

This is an interesting point, and one of the strongest points in favor of what Jondrean & Softmints espouse. Personally, I wouldn't want someone to go through that in a Contest.

I have to admit, though, I'm surprised you didn't know about fixing leaks & stuff like that. That's, like, one of the first things a coder learns to deal with. It's all over the resource section, the past Contest's Criteria, the many Coding tutorials...

 

[Loner-Magixxar]

And by the way, there was some other thing I noticed:

Calibration constants - 0.5
The spell has a calibration section but many of the settings require the editing of other triggers. Some aspects are not fully configurable, for example the scale of the core.

OK, I get the lack of configurable for scaling the hero, but there is some issue with this category.

Those parts of the code that you said need to be configured are not an integral part of the code (the code is complete with almost all of the variables being configurable). If you look carefully, If the user of the spell wants to add a new type of unit that has synergy with the other unit types, all the entries have to go through the same process I provided in my spell. The irony is, I got penalized by 2.5 points (!) for including a simple way and enough documentation for the user to do such a thing and add any new units he wants and set the combination of said units with other ones. This feature is a bonus and my only advantage point against other entries in the coding section, which you considered as flawed. Again if I knew there wasn't any category of bonus features of the spell, I wouldn't go through the hassle of adjusting my spell to the user's needs and get burned in the coding section by 2.5 points!!!

Edit:

I have to admit, though, I'm surprised you didn't know about fixing leaks & stuff like that. That's, like, one of the first things a coder learns to deal with. It's all over the resource section, the past Contest's Criteria, the many Coding tutorials...

I'm not a coder, I'm a designer; but when it comes to working alone and without help and being have to deal with buggy interface of WC3, and only beginning to learn C# which doesn't have to deal with leaks, so it's expected, is it not?

By the way, I'm learning to code by myself and by online books and without participating in any training courses, mostly because coding is a means to an end for me not a goal, something to breathe life into my ideas and something that with it I can understand the barriers for expressing the ideas better. If I feel overwhelmed by the coding task, I am openly accepting any programmer who can do that for me. I joined these contests to test my skills (however inferior) on a fair ground, not getting trampled by the importance or the fame of other contestants; because I thought it is a spell making contest not a coding contest, which nevertheless favors skilled coders anyway.

I get the efficiency of the codes matter, but surely not this much, because there are so many other categories as well such as the mechanisms of the spell, its looks, its understandability, its fun qualities, its creativity, its originality, and etc. These are all parts of the spell making contest, but unfortunately they are all hugely overshadowed by only one of the aspects of making a spell (coding). And I find it hard to realize the reason behind it!

 

[Kyrbi0]

I'm not a coder, I'm a designer; but when it comes to working alone and without help and being have to deal with buggy interface of WC3, and only beginning to learn C# which doesn't have to deal with leaks, so it's expected, is it not?

Hey, same here; I essentially code little if at all. And like I said, I agreed with your point in general; just expressing some 'surprise on the side' as it were.

 

[IcemanBo]

leave the other contestants in the dark and it is considered a strategy, which almost all of the entrants are in favour of.

I would try to do it. e.g. the leaking part, which I didn't know anything about it until the previous Zephyr and I learned it through the results

Don't inform the entrants as much as possible, so that they could lose points.

In contest rules there are some important things to note. Also for example, that a submission must follow Spell Submission Rules, where Memory Leaks is an important topic.
Other users should not really co-operate with contestants by saying what exactly to change in your code, or which leak to remove. But if they test it and report a map crash, or so, it would be legit I believe.

but people like me who are beginning to code, would have no chance!

I'm not a coder, I'm a designer

That's pretty normal. If you are not familar with our code standards and rules you will likely have no good chance to get a high score.

 

[Loner-Magixxar]

That's pretty normal. If you are not familar with our code standards and rules you will likely have no good chance to get a high score.

If only it was a coding contest and not a spell making contest.
I just provided an example to show the effects of knowing something and not knowing it. Not every category is mentioned in the spell rules.

Since I feel you don't get my point, I explain it differently:
Take a look at this:

Coding

Is the skill bug- and leak-free? Does it support multiple instances? Is there a good documentation and are there enough configurable variables to fit the needs of different user? Does it cause performance issues upon effect? Is the code fitting for a decent spell submission, or is it too simple? /20
Concept Is it unique? How creatively was the idea executed and is it fitting the contest theme? /10
Visuals How does the whole spell procedure look? Is it overloaded with special effects? How explanatory is the tooltip/description of its functionality? /10

These are the criteria that I focused and worked on, because I thought they are the only areas which the judge will be evaluating.
But it turns out that things like Initial description or setup instructions are important as well.
Why have I not informed about this?

And here is an honest question? Is it so bad or improper to put a reference list for the areas that the spell is going to be evaluated based on them by the judge?

By saying this:

That's pretty normal. If you are not familar with our code standards and rules you will likely have no good chance to get a high score.

If you mean that I should get lost and not join the contest because I don't know what is conventional between you guys, that is rude. But I think that's a tricky way to cover up your incompetency or laziness in hosting a contest!

Anyways I don't want any drama over already discussed and disputed matters such as "Zephyrs are all about coding", "It's a common knowledge", or such. I just expressed my opinion. If you don't like it you don't have to apply them. You have the controls. I'm just trying to make this a better environment for all to participate in something creative.

 

[Deleted member 219079]

@Loner-Magixxar I'm a bit confused whether you're against my suggestion :/ I think judging re-prioritization could be nice, see the last sentence of my previous post

 

[Loner-Magixxar]

@Loner-Magixxar I'm a bit confused whether you're against my suggestion :/ I think judging re-prioritization could be nice, see the last sentence of my previous post

I get the efficiency of the codes matter, but surely not this much, because there are so many other categories as well such as the mechanisms of the spell, its looks, its understandability, its fun qualities, its creativity, its originality, and etc. These are all parts of the spell making contest, but unfortunately they are all hugely overshadowed by only one of the aspects of making a spell (coding). And I find it hard to realize the reason behind it!

Is this not? I mean I talked about other things as well, but I said that coding is only one aspect and should not be prioritized over other aspects.

 

[Deleted member 219079]

I proposed to prioritize concept...

 

[IcemanBo]

If only it was a coding contest and not a spell making contest.

It's a spell coding contest.

Why have I not informed about this?

As said, read rules. It's stated there. If one is not up to date to our spell rules and standards, there might occur issues with the submission.

If you mean that I should get lost and not join the contest because I don't know what is conventional between you guys, that is rude. But I think that's a tricky way to cover up your incompetency or laziness in hosting a contest!

I did not say or mean anything alike. I believe you're interpreting a bit too much here. Everyone who seriously wanna pariticipate is very welcome.

I'm just trying to make this a better environment for all to participate in something creative.

Which is appreciated. But though, it needs to be evaluted if given critique is reasoned. For example something like "nobody told me about memory leaks or to read spell rules" doesn't convince me.

 

[Murlocologist]

Contest lasted too long. And about judging the problem is same. It took too much time. But I don't see a problem with judges' presented reviews and criteria they had. After all they had same criteria for all of submissions. If you were to ask me, they can alter or change criteria however they want, as long as they don't write it in a lousy way. And in my opinion, display of categories until end of contest isn't necessary. The only thing people need to know is spell resources rules, date to finish and theme. Judges should design how they want to form criteria of category they are to give a review about.

 

[IcemanBo]

Yes in parts I agree with you.

How ever I remember also when I was judge the first time, and it's good to have some rough guide to look at or to compare to.
And in major part the "guide" should be also correct way to go, but I also agree and don't see an issue if the judge takes initiative
and also works with his own style as long the judgement still confirms more or less with our rules and standards. Anitarf for example
worked out his own shema and listed own aid points to work though the relevant technical aspects under his "Code" criteria, which was structered pretty well in the end.

 

[KILLCIDE]

But it turns out that things like Initial description or setup instructions are important as well.

From the Contest Rules and Conditions:

"If a submission does not follow the Spell Submission Rules the creator may/will be disqualified."

From the Spell Submission Rules:

"The spell/system must be leakless."
"Spells and systems must have decent importing instructions."​

I'm not a coder, I'm a designer; but when it comes to working alone and without help and being have to deal with buggy interface of WC3, and only beginning to learn C# which doesn't have to deal with leaks, so it's expected, is it not?

From the Coding criteria:

"Is the skill bug- and leak-free?"​

 

[Anitarf]

I would like to offer some clarifications, since my judging has been the topic of several posts by now.

First of all, with regard to the weight put on the code judging: looking at past contests, the coding has always been worth more than other categories. The ratio differed from contest to contest, but this is not the first time that the coding was worth as much as all the other categories combined. I won't argue about whether that is right or not, since this was not up to me to decide in the first place. I'll just mention that the point distribution between the main categories was known from the start of the contest, so now is a bit late to complain about this. It might be an interesting exercise to calculate what the rankings would have been if the judging categories were weighted differently, but don't expect them to actually be changed retroactively.

Now to address the issues that have been raised specifically with my code judging:

Those parts of the code that you said need to be configured are not an integral part of the code (the code is complete with almost all of the variables being configurable). If you look carefully, If the user of the spell wants to add a new type of unit that has synergy with the other unit types, all the entries have to go through the same process I provided in my spell. The irony is, I got penalized by 2.5 points (!) for including a simple way and enough documentation for the user to do such a thing and add any new units he wants and set the combination of said units with other ones. This feature is a bonus and my only advantage point against other entries in the coding section, which you considered as flawed. Again if I knew there wasn't any category of bonus features of the spell, I wouldn't go through the hassle of adjusting my spell to the user's needs and get burned in the coding section by 2.5 points!!!

First of all, you did not loose 2.5 points for this. As was already stated in the description of my code judging criteria, I reserved one extra bonus point for spells that would go beyond the functionality of the spell with their calibration. No spell earned the full bonus point here and only 3 spells earned half of a point. So really the base amount of points available in this category was 2, not 3, so you lost 1.5 points for both of the issues noted in the explanation, not just the one you're talking about here.

Second, having all configurable values in one section separate from the code is an important aspect of spell usability since most users don't feel competent for editing code, even with instructions. Anything that needs to be configured outside the calibration section might as well not be configurable as far as most potential users are concerned. Furthermore, having to enter the same value at multiple points can result in potential errors if users input different values by accident.

These are the criteria that I focused and worked on, because I thought they are the only areas which the judge will be evaluating.
But it turns out that things like Initial description or setup instructions are important as well.
Why have I not informed about this?

The initial description and setup instructions are a part of "good documentation" mentioned in the judging guidelines. Both are very important for usability, so I've written them down as separate categories to help me with point assignment. The need for setup instructions should be fairly obvious: they allow users, even those with little experience, to easily setup the objects and systems needed for the spell. The point of the initial description is to provide an overall context for the more specific documentation later in the code. You can explain all you want about how a calibration constant configures the acceleration of the red triangle, for example, but without an initial description of the spell I won't know what the red triangle is supposed to do, how does it fit in with the whole, is it just a special effect, is it a projectile, etc.?

Of all my different judging sub-categories, only encapsulation and library use are not explicitly covered by the judging guidelines, that's 3 points out of 20. I added them because I thought they covered some important usability issues not covered elsewhere. All the other categories are directly derived from the judging guidelines posted in the contest thread.

 

[Loner-Magixxar]

OK, if I join other Zephyrs I will keep the results of this contest as a reference. But one last question:

case selection is done through loops and if-then-else chains instead of direct array lookups

Can you clarify this part for me a bit more? I don't quite get it. Or if there is any tutorial or document of any sorts, can you refer it to me?

 

[Chaosy]

Daym, I hit a new low.
Lesson learned, use GUI ;p

 

[Flux]

Daym, I hit a new low.
Lesson learned, use GUI ;p

Don't please! People should be moving from GUI to JASS/vJASS not the otherway around.

Also, just my feedback on the review on my entry.

Some values are not configurable like max height of bullet, max bonus.

I don't see a reason why would anyone edit the max height of the bullet. Wasn't expecting that my massive configuration list would be overshadowed by a max height of bullet configuration I didn't consider. What do you mean by max bonus?

Inlining system code is not a good method of making requirements optional. Linked list and timer code could be delegated to an external library, as well as bullets

I admit, that's one on me. But knowing that Zephyr is a coding contest, I thought it was safer to just make all dependencies optional rather than relying on it. More debate about it here

It would be enough to update gun targets on each shot instead of each iteration.

But if I do that, there will be times when the "overhead" target effect will be on a unit outside the AOE indicator. It could happen when the user configured the Firing Rate to a low value.

The channeling transition is bumpy as the plane doesn't appear for quite some time, giving me the impression that the spell wasn't working at first. If the plane was visible or some kind of visual indicator was immediately apparent upon casting, this score would be higher.

There is a visual indicator visible. I don't know about you, but after the spell cast, I immediately saw the indicator.

Anyways, that's just my opinion on the subject matter. I'm not complaining or anything, just expressing my opinion on the judgement.[/quote][/quote]

 

[Chaosy]

Don't please! People should be moving from GUI to JASS/vJASS not the otherway around.

Oh the things we do for higher ratings!

 

[Anitarf]

Can you clarify this part for me a bit more? I don't quite get it. Or if there is any tutorial or document of any sorts, can you refer it to me?

• For each (Integer A) from 1 to SI_MaxLevel, do (Actions)
  • Loop - Actions
    • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
      • If - Conditions
        • SI_TempInteger[6] Equal to (Integer A)
      • Then - Actions
        • Unit - Add SI_GreaterGolemAbility[((6 x SI_MaxLevel) + (Integer A))] to (Last created unit)
        • Unit - Add SI_GreaterGolemAbility[((5 x SI_MaxLevel) + (Integer A))] to (Last created unit)
      • Else - Actions

This could also be written as:

• Unit - Add SI_GreaterGolemAbility[((6 x SI_MaxLevel) + (SI_TempInteger[6]))] to (Last created unit)
• Unit - Add SI_GreaterGolemAbility[((5 x SI_MaxLevel) + (SI_TempInteger[6]))] to (Last created unit)

The effect is practically the same, the only difference would be that the loop version doesn't do anything if SI_TempInteger[6] is not between 1 and SI_MaxLevel, but if you need this check you can do it without using a loop too:

• If - Conditions
  • SI_TempInteger[6] Greater than or equal to 1
  • SI_TempInteger[6] Less than or equal to SI_MaxLevel
• Then - Actions
  • Unit - Add SI_GreaterGolemAbility[((6 x SI_MaxLevel) + (Integer A))] to (Last created unit)
  • Unit - Add SI_GreaterGolemAbility[((5 x SI_MaxLevel) + (Integer A))] to (Last created unit)
• Else - Actions

This could be applied to pretty much all the loops you use this way. In some cases, though, you use the loop integer as an array index in your comparison, instead of comparing it directly. Even in these cases, the use of a loop could be avoided. For example, say you have a random unit and you want to find out which level of the spell it belongs to. If you store unit types in an array and use their level as the array index, then you need to loop through that array until you find a match and when you do, your loop integer equals the level of the unit. This is the approach you use. An alternative would be to store levels in an array and use unit types as an array index (since you can convert a unit type to an integer). In this case, you could get the level of a unit by directly reading from the array, without the need for a loop. Of course, arrays are limited in size and converting unit types to integers gives you numbers that are too big to use as array indexes, so you would need to use a hashtable instead of an array, since hashtable keys are not limited in size like array indexes are. The same principle applies when you want to store data to specific units rather than specific unit types, since units can likewise be converted to unique integers by getting their handle id and those unique integers can then be used as hashtable keys to store data for a specific unit.

 

[Almia]

I was late, I didn't know the results have been released :O Congratulations everyone, specially to Flux. Man, your spell is awesome, still amazes me even months have passed.

I am also grateful that I won the best visuals LOL

 

[Flux]

Congratulations everyone, specially to Flux. Man, your spell is awesome, still amazes me even months have passed.

Thanks for the special mention. Likewise.

I am also grateful that I won the best visuals LOL

Those crawling spiders were executed pretty well.