Skip to content
View pyroxdd's full-sized avatar

Block or report pyroxdd

Block user

Prevent this user from interacting with your repositories and sending you notifications. Learn more about blocking users.

You must be logged in to block users.

Content in all repositories owned by your account will be closed.
Maximum 250 characters. Please don’t include any personal information such as legal names or email addresses. This note will only be visible to you.
Report abuse

Contact GitHub support about this user’s behavior. Learn more about reporting abuse.

Report abuse
pyroxdd/README.md

vibe coding a game framework

genre: sandbox 2d top-down survival multiplayer
inspiration: Mindustry Terraria Minecraft Rust
idea: nested tilemaps still idea phase, GDD exists.. in my head

making prototypes on the way there, currently looking into replayability using ECS events ("onhit", "onkill", "onattack"...).

why???
because..

unity felt uncomfortable with all the bloat and the strange mix of its OOP objects and DOTS.. i left before the runtime fee happened!
unreal engine was extreme overkill for my goals, too much stuff i didnt need, extremely slow to open and set up
i barely tried godot, but i assumed i would face the same issues as i did with unity
monogame had menus that i hated, and i wanted to try something other than C#
bevy had borrow checking that i wasnt ready for
raylib was efficient, but i hated how i still had to create workarounds for special drawing techniques such as tilemaps.
C++ was supposedly the game engine language, so i ended up with SDL2, where i stayed for good two or three years, i recently switched to Sokol and i might try Bevy with Rust again.

overall, i hate how all of the frameworks make a lot of things easier, but the things that arent easier, are harder to do instead. im picturing it like staircases in all directions, where each step is something that needs to be done, while these frameworks make lots of these steps smaller, they always have steps that are a lot harder to get past than they would have been otherwise
depending on the game that you are making, having all steps with the same height is often better for the long run
(me using AI is very contradicting, because it makes a lot of things easier, and other things a lot harder too, i am using it because i have the opportunity, and im open to new technologies. i face the change, i dont hide it from myself, but it would probably be better if i ignored it, at least i know what its good for and what i can use it for, when i need it)

the most successful games made in the engines probably could have easily made their own engine with the amount of effort they put in, they just might not want to admit it, or they didnt think about it


i am not a competent developer and i have no idea how to work in a team. i shall not bother contributing to anyones work, i am not the kind of person to enjoy maintenance, i dont think i will ever create a codebase that will be worth anyones time, so i will just share my high level game engine progress and hope someone finds it informative in some way. i dont think im the kind of person to be making a game engine, im just trying to get a good enough setup to make a game in, also figuring out what is AI capable of in the process
rules
❌stable
❌memory safe
❌predictable
❌writing tests
❌error handling
❌maintenance

✅vibe coded
✅if its not broken, dont fix it
✅memory leaks
✅undefined behavior
✅works on my machine
✅printf, the only debugger and profiler
✅improvisation
✅stolen laptop
✅neighbours wifi
✅never paid for it
✅"fatal error: too many errors emitted, stopping now"

some of it is sarcasm, some of it is true!
the only thing that really matters is time, motivation and consistency
failures and reality checks are expected
tech
🌕 already went through it
🌗 working on it
🌑 planning to look into it

currently starting over with no codegen this time

engine/framework/graphics-library
🌕 Unity, HTML/JS (2d rendering context), Unreal, Godot, Monogame, Raylib, Bevy, SDL, OpenGL (OpenGL-ES, WebGL), Roblox Studio
🌕 SDL2
🌗 Sokol
🌑 Vulkan, DirectX, SFML, Love2D, the Forge, bgfx
tooling
🌕 Git - Github
🌕 Cmake
🌕 Emscripten - WASM
🌕 python codegen
🌑 Tracy profiler
engine architecture
🌕 two ECS worlds, one for tick thread, one for render thread. this required snapshots, and made things way too complicated
🌕 server to client ECS world replication via networking
🌗 single shared ECS world, its so much easier to do stuff on both tick and render side, but might face performance bottlenecks later, theres only one way to find out :)
🌗 hot reloading via DLL swapping, ECS world is in engine, so it survives the reload. reload takes one second and its unoptimized Odin "everything" compilation, including all game code content files, all shaders and all assets, theres also optimized web build
networking
🌕 UDP, then TCP
🌕 basic client/server project
🌕 sent spatially partitioned entity component data
🌕 better dirty ecs component tracking to send only changes
🌕 WebTransport - QUIC, imquic
🌕 message types (reliable, unreliable), payloads, serverless mode
🌕 grid based server-side fog of war
🌑 VPS?
🌑 UDP again?
ecs
🌕 entt
🌕 serializable ECS components for networking/saving
🌕 spatially partitioned collision detection with swept box cast
🌕 linear and angular velocity
🌗 flecs
🌗 tile entities
🌗 events!!! still getting used to them
🌗 switched to box2D
🌑 more types of colliders, tilemap collider, SDF colliders?
codegen
🌕 using python, extending C++ with tags and special keywords
🌕 ECS integration - component structs
🌕 residency tags and transitioning between them (SERVER -> netcode -> CLIENT -> mirroring/snapshots -> RENDER)
🌕 shader components (shader logic defined directly in component as a function, component variables have automatically generated GPU layout), this includes vertex shader and fragment shader
🌕 it is also possible to define compute shader blocks which are primarily used by particle emitters, those are also directly placed in C++
🌕 internal components which rely on other components
🌕 component hierarchy (one component automatically creates other component, several components rely on other component, but that component can only have one child component of this kind, forcing a replacement. there are also required variables, components and events. this essentially works as OOP class inheritance)
🌕 built-in events (add, remove and set, theres also update event, which is converted to systems under the hood), and custom events with queries, all events have optional named ordering and are defined as regular functions with a special "ON(my_event)" keyword.
🌕 "dense case" feature, currently used for efficient 2D tilemap storing, used primarily with enums. codegen figures out enum element count, automatically appends to switch case, this makes it possible to store many kinds of tiles in tiny value such as 16bit integer, tiles will have their enum defined in themselves, most commonly a rotation, which is an enum of 4 elements. simple wall tile without rotation will take up one space, while a tile we can rotate will take up 4. if a tile also has growth enum with 3 elements and can also rotate, it will take up 12 lines in a switch case. there is also offset enum used in pairs by the offset tile, enabling clean multi-tile structure references (currently a 7x7 space)

🌗 NO CODEGEN ALLOWED! enough codegen for life hopefully :D ..except for atlas coordinate generation, msdf-atlas-gen for fonts and Sokol-shdc
procgen
🌕 rectangular structures with pathways
🌕 noise (perlin, simplex...)
🌕 cellular rooms
🌕 layered subdivison / erosion
🌕 deterministic scaling structure layers
🌕 realtime simulated generation with branching - "biome brush" entities
🌑 cave carving
editor
live preview simulated editor for: graphics audio entity code
🌕 shaders
🌕 ecs
🌕 dsp
🌕 basic export
🌕 seamless noise texture generation
🌑 font file to font SDF texture converter
🌑 whole native editor: view all assets simultaneously, while being separate files, also while being able to change them from the editor. edit shaders, write custom hierarchies to show assets combined into live entity, export with custom values such as points. in general similar direction to Aseprite, but more custom game framework focused
gpu
🌕 OpenGL/GLEW within SDL
🌕 compute shaders
🌕 using textures to store everything (very wrong)
🌕 single shader for everything (also wrong)
🌕 no separate thread (TPS = FPS, also wrong)
🌕 custom text rendering, with font SDF texture
🌕 update/render thread separation + sub-tick interpolation
🌕 frame buffer, start of graphics editor
🌕 tiny C-like language into wasm
🌕 bloom (hate it)
🌕 VFX editor
🌕 WebGPU
🌗 Sokol with sokol-shdc
🌑 multi-shader pipelines
🌑 geometry shader, tesselation shader and native 3D GPU programming in general
audio
🌕 audio callback
🌕 spectrogram
🌕 spectral synthesis
🌕 digital signal processing
🌕 DSP editor
🌕 spatial audio (stereo)
language
🌕 C#, JavaScript, HLSL, C, Rust, Lua
🌕 GLSL, WGSL, custom ECS language, Odin, Zig
🌗 C++, GLSL: sokol-shdc version
🌑 Java, Jai, Rust (again), DLang -betterC
llm coding
🌕 gpt (browser), gemini (browser), gemini cli (decent amount of time until nerfed), cursor (barely tried), claude (barely tried)
🌕 local models: qwen coder, gemma. using: ollama, aider, LM studio, roocode - not enough VRAM and RAM for it to be smart enough
🌗 Codex plus: currently planning with GPT6 Sol and implementing with GPT6 Luna
secret AI opinion: i believe its extremely powerful, but using it correctly is difficult, using it incorrectly can cause serious issues, so basically the same as C++ and GPU programming :)
AI is what made me realize the importance of technical debt
personal
from: Czechia
age: 22
career: CEO @ unemployed
job experience: 0 in total less than a year
education: graduation worthless nowadays
first touched C: 3 years ago thats when i believe a software developer is born :)
personal info: sold
if you got this far, DM me the word "frog" on discord :)
progress updated: October 28, 2026
discord: pyroxdd

Popular repositories Loading

  1. pyroxdd pyroxdd Public