Disclaimer: all videos in this article are from the alpha stages of development and do not reflect the models used in the release version. For current examples of what the race looks like, refer to the screenshots. Download link for the map is at the bottom.
After I submitted my Feykin race for the Techtree Contest number 10 on The Hive Workshop, I had intended it to be my last submission. If that had been the case, I would have done so having failed to really deliver on a race that was fully-featured and full of its very own custom models. As the Techtree Contest 11’s discussion came around, I started feeling this familiar longing to participate, the ideas already starting to simmer in my head. I thought I’d just scout out the thread and see in what direction it was going, and ultimately a theme was voted in; Techno-Magic. This one was suggested by yours truly since I wanted something new. The entire idea behind this particular theme was to work with a teammate so that we could divide the workload and really deliver a great and compelling new race. I was ready for the challenge, but plans have a way of rarely working out, do they?
The ideas had already started to coalesce in my mind, albeit somewhat haphazardly, but I already knew that I wanted to do this. Just then I got contacted by a user by the name of Astaroth Zion, another proponent of the paired contest idea. He seemed quite motivated and had a number of custom models to his name, so I figured this would be an easy ride – easier than going solo, at least, and you know what? It was easier, in a way.
If I had to identify where we went wrong, I’d say that it was too much planning. Astaroth Zion had made a Google spreadsheet to put all of our ideas in and we started brainstorming over Skype calls, inputting ideas and discussing whether they would follow the thread of our theme. In retrospect, I think Astaroth and I might have had different ideas on the magnitude of the project we had embarked on. I had envisioned something grand and ambitious that was drastically different from vanilla Warcraft III; Astaroth, I feel, had some more grounded goals. Still, we could have delivered something much better, but then, just as we were finally done with the bulk of the brainstorming and I had started to code some systems, Astaroth’s job came knocking. I had not asked him for details, but it seemed to me that it left him with little free time to work on making 3D models. That was unfortunate since the whole idea of teaming up was to have the ability to deliver a custom race of a quality that is rarely seen on the Hive, to the best of my knowledge.
Midway through development, I started getting involved in Starcraft II modding. I had made a new friend who wanted to collaborate on an old project of mine and this took a chunk out of development time for the contest, time that could have been used to play-test the custom race. I had seen too big, as I always do, and ended up spending days upon days coding and bug-fixing systems. Still, the custom models were not coming, and I was starting to get frustrated. A few weeks before the deadline, Astaroth finally contacted me and apologised for the radio silence as well as explaining his predicament. But it was not over yet, and he powered through, making as many custom models as he could on a tight schedule. In the end, even though we didn’t get much, I was able to scour the Hive for custom models to use. That was something I was unwilling to do, but I was left with little choice.
Our saving grace came when, deadline approaching, the contestants were offered a small reprieve in the form of an extension that gave us one more week to work on our submissions. I powered through and managed to fix, as far as I’m aware, all the bugs that were plaguing my map. I submitted the map and despite all the work, I was feeling rather unsatisfied with myself. The systems I had dreamed up were hardly the most practical, and the lack of custom models bothered me more than I cared to admit. Even the demo videos I made were hastily done and not as good as I’d want them to be. But what was done was done, and it was up to the judge and the public polls to decide what Astaroth’s and my submission was worth. You can see the results here.
If you’re feeling brave and adventurous, you can look at the brainstorming spreadsheet Astaroth and I used. Beware, there are a lot of… colours. Check it out.
What I had in mind when I pitched Techno-Magic was to take existing factions and reimagine them. When the theme got chosen, Warcraft II factions were thrown in there to widen the scope a bit, but in the end, contestants just picked from any race that existed in Warcraft III lore. This wasn’t particularly egregious to me since I understood that while the Hive already contained a wealth of ‘Techno-Magic’ models, those were reserved for races like Goblins, Gnomes, Dwarves and Blood Elves (siege weapons and golems) and little for the vanilla factions. What did slightly bother me, however, was how unwilling everybody was to work in pairs. Everybody wanted to go solo, which kind of boggles the mind when you know how much work goes into making a custom race. It’s why it has so few contestants – it’s a huge endeavour. In the end, only Astaroth Zion and I teamed up.
As a team, brainstorming came much, much easier. I always run into creative blocks at some point, and having someone to bounce ideas off of, and receive some in return, did a lot to help the creative flow. Astaroth’s initial idea was some sort Dalaran-like coalition of Human and High Elven mages that would use remote-controlled golems to do their bidding. For me, I wanted to do something that was an alternate-universe style retelling of Warcraft III, and so I pitched the Unificators. Astaroth liked the idea, and so our focus was set on a race of Techno-Magic Undead faction.
When Warpseer Ner’zhul activated the Portal Engine to flee Draenor, and consequently doomed the planet, he met his ‘end’ when the wormhole he took sent him face to face with Kil’jaeden the Deceiver. The Warpseer was lobotomised and his spirit encased within a highly-advanced Legion device called the Frozen Throne. The Dreadlords, elite agents of the Legion, were sent to monitor the Warpseer’s soul as it was tasked to create a force powerful enough to sweep through the lands of Azeroth and lay waste to the natives. Ner’zhul’s efforts created the Unificators, but secretly, his spirit managed to find a loophole through the Frozen Throne’s AI. He sent telepathic messages forth so as to create sleeper agent within the Unificator cult that would enable his freedom from the Legion.
The premise I was focused on was the use of souls as fuel. Instead of using corpses, it seemed more fitting for a cult of technologically advanced necromancers to focus their attention on the ethereal. To make this idea stand out, the souls had to be ubiquitous, which lead to the creation of the Soul Cube. These little fellas carry souls inside them, which is how souls are safely transferred from place to place. Everything is done with Soul Cubes, from building to harvesting to creating troops. They can be used as fuel for a flying support unit called the Soul Projector, and also to empower Bane Chariots and Annihilators (more on those below). They can dock into a couple of buildings, which gives the player an incentive to just have them around the base. The only thing they don’t do that other worker units do is repair buildings or mechanical units, and the reason being that repairing is reserved as a spell for another unit. Additionally, Unificator buildings auto-repair when their mana reserves are full, a mechanic I go into more detail below.
In the spirit of keeping with the high-tech aspect of the theme, Unificator buildings are capable of self-maintenance, but require energy – therefore, mana – to function. Their mana constantly drains and has to be replenished by the dedicated food-provider, the Spirit Well (which doesn’t consume mana). Otherwise, they begin to take damage every second until they are destroyed or their mana goes higher than zero. In an effort to make the mana mechanic a bit more worthwhile, all buildings have a passive mana-shield type protection that reduces any damage they take by a percentage, up to 50% at full mana. When they take damage, however, their mana reserves reduces by 5% of the initial damage inflicted, which means that for maximum protection, a building needs to keep it’s mana pool at 100. This is where the Soul Cube and the docking mechanic comes in handy; as the Spirit Well distributes mana around to nearby buildings, its own reserves are used up. It recovers quickly, but if there are too many buildings around, it will struggle to feed them all. Docking Soul cubes onto a Spirit Well boosts its mana regeneration, allowing you to use the Active Transfer ability, a reverse Siphon Mana spell, to directly refill the energy of a target building. All of these separate mechanics can synergise to open up new ways of defending your base. Just like Peasants can take up arms and defend their base, so too can Soul Cubes, in their own indirect way.
It doesn’t end there, however. The initial reason why structures’ mana-dependency was ever implemented was because of how the Unificators build their bases. I’ve always been a fan of the Command and Conquer method of building bases, where your building is constructed in the safety of the UI and then rapidly deployed on the battlefield once it’s done. With a submission prior to the Feykin, the Sandborn, your food providers could build the buildings in safety, and once they were done, deploy the structures in reach of any one of them. With the Soul Cubes, I wanted to make something different, and I didn’t want to mimic the Protoss Pylons from Starcraft, mostly because there is no way of enforcing the grid placement to show buildable areas without altering the terrain.
The way the Soul Cube builds is by channelling a custom spell for 40 seconds worth of build time. Because of that, Unificator buildings themselves deploy quicker than that of the other races. Besides building things, a Charged Cube can only dock and harvest gold.
Once construction begins, the Soul Cube is destroyed. Since the buildings construct quickly, it meant that there was a potential abuse of tower-rushing tactics. To help balance things out a bit, the mana mechanic was introduced to force towers to be near a Spirit Wells, lest they drain away all their energy reserves and decay. While this didn’t impact the rushing speed itself, it impacted the cost of a tower rush strategy.
Finally, Docking is used to harvest lumber. Soul Cubes themselves don’t directly knock down trees but power an indestructible construct via a Logging Station. Up to five Soul Cubes can Dock, and each one makes the golem harvest 1 more lumber per hit. The golem itself with automatically seek out the nearest tree to harvest.
While this system received praise from Kam, the judge of the contest, I do feel that the system could be better. The trouble with harvesting lumber is that trees are destructibles. As far as I know, there is no way to catch when a destructible was damaged. If that were possible, I could have made the system work flawlessly. Unfortunately, I’m left with having to swap out a modified lumber-harvesting ability used by Ghouls, and that particular spell cannot be levelled up. Removing it will reset the total amount of lumber harvested to 0, which means I have to make the golem return to the station, deposit its currently harvested lumber, and then swap out the ability.
The way this is handled is hardly the most elegant. As there is no way to easily catch when certain orders are passed, I have to rely on a timer that checks for a change in order to figure out when to swap out the ability. This has the potential to bug out, which can only be reset by Undocking all Soul Cubes and restart the process all over again, Docking them one by one and waiting for the golem to strike a tree at least once.
The only way I can currently think of that will fix this issue is to have a golem for each cube, but I’m unwilling to do that because more units mean more overhead.
Another function the soul Cubes possess is to build the basic army of the Unificators. I call them Husks and there are two types of buildings that make them: the Fabricator and the Advanced Fabricator. They produce them automatically, creating a base Empty Husk that you may then charge up with Soul Cubes. You may charge them twice to create the 2-food Husk, or thrice to create the 3-food Husk. Two Soul Cubes represents 120 gold and 2 food, whereas three Soul Cubes represent 160 gold and 3 food. We use those values, to balance the costs somewhat, and charge a flat 10 or 20 lumber (depending on the Fabricator) upon activation of the Husk. See, the Husks themselves don’t do anything until you order them to move. Once a slot on a Fabricator is free, an Empty Husk will eventually get built and placed there.
A late game upgrade called the Immortality Protocol allows Husks to be revived by Soul Cubes or Soul Projectors if they fall in combat. The downed state they enter has a 50% chance of triggering. This gives them an ‘Undead’ feel, similar to the Necrons in Warhammer 40k.
Earlier, I mentioned two units, the Bane Chariot and the Annihilator. Those units are a bit special, separate from the bulk of Unificator units in that they are ‘trained’ traditionally through the Fabricators and can be altered to serve a different purpose.
The Bane Chariot is a siege unit and fires shadowy projectiles in an arc similar to other siege units in the game. The difference is that you can garrison (not sacrifice) Soul Cubes into it, up to 3, to empower its attacks and increase the number of projectiles it fires. Basically, if the unit is taking up more food, it should perform better. Therefore, if you wish to beef up your siege units, throw some Soul Cubes in there. The only downside to being able to dynamically increase the number of missiles fired is that I can’t give the Bane Chariot an Attack Ground ability. Because the firing of the missiles are controlled via a system I made, it foregoes the ability to trigger on trees since, as mentioned earlier, there are no known ways in Warcraft III to detect when a destructibles takes damage.
The Annihilator, an end-game unit, is inspired directly from Independence Day, which fires a continuous laser beam directly below itself. It can be empowered exactly like the Bane Chariot but simply gains a flat damage increase instead of additional beams. The Annihilator’s attack, by default, applies a Cold debuff on enemy units struck, and I do that by creating a dummy unit at the epicentre of the beam impact and ordering that dummy to cast a custom Frost Nova on itself. I use a combination trick of Chaos and Locust to make the dummy unselectable but still targetable, so the illusion is maintained.
But wait, there’s more! The Bane Chariot and the Annihilator can also completely change their roles by being Piloted by Mechaweavers and Dominators. As the only sapient units in the Unificator army, Mechaweavers and Dominators possess the ability to Pilot Bane Chariots and Annihilators and give them a different function on the battlefield. I don’t quite remember now who’s idea this was (might have been mine) but I had some reticence at the idea of just swapping out pilots to change the function of a unit at will. This had the potential to be overpowered and I was aiming to avoid such a situation as much as possible. To alleviate that concern, I took a look at how vanilla Warcraft III handled Archers riding Hippogriffs and noticed that there was a cooldown upon Mounting, so this was exactly what I did for Piloting.
The reasons why I hadn’t simply just used the Couple/Decouple spell to make the Piloting work are two-fold. Firstly, piloting is handled by checking the size of the Pilot, and that value can either be 1 or the maximum, which is 3. Anything other than those two numbers can cause the system to bug. If a Mechaweaver or Dominator attempts to Pilot a vessel that already has at least one Soul Cube inside, it will see that the resulting space that will be occupied is greater than 3, and will cancel the Piloting. Using a Couple/Decouple, the Piloting would have occurred anyway and the loaded Soul Cubes would have been lost.
Secondly, the Bane Chariot and Annihilator were not initially planned to use alternate unit IDs and would simply have been given a weapon change and new abilities. As development went on, the limitations of this technique became apparent, and so I had to make the units change completely so I could more easily control maximum health and mana and all the other stuff of the like. This was accomplished using Passive Transformation, a simple trick I encourage a lot of Warcraft modders to get familiar with since it can completely change a unit and avoid all the bugs that come with using Chaos. It even preserves the unit’s custom values, so if you, like me, swear by Bribe’s Unit Indexer, then Passive Transformation is what you need. To top it all off, it works on Heroes. That should be enough to convince you.
The design philosophy behind the heroes was always to preserve the essence of what they were in vanilla Warcraft III and recast them in a Techno-Magic mould. Heroes were made in the late stages of development, though I did surprise myself with how easily some of the ideas came to me. Astaroth Zion and I had never really discussed Hero ideas, mostly because we were a bit stuck on some of the other ideas we were trying to work out. Things change constantly, so I had thought we would plan the Heroes later on, but with Astaroth’s surprise work schedule, it was up to me to wing it.
Units are separated in tiers depending on the level at which the Unificator Town Hall is at (Soul Pyramid, Spirit Nexus and Apex of Unity respectively). Technically, since the mutually exclusive upgrades for the Bane Chariots and Annihilators have not been implemented, the Scorn Tank and Rift Tank should be Tier 2, but for the sake of not loading up Tier 2’s tabs with 2 more entries, I moved them to Tier 3.
Honestly, I was a bit surprised when I found out that Astaroth Zion and I were awarded first place. I felt the race was unfinished and was lacking most of what a paired submission was supposed to have. Upon reading Kam’s analysis of the race, I’ll have to agree with most of his criticisms. The multiple ways in which units are trained become really cumbersome after a while, and while I personally think sacrificing Soul Cubes to obtain different types of Husks is a mechanic a player can get used to in the long run, I admit to the Piloting being a bit too much of a hassle to deal with. In the event that I do revisit the Unificators (which will require I finally get those custom models), here are five principal things I would like to address:
1. Revamp the lumber harvesting. If you’ve missed it, you can read up on how bug-prone the current system is under Docking (four last paragraphs of that section). This will be something I would love to be able to tackle, but currently, there is no way to detect when a destructible gets damaged.
2. Find a different way to create Husks with the Soul Cubes. Kam’s suggestion is interesting, but this would mean you will need multiple Fabricators with different numbers of Docked Cubes to change the Husk type, which to me amounts to the same problem of having to micro-manage your workers. This new Husk-generation method would be used to also handle Mechaweavers, Dominators, Bane Chariots and Annihilators. Maybe something with wormholes…
3. Consider removing Piloting. During my own playtesting, I found this mechanic to be particularly cumbersome when you had to juggle multiple unit-training methods. If all units are trained under a unified system, then perhaps it can stay.
4. Give the Unificators a fourth hero. I acknowledged in the alternate universe lore that Dreadlords are a thing, so like the Undead, it would make sense to have them as a possible hero choice.
5. Integrate mutually-exclusive upgrades to force the unit roster count per game down to 12. This could be down to a simple matter of casting an ability if it turns out to be too much of a hassle to wait for an upgrade to finish.
There you have it, folks. This was my experience with creating a new race for Warcraft 3. If you wish to try out the Unificators, you can download the map in the image link below. To play as them, select Undead at 90% handicap.