And here we are now, a month after launch on itch. I've been working hard on getting the steam version ready, too. Learning how to do steam achievements in Love2d (which is interesting!). I am toying around with other ideas now, my mind is already thinking of the next project. it's not ready to code it just yet, but soon! If I do use Love2d and Lua for the next one, I plan on building an achievements library that leverages steam but also allows people who got the game elsewhere to store achievements locally. Why should steam players have all the fun?

My original thoughts, about halfway through Emberglass, was to create a robust game engine as my next project, something for me to easily make games after this. I was going to open source it, etc. But now, after emberglass (and after attempting and tossing aside some half finished messy engine code), I realized that what I want is a series of mix and match libraries I make in Love2d. Things I can just plop into projects as needed and use piecemeal. Rather than one ur-system, these small interoperable libraries would allow for quick and nimble development. Anyway, that's the thought at least.

So in a way, this is a post-mortem. The reason why I switched from an ur-system to libraries was because of what I learned making Emberglass, and looking over what worked for me and what would work for future projects. I wanted something that was versatile and strong, and an ur-system is not versatile. No matter how loose you make it, it will either do too much for the programmer or too little. And in either case, it's hard to make it flex and sing when challenges arrive.

There was so much I learned while making this game. Libraries that were new to me, how to use TileD, etc. TileD was one thing I would do completely differently for my next project! I didn't leverage things like wangsets and tile stamping, nor object tiles or any of the tools TileD gives you (like projects!) that would've made my map development time go a million times faster. Instead, I had to manually go in and design things like the rock faces and the ground and do it for every single map. This was a long and painstaking process, and the end result does have a nice, natural organic look. But it made map building such a chore, I would spend a week or so on a single, small map. This was far from ideal.

Near the end of the project I delved into the tools inside TileD that would've made this so much easier, but it was too late. The game was nearing completion, this would have to be for the next project. Some other things I picked up while building emberglass- a better way to do object collisions. Really, I know collision math on my own (just some simple bounding box vectors), but I wanted to speed up development, so I used a Lua collision library called Bump2d. It had some great tools, but after awhile I quickly learned the drawbacks to using a pre-build library for something I could code myself in an hour or two. There are flaws, yes.

Though some of the things I was able to do where really cool, and stuff I will definitely use for future games. It had been a few years since I made a game with a framework from scratch (and yes, Love2d is a framework, not an engine. it does very little for you, and that's how I like it), and I was able to bring in a lot of stuff I'd learned from my dayjob as a software engineer. Debugging, for example, was a skill I'd learned doing it work every day for over a decade, and I was able to very quickly dispatch of any bugs that popped up in the game. This was exciting! So many half finished games in the past, due to crippling bugs. Not so much here. I even created a very robust debugging library that overlayed the screen with all the debug stuff at the press of a button. Amazing. And it was loose enough code I could easily use it as a library in any future engine.

One thing I would do differently in future games (and something I learned working on DeathKart) was creation of a robust scene stack library. The Finite State Machine that controlled Emberglass was all hard coded in the main.lua file, and this was not ideal. It worked great for this game, and did exactly what I needed it to do, yes. But near the end of development it was becoming unwieldy, but was too baked into the game to refactor. I just made notes for the next game, and used the code that I had to do what I needed to do.

This was, ironically enough, supposed to be my "simple game". I kept working on complex RPG's (those half finished game engines), with item management, complex conversation trees, etc. So with this game I wanted it to be bare bones, and the barely any menu system. Menu systems are a bear to code, so I wanted this one to have at most an option menu in game and a start game load/save/etc. Not even multiple load save states, just bare bones. This was on purpose. No conversations during the game, also on purpose. Simplify, simplify, simplify!

This turned out to be foolish, the game was not simple at all. What I lost in complex UI and conversation trees I made up for in combat mechanics and programming gravity and jumping. Some stuff was simple, I'd coded it before after all. I just had to use the same logic, and there you go. Change of day and night, weather cycles, all stuff I've done in the past and knew exactly how to do it in quick and timely manner. Basic combat, sure. And I was smart, I used object oriented coding for the enemies and the items. This made item and enemy creation a snap, I would just inherit the main object, and then overwrite the functionality for the AI and the item use commands. Not too shabby, and this was probably the best part, and what I'm going to take forward in other projects- easily creating and extending world objects.

So, some other stuff. I also had to learn how to make levels and maps during this game. All my half finished games in the past only had a handful of maps or levels, and nothing of this stature. I had to figure out how to layout where to jump, I had to figure out where to place enemies so that they were a challenge, but didn't overwhelm. I had to figure out how to make bosses interesting and puzzles in and of themselves. This was complicated, and interesting, and fun. But also? A lot of work. I learned so much.

So, even though I've been making games as a hobby for close to 20 years, this was the first game I made completely all the way through. A decent sized game (not gigantic), with lots of maps and items and everything else. The actual map and game development (and sheer amount of pixel art) was all stuff I learned on the fly and had to figure out through trial and error. I think for a first game it's really okay. I learned a lot, and was able to put to use the stuff I'd learned from my dayjob but also in the 20+ years of fiddling with video games on the side.

What's next? I have a few ideas and projects. I'm not sure if I'm going to use Love2d for my next project. I might, but it is a lot of work doing the code. I'm looking at Godot and Gamemaker and the rest. I'll probably just stick with Love2d, but I'm keeping my options open. I won't use Unity, though. It feels like an overkill for what I want to do. And that's just make 2d games for fun. The engine coding part is the part I liked, so it might not be Godot or Gamemaker or any visual coding environment. Though I might try my hand at Genesis/Master system coding, since I do know C and that seems interesting and fun. Or I might learn Monosharp and XNA. I don't know yet! The sky is the limit. I'm even tempted to make DOS games in Allegro and DJGPP again (that's where I got my start, back in the day) and distribute games with DosBox. Would be cool and fun. Dunno!

But for now, it's probably going to be Love2d. There is just something about it that's familiar and interesting and easy for me to pick up and sketch game ideas.