The Our Machinery team writes about building a game engine in C, covering code structure, memory, audio, and development workflow.
Commenters point to its post on allocating large virtual memory ranges and its move away from GitFlow, and recommend the blog for engine development writing.
Very lengthy and seemingly pretty good, but I wanted to see it applied. So...
* The home page at https://ourmachinery.com just says "We are building something..."
* The About Us passage on the home page just says "We are game engine developers with a passion for diversity, openness and knowledge sharing etc." without saying what they do, then points you to Instagram, which shows a super diverse team of three adults and one child, but doesn't give a clue about their project(s?)
* The blog https://ourmachinery.com/post/whats-happening-this-year/ talks about transparency but I still don't know what they do
* There's no GitHub or similar link
If I read correctly, this is trunk-based development.
https://trunkbaseddevelopment.com/
And this is also my experience, I absolutely hate spending time to merge things and resolve the conflicts and bugs.
I think this should be the default behavior for small/medium teams.
Branching should only be used when trunk-based dev is no longer possible.
I really liked this article from the Our Machinery guys, who created the Bitsquid engine.
https://ourmachinery.com/post/moving-away-from-git-flow/
This other article is also interesting:
https://medium.com/@mattia.battiston/why-i-love-trunk-based-development-641fcf0b94a0
This looks pretty shady.
The current EULA on the website includes a bit that says they can terminate your license and ask you to delete all source and binaries entirely at their discretion[1].
The latest copy on the wayback machine from May does not have that bit.[2]
1. https://ourmachinery.com/eula.html
2. https://web.archive.org/web/20220529230958/https://ourmachinery.com/eula.html
So they used the 'we can update the eula at any time at our discretion' clause to add a 'we can tell you to delete your source and binaries' clause and then immediately invoked it.
Interesting what you say about struct-of-arrays, I have been following this topic closely recently. Do you know any well known JS code implemented using struct-of-arrays or have some interesting resources about it? I am worried that SoA codebase is difficult to maintain and hard to express in a simple API.
I have been reading two resources about it, https://ourmachinery.com/post/data-structures-part-1-bulk-data/ and https://stackoverflow.com/questions/39799874/why-does-javascript-process-an-array-of-structures-faster-than-a-structure-of-ar.
Headers not including headers is still good advice, it's not so much about fast compiles (at first at least while a project is small), but about not letting header inclusions grow out of control (see almost every C++ project with more than a few hundred source files, it's almost impossible to clean up unused headers, and even when that happens - after a few weeks it's back to the old mess).
See here for a relatively recent take on this:
https://ourmachinery.com/post/physical-design/
You can allocate 4GB of virtual memory which will ensure that it doesn't get allocated until you actually hit a new page. Heck, you can, and OurMachinery has a great blog post on this, allocate 100GB of virtual memory and then use pointers as immutable ids and your app will only use as much physical memory as needed and the OS will take care of the rest.
https://ourmachinery.com/post/virtual-memory-tricks/