BRIX is coming along slowly, but surely. Since it was originally written for Garry's Mod (and to be used with an addon already in the game), looots of the client code needs to be rewritten. The differences between these environments are too big to simply copy-paste it all and delete all of the incompatible GMod stuff. This is yet another opportunity to refine the structure of the game client to be more modular. Going down this path has kind of led me to making somewhat of a game engine of my own--at least, one built upon Love2D.
I think it'd classify as a game engine, since it's just a handful of Lua files that define a pretty rudimentary game framework. It takes on a structure akin to Unity, with scenes, events, actions, and a "GameObject" philosophy of general objects. So far, the code barely makes any references to the game that will be BRIX. Instead, it's code that can be used for any general 2D game on PC. The current code was derived from my previous take on this concept (which is still shown in the GMod repo) and is nearly complete.
One of the problems I faced in GMod was performance. Because Starfall (the addon I used to present BRIX in-game) is also written in Lua, there's more overhead code that sandboxes the game code inside of the main code. And anybody who has ever tried to play a brick stacking game (at fast-paced speeds) with an inconsistent framerate can probably agree that it's vital that your FPS doesn't drop below 60.
The method of drawing images to the screen has been done before, but isn't a common thing to do unless you're going for performance. GMod in particular was set up so you'd first have to tell it which image to draw, then all future image drawing functions would use that image until you told it to use a different one. I found that was an expensive thing to do, so I leaned towards making only a few sprite sheets for the game with the most common sprites found in just one file. Then for each individual sprite, a lookup table would be used to define the coordinates of them on the entire sheet, then draw that rectangle onto the screen.
Also, Starfall was limited to a small number of user-created materials. That is, any Starfall processor in a Garry's Mod server is limited to creating up to 40 custom materials, probably to deter malicious users creating many materials at once and crashing the game. That's one of many security features Starfall implements to keep nefarious script kiddies from going on random servers and crashing everybody on them.
I could go on and on about each and every reason why I made the choice to switch to Love2D, but the main reason was to have a way for anybody to play--nobody should have to own Garry's Mod to play.
That, and I can draw thousands upon thousands of sprites at once with the game hardly slowing down at all :)
It's not entirely necessary for this game to be able to do that much. In GMod, this game was running pretty smoothly considering what was on the screen at any given time. I pulled it off with a pretty easy technique, though I didn't know about it until I started hitting performance issues in GMod. The old code would store a buffer of a displayed object (if it was necessary for optimization) and only re-draw its contents if they were marked as invalid. This would happen if a piece moved on the screen, your opponent clears a line on their tiny board on your screen, etc.
Looking forward to working on the rest of BRIX! The next few things to get done in the engine are: the object tree, input management, audio, and networking. The goal is for those components to be as general as possible; no game-specific functionality. I've been trying to keep a schedule for myself on my personal projects, which I'd like to be every other day after work. As this project picks up speed again, I think I can see that happening.
Anyhoo, thanks for the read. Hope ya learned something, and cheers :)