Does nobody else want this? Does nobody else feel this way?
What if I run my imagination for a bit??
Reforged do-over. I'm the boss now. Only "Reforge" what I say.
What's that? Corporate leadership called and said I'm not in charge? I'm sorry, I can't hear you over the sound of how awesome Warcraft 3 was. *hangs up*
Great, now I'm the boss. It's 2017 again but instead of going to work at my job I got just out of college, I'm in a different timeline where I'm actually the boss of Warcraft III now and between 2017 and 2020 for the release, I get to decide what to do.
Now let us begin.
First order of business: World Editor
We upgrade this first because we will use it to make the new content available elsewhere in the game! Duh!
Feature 1: Object Editor
Object Editor operates based on simple repeated rules that are very hard-coded. We want to expand them for the remaster. Add tabs to Object Editor for game components that players could hack in but weren't easily-accessible. Each new tab will have its own binary changeset file included in custom maps with its own file extension. Brainstorm list of tabs that will be VERY EASY to add in the first draft:
- Lightning Effect tab (customization for bolts like Chain Lightning, Healing Wave) -- edits `Splats\LightningData.slk`
- Ubersplat tab (building splats / stylization that appears under them) -- edits `Splats\UberSplatData.slk`
- Terrain tab (available tileset textures, and what the names are for their parts) -- edits `TerrainArt\Terrain.slk`
- Cliffs tab -- edits `TerrainArt\CliffTypes.slk`
- Weather tab -- edits `TerrainArt\Weather.slk`
- Soundsets tab -- edits `UI\SoundInfo\UnitAckSounds.slk`
- Races tab -- edits the sort folders for units, and the list of available races before a map starts (so you could add Naga for example)
(NOTE: I added the "Races tab" idea above later on after the rest was written in an edit -- it would take more effort to create due to its impact on C++ game systems that aren't SLK. But it's a needed feature.)
New cliffs and terrains defined in object editor should be available when painting the ground, and we should remove the limit of 16 ground tiles & two cliff tiles per maps. Cliffs are pretty easy to solve by changing the default implementation of `TerrainArt\CliffTypes.slk` so that it refers to the file path with an underscore instead of the "ReplaceableTexture" file paths, which are actually just getting overwritten by the Tileset MPQs in this case (such as A.mpq in the game install for tileset 'A'). The 16 terrain tile limit is harder than this to solve and requires some C++ change but that's fine, just do it, to let larger maps be more creative.
We should also make it that the Object Editor can select multiple "objects" at a time, and editing the property of one edits them all. Copying many at a time should create a copy of them all, and preserve data links to the best extent possible. Also allow selecting multiple "properties" at a time, and copying and pasting them all at once. Also, add a hotkey and right-click option on the objects called "Refactor" that can change their data ID (4 letter integer constant) while updating all discoverable references to that ID. (It might be slow, but has high utility. Script functions that dynamically generate IDs and then call them up would fail to refactor and that's expected -- 99% of cases where scripts use these rawcode IDs, they use them as a 4 letter character literal that's easy to refactor.)
Feature 2: Trigger Editor
This is an antiquated system for developing game behaviors.
Updates to Trigger Editor involve two distinctly important kinds of changes:
- Changes to the available set of actions the map sandbox can take
- Changes to the procedure for users wiring together logic for invoking actions in the map sandbox
All of our changes for my non-stupid better remaster pretty much fall into one of these two categories. Now, there are times where looking at the modding community to see what they already do, and then building out the remaster system based on that, is an awesome way to pay homage to the fans. "Changes to the available set of actions the map sandbox can take" is not one of those times. I'd like to avoid mentioning the "R" words in my imagined paradise here, but Reforged is idiotic lunacy when it comes to how it handled the first of these two bullet points. In an effort to support "pre-existing" content from foreign countries like China where it is legal to do (illegal?) binary hacking and inject new instructions into the Warcraft III game, somebody in the timeline you (our reader) comes from had the idea to ask community how to handle UI interface. This led to the contrived misuse of FDF technology as a way to inject custom 2D interface into maps, in a way that even the game's own IP holders didn't understand (as evidenced by their move to HTML for the menu).
Don't do this. I don't want to talk about it anymore.
2D interface is a well understood problem in other ecosystems, and it's fairly straightforward to define simple pipelines for drawing and rendering. The community-based usage of FDF in Reforged has degenerated into designs celebrated for their ability to create UI entirely through code and without using FDF anyway. The whole thing is madness. You wouldn't want to do it that way at all.
As a litmus test for whatever new API is designed for handling the UI, there should be a second copy of the standard game UI (unit selection and commands, and the ESC menu) that is itself expressed in the map script language rather than being written in C++. If this is not possible, then your API is -- like Reforged -- "idiotioc lunacy." Full stop.
(Case in point: why is it easier to build 9 item inventory on Warsmash by reinventing the entire thing than it is to build 9 item inventory on Reforged in any way, shape or form?)
I have avoided expressly describing an API here because of the possibility of my exact language syntactical opinions being wrong in the future at the time that the readers find themselves reading this, because unlike Warcraft 3's closed-source proprietary system the world of 2D graphics and software development evolve through time. This brings us to our second bullet point, and perhaps a larger problem: the procedure for users wiring together logic for invoking actions in the map sandbox. Tragically, this process of "Creating a Trigger" that might once have been a tutorial on a fan site is quickly evolving into a space where everyone believes that even editing this 2002 game that would usually run on your toaster should require the use of an LLM to build the map script logic for you which itself might require a computer the size of my house to train it, and then a stack of graphics cards the size of your microwave oven (but with a much larger power draw!) to do the digital thinking to invent the map script logic, because this is intellectually easier than decoding a human expression such as "I want to have minions run down three lanes" into discrete steps of "Event - Unit enters region" and "Condition - Unit is a minion" and "Action - Send unit to next section of Bottom Lane" or what have you. I have a sense that current events and social trends in my life aren't finished and what I'm describing here will be even worse in the future. I cannot accurately predict the future, so I will only speak of my personal experience.
The blueprint scripting UI from the Unreal Engine seemed quite good, although I am certain they would have "Patented" it over at Epic Games, as any skilled villain would do. We can hope that by the time the reader reads this message, AI will have laid waste to human society in such form that "Software Patents" will have ceased to exist, so perhaps in the future it will be easy and freely imagined to develop a second mode for the Trigger Editor that has a visualization like Blueprint Scripting from the Unreal Engine.
In the meantime, there is also TESH available on places such as the Hive Workshop. If we look back through history at the way that fans were able to create JNGP and make syntax highlighting in the Trigger Editor as well as advanced scripting syntax, those features would be a must-have in the remaster. Rather than ripping off the community solutions directly and including an x86 binary compiled in the Delphi programming language by a person who disappeared into the internet a dozen years ago and never came back like Reforged, the right way to do this is to intelligently update the Warcraft III World Editor code itself to natively handle this, which may include updating the game to support language feature improvements. Declaring the LUA must be used instead of JASS is intellectually lazy and it assumes that JASS will always be slow by design, instead of considering the possibility that the syntax is fine but the implementation and execution of the language is too slow. Having a game system that swaps between JASS and LUA dynamically is also stupid. Pick one. If you want LUA, fork the game and offer that as a separate offering or something. If that separate offering wins the popularity contest (although it might make me personally sad) then delete JASS and have LUA be the language of the game. Don't force the game to be maintained as a duplex frankenstein system, or else you might get stupid bugs like Reforged.
So in summary, for Trigger Editor:
- Add new API functions for drawing shapes in the user interface -- drawRect, fillRect, drawOval, fillOval, drawPolygon, fillPolygon, drawImage (important!) -- same stuff you see on HTML5 canvas and the like; leave FDF as the technology of the out-of-game menu
- Add new API functions for capturing mouse X/Y in the 2D user interface for use with these functions (click events, X location, Y location)
- Don't literally rip off the code of TESH without asking, but upgrade the game itself to have TESH-inspired JASS syntax highlight and autosuggest -- or highlighting of the one (and only!) language used in the game, if you change mapscript language for all maps -- and have this available on any trigger converted to custom text
- Maybe add Blueprint Scripting with a node graph similar to Unreal, but obviously this would compile to JASS (or the game's new map script language)
- Allow local variable definitions in GUIs, or replace GUIs entirely with an IntelliSense IDE experience that's so good nobody needs a GUI (or the youth will want to just plug in AI, but personally I probably wouldn't bother since future AI will know how to plug in itself)
- Expose the war3image concept into map script so model animation, scaling, translation, rotation, etc function APIs can be applied likewise to units, "special effects" or "spell effects," or to sprites on the 2D screen UI like the clock and animated cursor.
Feature 3: Content
So now we have a bunch of new features in the programmed systems, but we also want to have new content mostly made with those features (although in a few cases as code changes to the game itself).
One of the first glaring flaws in the game for anybody who tried to use Object Editor for any long period of time is the problem of the "Build" concept being hard-coded between units. In rare situations, users want to make a map with a new style of build that works differently from the existing ones, or mixes and matches them. To accommodate this, our remaster should add some new abilities to the Ability Editor's list of standard default ones, and this means adding more C++ classes for how they work as well as SLK ability database entries:
- `Custom Build` - An ability that has "Data - Structure Built" as a unitList setting similar to the abilityList of the "Spellbook" ability, "Data - Race of Build" as a control for how the build operates (summon like undead, powerbuild like human, etc), and "Data - Base Order ID" that allows ensuring two different instances of this ability open safely into two distinct menus.
- `Custom Build Single` - Rather than being similar to "Spellbook" this one is almost an exact copy off of "Build Tiny Altar of Kings" except that it has a configurable gold cost, lumber cost, and "Race of Build" setting.
- `Custom Queue` - A single icon ability that trains or upgrades a technology but which can be given a mana cost (for fun), is otherwise functionally similar to using Unit tab to make a unit train another
- `Custom Sell Unit` - A single icon ability that sells a current unit type selected as its Data field, however it does not have the special hardcoded rule that requirements only apply if the unit being sold is a hero (like how Taven heroes require an altar but if you make a Mercenary camp unit require an altar the requirement is skipped!). No nonsense, just a clean, configurable way to sell a unit that requires triggers if you want special rules for it. It also stays available even if you get 3 heroes and the unit it was going to create was Hero type, so again if you want special rules you'd have to trigger them in.
You could probably also add custom sell item but I don't think there are as many problems with that so it's less necessary. Combining these abilities will mean that a player could make a map for example where a neutral shop has a menu that opens up to list items of different kinds and that sort of thing, but do it entirely naturally with Spellbook instances that contain instances of `Custom Sell Unit` or `Custom Sell Item`. Would be fun.
Once the new content that requires C++ systems code is done, the more fun part would be the gameplay experience content. So, obviously this is a bit of a slippery slope because there are 20 years of custom mods and when you add new custom content to the game, there's always going to be a really passionate player who says that he did what you did already in the past, but he did it better than you. This is going to happen regardless of whether it's true, but the way to try to respect that person is to first and foremost keep the new "gameplay experience content" that I am about to describe constrained to a new third mode. For example, along with `Warcraft III.exe` for the base game and `Frozen Throne.exe` for the expansion, we deploy our new content essentially like a third expansion with its own launcher. This is going to require creative gumption on the part of the person making the new content to believe in themselves despite nay-sayers, and an important way to do that is to make sure the nay-sayers have a `Frozen Throne.exe` to play without the new content. Make no concession as to the importance of this regard.
Essentially all monitors are widescreen now. In the new third launcher, include a ConsoleUI 5 and ConsoleUI 6 texture that fill out the rest of the UI for supporting 16:9 interface, but on these UI pieces there should be 3x3 inventory instead of 3x2, and 3x5 command card instead of 3x4. This will allow players to build more advanced creative content in World Editor, or allow more advanced hero missions with 9 slots of inventory.
Finish the Naga race which in the form presented in The Frozen Throne is imbalanced and incomplete. Of course, the Frozen Throne data remains the same for full backwards compat in Melee_V1 and Custom_V1 folders, but our new stuff which is filed as Melee_V2 and Custom_V2 content will include the Naga race as well as possibly other races. In the Build menus of the existing races, we can include support for Naval gameplay by adding a Shipyard to all the non-Naga races (Human, Orc, Night Elf, and Undead). The Shipyard graphics are already in the game from Frozen Throne when this was attempted but scrapped long ago anyway. However, the Frozen Throne campaign implementations of Shipyards are not very fun and were scrapped for a reason. In our system, we should build out how those work to have some of the features from Warcraft 2 in our creative new stab at things.
Then, add a sixth race based on whatever inspires the person currently working on this project. This could be something they find cool from World of Warcraft, or something from the old Warcraft 3 game that was alluded to but never finished such as Draenei (what WoW calls "Lost Ones"). Similar to the work done when finishing the Naga, the art for these new creations should be true-to-form of the guidelines and styles of original Warcraft 3 game art from the 2002 game. In corporate settings that's hard to do but on the internet it's actually pretty easy and there are tons of people on Hive Workshop who know how to do that. So what that means is that it's actually pretty easy to do that -- get over yourself. If your artist thinks the graphics in the game should all be redrawn in his new style, get a different lead artist who wants to play Warcraft III instead.
Using two new races, add a campaign using campaign missions that are built with the new World Editor features we created. This includes:
- The new UI natives to draw things onto the screen, used for some extra campaign flair and stylized map-specific UI
- A hero mission where an event causes the hero to have a bigger satchel, and he gets 9 slot inventory, and then can pick up more items, carry them across 2 or 3 lone hero missions without base building, and build up that fun 9 item inventory
- Storyline for the new races, gradual introduction to their new units and abilities during the player experience
- Introduction to the naval gameplay
- A map with unique characters, map-defined soundsets, lightning effects, and weather that challenge players who try to make maps to ask, "how do I put that thing from the campaign in my map?" which causes them to open the campaign map and learn about map-defined soundsets and lightning.
The six-races-mode in the new experience should also include its own ranked play, and new maps and items. You could probably make 1000+ new items and dump them in Item Editor mostly by just loading in the icons from World of Warcraft from the year 2005 until about 2010 and making them available to this game as well, but with the Warcraft 3 icon border slapped on them. From there, it's a simple matter of making up items with mostly existing behaviors but different names and descriptions, and occasionally maybe a new C++ class for their behavior if it's really weird -- and you would be able to rapidly prototype in a bunch of new and interesting items to mix up the experience and make it different experientially while still being "Warcraft III" stylistically.
This is how I remaster Warcraft III. I'm probably forgetting one or two things. Yeah, we would increase the maximum number of units that can be selected at a time up from 12 to at least 18 and have the 18 icons fit in the same UI without having to change it much (been proven on Warsmash that it works fine visually). Maybe we could paginate it like Starcraft 2. This can be a gameplay constants setting so if some goober who thinks it's an e-sport skill to fight with the 12 cap wants to go play `Frozen Throne.exe`, and have the old constants table that limits at 12 loaded, he can do that. But are we keeping that old limit for future content and custom games? No! Not in my remaster.
