Bogdle is my web-based word game, which takes Boggle’s rules (relaxed, currently) mixed with Wordle’s look and daily nature. Each day you get a new 3x3 grid filled with letters that make words from 4 to 8 letters long, with one 9 letters-long word (i.e. the pangram). Find them all and you win the day. Simple, eh?

Easy to understand and play, but while working on version 2 of this app, I realize there’s a lot more to it.

Filtering the English Language

There are a lot of words in the English language. Rough estimates range from tens of thousands to over a million. As for the amount of words most people know and use on a daily basis, the number is closer to the bottom of that range.

When I first made Bogdle, I found some freely-available corpora of words I could use to generate individual puzzles (grab a 9-letter word, and then find all valid words that exist using those words, as long as they are 4 to 8 letters long). I did not, however, really check to see which words were in these sources. Occasionally, I would do a puzzle and notice some…inappropriate words being used, be they uncommon or potentially offensive.

Now, censorship of accepted words in a language is a dicey business. Do I allow certain words because they are accepted by society, even if they are uncommon, or possibly vulgar?

If I want to allow unfettered access to all the wonders, positive and/or negative, of language, then yes.

If I want to make a game that uses language, but doesn’t potentially make users feel awkward or embarassed (offensive words), or dumb (uncommon words), then no.

To be honest, I was being lazy in v1. Now that I’ve used the app on and off for a while, I’m actually giving some real thought to the corpus used when generating puzzles. I actually wrote a whole script in python to filter word lists this time, so hopefully this makes Bogdle v2 more fun to use.

Saving State in a Stateless World (Wide Web)

Since the web is stateless by default, each time someone visits a web site their experience is novel unless otherwise specified.

Cookies were created so that the server could identify a user and make the web have some sort of state, allowing the browser to nom on tasty digital desserts in order to remember something about previous visits. HTTP Cookies are small by design, as they opted for Girl Scouts’ Thin Mints over Panera’s Chocolate Chipper Cookie, so don’t try to pack in much data if you use them!

The Web Storage API was created for client-side application code (i.e. Javascript), and there is both localStorage (does not expire until cleared) and sessionStorage (expires at the end of a browser session). Browsers create the limit on how much data you can cram into these stores, but they’re generally much more generous.

There is also the matter of IndexedDB, which is basically a database system inside your browser. I’ve tried to use it on projects in the past, but never actually got it to work. It may actually be the best way to store stuff for a web app, but until I figure it out in a functional way, I’m sticking with Web Storage.

Bogdle’s second major version is going to continue to use localStorage, but instead of only saving the current day’s game in an object, and also saving static statistics, it’s going to use an array of objects, one for each day, and create statistics on the fly by analyzing the data therein. I should’ve done this from the start, but I just didn’t think it through well enough at the time.

OOP-ification

As with most of my web projects, the Javascript is written very spaghetti-style. Until the most recent Advent of Code, I’d never really given a concerted effort to breaking down my code into proper classes, leaning on my intution of “add another function below the current one”. After a while, I have a lot of functions and not a lot of organization.

Hey, at least I namespace my projects! This means that all the variables and methods for Bogdle are in the Bogdle object, and not attached to window where it could interfere with existing properties (or be interfered with by other apps).

Regardless, at the very least I am making some subdirectories, creating files like helpers.js and localStorage.js, and generally trying to pseudo-OOP the project.

Actually Making it Boggle

Keen observers may have noticed that Bogdle doesn’t actually follow the main rule of Boggle: words must be constructed in an orthagonal manner, meaning that each successive letter must be reached by traveling north, east, south, or west from the previous letter.

When building the algorithm to construct words from letters, following a simple “can this smaller word be constructed from the letters in the larger word” flow was much easier. It also allowed me to use a randomize function to move the letters all to and fro inside the grid. Alas, it is not truly Boggle, though.

I’m not 100% certain if I’m going to change Bogdle to actually be more like Boggle in that sense, but I’m going to actually attempt to make it possible.

For the Road

Bogdle v2 is still in the works, but it’s coming soon!

By the by, Nebyoodle, my self-centered audio guessing game, took a lot of Bogdle’s codebase as its foundation. Thus, it has a lot of the same issues as Bogdle. I’m updating it to an eventual v2 soon, too, cuz why not?