Niklas Weber in focus.

Problem: Transcendence is 42's capstone project format — a large, module-scored web application with strict architectural requirements: a typed backend, a real database, containerized services, real-time multiplayer gameplay, security, and production-grade monitoring. The brief here was a full online casino — Blackjack, Texas Hold'em Poker, and a slot machine — playable live over WebSockets, not a static demo.

Solution: The result is a three-tier system: a Go and Gin backend handling auth, wallets, and REST/WebSocket traffic; a standalone C++ engine handling the actual game rules — card shuffling, hand evaluation, poker betting rounds, slot RNG — over a gRPC contract; and a React/TypeScript frontend on top, themed as a from-scratch "luxury casino" design system rather than a reskinned component kit, with cross-browser support and a spectator mode so a live hand can be watched by other users in real time.

Technical Approach: Two details push this past a CRUD app with a casino skin. Every balance-changing operation — a bet, a deposit, a payout — runs inside a locked database transaction using exact decimal arithmetic, since float math is unacceptable for money; the transactions table is an append-only, independently auditable ledger. And the real-time layer is a hand-rolled WebSocket hub, not a pub/sub library — it tracks per-user, per-tab, per-topic subscriptions and debounces presence so a page refresh doesn't flicker a player's status offline. Similar cross-language, protocol-level thinking shows up in the ELO Leaderboard's concurrent match processing.

Results & Learnings: The stack also carries a full observability layer — Prometheus scraping six targets and six auto-provisioned Grafana dashboards, with alerting routed to Discord. OAuth2, 2FA, and a custom music module are still in progress. Working across three languages bridged by a single protobuf contract made the tradeoffs of IPC design concrete in a way a single-language stack never does.

Problem: scop is 42's OpenGL project — render a 3D .obj model with only a math library and raw OpenGL bindings as external dependencies. There's no scene-graph, no asset pipeline, no glTF loader to lean on: the file parser, the vector and matrix math, the triangulation, and the camera all have to be built from first principles.

Solution: The result is a Go renderer on OpenGL 4.1 core with GLFW for windowing. Custom .obj and .mtl parsers handle geometry and material properties (Ka/Kd/Ks/Ns/map_Kd) with graceful degradation when texture files are missing, and three automatic UV-generation modes — planar, cylindrical, spherical — cover models that ship without texture coordinates. An orbit and free-fly camera sit on top of hand-written vec2/3/4 types and column-major mat4 math, including perspective and lookAt transforms, with no external math dependency.

Technical Approach: Two problems needed real solving. Arbitrary polygons — including concave, non-planar, and degenerate ones — get triangulated with ear clipping over each face's Newell-normal plane, so geometry stays correct regardless of how the source .obj was authored. And the render loop is allocation-free at steady state: a single VAO/VBO/EBO per model with vertex deduplication, Gribb–Hartmann frustum culling, and texture-state batching bring it to 0.06 allocs/frame under -debug. Parsing itself is parallelized — worker goroutines pre-parse vertex and face data per line-aligned chunk, the same concurrency discipline behind the ELO Leaderboard's match processing.

Results & Learnings: On the Utah teapot, concurrent parsing cut load time from 9.9ms to 7.0ms, and unit tests cover the parser, triangulation, UV generation, math, camera, and frustum culling. Building a rasterization pipeline by hand — after a SIMD raytracer the semester before — made the tradeoffs between rasterization and ray tracing concrete in a way tutorials never do.

Problem: The 42 Heilbronn community ran table football and table tennis tournaments with no shared way to track who was actually good. Beyond just storing results, two students could report the same match slot within seconds of each other — naive rating recalculation is a textbook race condition, since an Elo update is a read-modify-write against a shared score and two concurrent submissions can't be allowed to read the same stale rating and both write back.

Solution: I built a complete Elo ranking system in Go with PostgreSQL, optimized from the ground up for performance. Match submissions run inside a transaction that locks both players' rows before applying the rating update, so concurrent reports serialize instead of clobbering each other, while reads — the public leaderboard, player profiles, match history — stay on a separate fast path. The backend served a React frontend with live leaderboards, detailed player profiles, and historical match data.

Technical Approach: Composite indexes on the columns the leaderboard and history views actually filter and sort by, plus Redis for the aggregate stats (win/loss streaks, rating deltas) that don't need to be recomputed on every request and get invalidated on write instead. Go's goroutines handled concurrent API traffic cleanly since each match update was isolated to its own transaction. I profiled throughout development to find and remove the slow paths rather than guessing at them. Similar optimization patterns appear in other systems projects like the raytracer, where every algorithmic decision has direct performance implications.

Results & Learnings: The system achieved 30ms average response times and maintained 99.9% uptime across tournament seasons, and the row-locking approach never produced a double-counted match under concurrent load in practice. Query optimization and profiling-driven development are non-negotiable for systems that prioritize performance. The project is now archived and no longer under active development.

Problem: I started building a basic raytracer in C to understand computer graphics fundamentals. The initial naive implementation achieved only 1–5 FPS when rendering complex scenes with multiple light sources.

Solution: I rebuilt the core rendering loop with C systems programming principles at its foundation. The approach combined SIMD vectorization using SSE/AVX intrinsics for batch vector operations, cache-efficient data structures using structure-of-arrays layouts instead of array-of-structures, and multi-threaded tile-based rendering to leverage multiple CPU cores.

Technical Approach: Three pillars: vectorization, memory hierarchy, parallelism. SSE intrinsics process 4 floats in parallel, AVX handles 8. I restructured data to exploit CPU cache locality by storing all X-coordinates contiguously, then Y, then Z. The renderer divides the framebuffer into tiles, with each thread processing one tile independently. Profiling with perf and cycle-accurate analysis revealed that the ray-primitive intersection test was the hottest code path.

Results & Learnings: The optimized raytracer renders at 120+ FPS — an 80× improvement over the baseline. Systems programming at the graphics layer isn't just about algorithms; it's about respecting CPU cache behavior, instruction pipelines, and memory bandwidth.