{"slug": "the-last-blink-second-settlement-building-an-ai-driven-investigation-across", "title": "THE LAST BLINK: SECOND SETTLEMENT — Building an AI-driven investigation across timelines", "summary": "A developer and Yash Gupta built THE LAST BLINK: SECOND SETTLEMENT, a story-driven 2D investigative thriller for HackCBS 9.0 in which players investigate conflicting accounts around an incident at Relay 7 and use AI-assisted mechanics (BLINK and ECHO) to branch and compare timelines. The project pairs a React, Phaser, TypeScript and Vite frontend with a deterministic game engine and a backend that uses YugabyteDB's YSQL interface for session, event, snapshot and branch-history persistence, plus Meko as a contextual memory layer for NPC interactions. The developer reports a smoke test against a real cluster that created a session, committed an event and read back persisted records, while noting workload and failure testing are still needed before any production-scale claims.", "body_md": "*This is a submission for the [MLH x DEV Writing Challenge](https://dev.to/mlh-hackathon)*\n\nWhat if the AI helping you solve a mystery was also the reason you couldn't trust the evidence?\n\nWhat if a failed timeline wasn't a failure, but another piece of evidence?\n\nThat was the idea behind **THE LAST BLINK: SECOND SETTLEMENT**, the project I built with **Yash Gupta** at **HackCBS 9.0**.\n\nWe wanted to go beyond building another chatbot with a UI around it. We wanted to create a playable investigative thriller where AI, memory, persistent state, and player decisions actually affect how the investigation unfolds.\n\nAnd building it taught me a lot about both engineering ambitious ideas and navigating hackathons.\n\n**THE LAST BLINK: SECOND SETTLEMENT** is a story-driven 2D investigative thriller set in Veyra, a city hiding the truth behind an incident at Relay 7.\n\nYou play as Aster, investigating conflicting accounts, collecting evidence, questioning NPCs, and trying to understand what really happened. But there is a catch: the investigation can be manipulated, and the truth isn't always obvious from a single timeline.\n\nWe built several connected systems around that idea:\n\nThe central design principle was simple: **the player should have to investigate the truth, not just ask an AI to reveal it.**\n\nOur stack includes React, Phaser, TypeScript, and Vite on the frontend, with a deterministic game engine and a backend responsible for persistence and AI integration.\n\nThe most important engineering decision was separating three things that are easy to mix up in AI applications:\n\nThat separation is what makes an unreliable witness interesting instead of letting an AI response arbitrarily rewrite the story.\n\n**Project:** THE LAST BLINK\n\n**Demo video:** [Add your demo video link here]\n\n**Source code:** [https://github.com/demonstrikkk/last_blink](https://github.com/demonstrikkk/last_blink)\n\nThe best demonstration is a complete investigation loop: collect evidence, connect clues on the Case Board, encounter a contradiction, use BLINK to create another timeline, and use ECHO to compare what changed.\n\nI'd rather show one working investigation end to end than pretend every planned feature is equally polished.\n\nThis was one of the most interesting parts of the project for me because we weren't integrating technologies just to put their names on a slide. Each one had a specific responsibility.\n\nWhy use YugabyteDB when PostgreSQL and many other relational databases already exist?\n\nBecause our data isn't just a collection of user profiles or chat messages. We need to preserve sessions, ordered investigation events, snapshots, branch history, and the relationship between evidence and decisions.\n\nWe used **YSQL**, YugabyteDB's PostgreSQL-compatible SQL interface, for our relational persistence layer.\n\nThe intended architecture separates:\n\nThe game engine remains responsible for deterministic rules, while YugabyteDB persists the durable record.\n\nWe also tested the actual database integration rather than stopping at configuration: our reported smoke test connected to a real cluster, created a session, committed an event, and read back persisted session, event, and snapshot records.\n\nFor this project, the interesting part of YugabyteDB isn't simply that it stores data. It gives us a PostgreSQL-compatible starting point and a path toward distributed SQL as the application evolves. We still need workload and failure testing before making claims about production-scale performance or high availability.\n\nOne problem with multi-agent AI systems is that every interaction can start to feel disconnected. An NPC forgets relevant information, an agent loses useful context, or the same information has to be repeatedly included in prompts.\n\nWe integrated **Meko as a contextual memory layer**.\n\nThe idea is that AI-driven interactions can retrieve relevant memories rather than relying only on the current prompt. We use the game engine and YugabyteDB as the authority for canonical facts, while Meko supplies supporting context.\n\nOur integration includes live memory write-and-recall testing and an outbox-based path for delivering memory updates.\n\nOne limitation we discovered is that a working memory integration doesn't automatically mean a populated knowledge base. Our latest tests showed that the Meko knowledge-base search returned no results until documents are seeded. In that case, ECHO labels its local fallback rather than pretending the result came from Meko.\n\nThat distinction matters: **a system should be honest about where its information came from.**\n\nWe integrated Gemini and Groq behind a Model Gateway instead of scattering provider-specific calls throughout the game.\n\nThe gateway centralizes inference requests, while application-side validation helps keep AI outputs within the formats and rules the game expects.\n\nThe models can help power interactions, but they don't get unrestricted authority over the game's state. An AI-generated statement isn't automatically a verified fact, and an agent's suggestion isn't automatically an approved game action.\n\nThis also gives us a cleaner place to handle provider failures, fallbacks, and future changes to model selection.\n\nThese aren't external services; they're core parts of our game design.\n\nMORROW introduces controlled interference. ECHO helps the player inspect the resulting evidence and trace its provenance.\n\nTogether, they explore a question I find interesting: what happens when AI can influence the information a person receives, but the system preserves enough history for that influence to be investigated?\n\nInstead of treating AI as an unquestionable narrator, we make its effects part of the mystery.\n\nBuilding this at HackCBS 9.0 with Yash was a challenging experience. We were trying to connect a playable game, multiple AI components, persistent database state, contextual memory, and branching investigation logic under hackathon time constraints.\n\nOne of my biggest takeaways was that having a technically ambitious idea is only part of the work. You also need to decide what to demonstrate, make the important interactions understandable, and communicate what is genuinely working versus what still needs improvement.\n\nWe didn't make the Top 10. Of course, we would have loved to, especially after putting so much thought into the architecture and the investigation mechanics. But I also came away with questions about the event itself.\n\nOne thing I struggled with was understanding how consistently the **build-from-scratch expectations** were being applied.\n\nI saw a drone project that, from what I understood, had been started roughly two months before the event, and it placed second. I couldn't independently verify its full development history or what the organizers had approved, so I don't want to present that as proof of a rule violation. Still, it left me wondering how much pre-existing work was permitted and how that was assessed across teams.\n\nI also found myself wondering how the Top 10 decisions were reached. Some selections left me uncertain about the relative weight given to originality, implementation, technical depth, and presentation. At moments, I even questioned whether some outcomes might have been influenced by factors beyond the projects themselves. I don't have evidence to claim that the results were fixed, and I wouldn't want to make that accusation without it.\n\n**What I would genuinely like is more transparency about the criteria, the treatment of pre-existing work, and the feedback behind the final selection.**\n\nIf our project fell short in execution, clarity, technical depth, or demo quality, I'd rather know that specifically than assume the result tells the whole story.\n\nI believe hackathons are most valuable when builders understand both what they did well and what they could have done better. Clear criteria and useful feedback help everyone improve, whether they place first or don't make the shortlist.\n\nLooking back, I would focus on three things:\n\nThese are improvements I can act on regardless of the judging outcome.\n\nThe biggest lesson was that **building more features isn't the same as making a stronger project**.\n\nA system can have a database, multiple models, contextual memory, branching timelines, and an adversarial agent, but the audience still needs to experience one clear reason those pieces belong together.\n\nI also learned to be more precise about technical claims. A successful connection test is evidence of integration, not proof of scalability. A memory write-and-recall test isn't proof of a fully populated knowledge base. An AI fallback is useful, but it should be visible rather than disguised.\n\nAnd perhaps most importantly, I learned that a hackathon result shouldn't stop me from asking difficult questions about my own work—or about the process through which it was evaluated.\n\nI want to keep improving THE LAST BLINK: SECOND SETTLEMENT, especially the cross-timeline investigation loop, the quality of NPC interactions, and the integration between persistent game history and contextual AI memory.\n\nI also want to get feedback from people who care about game design, distributed systems, AI reliability, and fair hackathon evaluation.\n\nIf you have experience with YugabyteDB, Meko, multi-agent systems, investigative game mechanics, or hackathon judging, I'd genuinely appreciate your perspective.\n\n**What would you have wanted to see in our demo to make this project stand out?**\n\nAnd if you were at HackCBS 9.0, how did you interpret the build-from-scratch expectations and the judging process?\n\nI'm sharing this because the project is still worth building, and because the most useful thing I can take from a difficult result is a clearer understanding of what to improve next.", "url": "https://wpnews.pro/news/the-last-blink-second-settlement-building-an-ai-driven-investigation-across", "canonical_source": "https://dev.to/demonstrikkk/the-last-blink-second-settlement-building-an-ai-driven-investigation-across-timelines-31ci", "published_at": "2026-11-04 04:11:15+00:00", "updated_at": "2026-11-04 04:22:06.008842+00:00", "lang": "en", "topics": ["ai-agents", "ai-products", "artificial-intelligence", "developer-tools"], "entities": ["THE LAST BLINK: SECOND SETTLEMENT", "Yash Gupta", "HackCBS 9.0", "YugabyteDB", "YSQL", "Meko", "React", "Phaser"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/the-last-blink-second-settlement-building-an-ai-driven-investigation-across", "markdown": "https://wpnews.pro/news/the-last-blink-second-settlement-building-an-ai-driven-investigation-across.md", "text": "https://wpnews.pro/news/the-last-blink-second-settlement-building-an-ai-driven-investigation-across.txt", "jsonld": "https://wpnews.pro/news/the-last-blink-second-settlement-building-an-ai-driven-investigation-across.jsonld"}}