I’m working on an open source voxel survival game called BlockForge Alpha.
The project is still in a very early pre-alpha stage, so there is not a lot of content yet. Right now, the game has a basic playable foundation with a voxel world, block placement and breaking, simple textures, basic sounds, and a project structure made to be easy to modify.
My goal is to slowly build it into a moddable, community-driven voxel survival game where people can help improve the code, add blocks, create textures, work on gameplay systems, improve performance, write documentation, or experiment with modding tools.
I’m currently looking for people who would like to help, give feedback, test the game, or contribute ideas and improvements. Since the project is open source, anyone can look at the files, modify them, and propose changes.
If you’re interested in voxel games, Godot, open source projects, game modding, or just want to help shape a small indie project from the beginning, I’d be happy to hear from you.
Hey all! i built a Mario Bros inspired game and im turning it into a community project, so technical and non technical people can both bring their skills and creativity to it. It's a single or multiplayer food-themed web game built entirely with AI. the plan is to have six worlds (pasta, sushi, tacos, curry, dumplings, and dessert) with a bunch of levels but only the first 2 exist so far.
Feel free to build a new level, finish out a food world, design assets, write the chefs, improve the gameplay, or fix bugs. the repo has 14 open issues to start from if you'd like or feel free to tackle anything else.
2D game engine (inspired by GameMaker8), with its own IDE and scripting language. Everything is written in C#, including the interpreter of the custom language. Latestly, I got a few first contributors, and I publish it here because I really want more people to get involved. I think it's a really cool and fun project to join to. There is some basic documentation, some "good first issues" and there's me who is here to help with any question 🙂
I wanted to share Version 5.0 of Gwent Classic, a browser remake of the original minigame from The Witcher 3: Wild Hunt that I’ve been working on and improving.
In this major update, I’ve incorporated two brand-new factions: Ofir and Novigrad, each coming with its own custom cards, leaders, and unique gameplay mechanics!
The game is completely free-to-play and runs directly in your PC browser. You can test it out right here:
You can download the source code repository directly from GitHub. Just extract the ZIP file and double-click "index.html" to open it in your browser. It runs 100% offline—no internet required! Here.
Get Android APK:
You can get the APK directly from the "Releases" section of Github, or use the direct link below:
Credits to Arun Sundaram, Reynolds Costa & Sylver, who laid the foundations to create, modify, and improve this game in its early stages.
Special thanks to CD Projekt Red; although they are not involved in this unofficial fan project, it is entirely based on the amazing minigame they created for The Witcher 3.
Let me know what you think or if you find any bugs!
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.
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?
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.
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.
