DEV Community: Justin

GridyPig Quiz Clash: Turning Prompts into Multiplayer Games with Hermes Agent

Justin — Sun, 31 May 2026 19:08:29 +0000

This is a submission for the Hermes Agent Challenge

What I Built

I built GridyPig Quiz Clash, an agent-assisted quiz creation and multiplayer game mode inside GridyPig, a multi-tenant real-time game platform.

The problem I wanted to solve is simple: creating a good quiz for an event, launch party, classroom, community night, or team activity is slow. A creator has to plan the topic, write questions, balance difficulty, avoid repeating old material, validate answer options, and then turn everything into something people can actually play together.

GridyPig Quiz Clash turns that into a much faster flow:

A creator describes the quiz they want in plain English.
Hermes Agent plans the quiz structure and checks the existing reusable quiz bank.
Hermes avoids duplicate or repeated questions, balances difficulty, and returns generation notes with validated questions.
GridyPig normalizes the output into a playable quiz set.
The creator can edit, collapse, import, dictate, save, and launch the quiz as a live multiplayer room.

The result is not just generated text. It is an agent-assisted path from creator intent to a playable real-time game.

Demo

Demo link: https://www.loom.com/share/4092af7b2920444984bcdc73a5363cab

Recommended demo path:

Open a tenant workspace, for example https://justin.gridypig.com.
Create or sign in as a player/creator.
Start a new game and choose Quiz Clash.
Use the AI quiz builder prompt, for example:

Create a fun 8-question quiz about Nigerian tech startups for a launch party. Mix simple and tricky questions.

Show the generation button moving through planning, quiz-bank checking, duplicate avoidance, difficulty balancing, and formatting stages.
Show Hermes generation notes explaining the plan, bank check, duplicate avoidance, and validation checks.
Save the quiz set and open a live room.
Join with another player or show the simulation/live room flow.
Play through a few turns and show the final leaderboard.

Screenshots/video placeholders:

Game landing page
Quiz Builder with Hermes Agent

Code

Repository: github.com/cjustinobi/greedy-pig

Key areas:

Hermes Cloud Run adapter: deploy/hermes/
Backend quiz generation service: apps/backend/src/quiz/quiz-ai.service.ts
Quiz APIs and reusable quiz bank: apps/backend/src/quiz/
Frontend quiz setup UI: apps/frontend/src/components/quiz/
Real-time game room: apps/frontend/src/components/game/

My Tech Stack

Frontend: Next.js, React, Tailwind CSS, Framer Motion
Backend: NestJS, Prisma, PostgreSQL/Supabase
Realtime: Socket.io
Agent Runtime: Hermes Agent behind an OpenAI-compatible Cloud Run adapter
Infrastructure: Google Cloud Run, Docker, Vercel, GitHub Actions
Product Layer: Multi-tenant workspaces, PWA support, referral system, reusable quiz bank, wallet-aware game modes

How I Used Hermes Agent

Hermes Agent powers the quiz creation layer. I wrapped Hermes in a small Cloud Run service that exposes an OpenAI-compatible /v1/chat/completions endpoint, so the GridyPig backend can swap AI providers without coupling the game engine to a specific model vendor.

The flow:

Creator prompt
-> Hermes plans quiz structure
-> Hermes checks existing quiz bank
-> Hermes avoids duplicate/repeated questions
-> Hermes balances difficulty
-> Hermes returns generation notes + validated questions
-> GridyPig saves playable quiz set

1. Prompt-to-Playable Structured Output

GridyPig does not need a paragraph of generated text. It needs valid game data.

Hermes receives the creator's intent and returns a strict schema:

{
  "plan": "Short generation plan",
  "difficultyBalance": "How the quiz difficulty was balanced",
  "avoidedDuplicates": ["Bank question or duplicate pattern avoided"],
  "qualityChecks": ["Validation checks performed"],
  "questions": [
    {
      "prompt": "Question text",
      "type": "MULTIPLE_CHOICE",
      "options": ["A", "B", "C", "D"],
      "correctAnswers": ["A"],
      "difficulty": "MEDIUM",
      "explanation": "Why the answer is correct"
    }
  ]
}

The backend then validates and normalizes the output before it ever reaches gameplay. If a question is malformed, it is rejected instead of silently breaking the room.

2. Quiz-Bank Awareness

Before calling Hermes, GridyPig samples relevant reusable questions from the tenant and shared quiz bank. That context is passed into the agent as existingBankSample.

Hermes is instructed to review that sample, avoid exact duplicates, avoid close paraphrases, and explain what it avoided in avoidedDuplicates. This makes the quiz pool feel fresher over time instead of repeatedly generating the same obvious questions.

3. Generation Notes for Trust

The UI now shows Hermes generation notes after questions are generated:

The quiz plan.
The difficulty-balancing strategy.
What existing bank questions or duplicate patterns were avoided.
The validation checks Hermes performed.

This gives the creator confidence that the agent did more than return a blob of questions.

4. Agent Adapter Built for Production Constraints

Hermes Agent runs as its own Cloud Run service. During testing I hit real deployment issues: container startup, Cloud Run port binding, long-running agent loops, and noisy CLI output around JSON.

I solved this by building a dedicated adapter that:

Listens on Cloud Run's PORT correctly.
Secures requests with a shared secret between the backend and Hermes service.
Uses ephemeral runtime state so the agent does not hang on Cloud Storage/FUSE SQLite WAL files.
Bounds generation to a single quiet chat turn for predictable response time.
Extracts clean quiz JSON even when the CLI returns session noise or markdown wrappers.

That adapter made Hermes usable as a real service, not just a local experiment.

5. Human-in-the-Loop Creation

I intentionally kept the creator in control. Hermes accelerates quiz creation, but the creator can still:

Edit every generated question.
Choose predefined or custom categories.
Pick question type: yes/no or multiple choice.
Use voice dictation for questions and options.
Import questions from a template.
Save questions into a reusable quiz bank.
Search and reuse existing quiz questions later.

This matters because a great quiz is partly AI generation and partly human taste. Hermes gets the creator most of the way there, then GridyPig gives them tools to polish the final game.

What Makes It More Than a Quiz Generator

The generated quiz becomes part of a full multiplayer game system:

Turn-by-turn Quiz Clash: players answer in sequence and the highest score wins.
GridyPig streak mode: correct answers can keep a player in control, preserving the push-your-luck feel of the original game.
Server-side validation: scoring and turns are enforced by the backend, not trusted to the browser.
Inactivity countdowns: if a player stalls, the room warns everyone and passes the turn safely.
Draw handling: tied zero-score quiz games end as draws instead of arbitrarily picking the creator.
Final standings: the game ends with a leaderboard showing how each participant performed.
Tenant workspaces: each business/community can run its own branded games.
Reusable quiz bank: creators can build from scratch or reuse questions over time.

What I Learned

The biggest lesson was that agentic features need product boundaries.

It is tempting to let an agent do everything, but a real-time game needs deterministic behavior. Hermes is excellent at helping create the content, but the platform still needs strict validation, typed payloads, server-side scoring, and predictable fallback behavior.

So the winning architecture became:

Creator intent
-> Hermes Agent planning and bank-aware generation
-> Structured quiz draft with generation notes
-> Backend validation
-> Human editing
-> Live multiplayer game

That separation keeps the AI useful without letting it destabilize the game loop.

What's Next

I want to expand the Hermes layer from quiz generation into a full game-master assistant:

Suggest better distractor options for weak multiple-choice questions.
Rebalance difficulty based on historical answer rates.
Generate themed quiz packs for events, product launches, schools, and community nights.
Help creators convert reusable quiz-bank content into polished game sessions.
Create post-game summaries that explain what players struggled with and what they learned.

GridyPig started as a dice game. With Hermes Agent, it is becoming a creator-powered game platform where anyone can turn an idea into a live multiplayer experience.

Building for the bad guys

Justin — Wed, 20 Mar 2019 08:24:24 +0000

Often times, while still in discussion on how to go about a client's project, they always lay emphasis on the security of the app. They would recommend you install the "strongest bad-guys-fighting-software", and I'm always quick to respond that "security is a process." If they fail to do little on their part to ensure the security of the application, irrespective of whatever security plugin that was installed, it could be compromised.

It would be of no use of installing cool security software and neglect some simple security measure like using a dumb password or even storing passwords in plain text.

Before I proceed, I would like to define who a bad guy is in the context of this article. A bad guy is simply someone who looks for the slightest means to compromise your application through any loopholes found in the system.

From the get-go in software development, we plan for the worst and expect it. We assume our attacker is smarter than we are, not leaving any chances for a weak link in the chain.

So, I will be discussing a few simple ways a developer could avoid being caught in the net of bad hackers.

Input field sanitization

This is obvious and most common means of creating an avenue for attack. As a matter of fact, expect the worst wherever there is a form field in your application, a possible outcome is one trying to run JavaScript on your page. That is what’s called an XSS, cross-site scripting.

So I'm saying basically, treat anyone having access to any of your input fields as a suspect. Anyone with bad intention could put malicious code in those inputs and the rest would be history if the developer of such an app is not security conscious.

There are tons of great libraries one could leverage on to sanitize HTML, for instance, https://github.com/cure53/DOMPurify

However, all I have mentioned about input sanitization is for the frontend of the development. It is also good to double check it on the server side too because JavaScript could be manipulated on the frontend.

Authentication

Authentication is the process of determining whether someone or something is, in fact, who or what it declares itself to be.

During authentication, credentials provided by the user and are compared to those on file in a database or any other means of storage. If the credentials match then the authenticated user is authorized to use the restricted resources. This leads to my next point; Authorization.

Authorization

It is granting access to authenticated users. The access could be in different roles (privileges and preferences). The privileges and preferences granted for the authorized account depend on the roles' permissions. The settings defined for all these environment variables are set by an administrator.

Software updates

One needs to be alert and stay up to date with the latest security patches for the libraries or frameworks they are using.

With one command, one could update any third party plugin they have installed. This is where the use of package managers shines. With simple commands such as npm update for Node packages and composer update for PHP packages etc. one would have any outdated third-party library updated.

Hashing algorithms

Simply put, A hash algorithm is a function that converts a data string into a numeric string output of fixed length. Hackers today have access to powerful inexpensive computing resources that can be used to conduct high-speed password guessing. Salting is the coding technique needed to help defeat such attacks and de-duplication of password hashes since hashing algorithm like MD5 alone is not enough.

Conclusion

All the points I have mentioned, are just the basic way one could adhere to in order to avoid stories that touch. There are pretty much points I did not cover. I would be expecting your contributions on any issue not discussed here.