Regarding DBs...MMOs don't rely on them that much, it's safe to have everything in memory and persiste from time to time, and if it goes down, you just pull the backup and are good to go.
I've some other posts planned about this topic, I don't know when or even if im going to deliver, but you are free to follow the blog and receive the update if I ever do.
Tangent: Imho, the only reason it is good is because it's not as grindy and / or the community just didn't put as much emphasis on min-maxing things. GearScore was a thing of course, but theory crafting wasn't anywhere close to what we have now.
Not sure that's true for me, very good raids (minus the trial). Ulduar and Icecrown being the highlights for my guild. Though didn't mind the single boss ones either. Trial was a little janky though but the fights were fun. The big progression guild we were part of up through burning crusade wanted to leave for greener server pastures, a handful of us were kinda done with hard progression and the cuthroat nature of it. Picked up a few more and did 10mans/hardmodes mostly. Hooked up with another guild like us for 25man but we only cleared those hard modes once.. 25man was still a management nightmare...
Played through pandaland, skipped warlords, came back for some of legion and then finally broke the habit.
I liked the article! Do you know of MMOs that try to use database techniques like write-ahead-logs and log-sequence-numbers for persistence/replication? The nice thing about these techniques is that you can replicate state in a consistent way - so you could have multiple game state services all providing equivalent reads
haha, no I think they were giving a heads up to potential readers as to what they think is the interesting or unique points in the post. Still funny though :)
yep, I choose C89 for this project because there's no Object/Prototype/Class/overloaded bullshit, you get what you wrote and no more, i think it's easier to understand than any other high level language where you have to use obscure things by design.
Actually, this tutorial is not just about "building a game engine in C89", it's more about learning the concepts behind game engines, the language and the code is just illustrative examples.
I like C, but you definitely don’t “get what you wrote” in any meaningful way. You absolutely have to understand all sorts of nuance about undefined behavior, the size of primitives on various architectures, etc. I’m not advocating for C++, but pointing out that C is far more error prone and surprising than many HLLs. And this doesn’t touch on the regular error prone things about C, like memory management, array indexing, etc.
yep, i said "get what you wrote" and it's true, if you want your iterations to not get out of range you have to do it yourself, if you want to make a dynamic array you have to do it yourself and if something is not working as expected means that you wrote something wrong, that's far from the opaque flexible behaivour on javascript, f.e.
I meant that i think is easier to understand C than other languages cause you see all the flow without weird library stuff, maybe i'm wrong, dunno :(
Like I said, I wasn't commenting about out-of-range or those other things, I was commenting about the surprising undefined behaviors. :) JavaScript and many other HLLs have their criticisms, but they are generally far less surprising than C. In particular, there are languages like Rust and (to a lesser extent) Go which lack many of the dynamic runtime features of scripting/VM languages and behave very similarly to C, but with far fewer footguns (e.g., no architectures with 9-bit chars!).
Absolutely, i stick to C89 in this serie for clarity as you said, knowing what a game engine does under the hood is the only point here and C is a self explanatory language by design (even if it can be "tricky" sometimes), Im also doing tricky things with it (not that tricky anyways) like the method-like function pointers in the structures that can be "obscure" for those who only work with high level languages but i'm trying to explain everything with detail.
As i said previously, i'd never do a profesional game proyect (or even a hobby one to be sold) with C89, it takes lots of boilerplate and it feels like reinventing the wheel over and over. I'll have to code a hash map approach, a growing array (already did), a "garbage collector" in C89, things that you either don't need or have in the C++ Stdlib, so yep, you are absolutely right.
Also, i enjoy C :D
Maybe after this i could do the same with C++ macroprogramming
I like your approach, mostly because it's bottom-up, and because this is an excellent opportunity to illustrate common pitfalls. Those pitfalls can be identified using sanitizers (-fsanitize=undefined,leak,address,thread etc). With the correct CI setup you'll have a safety net, where sanitizers provide precise motivations why one approach works, and another also works, but at risk of undefined behaviour.
I have no opinion on use of C89 instead of C++, since that's just an implementation detail. Also, for your purposes, it works to your advantage, since C is basically the white-box of C++.
this is not about SDL, it's just an easy way to open a window, import assets, handle events and reproduce sound.
Would you like to see a tutorial about how to do that in c89 compatible with windows, mac, Gnu/linux, consoles, etc? it'd take half million lines and 3 years.
