• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

Design Goals and Philosophies

Status
Not open for further replies.
Future Vision

Warsmash is my vision for how I will be doing Warcraft III modding in the long-distant future and years to come. This project is based upon the premise that if I recreate the major components of the Warcraft III game, then this will allow me to mod the game in ways that surpass the standard rules of mapmaking. Warcraft III modding is a technology that is easy to get in to, and difficult to master, because a lot of what we do in the modding community is the result of "happy accidents" during the game's design that were later expanded upon by the Warcraft III development team to add support for what fans wanted to do.

If a user wants to make a simple Warcraft III map that follows the basic premise of a melee game, or even a 3-attribute, 6-item-inventory hero RPG with a limited scope, the Warcraft III World Editor makes this very easy to achieve. So, players can easily get into basic mapmaking, and the problem we encounter in Warcraft III modding is always when the users try to "go beyond." There are stories of people who have done it, and there are even fun maps that have done it. I played a fun and interesting implementation of the basic concepts of Minecraft as a map on the Warcraft III Reforged pre-patch 1.31 version. This was a typescript (to lua) map made by CanFight in 2019, and it was a lot of fun goofing around and building a multi-tiered building and cave system on that Warcraft III map and its engine and being able to save and reload the "Minecraft world" even when I exited the Warcraft III map and relaunched the Warcraft III game.

But what I find when I look at these two areas of Warcraft III modding -- that we have both the world of very basic user interaction with the game, and very complex sort of "hacks" to make the game into something that it was not originally -- is that I find there is a sort of gap in the realm of the "middle ground". There are concepts that humanly seem like they should be possible, but they are not easily possible without unreasonable, substantial amounts of work. My personal first project on Patch 1.31 was an attempt to upgrade the game using the new Reforged pre-patch modding APIs to allow me to "shift+enter" on the Inventory (Hero) skill to enter the number 7, 8, or 9 as legal numbers for the "Data - Item Capacity" field. This is a very simple concept. I wanted to make a system that would allow me to still get the benefit of the "easy and efficient to use" side of the Warcraft III World Editor and its Hero and Item systems, while at the same time allowing me to push the envelope and go further. What I found after days of work doing what I wished would have been a simple change to a numeric constant was that implementing what I wished to do in Reforged would have been impossible without substantial reinvention of the editor or game systems. I was able to isolate a series of new natives that could be added to the Warcraft III game to make what I wanted to do possible, but it was beyond my power to add natives. To achieve this vision I would have had to reinvent most of the components of the Warcraft III game and included them as scripts within the map, and quite possibly many of those black-box C++ components are actually outside the scope of what can be created in a Warcraft III map (or very nearly so). Because unlike recreating Minecraft with totally new and different ideas, it appears that attempting to leverage the in-game systems to go further in many cases is not possible.

Another example of the same problem was obvious to me during the 1.30 pre-patches for Reforged. I mentioned to William on Discord that I thought it would be very cool if the Reforged guys would do this very simple task of making an expanded version of the Build Tiny Altar of Kings skill that would have a Gold Cost, Lumber Cost, Racial Build-Type, and Base Order ID field so that making a second build menu using a Spellbook in the Ability Editor would become an easy and efficient task. William replied to me that this was going to become possible with the hand-wave high-level solution of UI natives that should "make anything possible" and so he felt that doing what I asked was not necessary. In theory he is most likely correct, but to this day I do not know how to do with the Reforged UI natives what I was asking him for a way to do -- from an efficiency standpoint, and from the standpoint of "upgrading the components we see in the World Editor" to have these sorts of expanded features.

And so it was in this context that I began to pursue the vision of Warsmash more directly as we approached the Reforged release date.
On Warsmash, it was a couple of minutes in an afternoon for me to change from a 3x4 to a 3x5 command card in a way that honored the World Editor's structures built list for any unit. All I had to do was go into the definition for the MeleeUI class and change the constant int COMMAND_CARD_WIDTH = 4 and replace the value 4 with a value of 5.
1617573898566.png

This is more or less the vision for the moddability that I am hoping to unlock. A lot of the code that I have written, if you read it, is the product of using and sharing code from many other Hive tools and is hastily written. I do not always support the kind of modding that I want to eventually be able to do, yet. But by open sourcing these components and encouraging people to understand how they work -- so that they can be remade -- in my eyes this opens the possibility of achieving this kind of future in ways that Reforged cannot do because it has to turn a profit and therefore has to remain closed-source.

Another example of an area of Warcraft III modding where I believe Warsmash will eventually be revolutionary when it reaches its full design goals and potential will be the case of projectile systems and custom ability behaviors. As it stands currently, until the 2019 Reforged pre-patches, for 17 years, the only and suggested way on Warcraft 3 to make a custom fireball missile shoot through the air from a spell-caster unit to a target unit was one of two options
  • Use an existing in-game skill that is hardcoded to launch a missile but change the 3D model (which has the side-effect that you cannot modify the in-game skill's behaviors that you are stuck with)
  • Use a "locust" unit type where we abuse glitches in the Warcraft III game to make a unit object walk from one point to another while its height is changed dynamically by a periodic timer (yes, this means our "missile" is something that holds state that will affect performance for data such as "Is a Building" or "Mana" or "Structures Built" or "Hit Points" or "Collision Side" or "Movement Type" or a whole host of other things that have no business in the structure being used to store a fireball art)

No designer ever originally thought this was a good way to design custom games for 17 years. These systems are inventions of necessity that arose out of the limits on the Warcraft III game. I have been modding this game for almost two decades and you could come up with a simple task for me to do in the World Editor that I still could not do in some cases. If you wanted to make an ability that can only target units who are buffed by Roar, and otherwise it does not let you click the unit and says, "That unit is not affected by Roar" as a yellow error message, this would be incredibly difficult to do and would require you to produce simulated error text that would clash with the in-game error messages, or be on top of the in-game error messages. There are just certain things in Warcraft III that cannot be done and there is nothing convenient that we can do about it other than reinvent or begging someone on staff at Blizzard to add new modding APIs, but since we do not wish to stop modding the game, it is likely that the begging would never end, and this is not healthy for both parties in most cases.

So, one of my plans on Warsmash to solve these sorts of problems is to hopefully allow the scripting APIs to define new ability behaviors corresponding to the SLK code column with an open-ended API that Warcraft III does not offer. There are so many ideas similar to this that become possible in a "mod anything" world, even if I do not have those ideas fully implemented yet.

To me Warsmash encompasses this entire design goal, but doing everything is impossible, so for starters what I decided is that in order to even attempt any of these ideas, first I need to have the source code of a working replica of the game component (what we can refer to as the "mod engine") that would be the building block and the testing ground where I could attempt to implement these kinds of ideas for additional knobs to make the game more moddable. For the sake of simplifying the scope, I decided on attempting to make an open source emulation of Patch 1.22 (with some basic widescreen support so that I can keep my sanity) so that I have a well-defined scope.
 
Last edited:
Level 13
Joined
Oct 18, 2013
Messages
690
If you wanted to make an ability that can only target units who are buffed by Roar, and otherwise it does not let you click the unit and says, "That unit is not affected by Roar" as a yellow error message, this would be incredibly difficult to do and would require you to produce simulated error text that would clash with the in-game error messages, or be on top of the in-game error messages.
The nice thing about memory hack is that you could directly call internal functions, like the one for error text. Such functionality still constricted you to the limitations of the engine itself, but you were free to use parts of the engine not exposed to natives that we had.
Doing things like adding symbols to the gold and lumber bars worked fine, but caused a lot of unexpected behavior like selection circles for your units turning to black. Is providing some kind of transpiler into the code that your engine would run maps on in the works for the future?

edit: ignore that last bit, just checked out your other threads. real question is memoryhack support WHEN
 
Last edited:
memoryhack support WHEN
If we look at my 2016 post here, Warsmash was basically invented to solve and eliminate memory hack. That's what is so great about having it as Java code; it becomes much harder or impossible to do memory hack (in return for having slightly slower performance).

No reasonable developer would want memory hack once you have the alternative of doing sourcecode modifications. Memory hacking does not seem to me to be a reasonably efficient way to do modding.

Edit: The whole point of a memory hack is based on wanting to encapsulate machine code into map files. If that is the working philosophy, then we might as well have each map be an EXE to maximize clarity of design. However, historically that was not done because the memory hacking map designers wanted to leverage the Battle.net distribution system to distribute their EXE-equivalent machine code containers to players. Warsmash by its nature is not going to be able to connect to Battle.net, so none of these ways of thinking are the same. Memory hacking is based on the philosophy of map developers losing control of the codebase. But the Warsmash source is on GitHub, so no one should lose control of it.
 
Last edited:
Level 13
Joined
Oct 18, 2013
Messages
690
Lol sorry, I should've put an /s at the end of that line. Yeah when you can edit the source MemoryHack is a meme.
 
Status
Not open for further replies.
Top