[This article is also available in German]

Summary

Conflict Nexus is a companion app for Warmachine/Hordes MK3, designed primarily for players who miss the functionality of the War Room 2 app. It is currently in the beta phase.

Click here to access Conflict Nexus

The following article explains how Conflict Nexus came to be.

What is Conflict Nexus?

Conflict Nexus is a web application for Warmachine/Hordes MK3.

At its core, it combines two major features: a ist builder for creating legal army lists and a Go to War mode for tracking damage, status effects, and other game information during play.

In addition, every model includes a direct link to the Warmachine University Archive, making the extensive strategy tips and rules references from the wiki just a single click away.

Background

When MK4 was released, many players in our gaming group were genuinely disappointed. Some had only recently bought or expanded their armies, while others were frustrated that the front- and back-arc markings they had painstakingly painted onto their models had suddenly become obsolete. On top of that came the widespread criticism of the new unit movement rules. Another player found that his collection could not be fielded under the MK4 rules in the way he had hoped.

Over time, those feelings have softened somewhat. A few players now also enjoy MK4, although mostly in the Unlimited format. I have also purchased a handful of MK4 miniatures that I simply liked.

That said, the majority of our group still prefers to play MK3—and that has not changed.

Unfortunately, continuing to play MK3 has become increasingly difficult. With the release of Google’s new SDK, the discontinuation of the War Room 2 app was announced for the following summer (late August 2024, if I remember correctly), and the app was subsequently removed from both app stores.

Even if you still have the Android APK, the app is effectively unusable. It installs and launches, but immediately attempts to connect to a server that no longer exists. I invested a considerable amount of time trying to get it working again, but ultimately without success.

As a result, the number of players who still had a functioning installation of War Room 2 steadily declined. Purchasing a new phone almost always meant losing access to the app.

I knew this problem would only become worse over time.

I originally had War Room 2 installed on three different devices. One was a company phone that has since been replaced. Another is an old phone that barely boots anymore. Only my tablet still runs the application today.

In short, I have spent roughly the past two years thinking about how a true replacement for War Room 2 could be created. In autumn 2024, I commenced the work. The actual coding, however, did not really start before winter 2025/26.

The first Foundation: Conflict Chamber

War Room 2 essentially provides two core functions: building army lists while enforcing the game’s list-building rules and supporting players during a game by tracking damage and other game information. In both cases, players can also look up each model’s statistics and abilities.

For army list construction alone, there used to be Conflict Chamber. This browser-based application was available online until around 2021, when it was taken offline. As I understand it, the developer felt that the project was no longer receiving enough support from the community.

I knew that Conflict Chamber already implemented much of the list-building functionality I needed, although it probably did not include the final MK3 rules updates. I therefore started researching online until I was able to locate its original developer. After reaching out to him, he very kindly made the old Conflict Chamber source code publicly available again at my request.

The Second Foundation: Warmachine University

For some time, I had already maintained a complete HTML archive of Warmachine University, giving me access to all of its content, albeit in an unstructured format.

A colleague of mine who works as a data scientist was kind enough to write a script that extracted all of the relevant information from Warmachine University. This was during the summer of 2025, when AI-assisted coding was still considerably less capable than it is today.

At that point, I finally had access to a comprehensive set of model data.

The Hard Part: Cleaning Up the Data

Unfortunately, Conflict Nexus could not simply be built from those two sources alone.

Both contained inconsistencies, omissions, and structural problems that had to be corrected before the data could be used reliably.

1. Inconsistent Data Structures

The weapon data, in particular, was inconsistent.

Some model pages contained well-structured tables, such as the Defiled Archon…

…while others stored weapon information only as plain text, such as the Satyxis Raiders:

As a result, automated scripts often failed to extract the information correctly – or missed it entirely. Even after making the parser more flexible, I had to assume that roughly every second entry still contained some kind of error.

In the end, I manually reviewed more than 2,000 weapon entries, a task that required many late nights.

2. Units and Attachments Mixed Together

The Satyxis Raiders page’s screenshot (as per above) illustrates another issue well.

Instead of containing only the unit itself, it also includes the data for its Command Attachment, the Sea Witch. For Conflict Nexus, however, those entries had to be separated.

I therefore created individual records for every attachment using the official stat cards, assisted by artificial intelligence. Conversely, AI helped identify attachment-specific information that had been embedded in the base unit entries, allowing me to remove it.

A similar problem exists for cavalry models, which have both mounted and dismounted profiles, as well as for Warcaster Units. Those entries had to be compiled manually.

3. Damage Grids and Spirals

Warmachine University only stores the total number of damage boxes for Warjacks and Warbeasts.

For Conflict Nexus, however, I needed the complete damage layouts: the individual damage columns and systems for Warjacks (left side, right side, Cortex, and so on) as well as the damage spiral and aspects (Mind, Spirit, and Body) for Warbeasts.

Here again, AI helped with the initial extraction, but every entry still had to be reviewed manually because the results contained too many errors to trust without verification. This was even true when using vision tolls – just the token consumption went up.

4. Animi

The Animi of Warbeasts were missing entirely.

The original extraction script had only searched for spells because my colleague had not realized that Animi needed to be treated separately. Fortunately, I was able to use AI to write another script that extracted this missing information.

5. The Little Things

Many of the common aliases (such as Haley2) were missing from Warmachine University and had to be added manually. The Objective rules were simple enough that I entered them by hand.

6. Army List Rules

As described earlier, the code from Conflict Chamber provided an excellent foundation—but it was not perfect.

For one thing, many point costs were outdated and had to be imported from Warmachine University. In addition, some list-building rules were implemented incorrectly, overly complicated, or had been imported incorrectly (as described later). In particular this wrong import required a lot of manual adjustments. The Partisan rules also required a number of corrections and additions.

As a result, I reviewed the list-building rules for every Theme Force individually, comparing them against War Room 2.

Whenever I found discrepancies, they could often—but not always—be resolved immediately. However, War Room 2 itself also contains mistakes. For example, Madelyn is a legal Mercenary option for Crucible Guard, yet War Room 2 does not allow her to be selected.

Overall, this part of the project required a tremendous amount of painstaking work.

7. Duplicate Model Entries

Conflict Chamber’s list-building engine does not distinguish between multiple appearances of the same model.

For example, Toro can be fielded in both Crucible Guard and Mercenary armies. Conflict Chamber solves this by creating multiple separate Toro entries.

That approach was unsuitable for Conflict Nexus.

Conflict Nexus stores each model only once, together with all of its rules, statistics, weapons, and abilities. This avoids maintaining multiple identical data sets—and having to correct the same information in several places whenever a change is needed.

Some models appeared even more often. Nemo4 for example, existed three separate times.

8. Text Formatting

For reasons I never fully understood, many of the text blocks imported from Warmachine University were poorly formatted. Missing spaces, inconsistent line breaks, and similar issues were common.

Fortunately, AI proved very effective at cleaning up these texts.

Conflict Nexus analyzes these descriptions for keywords and automatically identifies many common abilities—for example Pathfinder—which are then displayed as icons.

For the time being, I consider this approach sufficiently reliable, although it is admittedly still somewhat prone to errors.

Technical Implementation (Tech Stack) At the beginning of the project, I looked for a software developer to build Conflict Nexus. The first developer I found struggled to become familiar with the game and its rules. After roughly six months, he also became a father, which understandably meant he was no longer available for the project. After several attempts—including some reasonably successful experiments using AI-assisted coding with ChatGPT Codex—I eventually found a second developer, a Ph.D. student in computer science, who genuinely enjoyed the project and ultimately handled most of the implementation. In comparison to Conflict Chamber, whose source code was written in TypeScript and PHP, Conflict Nexus is developed entirely in TypeScript. The code has been completely rewritten from scratch. Some Conflict Chambers files are adopted unchanged but only certain information is extracted from them; the old code itself is not used as such. All third-party components used by the project are open source. The user interface is built with React and developed using Vite. React allows the interface to update immediately whenever the user interacts with it—for example, when selecting a different model. During development, Vite greatly accelerated the development workflow through its fast build and hot-reload capabilities. For production, it generates the optimized files that make up the web application. The application’s visual design is implemented with Tailwind CSS. TanStack Router and TanStack Query ensure that users always see the correct page while efficiently retrieving and caching the required data. Behind the user interface is a PostgreSQL database. PostgreSQL was a good fit for Conflict Nexus because of its flexibility and native support structured JSON files (as used for damage grids, status effects and save games) besides spreadsheets. An API processes user requests—as well as other requests generated by the user interface—and retrieves the required information from the database. Before any request reaches the application logic, it is validated using Zod , ensuring that it is complete and follows the expected structure. Since Zod integrates seamlessly with TypeScript, it was a natural choice for the project. To identify the currently logged-in user, the application uses short-lived Access-JWTs. These are renewed on the server through refresh tokens. For database access, the API uses Prisma an Object-Relational Mapper (ORM) designed with TrueScript in mind. Together with Express and PostgreSQL, it forms a well-established technology stack that was a natural fit for this project. The database stores both the static game data—such as model statistics—and user-generated content, including army lists, saved game states, and user accounts. The army list rules themselves are implemented entirely in TypeScript. They define what is legal during army construction—for example, whether a Cygnar army may include a Firefly. Parts of this implementation are based on the original Conflict Chamber code, although they have been extensively modified in a second step. The model data—including stat blocks, spells, weapon profiles, and similar information—was assembled from the sources described earlier. As a result, the project relies on a combination of manually created CSV files and data extracted from Warmachine University. Separating the game data from the rules engine offers an important advantage: the same rules can be used both by the server and by the browser, meaning they only need to be maintained in a single place. All of this information is imported into the database through a series of seed scripts. During development, however, another challenge emerged. Rules—particularly those governing army construction—were sometimes imported in the wrong order (in particular rules from Conflict Chamber). Finding and correcting these issues required a great deal of careful debugging. Overall, the data flow looks roughly like this: CSV files → Seed scripts → PostgreSQL → Translation layer → Army List Rules Engine → API → User Interface When a player creates an army list, the process works as follows: The application loads the model data from the database and passes it to the rules engine. Based on the selected faction, Theme Force, and any models that have already been chosen, the engine determines which additional models are legal and what their point costs are. The user interface then presents those options to the player. The Go to War feature is considerably simpler. It displays the completed army list and writes only gameplay changes—such as damage taken or status effects—back to the database as part of the saved game state.

Current Status

The current public release is labeled a beta version because, despite extensive testing, I fully expect that some bugs still remain.

In particular, I suspect that the data extracted from Warmachine University may still contain occasional inaccuracies. I hope that users of Conflict Nexus will help identify and report these issues so they can be corrected over time.

The following features are also planned for future releases (probably late summer 2026):

1. Downloading army lists for easy sharing with other players.
2. Viewing an opponent’s cards and game state, including damage and status effects.
3. Adding models that enter play during the game, such as those created by the Opening the Gate ability.
4. Support for Brawlmachine as an alternative rules format.
5. Support for multi-Warcaster lists in blended Theme Forces, such as Strange Bedfellows. This is currently not yet possible.

I will continue to update this article as new features are added.

Acknowledgments

I would like to thank Juckto for creating and maintaining Warmachine University, and especially David Bingham Brown, Ph.D., for developing Conflict Chamber and for kindly making its source code available again. Conflict Nexus builds upon his work, and without his generosity, this project would have been considerably more difficult to realize.

I am equally grateful to Cameron Simoleit, who implemented the majority of the software and continues to contribute to the project.