Gamedev Knitting #1

Welcome to Gamedev Knitting! This is a newsletter in which I talk about crafting games.

It's quite a big change from the previous newsletter style. If you want to know more, I talk about it more on this post.

A MUGEN Challenger Approaches

I like fighting games, even if my reflexes are only good enough to play Chess with a 10 minute timer. That doesn't mean I'm not interested in developing fighting games, though. Two mechanics that comes to mind that are trivial anywhere else but fighting games:

Player input handling. In a Game Jam, you're mostly worried about the state of keys per-frame ("is the right key being pressed?"). In fighting games, there are different states a character can be depending on a sequence of inputs in time (so you know when the user made a ⬇️↘️➡️🅰️ sequence for a Hadouken, for example).
Collision box and physics. Normally you'd only care for a single collision box per entity in your game. Fighting games require at least a hit-box (the areas your character can hit the opponent) and a hurt-box (the areas where your character can be hit), and those are set per-frame of character animation. Other fighting games might use even more collision boxes, such as a push-box (where your character body is, so that other characters are pushed away from its center instead of solving a collision intersection instantaneously). A good example is this article about fighting games collision boxes (and what Street Fighter V uses).

And between a hardcore-niche of players of the fighting genre and the challenge of making fighting games, you would expect many tools for game developers to tackle the challenges of this niche - and some of them do exist. But there was one Game Engine created in 1999 that had a lasting impact on the indie fighting scene, to the extent that a community still exists and spiritual successors are still in development, even when the Game Engine is no longer being maintained. And funny thing is, most players don't even know the game they are playing is a Game Engine in the first place.

I'm talking about MUGEN.

A very tame MUGEN Screenshot. Source: GamesDB

What the hell is MUGEN anyway?

MUGEN, or M.U.G.E.N. (stylized, it is not an acronym but the word "Mugen" means infinite in Japanese), is a Game Engine for Fighting Games and nothing else. It doesn't have an Editor, but it does provide you with an executable - that of the game itself. That means that the line that separates a game developer from players is very thin with MUGEN; what the players see when opening the game folder is exactly the same thing the game developer will edit, from characters to stages and menus. You can consider MUGEN either a very genre-strict Game Engine, or a very easy to modify fighting game, and both definitions are fine - you can still do a lot with MUGEN, as long as you understand how it works.

The history behind the development of MUGEN is a bit convoluted. It started as a MS-DOS Game Engine made by an anonymous group of developers called Elecbyte, and the Game Engine had more than a few hiccups during development, including the release of a hacked version of MUGEN which made developers drop out of the project. If you're interested, you can learn more about the story behind MUGEN on this article.

What made MUGEN specially attractive was the fact that characters and stages were "standalone" packages - the idea was that you could easily add a new character to your MUGEN by copy-pasting a folder and editing a single file with the name of the added character. Many bootleg characters were created, and especially in Latin America during the 2000s, back when copyright laws were copyright suggestions.

A MUGEN version of a bootleg Naruto Fight Game. Source: Internet Archive

MUGEN is, unfortunately, quite deprecated - the Game Engine stopped development at a beta 1.1 version in 2013, and it only supported Windows machines. Still, there are many development groups on the internet, and you can find many characters and stages being developed still.

A Modern MUGEN substitute

License model Open Source Programming languages Go Lua

Features

Publishing platforms Windows Mac Linux

If you want to test MUGEN and are worried about making it run on your machine, now it might be the perfect time to do so. IKEMEN is a modern MUGEN alternative written in Go, with support for Mac, Linux and Windows; and it recently reached its v1.0.0 stable version!

That means you can reuse many of the resources that already exists for MUGEN (characters, stages), plus additional features such as:

Network Play with rollback (supercombo had a great interview about Rollback connection in IKEMEN back in 2023, worth taking a look).
LUA Scripting for things such as Game Modes and different screens.
Support for 3D models (in Stages and interfaces).
Many quality-of-life features for character data (the file you write to create new characters).

And many other things that add up to customize your game even more, on top of what MUGEN already allows. And unlike MUGEN, IKEMEN has a permissive license, which means you can customize the Engine even further for your own needs if you want to venture into GoLang.

Materials and Photorealism

Two great articles this week about graphics that I liked quite a lot because I actually understood them.

First one is What in the Graphics is Volumetric Rendering?!, a good introduction on volumetric rendering with low amount of math and a good ratio of pretty pictures.

The second one is Anatomy of a Texture, and it goes a bit more technical about how game textures work in a GPU. It is not a hard topic per-se, but the tradeoffs of storing a texture in the GPU has many wrinkles, and it is important to understand what those tradeoffs are if you are interested in computer graphics.

Generating high-quality Textures

One of the ways of producing a high-quality texture is by the use of Photogrammetry.

According to ever-reliable Wikipedia, photogrammetry is "the science and technology of making reliable measurements and creating 3D models from overlapping two-dimensional photographs."

Basically: a bunch of 2D photos go in, a realistic 3D model goes out.

Specially in the AAA world, Photogrammetry is used quite a lot to generate the mesh of important objects in the game world, realistic-looking materials, and scanning feet to use as a reference in-game. But nowadays, Photogrammetry is much more accessible thanks to the high-quality cameras most developers have access to through their phones. Two major options you have:

Use RealityScan app. This is a software from Epic that makes it quite easy to create 3D mesh from photos, specially from small objects you can move around using your phone (the process of scanning is you moving around the object taking photos, and the phone estimating the distance from the object). It is not done locally though - the photos you take are sent to a server which will create the mesh for you, so maybe avoid scanning too much feet.
Use the free and open-source MeshRoom locally. It does require a more powerful PC, but it shouldn't take too long to create a decent-looking mesh locally. It might need more tweaking, though.

Those two options require a bit of a setup - you need to take multiple photos from different angles, and the more (and better quality) photos, the better. A third option I used for my last gamejam game was to use a faux-photogrammetry: instead of taking many photos, because I was by myself and I wanted to include my own leg in the game, I took a single photo from the side, and with a bit of transformer magic running on my own computer, I could generate a good-enough mesh that I could tweak on Blender for the game.

Source: me, that's my leg.

It was a weird process but quite fun, and with the advantage of running on my own machine (no leg photos for Epic). If you want to know more about it, I wrote more about it here.

Gamedev and the Contagion of Fear

Not directly related to gamedev, but I'm assuming you 🫵 are also aware of the many things going on in the AI world.

I made a decision to consciously gravitate this newsletter towards the things that really interest me (crafting games), but I don't want to be completely oblivious to discourses that surround technology in general, specially when it has such a huge impact in how we live day by day, and by extent to gamedev.

One of the most impactful pieces about AI and gamedev last week was It Breaks a Village: Bevy's 6th Birthday, on how AI usage is affecting the Bevy community. Some newsletters ago, during Bevy sixth birthday announcement, I wrote about the new AI policy Bevy was drafting, so it's important to note the early results in the Bevy community of that new policy, even if they are not looking inspiring.

And I know how insane it feels to live in a timeline where every now and then, someone from a big AI lab quits saying "Humanity is probably going extinct". But if you want to read something sober, though, I recommend reading The contagion of fear. If anything, it was an article that made me take some steps back from all the news and unhinged statements every Very Important Nerd ™️ said about AI, and how fear plays out in how we are hearing those news in the first place. To quote the article: "We should heed the wisdom of the late Carl Sagan that extraordinary claims require extraordinary evidence: the claims from Coxon and his ilk are the most extraordinary a technologist can make, and we must demand evidence commensurate with the claims."

Also from Engines Database Aggregator

Designing Dispatch Queue. This is an API breakdown of an asynchronous task dispatcher library for C++, using C++11 threading primitives, C++20 coroutines API, and even compatible with Emscripten for web builds. Really interesting API tradeoffs, specially comparing with how easy it is to use Unity's Job System and async/await in the C# world.
Some things Veloren does differently. Those are some of the "tech highlights" of Veloren, the Valheim of open-source minecrafts (game is awesome but I really have no idea how to describe it, you should totally check it yourself though).
Building Hexagon Sphere Using Animal Crossing-Inspired Trick. A nice interview by 80.lv with UNSUNG developers on their game "Tile Crawl". A cool reminder how every cool graphics we do is smokes and mirrors.
NES dumping over audio. An insane development story about digitalizing NES cartridges using Audio, because why the hell not.

Remember to comment and vote on new entries for the next Newsletter! And if you want to submit a link so I can talk about it here, consider becoming a supporter!

Game Engine News:

Git Activity:

Missed something?

If you have any suggestions, send me feedback on Mastodon, drop an email at henriquelalves@enginesdatabase.com, or just comment below! And if you want to add a new game engine to the website, consider suggesting a new Game Engine.

Gamedev Knitting #1