Hello, everyone! It was another week with nothing to post until Saturday. In my defense, I've been working hard on a visual edition of my game, which in turn uncovered some omissions in the prototype, so I had to go back and fix those too. Despite that, it took essentially as much time to make: another two weeks. Not bad at all, seeing how I had to make a GUI and it all took twice as much code overall.
So I give you Space Cruiser Orion. It was a bit rushed, to be ready in time for the newsletter. Still got to add sound effects and another small feature. But it's fully playable, even winnable, and doesn't it look gloriously retro?
And because this editorial is too short, let me announce that a sequel was planned from the beginning. Should be a lot easier to do, now that many details are all figured out, including a bunch of support libraries. Hopefully a few more ports, too, if this game proves popular enough, but somehow they never seem to be. Maybe some day.
In the way of news, we have a technical article about implementing game saves, and a couple of books about the implementation of classic first-person shooters. Details after the cut.
On Saturday morning, a fellow developer from Itch.io posts about the inherent difficulties with saving game state. It's something I've largely managed to avoid in my own games, by virtue of making them short. And in Keep of the Mad Wizard, which supports saving out of the box because Twine, all I had to do was make sure game state variables can be serialized without any tricks.
In the past, however, it wasn't nearly as easy. Ah, the fun of trying random codes in Prince of Persia for the NES, and seeing what happened. Or trying to cheat in The Sentinel. And some games, like Lords of Midnight, essentially had to dump the entire RAM to tape. I could never restore from a saved position until the advent of emulators. Then again, many early RPGs worked the same way, but as they ran on disk-based machines, the only problem was making a pristine copy first.
And well, as I pointed out in the past, all games are simulations deep down, and simulations just want to go on and on even after nothing interesting happens anymore. So in a way MMORPGs with their persistent state are the most honest kind there is. What lessons can a game designer learn from that?
Also on Saturday, a friend points me at a couple of books I didn't know about: Fabien Sanglard's Game Engine Black Books. There are two of them for now, exploring how Wolfenstein 3D and Doom were able to revolutionize gaming back in the day. And while figuring out fancy assembly code isn't exactly my speed, the historical information is invaluable, and the writing is plain amazing. Then there's the author's philosophy:
Twenty years after the release of Wolfenstein 3D, you can still play the game on anything with a CPU, some RAM, and a framebuffer.
This! This is what I keep trying to tell people: the humble framebuffer with its complete lack of tricks is what enables you to make any imaginable game. It's what made the Spectrum so vibrant. It's what enabled the stolid IBM PC to kill the Amiga, as Jimmy Maher points out in his book, and Mr. Sanglard explains in his introduction. It's universal. It's simple. It's cheap.
But hey, why paint with watercolors in a world where acrylics exist, right? Right?
Anyway, that's about all I have this week. Enjoy, and see you next time.