Here’s some waffling about 2019 and 2020.

Current State of Bolero

Quick recap: Bolero is a platformer engine / core that I’m working on. It’s built on top of LÖVE, a cross-platform framework for 2D games. LÖVE games are written in the Lua programming language, and the desktop versions of LÖVE use a faster implementation of Lua called LuaJIT.

So far I have two versions of Bolero: the first was used in Hibernator, which I released in April. Bolero 2 is the current WIP branch.

Bolero 1’s core codebase was heavily tied to Hibernator. There was some attempt at code separation, but I also threw in a lot of one-off hacks in the core just for this one game. After Hibernator’s release, I forked the codebase to start working on Bolero 2, and it was a huge pain to undo all this stuff. Being my first real Lua project, I lacked experience with the language, but I also wanted to just get the game done, so I held off on making sensible changes in favour of inching closer to the finish line.

As of this writing, I’ve been working on Bolero 2, and the associated (still untitled) game project that it’s going to host, for about twice as long as it took to complete Hibernator, and I’m still a long ways from getting it done. While the new project is more complex, the longer development time is partly also because I’ve been more serious about restructuring and refactoring. For 2020, I will be resisting the urge to rewrite things and try to focus on just getting the game done.

My ultimate goal with Bolero is to have something that can load and run game modules, like LÖVE itself. Right now, it’s still just a set of source files that are embedded within a project. Maybe after this project is wrapped, I’ll work on restructuring Bolero 3 to behave this way.

Thoughts on LÖVE

Background: A few years ago, I was trying to learn a Python application framework (along with Python itself), but I was struggling with how to package games, and I was also experiencing some input lag when running my test projects on Linux. While researching alternatives, I came across LÖVE, and the straightforward hello world!  demo and its snappier Linux performance impressed me enough that I switched over immediately. I got busy with real life though, and didn’t come back to game projects seriously (or write much of anything at all in Lua) until 2018. As of this writing, I’ve been using LÖVE heavily for about eleven months.

Good stuff:

• It’s fast. In most cases it runs well above 60 frames per second if I disable VSync, even on hardware from 2012. I can usually start a test session within a couple of seconds.
• It’s pretty lightweight. The Windows version of Hibernator was about 14 MB zipped, and could have been under 10 MB if I hadn’t included some superfluous executables. The standalone .love file for Hibernator is 5 MB.
• It’s cross-platform, including mobile, and behaves pretty much the same on Windows and Linux. (I believe it’s the same on MacOS as well, but I don’t have a Mac handy to test on.)
• The documentation is very good.

 

There are some catches:

• Many game engine features are not included. The homepage’s title tag says “Free 2D Game Engine”, but more recent documentation refers to LÖVE as a framework. There is no built-in game object class, no animation system, no built-in scene / level construct, no UI widget system, and no save/load system (besides the functions to read and write/append files.) That’s all left up to the framework user. You need to either use 3rd party libraries developed by the community for those tasks, or fill in the blanks yourself. (One exception is Box2D, which is the basis for love.physics.) I’ve made the questionable choice of implementing a lot of these things.
• It doesn’t have any kind of editor component. Writing a LÖVE game begins with filling out a main.lua file with the love.load, love.update and love.draw callbacks. Eventually, unless your game is procedurally generated, you’ll want some kind of visual editor to work on the layout of rooms / scenes / levels / whatever you call your game state context. Tiled is a good general-purpose tilemap editor, and you can coax it into being an object placement editor as well, but it takes some time to glue it into your project.
• The API is subject to change between major releases. It’s clean and sensible as a result, but games made for older LÖVE versions may not work in the latest without adjustments. For example, the last major release changed color ranges from 0 – 255 to 0.0 – 1.0.
• If you don’t know Lua, then you have some reading to do before you get in too deep. In some other environments, you can kind of wing it without knowing the scripting language well, because a lot of tasks are handled for you. That’s not really the case with LÖVE. It’s a good idea to go through Programming in Lua, a book by the language designer. (The final part about the C API can be skipped.) Make sure you look at the version for Lua 5.1.

 

Overall I’m satisfied with it.

Plans for 2020

I thought I might get this thing done by the end of 2019… Har har. I’m aiming to have a sizeable chunk of the game playable by March, and hopefully have it done by summer. I’ll probably put a price tag on it — not that I expect any real success, but just to get used to the idea of putting a price tag on a thing that I made. Once Bolero (the core engine) is good enough, I’d like to release it under some kind of open source license, but that’s likely a ways off.

I need to manage my time better. I’ll be posting fewer public-facing devlogs going forward, maybe one at the end / beginning of every month, instead of one every week. In 2019, I had the pleasure of playtesting and collaborating with some folks on ZZT projects. This year, I’ll be stepping away, at least from the editing side of things, until I’m feeling more comfortable with the state of this project.

I guess that’s all I have for now. I’ll make my next devlog post on the 31st of January. Happy new year!