Thanks so much for the shout-out and support! If you want more updates, make sure to also follow the lead developer, https://x.com/poiitidis, and another rock-star from our community who is supporting him, https://x.com/Frogbull55.
12 karma · joined June 5, 2016
I was king of scope creep, but I was also the engine and tools developer... Does it LOOK LIKE the engine and tools were the ones bottlenecking progress, or does it look like a lack of ACTUAL GAME CONTENT was the problem with Elysian Shadows? The engine and tools (which were my job) are probably easily at 90% done.
What I do own up to is being so bogged down with coding up a whole cross-platform engine and toolkit that I was an absolutely horrible manager who just relied on the rest of the team to know what needed to get done and take care of it, which obviously never actually happened. I was not as involved in the rest of the actual game aspect of ES independent of the tech than I should've been, and I own up to that...
But if you actually think THAT is what caused this game to never get done, you aren't seeing clearly. That's the one aspect of the game (other than audio, which was never a problem) which was actually where it should've been in terms of progress.
Also, for the record, LOL, ElysianVMU caused "drama" and extra work for the team? Funny, not one person other than me wrote a line of code for EVMU or even implemented the single line of Lua code it takes to display a VMU icon in-game... and as far as I ever knew, Patryk enjoyed getting to take a few hours to get away from killing himself being overworked on terrain and character assets to get to draw VMU icons, or so I'm assuming based on the fact half of what he drew were penises and jokes, initially. ;)
But yes, way to take the spotlight away from the developers who are pouring their hearts and souls into this project, of which I'm only an insignificant part of, to bring up some irrelevant shit from my past which I have owned up to and am literally working to correct by supporting projects like this... total douche bag move. Makes me feel sorry for the rest of the team, tbh.
The entire Objective-C runtime which is what powers the OO core of the language was also written with a similar purely C type system... It's just a small compiler layer on top...
I'm such a fanboy it inspired my own type system and massive core library, libgimbal, which uses a type system similar to GObject and targets game consoles like the Sega Dreamcast: https://github.com/gyrovorbis/libgimbal.
Now witness as Rust struggles to produce a compelling widgeting environment that isn't Qt or GTk bindings to other languages which support OO constructs. Witness as apparently creating a "Rust-friendly" OO paradigm or framework is an ongoing academic endeavor, because of this...
Believe it or not, for some domains, object-orientation is the right tool for the job... as some problems are just inherently modeled better with such a paradigm, and are able to take advantage of what it has to offer (encapsulation, polymorphism, inheritance).
Because, yes, sharing state among classes for code reuse, is fundamentally evil... How dare you want to couple state and logic?
Almost like every single UI framework in every mainstream language has converged upon OO as the best way to model the problem at hand... GTk even invented a similar type system to what was mentioned in this PDF just to give C OOP constructs... Now witness as the Rust language has failed to produce a compelling UI/widgeting framework or paradigm, and the best ones out there are Qt-based or GTk-bindings (letting C hilariously handle the OOP for Rust).
...and I literally almost gave up on being a C programmer because of bashing my head against language limitations... This book completely and totally changed everything and is the reason I completed this very ambitious project (https://github.com/gyrovorbis/libgimbal)... It's not just good for object-oriented C, but also for approaching the C language differently in general. For pushing its boundaries rather than accepting its limitations.
Anyway, this "PDF" was such an inspiration on me as a C programmer that I managed to track down a physical copy on Ebay. lol.
Anyway, I was sent down a rabbit hole of wanting to do object-oriented C for a language independent core as well, starting off with buying the physical copy of this PDF, because I liked it so much...
I have to say GStreamer is probably the absolute best, most ambitious, shining example of such a type system, as it's already built upon GObject, fixes a lot of its shortcomings, and just really takes the whole thing to the next level with a complex, highly OO architecture. Fantastic reference and inspiration for this kind of stuff.
I've studied everything out there on achieving OOP in C, and actually the OP's book reference was my original inspiration. There's a fine art to doing it and a few good codebases are out there that do it well... The entire GNOME stack is based on this kind of stuff.
Anyway let me know if you have any questions. lol.
But hey, maybe having a core, foundational framework written in the most performant language out there with the most hardware support should've been a priority. ;)
Dude, clicked your profile links, and wtf? Objective-S looks awesome! I had never even heard of it, but creating a more easy-to-use language ontop of the Obj-C runtime is epic!
I actually wrote my own C-based meta type system for giving my core library and applications that use it a language-independent object-oriented C layer for interop. That's actually how I discovered the magic that is Objective-C and how powerful the C runtime actually is... that's why I'm sad to see it slowly disappear, and anything like this that keeps it alive and uses it is really cool to me. :)
I just wrote unit tests for making sure the Objective-C runtime is working and doesn't accidentally get broken in the indie SDK, KallistiOS, for the Sega Dreamcast: https://github.com/KallistiOS/KallistiOS/pull/202, haha.
Gross. The whole appeal of Foundation was having this incredibly convenient, beautiful, high-level object-oriented API ontop of low-level, statically compiled performant C...
The true path forward for computing is clearly an alliance among the holy trinity of god's C languages: C, C++, and Objective-C.
Yes, the future is in Objective-C++'s hands.
The SuperH is still fully supported by the GCC toolchain and is well maintained.
Also the guy behind compiler explorer, Matt Godbolt, himself was a DC developer and has added the SH architecture there as well.
https://github.com/KallistiOS/KallistiOS/commit/99c716c8915f...
https://github.com/KallistiOS/KallistiOS/commit/99c716c8915f...