A REAL BOARD!

A trickier task than it sounds like, but I needed some clues finally! The default testing board was uh… not exactly “production ready” in my opinion (lol).

This was tricky particularly because, well, where am I going to get clues from? You kinda need a LOT of clues for a good Jeopardy game, and while UGC is something I want to make, I would like a default mode, too, and there is certainly no way that I was going to try to make a bunch of clues by myself.
(respectfully, I don’t think I am also smart enough to do that lol)

Jepp

I found a little project called jepp which exposes a LOT of existing Jeopardy clues through an API. I didn’t want to bother that API too much though, and there is an SQLite DB dump publicly available, so LARPARDY now uses that instead. With a little bit of SQL later (and, uh, remembering how to use SQL lol)… we have many, many clues!
The only thing is that the database does not store the value of clues, so it’ll be a bit random. A $1000 clue might end up being super easy lol, but I think that’s some jank I’m okay with.

Player list

Ooh also, I made a proper player list now! I did want literal podiums, which I may still do at some point, but I’m happy with this for the time being. This can now also react to changes in the game like points or who’s turn it is!

BEEEG DEVLOG

Wowwee! I’ve gotta remember to make devlogs more often.
Seriously. Here’s a list of changes that I’ve made since my last devlog!

• The basics of the board are implemented! You can’t interact with it yet, but the template to do so is there, and it now exists on the server-side too and the client reads from that state.
• The board is also animated now. When someone selects a clue, it will highlight the category and the clue, you can hover clues, and, my favorite bit, the categories get revealed one by one when the game starts!
  • That last part actually kind of sucked to implement lol. I prepared for this when making the lobby’s ready up system and made the state that it uses to work a bit dynamic because I knew that I would need it! The state stores readyForNextState, which for some states (like when we’re in the lobby) allow unreadying, but for others, simply act as a marker of whether a specific client is ready to move on. This is probably actually really important because if we just ran a timer on the server, a NUMBER of things could go wrong, most importantly being that a laggy client could get desynced VERY quickly and have a bad time.
• Alongside this, there is an intro now! I spent a good bit of time in Aseprite and messing with FL Studio to make some art and an intro track, both for the logo and so I finally have some artwork to add in the Discord Developer Portal, so there aren’t anymore blank assets. It’s not perfect (i am NOT an artist lol) See pictures below!
  • psst, I also made a “think” music track for if the final round is enabled! It’s not in the game yet, though.
• I made a number of styling fixes. The board in particular looks much better on different screen sizes now, even on my phone. Reminder to use relative sizes when able, not px!
• The server now registers the activity entry point command as having an APP_HANDLER handler, which means that the server must respond to interactions now, rather than Discord autolaunching the activity. The benefit of this is that we have control over whether a message gets sent to the channel it was started in (and when), or if we even launch the activity at all (disallow banned users? anything is possible…)!
• The rich presence actually has meaningful details now lol, rather than placeholder text.

NOWWW what?

I am going to, FINALLY, FOR REAL THIS TIME, (lol) actually start making the game logic. (It’s about time!)
More updates sooooon!

I prototyped the game board last night! This took a while to get the styling right as I want this to work well on all screen sizes, hopefully including mobile devices. It’s still a little rough on very small sizes (e.g., my phone), but one step at a time! I still want to add little “podiums” at the bottom for our players.

After that, I’m going to be working on getting the board working on the serverside, so that actually becomes part of the game state.

socket.io is cool, BUT

So. 8 hour devlog, my bad, but I’m going to start by talking about the thing that I’ve been mostly fighting with today.

The networking backend that I’m using for LARPARDY is Socket.IO, which works similarly to (and usually on top of) WebSockets, but with a lot more quality of life features and ease of use for specifically these kinds of situations.
I have been fighting for a few hours today trying to figure out why I could not, for the life of me, get socket.emit to work on the client.

It was, in fact, one setting, retries, in the client config, stopping it from working, for SOME reason. Oops.

Anyways…

PROGRESS! (GAME!)

Progress has been steady! Most of the changes that I’ve been making have been making the client more workable as I make new components, and actually more planning out the infrastructure. I’ve designed some new UI elements, moved where some state is stored, and so on. I have a bad habit of overplanning, or rather, being too worried about planning big projects like these, because I like to avoid having to do cleanup work later (like the cleanup that I’m doing on the client right now). It’s not strictly a bad habit, but sometimes it’s better to just write the code rather than spend hours deliberating about micro-optimizations with yourself.

I believe I am now ACTUALLY at the point where I can begin properly building the UI for the game board and the frontend & backend aspects around that.

This was more hidden work (and… fighting with the socket.io client, apparently) so I don’t have too much to show this time either, sadly. BUT, I did finally design and prototype the lobby! So you do get something fun to look at while I work on everything lol

it’s REDISin’ time!

wait is that… not the line from the movie?
(also SORRY this should have been at least a couple devlogs lol, please forgive me)

I’ve finally been working on the state management for LARPARDY! This turns out to be a MUCH harder task than I originally thought it would be, particularly because I’m trying to make sure that this will be safe and work well in a real environment.

Redis

First of all, instead of keeping state in the server’s memory, I have added a Redis DB to the project. This is part of why I wanted Docker set up, as this is now just in the docker-compose.yml!

I have NEVER personally used Redis before, so some time of the time from this devlog was admittedly stumbling my way through figuring out how to use Redis correctly.
CORRECTLY is the key word, to be clear. I’m building basically a wrapper class around the Redis database, StateManager, which abstracts away the nasty database stuff so the main code doesn’t have to worry about actually interacting with Redis. It was, kind of a pain to write actually (lol?), because I was worried about race conditions basically the entire time, since this code needs to run async (i.e., something else might do something to a thing while we’re also trying to do something with that thing). I HOPE that the state management code is bug free for now, but we’ll see.
(please…)

Client

The client has now also been updated to listen for new game states. I also finally figured out how to set up Rich Presence, so it will show that you’re playing LARPARDY on your profile!
In addition, I made it so in-game avatars will highlight green when someone is speaking (like Discord), and I added waiting UI for when a player has joined but hasn’t fully connected yet, AND for when you are still connectin#.

so NOWW can we start to make the actual game?

yyyyyYES! I think so. I hope, anyway (lol). I believe my next step will be making a basic lobby/waiting UI that lets you start the game, and then finally start to implement the actual game. I AM EXCITEEEEDD
(there’s not a ton to look at since this was mostly backend work. sorry! i’ll have more next time :3)

oops…

I wasted some time on accident, woops.
I thought Discord’s proxy verification meant that the discordsays.com proxy would send these headers to verify that an actual Discord client had connected with them, but uh, I checked the flowchart again and I got that wrong. Hm. Thankfully, I didn’t get too far into implementing that.

Regardless, trying to implement that still encouraged me to do a small bit of cleanup, which was properly declaring the environment variable. A certified moment.

(YES I am going to abuse the fact that I figured out that you can use custom emotes here. i am so sorry)

smol devlog

I HATE DOCKER i love Docker!!

So, I didn’t even write a devlog yesterday because I spent the entirety of the time that I did have setting up a Dockerfile and docker-compose.yml for LARPARDY.

…why did it take that long

Because I’ve never used Docker before! Well, I have, to run services on my PC and my homelab server, but I’ve never used it for my own projects before.

Specifically, I want to go ahead and set up Docker because I know that I’m going to need a database (or possibly two! SQL + Redis), and running everything together in a container will make both development AND deployment much easier for me.
I’ve never used it before, so this is, uh, a learning experience, to say the least.

oh also, pnpm

Oh. Also. pnpm has a bug. Apparently.
I’m using pnpm as the package manager for both the server and the client (since they’re both TypeScript projects). Both projects are stored in a monorepo (literally meaning just a repo with multiple projects, basically), which makes it easy to manage for me and keeps my commits together.

Nicely, pnpm recommends a Dockerfile for this exact scenario! I reconfigured the project to use pnpm‘s workspaces feature (which… is seperate from package.json’s workspaces, for some reason) so that this would work.
pnpm deploy is supposed to copy the project with it’s own node_modules since workspaces use a shared one. The problem is that, when it rewrites workspace dependencies (because I have a shared package for both the server & client), it links it to the wrong source, which no longer exists after it’s copied!
I tried to debug and get this working for ACTUAL AGES before I gave up and just wrote commands that manually copy the files instead.
I figured that there HAS to be a way to get this working, considering the documentation itself recommends this build file. But noooope. It doesn’t seem so (cite: this GitHub issue which has been open since… 2023???).

so what did you actually do

The Docker config works now, and that’s the important thing! I currently have the client build into an nginx image, but I’m either going to drop this entirely or have the server serve the client files itself. This will allow me to implement Discord proxy header verification too, if I decide to.

Socket.IO!

As for perhaps one of the most important bits… this is Socket.IO! I had to figure out how to get this working with Fastify first (thank you random GitHub commenter) since that’s my web framework of choice for the backend (for anything not going through Socket.IO), but here’s a basic implementation of it working!

what it do?

Socket.IO works similarly to (and if it’s available, on top of) WebSockets, where there’s a persistent connection with bi-directional communication between the client and the server. Socket.IO adds some extra fancy things on top of that, such as fallbacks when WebSockets aren’t available and rooms, and in general will make my life easier (lol).

This part is, of course, very important for getting a game handled by the backend to work! This will also allow us to do multiplayer. Discord gives you an instance ID for each activity that players are playing together, so I’ll use this to make the rooms, that way players in the same voice channel will end up in the same game!

ho boy…

I’ve wanted to make a Discord Activity basically since the feature began being teased… so, no better time than the present, right? I saw some guys playing Jeopardy the other night and I realized that I feel like the online ways of playing Jeopardy are kinda… uh, bad? I thought I should fix that.

I’ve been getting a lot more comfortable with frontend development recently (I’m normally more comfy with backend stuff!), so now this is really going to test my ability to handle FULL STACK development.
With that said, I’ve been playing around since last night and I have a working setup with (stable) communication with the Discord client via the SDK. (hooray!) Currently, it just shows the name and avatar of connected players.

don’t you love React?

Me too! Unfortunately, I am lying.
I’m trying Vue.js for the first time for this project. There is a LOT that I’m planning that is very new to me for this project. I expect to need Redis, Socket.IO, and (of course) the Discord activities SDK, none of which I’ve ever used. So, here we go?

the name. dude. what. why

I didn’t originally have a name for this (the README still remains “Untitled Jeopardy Clone” for now), so I was using the name “Leopardy” as a placeholder. Someone recommened me to switch to LARPARDY.
I couldn’t say no. I wish I did.

…anyways, next up is actually making some sort of game state work. I’m going to start working on the backend!