Super Mario War is a decade-old fork that outlived its original maintainer

A fangame with three authors and two decades of history

Super Mario War is a fan-made multiplayer Super Mario Bros. style deathmatch game in which players try to beat one another in a variety of gameplay modes. You can play on teams, design your own levels, design your own worlds, and much more. The homepage is smwstuff.net, the primary language is C++, and the last push was on 2026-10-20.

The history section of the README is longer than most, and it explains the current shape of the project. The original Mario War was created by Samuele Poletto in 2002, in which four Super Mario characters could fight on various levels by jumping on each other's head. It was written in Pascal and Assembly and released for DOS. Later versions also included a map editor.

In 2004, Florian Hufsky, founder of the 72dpiarmy forum, started an open source rewrite which became Super Mario War. That version introduced custom characters, additional gameplay modes and map mechanics, items and powerups. User content was stored on what was then smwstuff.com, with thousands of maps and skins available, and the open source nature carried the game to a lot of desktop and console systems.

At the end of 2009 Florian died, development slowed and eventually stopped, and SMW 1.8 beta 2 became the last official release. The README also records that smwstuff.com and its contents were lost to technical issues, with partial backups from uploaders remaining on the forum.

So the current repository is a fork started around 2014 with the initial goal of network multiplayer support that would work cross-platform between different devices. The same author also wanted to gather the scattered forum content in one place again, which became smwstuff.net.

That is why the game exists in this form, and it explains the tone of the README more accurately than any feature list would.

Why the online mode is described as far from perfect

The README is direct about the part of the project that people ask about. The network multiplayer was eventually made to work, but it is far from perfect. With good conditions, on local networks it may work fine, but subtle bugs and lag usually makes the gameplay over the internet far from optimal.

Then the explanation of why. The quality and structure of the original source code makes effective work impossible: most source files were in the around 10000 lines category, with 1000 plus line functions being common, most of them modifying global variables, and there was even an if-else with a hundred branches.

That is a fair diagnosis, and it is the kind of thing you normally only learn by reading the code yourself. A function that is a thousand lines long, mutating globals, cannot be reasoned about when the behaviour depends on timing, and network play is a behaviour that depends on timing.

The author's conclusion is that a proper implementation would likely require a redesign of several core parts of the game and another several hundred cleanup and refactoring patches to make the code maintainable. His own judgement is that in the long term a complete rewrite might be faster and more effective than patching the original game for years.

And there is the other constraint he names: with this kind of project there is also a chance that next morning you get a cease and desist letter from whatever company.

For me, this was the point where I stopped putting more time on this project, in 2016. He then says he hopes to have left the project in a better state than it was and that it will be of use to future developers.

Read as an engineering document, the README is a warning about how much of the remaining work is structural rather than incremental.

The 2026 revival, and what changed since 1.8

The README has a 2026 update, and it changes the picture from a project that was parked.

It looks like the author ended up working on it some more. While keeping the game alive, there has been significant effort to modernize the codebase and try to make it maintainable. There have been some performance improvements, stability fixes, an SDL3 port, and the game continues to support newer operating systems. The update also points to Super Cat Wars, described as a complete overhaul mod with its own graphics, maps and worlds.

The list of main changes since 1.8 gives the long view.

An experimental online mode, including an online lobby server. Lots and lots and lots of bugfixes, with the README saying seriously, there is at least 200. Added Web, ARM and an experimental Android port, and improved support for Windows, Linux and OSX. Improved music and sound quality. Ported all parts of the game to SDL2, for hardware accelerated drawing and improved support for many platforms. And a major cleanup of the source code and the build system.

The release tags match that story. There is a 2026-05 release, a 2026-04-01 release labelled the 2026 April's Fools Release, and a tag for the old 2025 releases. Older Mario War and SMW releases are kept under a separate tag in the same repository.

So the picture is a project that was dormant for a decade and then restarted, with the cleanup work landing alongside the SDL2 port and the SDL3 work.

The supported platform list is unchanged in spirit from the classic era. Linux, Windows, Mac OS X, ARM devices such as Raspberry Pi, XBox with a question mark in the README, Android as experimental, and asm.js as experimental.

The build requirements, and SDL 3 versus the sdl2 branch

The requirements list is short and modern. A C++20 supporting compiler. CMake. SDL 3, with SDL_image and SDL_mixer. zlib. toml11. And ENet, marked optional, which is the networking library the online mode uses.

There is one line that saves people an afternoon. In case you still want to use SDL 2, consider building the sdl2 branch. So the current tree targets SDL 3 and there is a maintained branch for people stuck on SDL 2, which matters because the SDL 2 to SDL 3 transition is where most of the porting work sits.

The dependencies can be installed with a package manager, and the README gives one line per distribution family.

apt install cmake libsdl3-dev libsdl3-image-dev libsdl3-mixer-dev zlib1g-dev libtoml11-dev libenet-dev

That is the Debian based line. The Fedora and RPM equivalent is in the README too.

yum install cmake SDL3-devel SDL3_image-devel SDL3_mixer-devel zlib-devel toml11-devel enet-devel

The Arch line is there as well, though the README text is cut off in the version available here, so it is worth reading the current file rather than relying on a copy.

The repository layout tells you what to expect from the build. There is a CMakeLists.txt at the top level, a cmake/ directory for the build logic, src/ for the game, data/, resources/ and dependencies/ for assets and vendored code, a .gitmodules file, a .clang-format file for the coding style, a CHANGELOG, a CREDITS file and a tests/ directory alongside a testmaps.zip fixture.

The modes, the editors, and the thousand maps

The About section describes the game loop plainly. Super Mario War is a Super Mario multiplayer game, and the goal is to stomp as many other Marios as possible to win. There is a range of different gameplay modes, and the list includes Capture The Flag, King of The Hill, Deathmatch, Team Deathmatch, Tournament Mode, Collect The Coins, Race, and many more.

The editors are the part that makes it more than an arena game. The game includes a level editor which lets you create your own maps from scratch, or re-create sections from your favourite Mario game. More recently included is a world editor, which strings a bunch of levels with specified conditions together to create an SMB3-like experience merged with tournament like play. That is a substantial piece of tooling and it is what turns the game into something people spend time in rather than something they finish.

The features list is written in the tone of the project, and one of its entries is that a lot of people did so with the editor: there are currently over 1000 maps. Other entries include up to four players deathmatch fun, a whole bunch of game modes featuring GetTheChicken, Domination and CTF, online and local multiplayer, the whole source code of the game being available for free, CPU players, and support for SDL making it fully portable to Windows, Linux and Mac.

One more thing worth reading carefully is the legal framing. The game uses artwork and sounds from Nintendo games, and the README says the authors hope that this noncommercial fangame qualifies as fair use work, because they wanted to create the game to show how much they adore Nintendo's characters and games. That is a stated position, not a legal conclusion, and it is the reason the project carries the risk the author mentions.

Where Super Mario War is the wrong tool

Three cases, and the first is the one the README itself concludes.

If your goal is a reliable online multiplayer game with matchmaking, this is not it. The online mode is described as experimental, the lobby server is listed among the experimental features, and the author says that subtle bugs and lag usually make gameplay over the internet far from optimal. Local play is the reliable path, and the source of the problem is architectural rather than a missing feature: the original code base has functions of a thousand lines that mutate globals, and a redesign of several core parts would be needed.

If you are looking for a maintained fork with a community behind it, the history is worth reading before you commit. The upstream project stopped when its founder died in 2009, the original content site was lost, and the current repository is one person's fork that was parked from 2016 and picked up again in 2026. The 2026 work is real, and the CHANGELOG in the repository will tell you how much, but this is one maintainer.

The third is a commercial project. The artwork and sounds are Nintendo's, the project states a noncommercial fair use position, and the author explicitly mentions the possibility of a cease and desist letter. Putting this codebase and its assets behind a paid product changes the legal question in a way that is not the project's to answer.

There is one practical trap too. The requirements ask for SDL 3 with SDL_image and SDL_mixer, and the README warns that most of the porting work in the last major push went into SDL 2 and then SDL 3. Building on the wrong branch, or mixing SDL 2 headers with SDL 3 expectations, produces link errors that point at the wrong place.

Licence, and what the repository does not say

One point needs care, and it is the licence. The repository metadata does not record a licence for this project, so there is no named licence you can point to in a distribution or a fork.

What the README does state is the fair use position, that the game uses artwork and sounds from Nintendo games and that the authors hope the noncommercial fangame qualifies as fair use work. That is an argument the authors make about their own use, not a grant of rights from the copyright holder, and the same README contains the author's own reminder about cease and desist letters.

So if you are evaluating this for anything beyond playing it, the licence question is unresolved rather than permissive, and that is a fact about the repository rather than a judgement about the project.

The credits are handled in a separate CREDITS file at the top level, which matters for a game that incorporates assets and contributions from a long history of contributors.

On maintenance, the picture is the one the release tags describe. A 2026-05 release, a 2026-04-01 April's Fools release, a 2026-10-20 last push, and a decade of near dormancy in between. The CHANGELOG and the CREDITS file are the two documents to read before you touch anything, because both a fork and a vendored copy carry obligations that the README does not spell out.

Editorial conclusion

Adopt Super Mario War if you want to play or mod a four player Mario deathmatch, and you are content with a local session being the reliable one. Do not adopt it as the base for an online multiplayer product, because the README says the network mode is far from perfect and that lag and subtle bugs make internet play suboptimal. Verify first which SDL version your build expects, since the current tree targets SDL 3 with an sdl2 branch for older setups, and read the CHANGELOG before you start, because the 2026 work modernised the codebase and changed the build requirements.

Frequently asked questions

Official sources

1. Issues
2. mmatyas/supermariowar on GitHub
3. Project website
4. README
5. Releases