1. 10
  1. 3

    This was absolutely fascinating to me, from beginning to end. It’s also very neat to see that the author is the one who developed the Newer SMB game(s) that I played with my family years ago.

    I think it’s interesting to see a successful game company actually structures their code and how much of that code gets reused for later games. Perhaps the most surprising is that, while the naming and functional conventions appear misguided or archaic (why still use _c as a suffix for all classes? Why have the d prefix at all?), it clearly didn’t get in the developer’s way very much.

    Based on all the details in this post, I wonder if it’d be possible or useful to create a standalone game engine like the one in NSMB.

    To me, one of conventions I wouldn’t have thought of is the separate lists/queues for things that need to be deleted, created, executed, or drawn; and moreover, that this list might need to keep around things that still need to be acted on. I would have thought that if something did get added to the “to delete” list, then it would just be immediately deleted then removed from the list, rather than asking it to delete itself and postponing deletion until the next tick if necessary. I wonder how much of that decision is based on (I’m assuming) a technical decision to not have multithreading but instead use a form of cooperative multitasking (which is common for games that need to keep their core game loop within a certain number of milliseconds to be ready for outputting the next frame).