so i have been working on this every day since may 10th with maybe a day or 2 knocked out bc sick/drunk missing commits for those days. i have ultimately started working feb 21st.

the original problem started 4 moths prior to building this engine. the issues was about roblox and luau. in luau there is not proper way to do oop and there was no real framework to create network driven objects and proper serialization to squash and store objects directly into data bases. so the 4 months prior i was on and off developing a frame work in luau to build exactly that.
it was hacky but when i was getting close to completion of it, roblox pushed ID verification hard, so hard that to upload a game to there platform you had to have an ID verified account and pay money, witch just made it totally useless. i went looking for alternatives i can develop on and none had the ability to make stand alone game and there platforms where really weak. the framework it self is engine agnostic witch plugging it into sockets or what every the underlying engine exposes.
the adventure into looking for alternatives put me into discord servers witch any sort of discussion or talk i had immediately got spammed with rule 8 and serious discussions deleted. witch sucked bc that was the only one developing a custom engine at the time, the rest are based off unity or godot or AI codded by some kid who knows nothing about computers.
after a while and seeing more news about shit, i went and started my own project bc i thought it couldn't be to hard to remake this.

so i started with figureing out libs i would want, and setup and structure of how things should be. i ended up finding roblox's API documentation is cc0 with mit code examples along with some test places also as cc0/mit there luau scripting fork was also open source.
i grabbed all of that loot, i picked D lang as my programing language and was intrested in sokol since i didn't really wanna have sdl2 and its legacy code base.
i first started out making a data driven API for luau matching roblox parity. i would define meta data like name, paramiter, description, wether it was server client, editor or native. and other little things like that.
i then started building out objects for each one of them structures (witch later i found out to be an issue) and i used that as engine internals i would passed around to the sound system physics and all.
the reason why the meta data API is important is because it defines one source of truth, everything will agree upon that. there will be little knock out flags for client server editor etc that will know its self and check agents the api (during copilation)
so each thing will know what it can and cant do with that
i didn't want to define every single luau to object layer, so the object files holding the api meta data meant there is one file to manage. and not 3 different file for this structure. as they would have been the bridge wiring, the object, and the object representation in luau.

this surprising worked really well that i was able to really early get scripts that worked in roblox to work in my engine. i had built a render witch would walk the whole data model, data model being a hierarchy of objects witch children and stuff. so u can properly parent thigns and sort them. (more issues later about all of this)
so every time i wanted to render i would walk the whole tree grabbing each part and sending it to the gpu its position size color and all.realy optimizations included walking the tree once, sending it all to the gpu, and then only sending stuff that changed witch gave me hooks to work with.

next was physics and man this was kinda a pain, jolt was kinda buggy but it worked after some tuneing, i was able to get it to do physics but it would destroy the cpu on all core max, that i had to turn down the hrz it did its cals or what ever a bunch.. and if it was to low, thigns would fall thu the floor and other weird buggy stuff. not much i can say other then i had many issues and lots of that was just fixing up physics world by tuning.

at this point every one of my tests where just luau scripts as a launch options. and that would generating the world and drawing it on screen. i started developing a editor around all of this and slowly converting everything to be driven by save files rather then launch flags. i got imgui from sokol to build the editor it self. (turns out roblox also uses imgui, i saw it in there latest engine showcase)
the editor must have its own VM and other custom bvinding just so that it can do fileIO and other things. it would run more powerful scripts that could do actual things on your system but idealy it shoudnt be posible to do stuff unless u got a plugin that does it. game scripts would be isolated into there game vm that has no fileio bindings and other things.
some of the editor stuff would include tools that can dip its hand into the data model and set positiongin and stuff. while the main thing it was, was to hold separate gizmos for positioning and scaling and other sorts of non game intractable.

so by this point i basicly got most things working i can import a roblox game and run it... but it runs like shit. and i dont really like the stupid lego people. so i sepnd long time optimizing things and working out what i can do to make faster. it turns out i am going oever the whole data model a hand full of times for many things like audio physics and other trash. i was able to have it go down a bunch. i then had to make a algo for oclusion culling witch meh it was okkay but what helped more was combinging pars with same textures and touching and all into one bigger shape reducing verties witch sure it helps a little more but the main issue was still the cpu burning recalcs, so some more optimizations was making a algo that apll parts start as records a small struct that defines what it is, but when a scirpt calls upon it, it will be made into a object on the fly and be used when need and held and if not usedfor a while will be turned back into a records. this saved a lot of ram, and then i was able to turn that list of awoken objects into a sparse set that i would then feed into systems as deltas making things faster. many other little things
another thing i am really proud of was getting duplexing working as it was HARD, most game servers opporate in 1 world per application. but i felt that my engien was light enough that i could duplex stuff. and have less rame usage and only have awoken stuff be the custom things for each work. as some games that are 1 users each per game or a tycoon with max of 6 players could also get this since it is a small game on paper. but 10 procsses would be 10 engines with 80-90% of the same base game.

oh here is another thing u need 0 allocation games if posible bc a single malloc and other things can cause the whole world to freeze. and in case with duplexing it is hard in many things with one procsses starving the cpu of other games and many other smaller things.
i had to redesign many things to have one base and things and then fork it into sub procsses, i was getting AI to help me and it basicly was refusing to help and said it was not possible and i had to study nginx to help figure out how it duplexes and all of that. i eventually got it working how i want but still needs tuneing but basicly the main issue was the cpu not being shared evenly and is why u had to fork rather then duplex in one processes and to actauly see real benifits you have to memory map from the parent procsses the engien and other unchanging data