Wes Cook

Rigging Bingo

Thu, 26 Mar 2026 19:00:00 +0000

In my last post, I wrote about the Backlog Bingo project, which I created for the Tildes community. Since then, I’ve added a number of new features and tweaks to improve the app. One of the more interesting ones is a seeded randomizer.

The general idea is that you enter a text string as a seed when creating a new bingo card. This makes the randomizer deterministic, always selecting the same categories during generation for a given seed, which allows you to share it so that others can play along.

The difficulty here is that JavaScript is a high-level language. It doesn’t give you control over the random number generator, other than choosing its range. We can work around this by creating a custom PRNG function, utilizing math operations to create something approximating randomness.

There are several popular algorithms, such as Mulberry32 and xoshiro128, each with different levels of speed, entropy, and range. I opted for a variant of SplitMix32 with improved constants, which met each of my requirements.

The app uses text-based seeds because they’re more human-friendly, but a PRNG requires an integer. For that, we need to hash the string to get a usable value. Hashing functions also have trade-offs, this time in speed, distribution, and collision frequency. Since a full cryptographic hash wasn’t necessary here, I chose DJB2a for its balanced profile in all three traits.

When put together, it looks something like this:

const hash = DJB2a(seed);
const rng = (seed) ? splitMix32(hash) : Math.random;

The reference to rng must be held, as recreating it with the same seed would reset its sequence.

I then needed to update any functions that used randomness to accept a custom PRNG. I didn’t need to replace all calls, though; only those that affected the final bingo card layout. I added an optional parameter to accept an rng value, falling back to Math.random if none is provided. For example:

shuffleArray(arr, rng = Math.random)

I could then plug the custom PRNG into the functions that select categories and dynamic values, ensuring the final bingo card is fully deterministic.

Backlog Bingo

Sun, 28 Apr 2024 18:30:00 +0000

In November of 2023, I participated in Tildes’ annual Backlog Burner event. It’s a community-run event where participants play through unfinished titles in their gaming libraries. As somebody with a backlog that never seems to shrink, this seemed like the perfect opportunity to finally make some progress in mine.

One of the ideas proposed for this year’s event was to use personalized bingo cards populated from a large selection of categories. A category might, for example, include playing a game with an animal protagonist, or from a now-defunct studio. These categories would be randomly selected, and participants would then play games from their backlog to fulfill the category requirements. The bingo cards themselves would be shared as Markdown tables when posting progress updates.

Though a fun idea, there wasn’t a simple way to generate these tables for each user. To help streamline the process, I offered to build a little web app to automate things. It first allowed the user to uncheck any categories they found impossible to complete, then selected randomly from the remainder and generated a table with the result. The user would save this table, and update it as the event went on.

The Backlog Burner event was indeed a success, and everyone had a lot of fun playing games and sharing our thoughts. The bingo card system also proved to be a crowd favourite. There was no required way of playing, so some chose to submit one game per category, while others played in a “golf” style mode, aiming to complete their card with as few game submissions as possible.

Though everyone was able to understand the system, the biggest source of friction was definitely in editing the Markdown. The generator was designed to run only once, producing a table for you to edit. This saved a lot of time versus building it yourself, but Markdown tables are still difficult to edit by inexperienced users, and especially when on mobile. For the next event, I knew I wanted to simplify this process even more.

New Ideas

So in February when I had some free time, I reached out to the event organizer and pitched some ideas. I wanted the bingo card to live on the site with a simple editor, such that the Markdown was generated automatically on each change. I also wanted to introduce some additional features, while still allowing the freedom that users discovered while using the first version. The organizer was excited by these ideas, so I got to work.

Like the original version, I began by writing in vanilla JavaScript. For smaller projects I prefer to avoid adding too much complexity from external tooling or build pipelines. Working from my original codebase, I started by separating the logic out into different modules: game rules, categories, and the bingo sheet itself. For the UI, I still worked from a simple HTML file but used <template> blocks to swap between the different “pages” in the app.

Eventually I began to find the complexity ballooning as I added new features. State management was getting messy, and all the DOM manipulation required a lot of additional code to keep elements in sync with their values in memory. These are the kinds of problems best solved with data bindings and a reactive framework.

New Tools

So it was time to introduce new tools. I considered a few options, but ultimately decided to use Vue 3. Vue offers quick onboarding and great tooling, and felt like the right level of complexity for the job. I was unfamiliar with the framework though, and did need to learn how to properly use it.

Thankfully I already owned the course Vue - The Complete Guide, which came highly recommended. At a whopping 32 hours long(!) I ended up running through most of the course at 2x speed. I’m not normally one for video tutorials, but I did find the comprehensive overview helped solidify many of the important concepts for me.

The majority of the tutorial used the Options API, which was the only approach available when it was recorded. Today the Composition API seems more popular, so that is what I ended up going with. For the most part the transition was just a matter of looking up the new syntax. There’s a few gotchas, and it requires a deeper understanding of Vue’s reactivity system, but on the whole using <script setup> with Single-File Components is a very nice developer experience.

So returning to my project, I decided it would be better to start fresh than try to layer Vue on top of my existing codebase. I used Vite for a local web server, an upgrade from the Python 3 server I was running before. ESLint was added to keep things neat and consistent. I also configured GitHub Actions to automatically build the project when I pushed commits.

For plugins I opted to implement Vue Router for navigation, but decided against Vuex/Pinia for state management. Stores and composables in Vue 3 seem good enough for this purpose, and I still wanted to minimize dependencies where I could.

New Start

This time I started by laying down a more solid foundation. Before adding any app logic, I introduced data stores, interfaces for interacting with them, and routing logic. Being my third version of the project, I had a better understanding of the scope and structure going in.

As before, I began by implementing categories.

Category Lists

In the first version, I had simply hardcoded the categories into the app. Of course I wanted to go further this time.

I defined a JSON format for loading categories, called Category Lists. I added methods for loading these from a file or URL. Vue components made it very easy to separate out the rendering code while sharing parsing logic. Prebuilt categories for the Backlog Burner were also included, so they can be easily selected from the menu.

Because JSON is very flexible, I was able to introduce additional metadata to each category. For example during testing of the original version, I found that similar categories would often end up in a generated bingo card together. I decided to create a grouping system to bias the generator to discourage this from happening, keeping each card feeling more unique. If desired, this behaviour can be turned off in the settings.

Game Rules

Next, I created a game rules interface for customizing how the game is played. I wanted to keep the app simple to use and accessible, while still allowing for the kinds of customization that benefits power users. I broke it down into two sections: Game Rules and Game Modes.

Game Rules are individual settings that allow you to customize the bingo card generator and interface. You can edit your grid size, win condition, the behaviour of the star tile, and more.

Game Modes then are predefined loadouts for those rules, each defining a specific playstyle or approach. For example, the Golf game mode - as inspired by the first Backlog Burner event - allows entries to count for any number of categories, but requires a complete blackout to win (not just a single row or column).

Selecting the Custom game mode allows each rule to be individually edited, so you can completely customize your experience.

Refine Categories

As before, it’s possible to filter out any categories that are impossible for the user to complete. I knew this page would likely end up being a wall of text though, so I tried adding some features to make it more accessible.

Selection toggles were added for bulk entries, as well as individual groups. Color coding was also introduced to make groups easier to recognize at a glance. Colors are generated dynamically to maintain an equal distribution in hue, while their lightness and saturation are determined by the color scheme.

Dynamic Categories

Later in the process I added dynamic categories as a way of including more variety within a single list. This includes an on-demand random number generator and a phrase selector. These are parsed from the JSON category name using a special syntax and constructed into Vue components. I’ll share some details there because I felt it was an interesting problem to solve.

My first approach was to use a regular expression to convert these values into elements as strings, then pass them to v-html (which is essentially Element.innerHTML). This worked fine, but it felt problematic to accept arbitrary user input (as a JSON file) and extract that data directly into HTML. Even when following OWASP recommendations to sanitize against XSS attacks, it made me nervous. This approach also had the downside that it couldn’t work with Vue components as they are not executed as strings.

After thinking about the problem some more (and bouncing ideas off of ChatGPT), I came up with a system for iterating through the string manually to build new elements. It’s still based on regex, but instead of returning a mutated string we’re assembling an array of elements with metadata. Then in the template, we loop through that array to create real elements. No more need for v-html!

Tooltips

At first I used the title attribute as a tooltip to show possible values for these dynamic categories, but of course this is not very mobile-friendly. I considered some common options like Tippy.js which I’ve used in the past, but it was a little larger than I wanted to include in this project.

Eventually I found Floating UI, which is a lower-level library but comes in at a smaller size. It’s roughly a polyfill for the upcoming Anchor Positioning CSS spec, so I may be able to drop it completely when that becomes generally available (though at the time of writing, it sits at an impressive 0% on CanIUse).

Floating UI doesn’t include simple tooltip code by default, but it does offer all the features necessary to write your own. So by following their tutorial and writing a little CSS, I was able to get Floating UI integrated into a Vue component and rigged up for tooltips. Now my dynamic categories were mouse, keyboard, and mobile friendly.

Bingo Card

Finally it was time for the bingo page itself. Thankfully, due to all the prep work this turned out to be easier than expected. Vue’s data bindings made it easy to model the actual form inputs, and the various abstractions I’d written meant the data didn’t get too tangled.

After implementing the basic UI and saving/loading, I wanted to add some logic. More than just storing your bingo card, the page should communicate things like invalid states or if you’ve won the bingo.

For win detection, I started by creating a list of possible win states. These are determined by the current win condition and grid size. For example if the win condition is “Row, column, diagonal” with a standard 5x5 grid, that will create 12 arrays: 5 rows, 5 columns, 2 diagonals. Each is mapped to the category IDs that make up that line, and if all are filled in then a win is detected. The function also returns the winning tiles so they can be styled differently.

Duplicate entries are also detected. In standard mode, any tiles with the same value will be grayed out, preventing a win until they are resolved. This behaviour can be disabled with a custom game rule, or by playing in the Golf game mode.

Accessibility

Though I’m not an accessibility expert, I try to follow the best practices and meet WCAG recommendations. Tap targets have been enlarged for mobile, and hotkeys for navigating tiles were added to desktop. I implemented ARIA roles on the tooltips, and remained mindful of semantic elements.

The app supports both light and dark mode, with hand-picked colors for each. I checked each page against common forms of color blindness, and verified the contrast levels meet recommendations.

Adding Delight

More than just functional, I wanted the app to feel delightful. I wanted players to feel excitement when completing their bingo card.

When your card is first generated, each tile starts facing away from you. The tiles then begin to flip over one by one using a 3D CSS transform to reveal their category. The animation speeds up to a flurry before dramatically pausing on the final, centermost tile.

Although I think it’s a lot of fun, I knew an animation this long could annoy some users. I made sure to include a Skip button, and to also respect the prefers-reduced-motion preference for those users with a sensitivity to motion.

Of course, the win detection needed some pizzazz, too. I opted to incorporate the lovely fireworks-js for a dazzling finish.

In Closing

This started as a fun weekend endeavour, but quickly turned into a more ambitious project. It involved a lot of learning, planning, and development. I’m extremely happy with the end result though, and am beyond excited for the next Backlog Burner event in May where we’ll be showcasing this new version.

As always, the code is licensed under MIT and available on GitHub.

Handy Dandy Notebook

Tue, 25 Oct 2022 16:00:00 +0000

Melvor Idle is an idle (or “incremental”) game based around the RuneScape IP. I started playing this one during a period where I was put out by renovations and had no office space. It kept me busy and paired well with audiobooks, another hobby of mine.

Mod Support

Melvor released an expansion last week, and with it came an official mod manager. Now writing scripts for idle games is not uncommon (for many that becomes the game itself), but official mod support for a web-based game is something I’ve never seen before. I was impressed and wanted to take a look.

I spent the first three days of the expansion tinkering with the new API and mod manager. The API is great, and offers useful hooks, storage features and lifecycle events. That’s everything you need to write a mod. The development experience however left much to be desired.

At least at the time of writing, you’re required to zip up your working folder, upload it to a third-party website, and then download the files through the game. This added significant development time compared to testing locally. The hosting provider also seemed to experience frequent caching issues, which means you’re never sure if your changes have synced or not. I admire the developers for integrating mod support at all, but this is a major hurdle right now.

First Mod

The first mod I wanted to write is a notepad widget for keeping track of goals and other information. Inspired by one of my favourite cartoons as a lad, I named it Handy Dandy Notebook.

Melvor makes heavy use of a library for creating modals called SweetAlert2. To maintain visual consistency I opted to use the same, which turned out to be a major decision. SweetAlert takes care of all the visual design and accessibility features which let me focus on the content, so I was pleased with how quickly it let me get an MVP up. I did however start to run into design considerations that did not include my use case. I was worried I’d have to rewrite the modal functionality myself, but eventually all problems were resolved or worked around.

As modding for this game is still at its infancy, a lot of things have yet to be standardized. One question I had was “where to place the notebook button”? After consideration I decided it’d be best to just let the user decide, so that’s been exposed as a user setting. I added a second setting to disable animations for low-powered devices such as older Android phones.

One of the biggest concerns I had going in was how to handle storage limits. Each mod can store a maximum of 8KB per character. If I went over that limit, the game would simply refuse to save and people would lose their notes. I built in a couple levels of safeties to prevent this from happening.

First, the game calculates the byte length of the input string. It issues a visual warning at 7,300 bytes, and physically prevents further typing at 7,800. This allows some headroom for the JSON encoding and future additions. While it’s less accurate, I also used the maxlength attribute as a secondary failsafe.

If you’re curious, 8KB is about 14 paragraphs of Lorem Ipsum.

Release

The reception has been very warm. A number of commenters have shared that it solves a real problem for them of needing to keep text documents or real notepads. I often keep a todo.txt file handy for the same reason, so that was definitely a main motivation for me in writing the mod.

On the very next day after release, I realized I could have squeezed another 40% out of the available storage space by gzipping the note data before saving it. I regret not considering this before. I wrote up methods to encode, decode, and test for gzipped data, but at this point I’m too hesitant to risk other people’s notes from a bug. For now, I think I’ll sit on the code and see if the existing storage limits prove to be a problem.

Conclusion

Although the development experience currently leaves much to be desired, I’m still thrilled to see official mod support in an online game like Melvor. I already have ideas for other mods, but may give it a little time to mature before starting another project.

Handy Dandy Notebook is available for Melvor on the web, Steam, or mobile. It can be subscribed to directly from the mod.io page or using the in-game mod manager. The source code is available on GitHub under an MIT license.

Steam Market List

Fri, 02 Jul 2021 22:00:00 +0000

For those with large Steam libraries, trading cards have been a way of earning store credit in exchange for a little time. They can be listed on the Steam market where you’ll receive a few cents for each card purchased. With enough cards, this can add up.

I’ve avoided bothering with this process until now because the time investment really didn’t justify the return for me. But with enough automation, it’s not unreasonable to be able to earn a few free games from the setup cost alone.

Tools already existed for idling cards and listing them on the market. The final step for me was automatically confirming every market transaction.

Valve have added various protections to their market over the years to prevent issues of account theft and scamming. Market transactions can be verified either through their mobile app, or through email. I decided to use the email method as it’s easier to automate.

Every market transaction generates one email. That email includes one button to create the listing, and another to cancel it.

Because I’m generating hundreds of transactions at a time, this would take a lot of manual clicking to complete. I opted to write a tool to scrape these emails for the confirmation links then exports them into a big list. Gmail automatically caps each email thread at 100 messages, which is a good number to work with in batches.

My first thought was to write a Greasemonkey script, but the Gmail source was very soupy and difficult to parse. It is also likely to change frequently. I decided instead to investigate Google Apps Script.

I’d never used Apps Script, but it’s pretty cool. It exposes an API to perform work on Google services. I was able to whip up a script to loop through my inbox and generate a list of market confirmation links in about half an hour.

The default option was to create a web app, but I also noticed the option to export as a workspace add-on. Add-ons are those mini apps that sit in the Gmail sidebar. I decided it might be worth the convenience of having this functionality built into Gmail, so I gave it a look.

It turns out that add-ons require considerably more effort to create. Rather than running straight on the Apps Script engine, they require you to set up a Google Cloud Platform project. This then requires defining IAM roles, OAuth scopes, and numerous API integrations.

After setting up the project, I needed to learn the UI toolkit. The add-on UI system seems to behave similarly to Android, whereby “pages” are cards being pushed to and popped from a stack. I ported over the logic and wrote a minimal UI for interacting with.

With that complete, I was able to generate a list of confirmation links with one button press. These URLs can then be fed into something like Postman to generate network requests.

To keep it simple I found a Chrome addon that opens all links for you, which I then discard. This saved me from having to extract the Steam login cookies into an external tool.

I decided not to publish the add-on for public use as it’s not very polished, and it’s an admittedly niche use case. If there’s much interest I can look into that though.

I’ve published the source code for both the web app and add-on version of Steam Market List on Github. Basic install instructions are included if you’d like to set it up yourself.

Peppers

Sat, 14 Nov 2020 03:00:00 +0000

I finally tried my hand at gardening this year. As a huge fan of spicy food, I was excited to try growing chili peppers.

To say I was a novice would be an understatement. A good friend who’s been growing for years helped me get started. He walked me through germination, soil types, and the basic equipment needed.

Generously, he also sent me the seeds of some interesting pepper species. The varieties were:

Bleeding Heart Yellow
Brazilian Pumpkin
Carolina Reaper
Count Dracula
Jorge’s Small Mexican
Pimenta Kathumby
Red Lightning Habanero
Rooster Spur
Uchu Creme
Variegated Purple
White Thai
Wild Brazil

I’m thankful for all his help. He sells a huge variety of seeds which you can find at MattsPeppers.com.

I’ve included a gallery of progress photos. Forgive the older camera; it’s long in the tooth at this point.

Prep

March 11

I started with 12 species of seeds. I soaked them in water for 24 hours to weaken the shells and improve germination.

I quickly ran out of containers and resorted to measuring cups.

Planting

March 12

For germination I bought a seedling tray. It contained a dome to keep in moisture, and a heating pad to keep the seeds warm.

With 24 cells available, I planted four seeds from each variety (side-by-side, with two seeds in each cell).

Sprouting

March 20 - April 10

After only eight days the first seedling sprouted. Very exciting! Before long another five cropped up.

Unfortunately that’s when progress tapered off. Of the 48 seeds I planted, only six sprouted in three weeks. Those six were doing well, but with a smidge of disappointment I turned off the heating pad.

Late Bloomers

April 16 - May 24

It seems I was too impatient, as within another week I started seeing sprouts from almost every cell. Soon they were all rapidly growing.

Sadly the reapers never germinated at all. I later learned they’re especially tricky, and I should’ve planted more seeds.

First Transplant

May 29 - June 16

At this point they were growing too large for their cells. With the confidence of someone who just watched a YouTube video on the subject, I began transplanting them to new pots.

You can see what’s either a count dracula or variegated purple starting to show its color.

First Flowers

June 19

After three months, flower buds began to form and open.

June 22

Today the plants got a little parched from the heat. I brought them inside and rehydrated. They bounced back within hours.

June 29

Back outside and continuing to grow strong.

Second Transplant

July 13

By this point the largest plants had long-outgrown their pots. I bought 12 fabric bags for the next stage and transplanted them again. I didn’t have any soil to fill them unfortunately, and delayed a couple weeks longer than I should have.

Fruiting

July 14

Four months in, the first pepper began to grow. It was a variegated purple.

July 16

I didn’t have enough fabric bags, so a few plants had to stay in their previous pots. They quickly became root bound and floundered.

July 17 - July 24

Those that were transplanted continued to do well. The purple species were first to fruit, along with the Brazilian pumpkin (a pepper, not a gourd).

July 26

We had a small heat wave so I took the plants in for protection. Day and night shot.

August 5 - August 27

Those that did well continued to fruit.

I had the most success with the count dracula, Jorge’s small mexican, Brazilian pumpkin, variegated purple, and white thai.

Harvesting

August 27 - September 30

Truthfully, I hadn’t planned this far ahead. So with no greater ambitions I ate a few raw, and turned the rest into chili flakes. The color was a vibrant red as opposed to the darker store-bought flakes.

Over the next month I harvested what I could.

By the time Autumn was in full swing, the peppers stopped ripening. I plucked what remained and placed them on a covered plate to let them ripen indoors.

I enjoyed growing peppers this year. I found it quite fulfilling and intend to do more next year. I think I’ll try adding in some other crops, too. I’ve already ordered more fabric bags in anticipation.

There’s a few things I’ll know how to do better in the future. I know now I should have pruned the plants early in their growth cycle, and I should have transplanted sooner. This likely would have improved the overall yield.

In the end though I wasn’t too fussed about it. I was more interested in growing something for the experience of it, and from that perspective I’m really happy with the result. I’m already looking forward to next Spring.

Flair Keeper

Tue, 08 Sep 2020 22:30:00 +0000

I’ve spent my last few weekends working on a new web app. Similar to Steampunk Spider, this tool was built to aid in repetitive mod tasks. It was written for the Dark Souls network of subreddits.

The Souls subreddits offer a unique system of displaying trophies next to user’s names. Each game has a trophy, and the trophies indicate that a user has completed all achievements in that respective title. It’s a small boast of skill and way of showing an appreciation for the series.

The technical implementation of these trophies is a little messy. They are built on reddit’s flair system, and controlled by a unique flair code. Due to limitations of the platform, a spritesheet must be used to display the icons. Every permutation of trophy set needs to be programmed in for the flair code to function.

Previously these codes were entered by hand. It required memorizing the ID for each game, then stringing them together in release order. Along with case-sensitivity and variations on new reddit, this introduced a lot of potential for human error.

Adding a new game to the system also required a significant amount of work. Every new permutation needed to be manually coded in, and the spritesheet had to be freshly created. It was not an enviable task.

So when building Flair Keeper, I had two goals in mind:

Allow for a faster way to update a user’s flair (no entering codes manually).
Come up with a way to generate these spritesheets automatically.

I’m pleased to say that both goals have been met.

A simple UI allows a moderator to select which trophies they wish to enable. This produces a flair code for easy copying. It also allows for automatic import and export of a user’s trophies. The games are specified in a JSON config file, which makes adding new titles very easy.

The spritesheet functionality ended up being a fair bit more complicated.

Initially, calculating the permutations wasn’t that difficult. There’s plenty of code examples for generating the power set of an array using recursion. I adapted the code for JavaScript and it worked without a hitch.

However, during internal discussions of the project we came up with the idea to offer trophy “upgrades” for completing more difficult feats. This required a new variant system, where each trophy could have 1 of n available variations. This complicated the math, and increased the number of permutations exponentially.

I couldn’t find any research online on generating permutations with exclusive pairs as this required. And unfortunately, my own math skills were not up to the task. Thankfully I got some brilliant help from a friend who was able to crack this one wide open. The solution required generating a new recursive branch for each variant on every iteration (including the “base” variant).

The total number of permutations are ((x + 1) ^ y) - 1, where x is the number of variants and y is the number of game entries. As a result, you can only maintain a small number of games and variants before the numbers become too large to work with.

In our case, the total was only 728 permutations (6 games, 2 variants).

Once the permutations are calculated, the generator uses a JS canvas to draw the icons in a matching pattern. An image is generated from that canvas, and the CSS is printed alongside it.

This was the first proper ES6 project I’ve written from scratch. I was already a big fan of arrow functions and the .map features in ES6, but now I was able to work with some features I’d only touched on before. Specifically, async and modules.

This project required a lot of network functionality, so it was a perfect time to learn async techniques. While I have worked with promises before, I didn’t have a great mental model for how they worked under the hood. Being able to implement functions using both promises and async/await gave me a better insight into how they were really just two sides of the same coin.

I was also very glad to work with modules. In the past I’ve ended up writing massive .js files which encompassed the entire program. This time I wanted to focus on writing more portable code. Modules were perfect for that. They encouraged writing functions that were both pure and idempotent; basically little libraries.

One technology that was new to me was OAuth. I have used wrappers for OAuth in the past, but I’ve never needed to implement the details myself. It gave me a better understanding of how the authorization protocol worked. It was important to understand scope, state, and grant types.

My first attempt involved generating a refresh token manually and saving it to the config file. This approach was quick and easy to implement. However as I had the intention to host this on the public web, it presented too big of a security risk to send that information over the wire.

I went back to the drawing board and reimplemented the code grant flow on the client-side. This ended up being more secure and more flexible, as I was able to include user-specific functionality.

Flair Keeper was a lot of fun to work on. The scope grew as it always does, but the end result was better for it (which is not always the case). I’m still pleased with the quality of the code, and I’m happy I was able to learn some new technologies along the way.

Flair Keeper is open-source, and licensed as MIT. You can find it at the usual place.

Let's Play

Wed, 15 Jan 2020 05:00:00 +0000

The original Dark Souls is without a doubt my game of the decade. Everything from its interconnected world, skillful mechanics, and ever-deepening story shows the brilliance in its design. What really keeps me coming back though is the creativity of its modding community.

There’s mods to fix bugs and improve quality-of-life. There’s mods to increase difficulty and modify progression. There’s even mods which change and expand the world in completely new ways.

The relatively-new mod Daughters of Ash falls into this latter category. A massive expansion to the game, it adds new items, bosses, and storylines.

I’d been following its development for some months and was excited to finally give it a try. Almost on a whim I decided to record this playthrough. I thought it might be interesting to compare notes with others, and I was also looking forward to getting some experience with video editing. This would be my first “Let’s Play”.

I opted to use OBS for recording. I’m a big fan of free and open-source software, and it came highly recommended.

I didn’t start with a video editor. In fact my early episodes consisted of stitching mkv files together and uploading the resulting file. YouTube offers a rudimentary video editor which allowed me to trim and split the clips. It was rough, but it worked.

The first ten episodes or so came quickly. I was able to record them in rapid succession - usually one per day. As a result of the tooling I ended up keeping in most of the content unaltered.

Eventually however I started to run into limitations with my recording setup. I was only recording to a single audio channel, and that made it impossible to stifle coughs or other noises. I was also reaching a point in the playthrough which required that I cut out content more often. YouTube’s editor was not equipped for either of these tasks.

I decided to address the audio issue first. I looked into configuring OBS to record to multiple audio channels: one for the game, one for my voice. This necessitated switching into the “Advanced mode” but otherwise seemed to work just fine. I discovered that YouTube ignores multiple audio channels, so I had to remux them into a single stream before upload.

Next I needed a video editor. I shopped around before deciding on Davinci Resolve 16. As a professional editor it offered a lot more tools than I really needed, but it offered Linux support and the price was right. I spent some time recording sample clips and playing around with the timeline tools, transitions, and the other features I thought I’d need.

The first video was a disaster. It turned out that when I switched OBS into Advanced mode it didn’t preserve any of my original settings. I was so preoccupied with testing the audio channels I didn’t think to compare the video quality. The episode I recorded was so low-quality that I had to discard the entire thing.

I spent some more time getting the settings right. It wasn’t trivial to copy over the “Simple” preset, and it involved browsing a lot of forum pages and even the source code to understand what had changed. Eventually I got my settings worked out so they looked just as good (if not better) than the original preset did.

Equipped with some new tools, I started making real improvements to the quality of the videos. I was able to edit out any excess noise from neighbors or physical button clicks. Transitions became a lot more natural, rather than being hard cuts at every turn. I normalized the audio to make it more consistent. I also started experimenting with small overlays to add additional details (or sometimes just to laugh at myself).

One issue that I was never able to fully solve was YouTube compression. I could export a video at a crisp 1080p, but after YouTube processing it would turn muddy and dark. I spent a few days recording sample clips just to test different encodings and bitrates to learn how YouTube would treat it. After a lot of testing, I found some optimal settings and determined that anything above a bitrate of 20K would be lost to compression.

Other obstacles cropped up. It turns out that video files are pretty large. I had to buy a dedicated 1TB SSD to work on, as the optimized media for editing can easily exceed 600GB for an hour-long episode. A solvable problem, but now I was spending real money.

As I became more proficient with editing, it started taking longer to produce each episode. I wanted to get it all perfect: the sounds equalized, the content properly paced. All these little improvements slowed things down. I’d even started recording at night to try and reduce background noise. What had started as an episode per day had turned into one every 1-2 weeks.

I was producing better quality content, but the process had started feeling more tedious and unfun. Without my realizing it had become a second job.

This may be the curse of the perfectionist. The more options we have available, the more decisions there are to be made.

It reminds me a little of programming. When we start, we really don’t care about “clean code”, design patterns, or abstractions. We’re just excited to see our code work. It’s only with experience that we start to notice all the things that can be improved. Maybe that’s how it feels to become more proficient in any field?

By the time I’d reached the final episode, I was ready to move on. I’d learned - and not for the first time - that the perfect is the enemy of the good.

I am glad I embarked on this project though. I’ve learned a lot about video production which may actually come in handy in the future. I’ve also created something of which I can be proud. It might fluctuate in quality here and there, and the rough start might put some people off. But in a funny way it shows both my progress through the game and my progress as an editor. I can appreciate the symmetry of that.

You can find my LP of Daughters of Ash on YouTube. Big thanks to Grimrukh, the developer of the mod for his amazing contribution to the Souls community.

Hacktoberfest 2019

Sun, 13 Oct 2019 17:00:00 +0000

This year I learned about an annual event named Hacktoberfest. Hosted by Digital Ocean, it encourages programmers to contribute to various open source projects.

You can sign up at the Hacktoberfest page. Participation requires submitting four valid push request during the month of October. The PRs don’t have to be accepted, but they should be more substantial than simple typo or formatting fixes.

It sounded like fun, so I decided to try my hand at it.

I spent the first hour or so searching through the list of projects that Digital Ocean suggested. I found that I wasn’t familiar with most of them, and that many had sizable codebases. As I’m not very comfortable making code changes without first knowing a product, I decided to search out some projects I was more familiar with instead.

Ultimately I decided that although Java is not my strongest language, I have played with enough Minecraft mods to make useful contributions to that ecosystem. I began searching Github by the tag minecraft-mod.

I decided on four mods: AgriCraft, Cooking for Blockheads, Waystones, and Rustic. Each a medium-sized mod that I’ve used before.

I scanned their respective issues lists and found a feature request or bugfix from each that I thought I could do. This ensured that my PR would actually be welcome. With four issues picked out, I set off to work.

One thing that is never fun in Minecraft mod development is setting up the dev environment. Getting IntelliJ, Gradle, Minecraft, Forge, and the various dependency mods to play nicely can be like herding cats. This took some hours.

Once I got down to implementing the feature or bug though, it was actually a lot of fun. The problems became strictly logical at that point and could be worked through with enough perseverance. If something’s not working, it’s possible to trace it through the code to understand why.

I won’t go into detail of every PR, but these were my four:

In the case of the last one, I was happy to add a new feature while reducing the total lines of code by eliminating a loop.

All in all, it was a very dense three days of coding. Two of my PRs have been merged in already, and I’ll have to wait and see on the other two.

Hacktoberfest seems like a really fine idea to me. It’s encouraging people to get out and code, and to do so in a way that gets them comfortable contributing to open source.

I might participate again next year, and maybe get a little more adventurous in trying out some new projects or languages.

Contributing Code to Tildes

Sun, 08 Sep 2019 17:00:00 +0000

A few months ago I released a userscript called Tildes Focus. I’ve since refined the project and submitted it upstream, and I’m pleased to say it’s now been merged into the site.

New Feature

The feature works by expanding new comments on topic pages. Rather than using a keyboard input like my previous project, this version adds a button named “Collapse read” to the page. As you might guess, it collapses all previously-read comments to focus on what’s new.

The idea is simple enough, although the logic ended up being more complex than I was expecting.

The Logic

Tildes comments can be collapsed and expanded, which might lead you to believe that comments have two states. However in actual fact comments have three states. They are: expanded, collapsed, and collapsed-individual.

The first two are self-explanatory. Collapsed-individual is a special case where the comment is still collapsed with a brief preview of its contents, but its daughter comments remain visible.

The logic went through a few iterations. The first version collapsed all comments by default, then walked upwards from new comments to expand their parents. Nice and simple.

This almost worked, but created an inconsistency with the site’s server-side implementation. It seems only one “layer” of comments should be collapsed, where expanding the shallowest comment in a branch would expand all within.

After thinking about the problem for a while I decided to invert the logic. All comments would start expanded. We’d then find the shallowest comment within each branch and collapse it (solved by checking for an ancestor that’s collapsed, and a descendant that’s new). Finally, we’d walk up from all new comments and expand as appropriate.

This was an interesting project for a number of reasons. It gave me a chance to learn some new technologies. GitLab was a new platform for me, and while it has many similarities to GitHub there was still a slight learning curve.

Vagrant was the biggest technology to learn. In some ways it keeps things simpler by reducing dependencies, but it does so by adding a new layer of abstraction. If things go wrong there’s one more layer you need to unpeel to understand what’s really going on. And as it turns out, things did go wrong.

Troubleshooting

I was on Windows at the time which made me the guinea pig for setting up a Windows 10 workspace. This ended up exposing two significant bugs in the development process.

The first was a dependency on symbolic links. Apparently symlinks have been locked behind a security policy in Windows 10. This makes security sense as symlinks are a major attack vector, but led to folder sync issues between Vagrant and npm.

After some research, I fixed this by toggling the relevant security policy in secpol.msc. A more permanent fix was later implemented by Tildes to bypass symlink creation altogether and run the tools manually.

The second problem was that of line endings; the age-old Windows/Unix issue that just won’t die. The linter was looking for LF line endings, but git will by default checkout using your platform’s native line endings (which on Windows are CRLF). As a result the pre-commit hooks would consistently fail.

This was solved by configuring git to avoid converting line endings and triggering a fresh checkout, then manually converting the files I’d modified locally. The linter was then happy and let me push my changes.

The more permanent fix was to specify this behaviour in the project’s .gitattributes file.

With those problems solved, I was able to finally submit the new merge request. After a few rounds of discussion and tweaks, the project was rebased onto master and made live on the site.

In Closing

I was really glad to work on this one. It gave me a chance to play with some new technologies (Vagrant), and refresh my memory of some older ones (jQuery).

It’s also really rewarding to see a feature you built show up in a site that you use every day. I admit that might be a little vain, but it’s a nice bit of validation.

I also have to give credit to the cleanliness of Tilde’s codebase. The files were well-explained and organized. Class names were logical and easy to work with. It’s about as clean a foundation as you can have in a large project, so big credit to Deimos and the other contributors for doing a swell job.

Tildes Focus

Sat, 08 Jun 2019 16:00:00 +0000

I’ve recently taken a liking to Tildes.net. It’s still a small community, but it feels much more comfortable than the wild west of other social networking sites.

One issue I’ve noticed with large threads however is that it can be difficult to find new comments since your last visit. New comments are distinguished visually but are still easy to miss when there’s a very active thread.

To remedy this, I wrote a Greasemonkey script to navigate to the next new comment automatically. It’s called Tildes Focus as it helps you focus on what’s new.

I implemented this in Greasemonkey to help keep the complexity down. When loading a thread, the script makes a list of all new comments to walk through them. Keyboard shortcuts are used for navigation, and once you reach the end of the list it wraps back to the beginning. A subtle background shading is used to highlight the selected comment and works nicely in all themes.

When working on this script I discovered that JavaScript’s scrollIntoView() function accepts options both for smooth scrolling, as well as vertical positioning (eg. center on element). This allowed for a very clean implementation without leaning on jQuery or other libraries.

Tildes Focus is available on Github, and licensed under MIT.