Hadronize

This is my first devlog for this project. It’s a multiplayer strategy game that you can play in your browser.

https://github.com/ethmarks/hadronize

Basically the only things that I’ve done so far are write the rules in the README and brainstorm a bunch. The rules are pretty important, so I’ll write them in this devlog. Because there’s a 4000-character limit to Stardance devlogs, I’m going to try to keep the rules shorter and less thorough than I did in the README.

Rules

Hadronize is a 2-6 player game which will probably take about ~10 minutes per game.

• The goal is to be the first player to hadronize 10 or more quarks.
• Quarks are basically the cards. There are 6 different flavors of quark: up, down, strange, charm, bottom, and top. By the way, I’m not making that part up.
• Quarks start out as Superposed Quarks, which are quarks in a state of superposition between three different flavors. Once the superposition collapses (more on that later), it chooses one of the three flavors in its superposition and becomes a normal quark with a single flavor.
• Each player starts with four collapsed quarks with randomly-chosen flavors in their respective cloud chamber.
• On each turn, a new superposed quark appears. The players know that the quark will be one of the three flavors in its superposition, but they don’t know which one. The player whose turn it is (aka the active player) will choose any player (including themselves) to be the observing player. The observing player observes the superposed quark, which collapses it and adds it to their cloud chamber.
  • If the observing player has none of that flavor (e.g. the new quark collapsed into charm and the player only has down quarks), then nothing else happens and the turn ends.
  • But if the observing player does have at least one quark of the same flavor, something does happen.
    • If the active player chose themselves to be the observing player, the new quark reacts with all existing quarks of the same flavor, and they all hadronize together.
    • If the active player chose a different player to be the observing player, the new quark reacts with all existing quarks of the same flavor, and they all quantum tunnel from the observing player’s chamber into the active player’s chamber. In other words, the active player steals some of the observing player’s quarks.

If my explanation is unclear, check out the README because I probably explained it better there. If the README is unclear too, feel free to let me know by commenting on this devlog or opening an issue or whatever.

Mantis

If the rules sound familiar, it’s because I mostly just stole them from the card game Mantis by Exploding Kittens. My original idea was to just create a digital version of Mantis, but I was concerned about running into copyright trouble if I called it “Mantis” and used the same terminology and whatnot. Game mechanics can’t be copyrighted, but names and terminology absolutely can. I considered just making my game about abstract colors, but then I suddenly realized that making it about quarks would fit really well, so I did that instead. I did make a few changes to the core mechanics (e.g. using 6 flavors instead of 7 colors, and combining “scoring” and “stealing” into “observing”), but it’s still basically just a reskin of Mantis.

Next Steps

Obviously the first thing that I need to do is actually implement the game logic in TypeScript, but I’m not 100% sure what I should do after that. I’ll come up with a plan in my next devlog.

P.S. I also spent like an hour making a terrible-looking banner for Hadronize to use as the Stardance project image.

1.0.0

Unless I think of more stuff to add, this is probably my last devlog before shipping.

Lume Theme Registry

A few hours ago, the PR that I created last devlog was merged into the official Lume theme registry, so you can now install my theme with a single command using Lume init, and it now has its own dedicated page on the official Lume website: https://lume.land/theme/tufte/.

README

• I added a How it Works section that explains how the Lume theme architecture works behind-the-scenes (spoiler: it’s just remote files) and explains what each of the 18 included plugins do.
• I updated the quickstart to use the Lume init command.
• I added a Showcase section that lists the sites that use this theme. It seemed kind of weird to exclusively list the Tufte theme site itself, so I also switched one of my documentation sites to use the Tufte theme.
• I added a shields.io badge to the top of the README that links to the theme’s page on the Lume website. shields.io relies on simple-icons for its logos, but simple-icons doesn’t have the Lume logo for some reason, so had to Base64-encode an SVG of the Lume logo in order to get the badge to work.

Next steps

I’m not going to ship this project juuuuust yet in case I think of any missing features that I ought to add, but I probably will soon.

Theme Registry PR

I just created a PR to add my theme to the official theme registry for Lume: https://github.com/lumeland/themes/pull/10.

Why

If my theme isn’t in the official registry, the best way for users install it is to clone my entire repo, which is silly, bad for separation of concerns, and just generally worse for UX.

git clone https://github.com/ethmarks/lume_tufte.git
cd lume_tufte
deno task serve

But if I get my theme into the theme registry, users can install it using the official Lume init command, which is much better in every way:

deno run -A https://lume.land/init.ts --theme=tufte

Conclusion

From my interactions with him in the past, the Lume maintainer (Oscar) seems like an extremely nice dude who seems to respond fairly quickly, so I shouldn’t have to wait too long before he either accepts my PR or suggests changes that I can go implement. Meanwhile, I’ll probably continue working on the README.

README, optimizations, and more

Since my last devlog:

1. I wrote the README.
2. I optimized the theme until it earned perfect 100s in every category on Lighthouse on every page.
3. I added a light mode.
4. I added support for tables of contents.
5. I added RSS feed generation.
6. I rewrote one of the demo blog posts.
7. I added styles for HTML tables

Link to the diff between last devlog and this one

Optimization

Most of the work I did today is pretty self-explanatory from my little summary, but the optimization work probably merits elaboration.

So while I was writing the README, I had the idea to include the Lighthouse scores. When I checked, they were 100/100/100/92 on mobile and 92/100/100/92 on desktop.

“100s on Lighthouse in some fields” doesn’t sound nearly as nice as “100s on Lighthouse in every field”, so I decided to start optimizing. Lighthouse told me that the SEO problem was a lack of descriptions, and the desktop performance problem was excessive network requests and chained network requests.

SEO problem

I fixed the lack of descriptions by adding descriptions. Simple as that. I wrote descriptions for all of the existing pages, added a description field to the CMS config, and added a mention of it in the usage guide. The network requests and chained requests were a bit trickier to solve.

Performance problems

The cause of the excessive network requests was that, even though the homepage didn’t use the KaTeX or Nueglow styles, they were still being imported. I solved that with a per-page check that runs at build time. Each page only imports the Nueglow stylesheet if it contains code blocks, and it only imports the KaTeX stylesheet if the page contains math blocks. Here’s a link to the relevant section of code. I think that it’s a pretty clever solution because it selectively removes the unnecessary CSS requests without using client-side JS or anything like that.

I used a similar approach to solve the chained requests. What was happening is that in order to download the woff2 files, the browser first had to download the CSS files, so it took twice as long because they couldn’t be downloaded in parallel. Font preloads are the way to solve this. The only problem is that if I preload too many font files, the browser will have download font files even if they aren’t used on the page. But if I preload too few, then the network requests are still chained. My solution was to have it check which font files each page needs and selectively preload only those font files. Here’s the relevant code if you want to see my implementation. Again, this solves the problem of unnecessary requests and chained requests without adding any client-side JS.

I’m glad that Lume and Vento are such powerful tools that I can easily do programmatic optimizations like this.

Next Steps

I think that the next thing I should do is submit my theme to the official Lume theme repo. That way I can simplify the installation process down to one command.

Hi there! This is a project I’ve been working on for the past week. It’s a theme for Lume SSG based on Tufte CSS.

Btw, I did the majority of the work before I started using Hackatime, so I’ve been working on it for a lot longer than 5 hours.

I’m just going to briefly tell you about everything that I did before I started tracking with Hackatime.

1. I looked through the Lume source code to figure out how the poorly-documented theme APIs work.
2. I copied the tufte.css file into the project. Then I downloaded the font .tff files, compressed them into .woff2 files, and wrote css font-face rules for them.
3. I made some Vento layouts.
4. I created, styled, and wrote the logic for the site header.
5. I wrote the blog post and blog index layouts and created the BlogList component.
6. I started installing Lume plugins like KaTeX and Nueglow.
7. I started writing the “Using this theme” post.
8. I created the tufte-sections and tufte-notes plugins for markdown-it.
9. I began heavily tweaking and customizing tufte.css.
10. I transcribed every word of the TufteCSS homepage from HTML to Markdown.
11. I started configuring LumeCMS.

Most of what I’ve done since then (what’s reflected in the 5 hours I’ve logged with this devlog) has been a lot of writing, mainly in the Using this theme post. I’ve also been adjusting the LumeCMS config a lot.

I think that the next thing that I’ll do is write the README.

Thanks for reading!