Data Oriented Game Engine Design ( DOGED )

Around 2012 I was working on a game called "Atomic Alice" under the name "MakeGamesHappen" I still use some accounts with that name... But I've lost track of some passwords or been locked out of other accounts because of not logging in often enough. Crazy how you can know your password and security questions and still lose your account if you let it go in active. Google has kind of forced peoples hands. Forcing them to converge everything around GMAIL. You'll either do this because you are overwhelmed with the task of keeping track of accounts, or you'll keep track of your accounts, but lose them anyways because hey... use it or lose it. This is a rant. I don't feel like working right now. After flash died and the game project died... I wanted to find a tech stack to replace actionscript. I tried haxe, golang + sfml , golang + opengl , C++ , JavaScript + Three.js , JavaScript + Canvas , JavaScript + Webgl. A bit of gamemaker. Some unreal engine coding... Not that much tech. But what I did look into I looked into pretty extensively. As I was working on a golang code base I read somewhere that "Go" is just a modern "C". I liked how "GoLang" did object oriented programming (OOP) and when I h eard "go is just a modern C" I thought to myself.... How is that possible? Wait... You can do OOP in C? And then I started writing C. Learned a bit of OpenCL and a bit of vulkan. Did an OpenCL and openGL interop project. Wrote some native win32 code for both my vulkan and opencl projects. Found OpenCL to not work properly on my graphics card... And the overall climate of OpenCL suggesting it was going to die just like flash... So I ditched it. Which is sad because the algorithms for my fractal auto tiling engine would work perfectly with OpenCL. Vulkan might work with GPU shaders or something.... But a bit too complex for me. I wrote many prototypes for a game engine in the past 8 years... But that is all they were... Simple toy prototypes. Sometime in early 2020 I started coding a game engine in earnest using JavaScript and WebGL... I got stuck when it came to file system access and started writing a Node.js file server... But then I got stuck on PNG compression and decompression. Then I spent a month reading all of the PNG specs and supplimentary information I could find on it. RFC 1951 and something else... Recorded myself reading 7 hours worth of documentation just to make sure I had something to show for all my reading and NO CODING... eventually I SCRAPPED the javascript project... I was already trying to write my JavaScript in a stripped down "C" style... And then I thought... "Why not just use C if I am going to write in this style?" I also had the thought that "No one is going to pay for a webgl game, no matter how well it is made." I don't want to do some weird advertising revenue BS that flash games were all about... I just want to make software and sell it. Keep it simple. So making something in C gives me more leverage to sell the software rather than offering it for free on a webpage and using some advertising scheme or in game micro transactions or whatever else. Just make something [ rare (not unique) ] and try and sell it. I am contimplating how I can make my engine findable via google search when I type in terms that I am looking for like... "Fractal Auto Tiling Engine". So here I am writing an article to help spur that SEO along. The engine I am working on is an auto tiling engine. But it is also fractal. I don't want to get into too many details about how that works right now. If you want details.... visit my stream and ask me. I'll explain. www.twitch.com/kanjicoder I am scared that talking about my idea will lead to it being "stolen" or rather someone beating me to the punch. But more worried that if I don't attempt this project and put it out there it will be 100's of years before someone has the same insights as me to code the kind of rendering engine I am coding. DODGE: Data Oriented Game Engine Design: I am intentionally coding in a data oriented style and avoiding best practices like "encapsulation". I know about scrum and clean code and I pick and choose things from both of those mindsets that make sense for my project. The concept of "context switching" from scrum is a good thing to be mindful of. The idea of "self documenting code" I have a [love/hate] relationship with. Specifically because 50% of the time when comments don't match the code... the CODE IS WRONG and the COMMENT IS CORRECT. And think about this... If you write code without comments doesn't that mean that your code is always 100% correct? Because code always does exactly what it says it does. I am not a fan of TDD either. (TDD == test driven development). I am a fan of writing unit tests though. 50% of my code base is unit tests. But the idea that you should arbitrarily decide to always start coding from the front-end api first is nonsense. Start wherever you have the clearest idea of how things should be. Then figure out the other parts later or have the other parts be a natural consequence of the domino effect that happens as you finish writing code for the clearest of your ideas. Anyways... this is still a rant. I decided on a tech stack of "C" and "OpenGL". You can see my code here: https://github.com/HeavyMetalCookies/AAC2020 You can see me coding my code here: www.twitch.com/kanjicoder