The Making of Epimythos
The Beginnings
One day I was using ChatGPT and saw a chat suggestion to “Quiz me on” something. I decided to try Greek Mythology, as I was feeling nostalgic and wondering how much I really remembered from when my 4th grade teacher gave me the title of “Class Greek Mythology Expert.”
The AI generated a bunch of easy questions like “Who is king of the gods of Olympus?” and “What part of Achilles was the only part that was vulnerable?”—multiple choice and all. I was amazed to find that AI could present a quiz game with a simple prompt, and I had fun with it for a while.
However, I noticed the topics started repeating unless guided by specific prompts. After about 40 questions, the game had run out of gas. That limitation sparked an idea.
Creating My Own Game
At the time, I was learning Python. I started building a simple quiz game using hardcoded questions and a manually typed list of incorrect answers, organized into categories: gods, heroes, demigods, locations, beasts. This system allowed random incorrect answers to be selected for each question, making the experience less predictable.
The first bug I encountered was duplicate answers—correct and incorrect showing up twice. I added logic to skip incorrect options that matched the correct one. After several iterations, I had a functioning text-based game.
To streamline question creation, I built a parser that turned .txt files into Python-formatted question code. Writing new questions became easier. Still, the whole thing was just an experiment.
The Decision to Use Unity
I realized Python wasn’t great for building a graphical game, especially with my limited experience. After poking around and consulting AI, I made the jump to C# and Unity.
Learning the C# syntax was one thing, but Unity’s architecture—Monobehaviour, Start methods, using statements—was a real curve. Taking on both at once turned out to be a challenge, and I leaned on AI and pressed on. My lack of knowledge at the time slowed progress considerably.
I split my question sets into two modes: Speed (multiple choice, timed) and Verbose (typed answers with explanations and art). They originally lived in the same spreadsheet, but that became unmanageable, so I split them into separate sheets, and a third for incorrect answers.
I intended to generate C# code from the spreadsheets just as I had done with Python, but shifted to building standalone converter scripts in C# that turned my .XLS data into clean JSON files. With metadata structured and stored that way, my game became truly data-driven.
Making the Questions
I worked on questions night after night. Some days I could finish only 4 Speed questions; other times, 1 or 2 Verbose questions, depending on how much research or editing they needed. By New Year’s, I had written 350 Speed and 109 Verbose questions.
Stumbling Start
I jumped into Unity development during my New Year’s break with no training—just half of a YouTube tutorial. It didn’t go well. Buttons didn’t work. Scene transitions failed. I struggled with Unity’s component system and how it linked to C#.
But slowly, with enough trial and error (and AI debugging help), I got Speed mode working. Verbose was a mess. I started adding helper methods and custom debug logs. Things became smoother.
Discovery Mode is Born
After a few months, I saw the need for a beginner-friendly mode. I repurposed my Speed data into a third mode: Discovery. No timer, just multiple choice with immediate feedback and a background explanation.
It took a weekend to append metadata to my Speed spreadsheet to support Discovery. It became the third pillar of gameplay.
Final Stretch
Through late winter and spring, I polished, tested, and expanded the game. I added new questions and built logic for handling achievements, metadata parsing, and more. Then I noticed something. Despite my efforts to make a game with a huge variety of questions, there were a few questions with overlapping context, creating the feel of repetition. This was the very thing that had disappointed me about AI generated quizzing. I had to do something.
Using my existing data-driven game structure, I introduced a topic variety filter to prevent question repetition based on thematic groupings (e.g., “achillesHeel”).
This filter was created by scanning my question data row by row for a key string (e.g., Achilles) and matching strings (e.g., heel, Styx). If both are present, the question joins a group. A cooldown prevents repeated themes too close together (20 for Verbose, 40 for Speed). If the game runs out of questions, it ends the round early, so you might see less questions in the scoring screen than you asked for. If you start a new round, it randomizes a new batch of questions and applies the filter again.
You can toggle this variety filter off in the options menu—helpful when achievement hunting.
This is the story behind the quiz game. What began as a simple AI entertainment became an educational piece of software.