When I was managing online editor last year, I often quipped about the possibility of a Games section at The Daily. As more engineers on our team become interested in working on this project, and as more cruciverbalists join Pavan’s team, it seems that may become a reality.
On the one hand, I am happy to see the enormous interest — it means that this project will likely live beyond my time here. On the other hand, I am incredibly hesitant. When I came into the role as a senior software engineer, I did not want to be in a managerial position. If I had wanted to be in a managerial position, I would have run for managing online editor again. My intent with the position was to have flexibility in pursuing different and wide-ranging projects that are both personally fulfilling and beneficial for the team and organization as a whole. Having flexibility allows me to take a break from projects, to intentionally give myself time to find the spark again.
What does this mean for you, the engineer? Frankly, I’m not sure at the moment. Part of me believes that I can maintain a fairly hands-off approach, but part of me also thinks it’d be better for me to step into a more managerial role to coordinate everyone’s efforts. As I take time to figure things out, bear with me.
For the time being, I will provide an overview of what I envision in this project, our current status and steps we can take to reach te vision.
A vague goal in mind is to reach some sort of parity with The New York Times, an common refrain you’ll hear for anything related to technology in a newsroom. This involves user authentication to be able to 1) save puzzle progress throughout different devices and 2) create a leaderboard among friends. This involves improvements to puzzle movement, and the ability to customize for user preference. This also involves additions in puzzle types and features such as implementing different puzzle sizes and rebus support. This may involve a better mobile integration through a native mobile implementation or push notifications.
Aside from these user-facing goals, there are also infrastructural goals to strive for. Currently, we have quite a convoluted process for testing a puzzle, publishing a puzzle and preparing a puzzle for the print edition. Although it has been manageable for Pavan and I thus far, there should be a concerted effort here to make this process more efficient as interest grows in this project, both from the puzzler’s and engineer’s perspective.
I don’t think we should be creating an authentication layer from scratch. I’m thinking that we should rely on Auth.js, the framework agnostic authentication library previously known as NextAuth. There is a long list of OAuth providers that we can choose from, though I’m looking specifically at using Amazon Cognito or Google.
Currently, we persist game state through local storage. I think we should continue to do this in case the user is offline or cannot connect to our database for some reason. I think the idea is that we periodically push game state from local storage to a database. In the case that local storage and database game states are out of sync, the local storage state should always be preferred. How often should we push game state to the database? And, is it possible to save to the database whenever a user is going to close their game tab?
To accomplish this, my initial thought is to create a SQL database with users and puzzles tables, along with a connective table between the two models to indicate game state. In the case that we also implement some sort of friend system with a leaderboard, we’ll need some other table that relates users to other users. I imagine that we could also implement this through a NoSQL solution with a document database. I think most SQL implementations are capable of storing JSON values, which our puzzle data is formatted in.
I implemented the current puzzle movement in a incredibly brittle and spaghetti-like way. I wouldn’t be opposed to a complete rewrite, with a closer attention to different edge cases and an approach that would allow for optionality and user preference.
Puzzles can come in different sizes. Notably, our puzzle makers plan on making a 21 by 21 grid to round out the semester. I believe @Will Gushee is planning on implementing the ability to generate puzzles of different sizes. This would also be beneficial in the case that we want to create mini crosswords in the future.
A rebus square allows for inserting multiple letters in a single square. Currently, the player (and builder) only supports inserting one letter per square.
In order for a mobile implementation of the player, I think we need to expose a public API that retrieves game data and user data. This would require decoupling logic, and I’m curious about the implications this would have on how we approach authentication.