You are browsing as a guest. Sign up (or log in) to start making projects!

jayanth_raveendra

@jayanth_raveendra

Joined June 6th, 2026

  • 9Devlogs
  • 4Projects
  • 4Ships
  • 72Votes
Ship Changes requested

ARENA is a real-time multiplayer game where your face is your login. No passwords, no typing—just split-second biometric verification computed directly on your device’s GPU.

TECHNICAL HIGHLIGHTS:

🔹 Edge ML Biometrics: Uses face-api.js for zero-latency, client-side 128-d facial encoding.

🔹 Real-Time WebSockets: Live asynchronous matchmaking lobby and instant mid-game disconnect handling.

🔹 FIDE-Standard Elo: Mathematically calculates win probabilities and dynamically updates your global ranking.

🔹 Resilient Microservices: Fully containerized stack (FastAPI, Nginx, MySQL, MongoDB) with automated database retry loops.

HOW TO DEMO:

Because ARENA is a full-stack microservice architecture, it is too heavy for a free cloud host. My GitHub repository is the demo! To experience the magic on your own machine:

Clone the repo and add the .env variables.

Run "docker compose up --build -d" in your terminal.

Go to localhost:5500 in your browser and register your face!

(Want to play with friends on your Wi-Fi? The README has instructions on how to use ngrok to securely tunnel the Nginx proxy to their phones!)

  • 1 devlog
  • 7h
See source code →
Open comments for this post

6h 32m 15s logged

What started as a basic software systems course project just got a massive 6-hour architectural overhaul. I wanted to build ARENA, an identity-verified multiplayer Tic-Tac-Toe game where your face is literally your password.Here is the breakdown of the sprint to get to v1.0.0:The Biometric Overhaul (Moving to the Edge)
Originally, the facial recognition was a heavy, monolithic server-side pipeline. It was a dependency nightmare and crushed the server. I completely ripped it out and migrated to Edge ML using face-api.js. Now, the client browser computes 128-d facial encodings directly on the user’s GPU. Server load dropped to near-zero, and the latency is basically gone.The Microservice Migration
I took the original god file and shattered it into a clean microservice architecture. Containerized the whole thing using Docker Compose. It now features a resilient Python backoff/retry loop so the FastAPI backend waits patiently for the databases to initialize before booting.The Local Network “Final Boss”
This was the hardest part of the overhaul. I wanted users to connect via their phones on the same Wi-Fi. But Chrome strictly blocks webcam access on unencrypted HTTP connections unless it is localhost.The Fix: I set up an Nginx reverse proxy to route frontend and API traffic through a single port. Then, I wrote dynamic JavaScript routing and piped the whole thing through an ngrok tunnel. Now, I can spin up the containers, run the tunnel, and send friends a secure HTTPS link to play against me locally! It was a crazy 6 hours of fighting WebSocket race conditions and Nginx regex bugs, but ARENA is finally production-ready (I hope :) ).

0
0
21
Open comments for this post

6h 10m 49s logged

Logged 6 hours today wrapping up my C-Shell mid-submission, focusing on fixing a major architecture bug, optimizing features, and thoroughly documenting the codebase. First, I added a stale path cleanup mechanism to my Zoxide-style hop command, ensuring that deleted directories or those with a frecency rank below 0.5 are automatically purged from the hidden database. Next, I tackled a tricky OS trap involving multiple output redirections: because execv() replaces the entire process image, it was obliterating my post-execution file-writing logic. I fixed this by building a custom tee-style pipeline that forks a second proxy “writer” child to safely read the command’s output via a pipe and distribute it to all files simultaneously. Finally, I went through all my files to rigorously comment the complex dup2 file descriptor routing and backward file-chunking logic.

0
0
7
Ship 💀 Cursed

After 11+ hours of wrestling with C, pointers, and POSIX syscalls, I am shipping my custom Unix shell!

What started as a custom lexer and parser (built entirely from scratch without tools like Yacc) has grown into a fully functional execution environment.

Highlights:

Full Execution Engine: Handles complex pipelines (cmd1 | cmd2 | cmd3) and I/O redirection (<, >, >>) using precise file descriptor management (dup2, pipe, fork).

Zoxide-style Navigation: My hop built-in tracks every directory you visit and uses a time-decaying frecency algorithm so you can jump anywhere using just a substring.

Memory Optimization: Built-ins like peek read files backward chunk-by-chunk using lseek to avoid loading massive files into memory.

Building a shell from the ground up completely changed how I look at the terminal. Source code is linked below, as well as a short demo video!

  • 2 devlogs
  • 12h
  • 12.85x multiplier
  • 75 Stardust
Try project → See source code →
Open comments for this post

3h 18m 19s logged

Spent the last 3 hours building the core execution engine for my C-Shell. I implemented external command execution by scanning $PATH and using the fork() and execv() syscalls. The biggest challenge was getting I/O redirection and piping to work correctly. I used dup2() to hijack standard input/output and route them through anonymous temporary files (tmpfile()) to handle multiple file redirections at once.I also ran into a brutal segmentation fault because my built-in commands weren’t expecting redirection operator tokens. I ended up doing a massive architectural refactor to move the entire file descriptor routing to the parent shell level. Now, whether it’s an external binary like ls or my custom peek built-in, they both seamlessly read and write through pipes and files!

0
0
8
Open comments for this post

8h 25m 50s logged

I spent the last 8+ hours building a custom POSIX-compliant C shell from scratch. I built a custom lexer and parser to handle right-linear grammar, quoting, and escaping without using standard parsing tools like Lex/Yacc. I also implemented several complex built-in commands natively without relying on exec system calls, including a custom directory jumper (hop) with a time-decaying frecency algorithm (similar to Zoxide) that persists across sessions, and a custom cat-like tool (peek) that uses lseek to read files in reverse chunk-by-chunk to save memory.

0
0
8
Ship 💀 Cursed

A bare-metal, 32-bit RISC-V CPU emulator written entirely in Rust from scratch. It features a simulated 1MB memory array, a full RV32I base integer decoding pipeline, and Memory-Mapped I/O (MMIO) that intercepts writes to a specific memory address to simulate a physical terminal screen.

Instead of just running standard assembly, I built a proxy-kernel into the emulator to intercept RISC-V ecall instructions (Syscall 64 for write and Syscall 93 for exit). Alongside a custom Makefile and linker script setup, this allows the emulator to natively execute freestanding, bare-metal C programs compiled via a Linux RISC-V cross-compiler toolchain.

  • 1 devlog
  • 7h
  • 4.46x multiplier
  • 16 Stardust
Try project → See source code →
Open comments for this post

6h 56m 8s logged

Spent the almost 7 hours building a bare-metal, 32-bit RISC-V CPU emulator entirely in Rust from scratch! I finished the core RV32I instruction decoding and set up a simulated 1MB memory array, but getting actual C code to run on it was a massive challenge. I ran into two brutal bugs: The GCC cross-compiler was secretly compressing my instructions into 16-bit chunks, causing my 32-bit fetch() cycle to mash instructions together into unknown opcodes. I had to configure -march=rv32i to force strict 32-bit mode. My CPU tried to jump to an address 4.2 billion bytes out of bounds because of a 64-bit sign-extension trap in Rust! After fixing those, I wrote a tiny bootloader routine to set the Stack Pointer (x2), built a proxy-kernel to handle ecall system traps, and set up Memory-Mapped I/O (MMIO). The emulator can now successfully run a freestanding C program, print to a fake terminal screen, and exit cleanly!

0
0
10
Ship

I made a 2d platformer where you play as a plucky knight. You have to collect coins, avoid the green slime and reach the end without falling off. For now, there is only 1 level, but it is completely developed. You can try it out on my itch.io project page. I hope you like it! I built it in Godot 4, with assets and game design from a Godot tutorial by the Youtube channel Brackeys. I actually spent a lot more time on it than my devlog says, since there was a lot of stuff that I did in the engine that couldn’t be recorded.

  • 1 devlog
  • 2h
  • 7.23x multiplier
  • 18 Stardust
Try project → See source code →

Followers

Loading…