A brief update on my game project
It’s been a month since my last update. I don’t have substantial updates on my game project, but this post is born directly from my work trying to organize The Honor Sagas.
What is Khonsubase?
Khonsubase is my attempt at providing a lightweight project management solution that provides some of the rigidity of issue trackers – such as JIRA, GitHub Issues, and Redmine – while still being very lightweight. The overarching goals of the project are:
- Support issue tracking and a wiki/knowledgebase that shares a unified Markdown syntax
- Be intuitive and help users not accidentally miss work because of a shortcoming of the tool
- Be incredibly easy to self-host
- Be fast and lightweight
- Support what I think are important issue-tracking features:
- “Infinite” issue hierarchies: Subtasks sometimes end up being more complicated than you expect, and so you want to create a subtask for your subtask. There shouldn’t be a limit to how far you can nest.
- Customizable Taxonomy: Tags are incredibly powerful when paired with the concept of tag groups or tag categories.
- Easy progress tracking using point-based estimation
- Permissions system
- A solution for providing a roadmap that spans multiple projects and supports private and public views of the same roadmap.
- Built-in tools that help administrators handle GDPR-related problems, such as having time-expiring private attachments and tools to help find and scrub old data that might contain personal information
- Support Confidential Issues – a flow to allow private information to be reported and access to be limited to trusted staff
The project, as with basically everything else I’m doing, is written in Rust using the async-compatible development branch of Rocket. It uses sqlx to talk to PostgreSQL with compile-time type-aware SQL analysis.
What’s the status of the project?
It’s still early-in-development, and I wouldn’t recommend other people use it yet. However, as of yesterday, I reached a personal milestone: I am now eating my own dogfood by managing my tasks using Khonsubase. To reach that milestone, I implemented basic support for projects, issue hierarchies, issue relationships, issue revision tracking, and more. But, it’s still missing many critical features – for example, no one can sign up for an account yet.
Currently, I’m still developing my personal vision for the project out and am hesitant to accept collaborators this early. Much of the remaining design is still in my head. Once the project is further along, I will gladly welcome additional collaborators.
Until then, if you’d like to follow along, feel free to watch the progress on GitHub, talk to me here, on Twitter, or on Discord.
Why in the world are you writing an issue tracker when a bazillion already exist?
In short, none of them are perfect fits for my personal vision of project management. If you want to understand more about that, read on. If you’re just here to find out about the project, you can safely skip this section without missing any tantalizing details about the project. To answer more completely, let me start with my use case:
I’m essentially running a business. I’m not focused on revenue or profits at the moment, just on building cool things and seeing what comes from it. I want most of these cool things to be open-source and freely available for people to use and/or learn from. I want most of my game project to be open-source as well, but there will be some private code to hide important details that would otherwise make the game not a mystery to players. Similarly, I will want to manage some of my tasks privately while I want to manage other tasks in a public-facing manner.
To give a concrete example, Kludgine is the 2d engine that my game is being built atop. It’s an open-source project. Eventually, I hope some others might find my engine fun to use. That means I will want to allow users of Kludgine to see that project’s roadmap, allow them to submit issues, allow some to participate in the development, and so on. I will also often develop features in Kludgine that are to support features in my game, and I want my issue tracker to help me track what issues block other issues, including when I bridge across a public/private boundary.
To my best knowledge, no issue tracker fits that use case. GitHub Issues as of the writing of this post does not support actual issue relationships and blocking statuses. Its cross-project management is also very limited, and I grew frustrated with it when trying to use it. Most of the other alternatives require you to pay per-seat, which limits the usefulness for open-source projects.
GitLab Issues is another very viable candidate. It’s much more feature-rich than GitHub Issues, and it even supports issue dependencies. However, “Epics” are a Silver-level tier, which to me starts getting a little too pricey for my needs. Additionally, there were worrisome events with their telemetry rollout that they then rolled back after a huge public outcry. I think their products are great, but I wonder if they might reverse course in the future or do something else I would disagree with. Regardless, for me, the price alone was a dealbreaker.
Over the 10 years of running the tech team at my last startup, I tried a lot of products. I honestly didn’t try as many in this go-around, but I’ve been struggling to find a tool that fits my desires since I quit my day job in November 2019. I know that there are capable self-hosted options, but I also have had a lot of pain maintaining self-hosted trackers in the past.
I almost convinced myself to write this project back in July of last year. At the start of the new year, I was trying to bend a combination of project management tools to my will. I was growing frustrated and started being tempted by starting this project again. It just didn’t feel that hard to build what I wanted, but I also knew it would take me away from my primary goals.
Amidst these thoughts, I stumbled on Why Jira Sucks on Hacker News. Following that up, one of the entertaining game development podcasts I listen to also talked about how they were switching their project management tools for the second time in recent history.
With all of that momentum of hearing other people not being satisfied with their tools, I started this project on January 2. It’s been fun so far, and I’m happy with the progress so far. Will my tool solve all these people’s issues? Absolutely not, but I was no longer feeling “wrong” for wanting something different.
What’s next?
I haven’t settled on an exact set of features I’m aiming for before switching back to coding on my game. I’ve still been dedicating some time each day to fleshing out my plans for various aspects of the game. I think in the next two-to-three weeks, I’ll have enough of Khonsubase implemented that I will be ready to pick up the development of the game again.
As I was writing this post, I started diving into some of my joys and pain points that I encountered while developing. I quickly realized that this post was already long enough, so I’ve saved off that as a draft and will soon post those thoughts. The summary is that I feel like Rust is ready for general purpose web development, despite a few hiccups.
Thank you for reading about this project. Developing projects solo during the COVID-19 pandemic can feel like an echo chamber sometimes. If you have any thoughts to share, I’d love to hear them in the comments below, via email (jon at the root domain of this website), on Twitter, or on Discord.