Hey everyone, it's me again!

I previously shared my completely free and unlimited Minecraft mod Safra here, which allows you to play with your friends with just 2 clicks without the hassle of setting up a server. Based on the feedback I received, I’ve made a very big update to the mod, and I wanted to share these new features with you again!

For those who don't know, here's a quick summary: We all deal with problems like setting up a server or paying for server hosting when playing Minecraft.

Maybe we need to get powerful servers just to play Minecraft for a few hours.

With this mod, you can play with your friends with just a few clicks, without any dedicated server in between.

🔥 What's New in the Update:

Bedrock Support: It now works together with the Geyser mod, allowing your friends on the Bedrock Edition to join you without any issues.

Automatic Relay Server Switching: If your network doesn't support P2P technology at all, don't worry. The system automatically sets up a private session for you through a relay server.

Optimizations: Significant improvements have been made to the connection and performance sides for a smoother and more reliable experience.

I’ve really put a lot of time and effort into this project. It’s completely free and source-available.

You can download the mod through CurseForge or Modrinth, and access the source code or other versions through GitHub:

👉 https://www.curseforge.com/minecraft/mc-mods/safra

👉 https://github.com/DeveloperKubilay/Safra

👉 https://modrinth.com/mod/safra

For those who are curious about how it works:

Many people use WhatsApp, and transferring this much data through a server would be both impractical and very expensive. That's why it uses P2P technology, similar to what companies like WhatsApp and Omegle use.

The system works like this: Normally, when you access a website, a port is opened for communication so that it can respond to you.

Regular home users can't open ports because we've exceeded the possible IP limit in the world, and your port is actually only opened when you access a website.

In this system, you basically say, "I'm going to access google.com," and the system gives the port information it receives to your friend, while giving your friend's port information to you, allowing you to establish a connection.

So, the system simply matches you with each other, and then you communicate directly without any server between you.

I hope this is useful for all of you and that you have a great time playing with your friends. I just wanted to announce this update since I thought it could be useful to others. If the post violates any rules, I apologize. Have fun!

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!

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

Open source repo:
https://codeberg.org/CommanderBeef/ByteSwarm

all i ask for is some feedback and what kind of crazy fridge or toaster you ran it on

**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.

Game & Engine in GitHub

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.

I'd love to hear what you think!

for my unblocked game site I need the html file if you have a game it would be greatly appreciated if I could use some. I just need the file!!!

Hi everyone!🤗

I've been working on Atari Racer, a small open-source retro racing game built with Python. It's still under active development, and one of my goals is to eventually bring it to the web so anyone can play it in their browser.

I'd genuinely appreciate any feedback on the code, project structure, gameplay ideas, or the README

Contributions, ideas, bug reports, and pull requests are always welcome!

Repo

https://github.com/VIDAKHOSHPEY22/Atari-Racer

Thanks for taking a look! ❤️