Tool Reviewer
Level 27
Apr 19, 2008
This thread is a place for Warsmash developers to post notes on their updates and progress in maintaining and improving the engine code of Warsmash.

Current progress history:
  • Project ideation began 12/02/2018 fall. I had practiced in the spring with the HiveWE source to do unit animations in a rendered War3 style game map preview. I created a web document describing my visions and goals:
    • Use Hive's "View in 3D" viewer code as a basis for rendering units
    • Use HiveWE terrain code as a basis for rendering map terrain
    • Copy game engine unit logic from my previous attempt at making a strategy game where possible
    • Create a Jass parser using ANTLR
    • Create an FDF parser using ANTLR
    • Use @DrSuperGood 's MPQ parser
    • Use HiveWE's ShadowMap.cpp as a basis for parsing .shd files

  • Each Map File will be an MPQ archive parsed by Dr Super Good’s Java MPQ parser
    • There will be a terrain data file with the extension “.w3e” that will contain a grid of map terrain information, loaded with a Java transcription of “Terrain.cpp” from HiveWE (a “w3e” parser)
    • There will be a terrain shadow map file with the extension “shd” that will contain a grid of shadow information. This can be made from either a transcription of “ShadowMap.cpp” from HiveWE, or “ShadowMap.java” from OgerLord’s open source WcDataLibrary
    • There will be basic Game Object Data information stored in a series of SLK tables, for which I already have Java code to parse, available in my “JWC3” code workspace, using my own SLK parser implementation. These files will be specific to the Game Application, and should not be included in Map Files
    • There will be Game Object Data Changesets stored in class-specific binary changeset files. These files will be used in Map Files to describe which Game Objects have been modified. For these, I already have transcribed code from PitzerMike’s C++ Game Object Data Changeset parser.
    • There will be a class of object that is immutable at runtime and baked into the terrain called Doodad that will serve as a 3-dimensional decal. These will be stored in “.doo” files which will specify Doodad type and location. Doodad type will be an “integer” variable referencing an entry in the list of possible Doodads, which will be described by Game Object Data
    • There will be a class of object that is mutable at runtime, and can be destroyed or removed, called Destructable. These will also be included in the “.doo” file, for simplicity, but will have an integer key referencing a different hashtable of unit data information.
    • The combined pathing map of the Doodads and Terrain Tiles and decals will be generated by the Map Editor and saved in a “.wpm” file, which will be a binary definition of pathing map information. This can be parsed with a transcription of the “PathingMap.cpp” file from HiveWE
    • ANTLR will be used to generate Java-based parsers for the JASS syntax, and then user created JASS code will be present in maps. The parser from “wc3libs” for this can probably be used (see “Jass.g4”), in conjunction with the prototype written by Retera used to illustrate that code arrays can be safely added in the Java Virtual Machine with a custom interpreter for the JASS language.
  • TGA Targa image files will be loaded using OgerLord’s “TgaFile.java” open source code
  • BLP image files will be loaded using “blp-iio-plugin”, an open source BLP ImageIO parsing plugin for Java
  • ANTLR will be used to generate Java-based parsers for Frame Definition files to build the User Interface for the Game Application. An open source Java repository named “wc3libs” claims to have an FDF parser, but they seem to only support a small subset of the specification, for parsing constant definitions. This will be improved so that we can parse the entire UI definitions for the Game Application
  • Rendering models will used a transcription of “mdx-m3-viewer” from JavaScript to Java. I already have a working transcription of this code in “JWC3” however it was written hastily and with bad performance. For this project, we want to try to support as many units in the game at a time as possible, so we will need to transcribe the instanced rendering methodology from “mdx-m3-viewer” as well as the logic.
  • Methodology must be added for selecting units and issuing them commands. Units can be given commands with a target, and will have one active command at a time. The specific behaviors of the commands will be defined as hard-coded behaviors for the various entries in “Units\AbilityData.slk”, although multiple entries can use the same behavior by way of the “code” column, which will be a hashtable entry.
    • For this logic, I will borrow an adaptation of the command system used in my own turn-based strategy game, modified so that it utilizes lock step per frame instead of per turn. Any player will be allowed to command any unit controlled by that player. Each behavior will have an Order ID hash value, and multiple abilities using the same behavior will not both be usable by the player -- save for the ‘ANcl’ entry, which will be allowed to specify a different Order ID hash value to use for its network traffic.
    • In the case of a unit with Order ID collisions, the first available ability will be activated when the unit is commanded by a player. If the ability is on cooldown, or the unit has insufficient mana, then the second ability with that Order ID will be used instead.
  • Players will be able to chat in multiplayer games. This feature already works in my own strategy game, so the same system can be borrowed
What is above is a summary of progress that has led to where things are at the time of writing.
As more progress gets made, we can update this thread more!


Tool Reviewer
Level 27
Apr 19, 2008
Updates for the weekend of April 11, 2021:

  • Practiced how it might work to onboard a new developer in a chill call with @Spellbound . We both redownloaded WarsmashModEngine from source and then changed our setups to load Warcraft III content from a Reforged 1.32 install. It was a good time.
  • We gave ourselves the goal of eventually making Human Build while chilling, probably in a future call. This will require first making Human Repair. In order to make repair, I chatted with Spellbound about the current API and how to configure a new Java class to extend CAbility. The goal is that the class we worked on will eventually be spawned for Abilities with code=Ahrp, although we did not do that configuration yet.
  • The chilling and chatting already left us brainstorming how we might improve the Warsmash API for implementing new builtin skills in the future. I am kind of hoping at some point the skills will all be implemented in scripts external to the engine, but for the time being I am using basic Java classes and CAbility as a Java interface.
  • Later in the weekend I posted on the Tools section download of the binary build with a sample config for running with a 1.32 installation.
  • In accordance with that post, I updated the main branch of the public repo with a few changes to improve 1.32 compatibility when browing Campaign menus. However, the Warsmash engine still is not capable of launching maps created with the 1.32 map editor, so clicking the maps on the Campaign menu does not play them when using a 1.32 installation as a source of Warcraft III game data because Warsmash while crash during map loading.

All in all, I would say this weekend was a bit of a vacation as far as Warsmash development goes (aren't they all).
Last weekend I was trying to implement some JASS natives for the APIs such as Timers and Regions. Back then I wrote a lot of untested code and I was hoping to build out Jass support and then test it "all at once" with systems testing. But I am not at that testing phase. That will probably be for a future weekend. The goal here would be to have a stable building block that can easily support the "config" function in JASS so that map configurations can be better supported.

(I do not get much done during the week. I have a job! So, 'til next week, folks!)
Last edited: