Up to date as of July 2021.

ggez is a lightweight cross-platform game framework for making 2D games with minimum friction. It is written in Rust, and is both my first major Rust project, and my first major and consistent contribution to open source software in general. I started writing up a blog post of a sort once a year, just to discuss what ggez has done in the last year, and what the goals for the next year are. So without further ado…

ggez 0.6 is released!

Huzzah, at long last! The goal was to do this in early 2021, keeping up with the informal one-big-release-per-year schedule. By February the release was more or less 90% done… and I was well and truly burnt out. More on that later. But we made it in the end.

For ggez itself though, 0.6 is an incremental but significant improvement over 0.5 in many small ways:

• Many dependencies were bumped with minor improvements
• winit is updated from 0.19 to 0.24, which brings many large improvements, including bug fixes, better Wayland handling, better high-DPI handling, a new style of event loop that is harder to break on various platforms, more consistent event types, and more!
• nalgebra is no longer re-exported, and the entire public API uses mint types. This basically entirely decouples whatever math lib ggez happens to use internally from whatever the game writer wants to use.
• Slightly smoothed over error handling to make it compatible with the new incarnation of the std::error::Error trait.
• Improvements to canvas drawing, fixed some memory leaks in the rendering engine, and improved a few things in text rendering
• Some significant fixes to canvases and high-DPI drawing in general
• Many other small bits and pieces

So, going from ggez 0.5 to 0.6 isn’t going to change any worlds, but should make life easier and better in many small ways.

Turns out burnout is real

ggez is not a huge project, about 15,000 lines of code+comments and a few thousand more of text documentation. However, that’s enough that making significant changes to ggez is quite a lot of work, and enough people use it that I have to think pretty hard about it. Changes have to be tested on various platforms, examples and docs have to be updated, and so on. While most of the code is as modular as I believe is feasible, there are still a number of quite fragile systems involved in in graphics, render targets, transforms, text rendering and so on that are difficult to change without breaking something else somewhere, and dependencies can update and break them without much warning either.

It’s honestly fun and satisfying to deal with this stuff a lot of the time, and it gets one very involved in the Rust gamedev scene. Making a game framework designed to be accessible to beginners and useful to experts gets you personally talking with a lot of different projects like few other things will. It’s really great to watch people use ggez to make cool games or toys or whatever strikes their fancy, and since 2016 I’ve hung out, had coffee and traded war stories with probably 80% of the toolsmiths in the Rust gamedev ecosystem, either in person or online. They are uniformly wonderful people. ggez has directly gotten me at least one job (which I sucked at), offers for several more, and taught me far more about GPU’s, operating systems, and technology standards than I ever expected. “Toolsmith” is a position I quite enjoy, since I get to be the sort of person who knows a little bit of everything and connects front-line people who make stuff (such as game devs) with those slightly more removed who make tools to make stuff (such as the algorithm developers in glyph_brush, lyon, and so on). And I like using ggez myself for my own game projects, which swear I will finish Any Day Now.

But ggez also essentially does most of the stuff I want it to do. This means I don’t have many big improvements to look forward to, personally, just lots of tech support and small fiddly problems. Conclusively fixing the small fiddly problems is either impractical me alone (for example, font rendering is a moving target that is always getting better, because human text is Hard), or is best done IMO via a redesign of core parts of ggez (a number of canvas bugs come from a fundamental impedance mismatch between the LÖVE-like 2D API and the underlying graphics rendering hardware). Doing those would be interesting but also a ton of work to do well, and trying to tackle those and make ggez continue functioning at the same time is more than I can handle. I made a few small experiments to explore those designs, but never could summon the energy to carry them through to something practical. Plus my day job has continued getting more involving and more busy as I keep working on bigger and more exciting projects, which started consuming more and more of my inspiration and programming energy. (Pro tip: Anyone who wants to work in game dev, consider looking at robotics instead/as well. Most of the programming technology is very similar, to the point that a number of places use game engines such as Unity and Unreal to generate simulations!)

So by early 2021 it was pretty clear that I was done, and had to either hand off ggez to someone else, or just stop caring about it and let it slowly bit-rot. I made an issue asking for volunteers and got a number of very good responses, but by then work and life were taking a lot of attention, and my usual Seasonal Affective Disorder was in full swing with a pretty dismal spring. I’ve not been personally affected much by the COVID pandemic, thank Eris, but 2020 was still a pretty tough year and it’s only now getting significantly better. And now I had to do everything on ggez that I still had to do, plus talk to people and find a maintainer I trusted to keep going with the project.

So I just stopped looking at Github for a few months.

So long, and thanks for all the fish

I’m feeling a lot better now. Summer is here, I’m doing exciting stuff in my day job, and I’m eager to wrap things up nicely for ggez and hand them off. I went back to the issue tracker to try brushing away some cobwebs, only to find that several people who had expressed interest in maintaining ggez had started acting like they were maintaining it anyway during my absence… vetting PR’s, responding to issues, and submitting bug fixes even if none of them had permissions to merge anything. This wasn’t exactly the way I had hoped to find maintainers, since asking someone “hey you want to do a pile of my work?” and then vanishing for a season is pretty rude, but it seems to have been effective nonetheless. It’s a somewhat weird experience to fix a rendering bug by writing up a maintainer’s code of conduct and forcing a handful of strangers to agree to it, but that’s what I did. I’ve pushed the baby bird out of the nest, and it’s flying free.

In the process it’s made me think more about the nature of human organizations, how such things form, run, and fall apart. When a bunch of friends get together to make something, there’s a fairly natural, tribal-ish structure that evolves because all the people involved talk with each other, hang out together, have similar goals, and know how each other think. This is an extremely human thing to do, that has been done by small groups of people since long before written history. However, the natural maximum size of this group is about 5-7 people, more or less the maximum size you want for a Dungeons and Dragons party. Once the group becomes bigger than this it naturally divides into sub-groups which do different things, operate slightly differently, and it’s more difficult for everyone to always be on the same page if only because they operate on different schedules and have more things going on in their lives. It’s harder to get everyone in the same discussion at the same time, have them actually participate in the discussion, and have them invested in the same parts of the project. This is just the pattern of human nature, and the way these groups break up and self-organize often leads to a hierarchical structure of some kind or another. If things are handled well, then it becomes a few different groups of friends all working together harmoniously, usually held together by a few key personalities. If things are handled poorly, it degenerates into politics, cliques and infighting. If the group breaks up on bad terms and there are physical assets, significant intellectual property or money involved, then that’s when it gets really messy and the knives and layers come out.

So when getting un-involved something I’ve spent years of my life on and handing it to, frankly, a few people I don’t know very well who haven’t worked together before, what do I do? I’m not just passing the torch here, I’m setting a precedent for how ggez as a project should be run, and I don’t want to half-ass it. This is where the technology of human systems comes in, and fortunately there’s a lot of advice and examples for how to do this for open source projects. There’s also recently been some rather sordid demonstrations of how such things can fail when you don’t do this and just stay at the level of “groups of friends operating together”. The solution is really quite simple in concept, and goes back to the dawn of civilization: Write things down.

More specifically, write down a set of rules and guidelines for what the project’s goals are, how it intends to achieve them, and how you want people on the project to behave. There’s some good advice out there on how to do this for open source projects, which I luckily discovered quite early in ggez’s history. So a lot of the groundwork was already there. There is now also a Code of Conduct specifically for ggez maintainers, explaining what the expectations and ideals are. ggez is still small, and will likely stay that way, so that’s probably all that is needed for now. Anyone who wants to maintain ggez in the future should open an issue and talk about it with the existing maintainers, and agree to the Code of Conduct. If a maintainer can’t or won’t uphold the Maintainer’s Code of Conduct, they should step down. There’s no real process besides that. But 99% of the actual code changes that people might want to do to ggez can be done via normal PR’s, so maintainers really are just the ones who keep things running, keep standards high and set long-term technical direction. Any arguments about this should be solved by consensus, should be done in the open on the issue tracker, and should be written down. For the foreseeable future, that’s probably enough.

There’s been some occasional discussion on the ggez issue tracker of donations, bug bounties, etc. I’ve avoided dealing with such things in the past mainly because that means having to deal with actual money, and I personally wanted to avoid that unless it I was working on ggez as my full time job. For example, I have a Patreon that various people have donated a bit to for supporting my work on ggez. Thanks to all those people, as it really helped keep me motivated in some rough times, and I’m happy to say that asking for people to give me money is now more trouble than it’s worth. However that Patreon has never been donating to ggez as a project, it’s been to been donate to me personally to work on ggez, and I hope that has been clear. The issue is that if significant amounts of money get involved in a project with multiple people cooperating on it, the project must have a way to manage that money sensibly. That means creating or being sponsored by some kind of non-profit or other legal organization so the money only gets used when people agree about how it should be used, and everyone knows how those people are chosen and how the decisions are made. This a good way of preventing some really bitter arguments, and is also is the societal API hook that lets disputes get resolved by the legal system in a semi-reasonable way and protects against exploits in the system such as the Freenode debacle. So, take that advice into the future.

Enough meta-talk and philosophy. Let me introduce the new maintainers:

• PSteinhaus, who has the diplomacy and coordination to handle communication better than I can
• nobbele, who has the skill and persistence to dive in head-first on difficult technical issues
• IGBC, who has the desire and inspiration to add features and keep working to make ggez better

Those three are now the owners of the ggez github and crates.io groups. I am removing myself from the ggez github and crates.io groups entirely, but will definitely still be using ggez in my own projects. This means I will probably keep up on relevant issues and discussions anyway from time to time, and will probably contribute code and maybe help with design and upkeep if I find time and motivation, but any contributions I make will just be in the form of pull requests like everyone else’s. svenstaro, one of the original creators of ggez, will remain as admin on the Github organization and crates.io group as a fallback in case everyone else suddenly vanishes off the internet or something. He’s crazy enough to be maintainer for something like 200 Arch Linux packages already, so being the last-resort responsible person for one more thing doesn’t bother him much. He’s also the owner of the ggez.rs domain name and has kindly offered to keep paying for it for the foreseeable future, since it’s basically pocket change and all the actual website stuff is done through Github Pages.

ggez has taught me so much. Last lesson: how to let go.

So that’s it. I’m moving on, and ggez is moving on, and our paths will probably only lightly intersect for a while, and that’s fine. I look forward to seeing where it goes. For everyone who ever saw something cool and said “I want to make something like that!”, this is a tribute to your determination. Glory to all the zealous challengers!

(My friends make fun of me for being a workaholic, so what will my next major project be? Well, it hasn’t come to much of anything yet, but I’ve always wanted to make programming languages…)