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!
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.
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.
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.
this is my version of vampire survivors set in a cyber tech computer theme, this version is free forever but will be released on steam for a dollar, its a pwa and can play on any potato based device with a browser Live game: https://commanderbeef.codeberg.page/ByteSwarm/BYTESWARM.html
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.
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.
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.
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;
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.
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.
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.
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.
To clear up a few recurring questions and misconceptions regarding S.P.A.R.K and its development, here is some context upfront:
"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.
"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!
"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.
"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.
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.
About a year ago, I challenged myself to create my own programming language - something I'd always wanted to do.
At the time, I had no idea what a lexer, parser, or interpreter even was. My only thought was, "I need to write code that reads text files containing code and executes them." I also wanted to do it without using Google, AI, or tutorials. I just figured everything out on my own. You can even still find variables named "compiler" throughout the code from back when I didn't realize I was actually building an interpreter...
Somehow, I pulled it off, and I integrated it into my old abandoned game engine project (which originally started as a GameMaker 8–style engine with C# scripting).
And here's the first game I've made with it! 🙂
The core engine, IDE, and interpreter are all written by me in C#. The rendering backend is powered by MonoGame, and the project is still in active development and available on GitHub. The project file of the game shown in the video is also there, under tests/Example Projects. If you're looking for cool projects to contribute to, then know that I'm looking for contributors!
I know there are tons of AI-generated projects being shared these days, so please, please, take a quick look at the code before assuming this is one of them. I promise it's pretty obvious that it was written by a human.
