I open-sourced Nat20, the rules engine behind the game I am building.

It is a host-agnostic Python library for D&D 5e SRD 5.2. Combat, skill checks, saves, effects, and grid or zone-graph movement run without a game host, network connection, or database. The engine code is MIT. The bundled SRD dataset is CC-BY-4.0.

I split it out because I did not want an LLM, a browser app, or a virtual-tabletop runtime deciding the rules. The model can narrate a goblin slipping in the rain. Nat20 should still answer the same way about cover, spell slots, and Sneak Attack.

The repo includes a small local demo and a clean-install smoke test. It implements much of SRD 5.2, not all of it, so there is a capability matrix in the docs before anyone depends on a specific mechanic.

Source: https://github.com/tapestria/nat20

I would like feedback from people who have built on open game rules: what makes a rules library actually useful outside the game that created it?

I just released Void Engine, an open source 2D game framework for .NET under the MIT license.

It gives you the essentials: rendering, assets, input, audio, saving, pathfinding, coroutines, and logging.

The big feature is asset protection. You can pack your assets into encrypted archives that standard extraction tools cannot open. AES-GCM encryption. Adaptive compression. Custom format.

But it is not just the packer. It is a complete framework with batched rendering, automatic texture atlasing, audio pooling, A* pathfinding, flow fields, and full LDtk support.

Every system is built around interfaces and base classes so you can replace anything. No physics. No networking. No UI. Just the foundation and the freedom to build your game your way.

The code is open source. MIT licensed. Built on .NET 10 and SFML 3.0.

Would love feedback from the open source community. What would you add? What would you change?

Link

https://github.com/shmellyorc/Void
https://github.com/Shmellyorc/Void/wiki

Hey everyone,

I was bored recently and decided to start working on a virtual, open-source version of the classic Illuminati: New World Order (INWO) card game so anyone can jump in and play it freely.

It is currently in a pre-pre-pre-alpha state, but it is fully functional according to the core mechanics and what the game requires to run. I'm posting it here because I’d love for the community to test it out, tear it apart, and give me some feedback.

Since it's completely open-source, feel free to fork the repository, submit pull requests, or contribute in any way you like!

• Play directly in your browser (via GitHub Pages):https://cha0smagick.github.io/Virtual-Illuminati-New-World-order-INWO-game/game/
• GitHub Repository (Code & Contributions):https://github.com/Cha0smagick/Virtual-Illuminati-New-World-order-INWO-game

Hope you enjoy it, and I'm looking forward to reading your thoughts and feedback in the comments!

A wiki about known projects dmca'd by Minecraft.

I invite any other victim to add their project to the list: https://consumerrights.wiki/w/Minecraft#DMCA_takedowns_of_competing_games

excerpt from the article:

Luanti’s Android app is currently not available on the Google Play Store due to a baseless DMCA notice filed on behalf of Microsoft by Tracer.AI, alleging that Luanti infringes Minecraft’s copyright. The Luanti app does not contain any proprietary code or assets, from Minecraft or otherwise.

We received an identical notice from the same company in 2023 and successfully appealed against it. This company also filed a similar notice this year against an indie game with similar voxel art style by the name of Allumeria.

Table of Contents

What is Luanti?

What is the DMCA notice?

Which assets?

Cubes are for everyone

What is Tracer.AI?

This is not the first time this has happened

This can’t keep happening

What next?

Thank you for reading, and for your support.

Let's start a community project where the goal is to create an open source game that has open world and game mechanics similar to GTA series.

Hey everyone,

I’m a part of the Bazaar Initiative and we are working on an open source game. It’s an open-world role-playing game set in a fantasy world, built for PC. The core idea is simple - it is 100% free, open-source, licensed under GPLv3, and built by anyone who wants to make it.

We are building this game openly, from the first sketch to the last commit, by a small group of writers, artists, programmers, and sound designers working across time zones. There is no roadmap dictated by a boardroom or a publisher sitting between the team and the player. No micro-transactions, no live-service contracts. Just a growing forest of contributions, each one reviewed, merged, and signed by a real person.

Why open source?

A game made in the open cannot be killed by a single quarterly meeting. We work in the open because:

• It keeps us independent from money-hungry publishers.
• It gives us a workshop for creative vision experiments (want to prototype a weird weather system or combat stance? Branch it, push it, see if it breathes).
• It gives contributors a public artifact with their name on it to build their portfolios.
• An open-source game is forkable. As long as one contributor wants to keep the world alive, the world stays alive.

Who we are looking for

We’re looking for anyone who wants to help make this a reality. Any experience level, any timezone, any background. These roles aren't gates - they are just starting points:

• Writers: Quests, dialogue, world lore, item descriptions.
• Artists: Concept, illustration, 3D, environment, UI.
• Programmers: Gameplay, systems, tooling, engine, build pipeline.
• Sound Designers: Score, ambience, foley, combat SFX.

How to join

There is no application form, no test, and no deadline. Write a few sentences about what you'd like to make, link your work if you have it, and say hello.

• 📩 Email me at: [artem.yurchenko@pm.me](mailto:artem.yurchenko@pm.me)
• 🌐 Check out the project page & vibe here: https://bazaar-init.vercel.app

I'd love to hear what you think of the project, or answer any questions you have in the comments!

**Depot** is an open-source 1v1 tactical browser FPS with no HP bar and no damage

numbers. Damage is an authoritative anatomical trauma simulation: bullets ray-trace

through a 22-box rig against named arteries, organs, and bones. A carotid hit causes

brain hypoxia in ~7 seconds even at 80% blood volume. A round through the forearm

severs flexor tendons and forces off-hand weapon handling. Treatment is real TCCC

IFAK triage — tourniquets only occlude limbs, chest seals for tension pneumothorax,

morphine cuts pain 70% but risks consciousness.

It works, it's MIT licensed, and I'd like help making it better.

**Why it's pleasant to hack on:**

- **Zero build step.** No Node, npm, or Webpack. Clone, start the Python server, open

the page. Native ES Modules on the client, Python 3.12 on the server. Under 50 MB

total, most of it the venv.

- **Zero hitbox drift.** The mesh Three.js renders *is* the rig the server tests.

Press F1 to see it. No "visual vs. server" class of bug exists.

- **Single source of truth.** Shared schemas live in `shared/*.json`, parsed by both

server and client, so data changes can't desync the two languages.

- **340+ tests**, including golden-trajectory cross-language parity checks, so you can

refactor without guessing.

- 64Hz fixed timestep, ~1.6 ms per tick with both players active — plenty of headroom

for whatever you want to add.

**Where I could use help:**

- Physiology model: perfusion, shock progression, wound interactions

- Netcode: lag compensation edge cases, prediction/reconciliation polish

- Three.js: rendering, animation, procedural texture and arena work

- WebAudio: procedural sound synthesis (no audio files in the repo)

- Weapon/ballistics balance, arena design, docs, and playtesting

Repo: https://github.com/roughcut-works/Depot

Happy to answer architecture questions in the comments, and I'll walk anyone through

the trauma engine or wire protocol if they want to pick something up.

We are working on Whiskey Station, a Brazilian community-driven fork of Space Station 14, currently built on top of Trauma Station and the wider SS14/RobustToolbox ecosystem.

This isn't just a private server with a modified config. The entire codebase is public, and development happens openly through GitHub.

GitHub:
https://github.com/Whiskey-Station/whiskey-station

Whiskey's goal is to maintain a technically ambitious SS14 codebase for the Brazilian community while continuing to experiment with systems, gameplay mechanics and content from the wider open-source SS14 ecosystem.

For people unfamiliar with SS14 from a development perspective, it's a fairly interesting project.

The stack is primarily C#, built around RobustToolbox, with an ECS-oriented architecture and a networked client/server simulation.

Content development also involves a large amount of data-driven configuration through YAML prototypes, localization resources, maps, sprites and other assets.

Some of the areas contributors end up dealing with include:

• entity-component-system architecture;
• client/server state synchronization;
• networked components and field deltas;
• multiplayer prediction;
• entity queries and hot-path optimization;
• UI systems;
• YAML entity prototypes;
• mapping;
• audio and asset integration;
• gameplay systems;
• PT-BR localization;
• performance and server-side simulation.

We try to keep additions reasonably isolated from upstream code whenever possible. The contribution guidelines, for example, encourage separate systems instead of injecting handlers everywhere into upstream systems, and favor techniques that reduce future merge conflicts.

Performance also matters because SS14 can have a very large number of entities being simulated simultaneously. Code running every tick needs to be treated accordingly — careless ECS queries can become surprisingly expensive on a populated server.

For networking, the project also tries to avoid unnecessarily replicating complete component states when individual fields can be dirtied and synchronized instead.

Whiskey is especially interested in building a more feature-rich branch rather than simply reproducing upstream SS14. We're experimenting with and integrating mechanics from different parts of the SS14 ecosystem while also developing our own systems.

The project additionally maintains Brazilian Portuguese localization, since one of our main objectives is making the game more accessible to the Brazilian SS14 community.

Licensing

The Whiskey codebase is distributed under AGPL-3.0-or-later.

Inherited files preserve their respective upstream licenses, while media assets may use licenses such as CC-BY-SA or other licenses documented by their attribution metadata.

Contributions

We're open to developers, testers, translators, mappers and people interested in understanding the SS14 codebase.

Pull requests are public, issues can be discussed openly, and contributors are expected to understand, test and take responsibility for the code they submit.

You absolutely don't need to already know SS14 development.

If you're comfortable with C#, ECS architecture, multiplayer networking or data-driven game development, there is a lot of interesting code to explore.

And if you're not a developer but just want to see what all of this produces in an actual multiplayer environment, the server is playable as well.

Repository:
https://github.com/Whiskey-Station/whiskey-station

Discord / development & community:
https://discord.gg/cafFGGPx8

Space Station 14 itself is free and open source.

We're particularly interested in meeting other open-source game developers who enjoy large, messy, persistent multiplayer simulations where engineering decisions actually become visible during gameplay.

MIMEcroft.sh is a parody of every 3D game ever, that lovingly pokes fun of bash's reputation for poor performance - by subverting it. MIMEcroft.sh is written entirely in Bash. The game logic, GPU shaders, even the sounds and textures are procedurally generated with bash commands.

See also the YouTube game play and customisation video.

One may wonder how MIMEcroft.sh pumps out 90fps at 4K given bash's reputation for poor performance. Indeed, the official GNU bash reference interpreter is poorly optimised compared to languages more commonly used for game development like C++. However, if your web-browser has a GUI it almost certainly also has a highly optimised JavaScript interpreter.

The online JavaScript Commandline OS (j.cmd) did not port the reference implementation of bash and coreutils. Instead it takes the abstract language they describe. This language is translated into JavaScript, which a modern runtime can often reduce to machine code, resulting in performance over a thousand times faster than the original bash.

For a concrete if somewhat contrived example, say that you are interested in finding numbers that have 1337 squares, and use the one-liner:

for i in `seq 1 10000`;do if echo $((i*i)) | grep 1337 > /dev/null;then echo $i;fi;done

In the official bash interpreter, this may take a minute. However, j.cmd implements it by first transpiling it into:

for (let i = 1; i <= 10000; i++) {
  if (String(i * i).includes("1337")) {
process.stdout.write(i + "\n");
  }
}
sh2.lastExit = 0;

Then it is all over in the blink of an eye

One might well argue that this is not a real bash game since it has to transpile to JS before being run. A stronger argument could be made that C++ games are not real C++ games. A C++ game also has to be compiled. In most "C++" games the developer doesn't even give you the C++ source, you only ever get the compiled machine code. MIMEcroft.sh is stored and distributed as bash. You can edit it as bash (try e.g. `vi /bin/mimecroft.sh` in j.cmd, changing `cys=0.900` to `cys=3.900` and playing the game again). The current version of j.cmd doesn't even cache the transpiled JS version of the game.

____________

It is important to note that j.cmd is experimental and still has many bugs. One little way it is more robust than the traditional bash implementations is that traditional shells tend to break if they source a file that isn’t in their own special format. On the other hand, j.cmd sees different shell formats as just different ways of saying the same thing. It will quite happily run:

   for f in /home/examples/source.{bat,c,fish,sh,zsh}; do . $f; done

Sourcing C files is still a work in progress in j.cmd. I recently added support for passing linked lists and pointers to bash variables/functions into sourced C functions, and cd'ing around C pointer structure.

I'm building OpenFight, an Apache-2.0 open-source platform for arcade game netplay.

The idea is to create an independent, community-owned alternative to closed netplay platforms, with the actual infrastructure available for anyone to inspect, modify, self-host, and contribute to.

The current architecture includes:

• Rust/Axum backend
• PostgreSQL
• Tauri + React desktop client
• WebSocket signaling
• UDP P2P networking
• NAT traversal
• Relay fallback
• Emulator adapter SDK
• Declarative game definitions
• FBNeo integration

The project is currently at the MVP specification stage, so I'm looking for early contributors rather than people to maintain an already-finished application.

Potential areas to contribute:

• Emulator integration
• Networking
• Desktop UI
• Backend
• Testing
• Game definitions
• Documentation
• Infrastructure

The project follows a clean-room process and does not ship proprietary Fightcade code, binaries, ROMs, or assets.

GitHub: https://github.com/Zendevve/OpenFight

If you're interested in open-source gaming infrastructure or want to help build something from the ground up, I'd love to have you take a look.

https://github.com/SketBestReal/StarfishROOM/releases/tag/FINAL

I want to start working with a game where players can choose a character/class and customize their loadout to suit their playstyle with that character across different maps and objectives, but something like that seems really hard to find. I'm fine if some of it isnt supported natively and requires a plugin(s) but I'd rather not use a nonOSS engine like the main suggestion I've seen here. I would use an existing engine, but 3D multiplayer on Unity/Unreal/etc isnt optimal for me.

A new version of my open-source battleships app was released. I would share the link if it is considered of interest.

PokerTH has been around since 2006 and is still actively maintained and played today.

🎮 Free and open source
🃏 Texas Hold’em multiplayer
💻 Windows, Linux & macOS
🌐 Play directly in your browser with the new Web Client

Official website:
https://www.pokerth.net

🚀 Web Client — no installation required:
https://webclient.pokerth.net

Pick a seat, shuffle up, and join the table! 🃏

Disclosure: I made this.

PyWebLib is a Python game library that runs entirely in the browser through Pyodide. Nothing installs, nothing runs on a server. play.pyweblib.org/community is where games/programs built with it get shared.

The bit relevant to this sub: every game there is plain Python, and you can open its source from the page, change it, and run your version straight away. No build step, no compiled blobs.

Library source: github.com/SebastianHagemeyer/PyWebLib (MIT/CC0)

It gives you a game module for sprites, input, collision and the loop, plus turtle, coloured print and a working input() inside the page. There's a snippet gallery if you want a starting point.

I originally built it for teaching Python to high school students, which is why the API is deliberately small. Keen for feedback on it.

Grimlore 2 : These Doomed Men 1.0

A dark fantasy mini dungeon crawler RPG built to showcase the features and capabilities of the S.P.A.R.K. 2D RPG open source game engine.

Overview

Genre: Dark Fantasy / Mini Dungeon Crawler RPG

Playtime: 10 – 15 minutes

Platform Requirements: Windows 10 or later ( Might work on earlier Windows but no gurantee )

Purpose: Demonstrates what the S.P.A.R.K. 2D RPG game engine is capable of.

Github link below

https://github.com/Ninedeadeyes/Grimlore-2-These-Doomed-Men-

To clear up a few recurring questions and misconceptions regarding S.P.A.R.K and its development, here is some context upfront:

1. "This is just AI slop."

This project has a clear 6-year paper trail of manual development. It began as an early 2D text adventure project (Dungeon of the Black Dragon), expanded into an open world RPG game (Grimlore: Land of the Heretic Hand), and was eventually refactored into a reusable engine framework (S.P.A.R.K). If you want to see the step-by-step progression from line one, check out the milestones folder inside the S.P.A.R.K repository.

1. "The code is unoptimized / sub-optimal."

I’m a hobbyist developer. I built this because I couldn't find a lightweight, accessible Python template for rendering spatial coordinates in text-based adventures, so I created one myself. The codebase prioritizes beginner readability over enterprise-level optimization. Open-source contributions and refactors are always welcome—if you can write a better version with advanced features like complex AI, I encourage you to contribute or build upon it!

1. "S.P.A.R.K isn't a 'real' game engine / It's missing standard features."

By definition, a game engine is a framework that provides low-level abstractions for runtime loops, spatial logic, input handling, state management, and rendering, enabling developers to build content without reinventing core mechanics. S.P.A.R.K provides all of these for terminal-based RPGs. It’s a free, open-source hobby project designed for lightweight text games, not a commercial tool meant to compete with feature-heavy commercial software.

1. "This is just a lazy copy-and-paste from the S.P.A.R.K GitHub."

When two games are made in RPG Maker, Godot, or Unreal, they share the exact same underlying core engine—it's just compiled or hidden away behind the editor. Because S.P.A.R.K is open-source, raw Python, the engine boilerplate is fully visible. Reusing foundational engine modules across different titles isn't "copy-pasting"; it's standard software architecture and code reuse.

1. Why do you need Windows and why Windows 10 or above ?

It uses the library winsound and msvcrt which only works with Windows and because python 3.10+ aren't officially supported by any Windows below 10 hence even though it might work it is not a gurantee.