Solstice Sync: A Dynamic Gemini AI Alignment Puzzle

This is a submission for the June Solstice Game Jam

What I Built

Solstice Sync is a fast-paced cosmic puzzle game where players must balance the light and shadow forces of the June Solstice. The goal is to achieve the highest synchronization score possible within a strict 30-second countdown. Every 6 seconds, the game delivers a cryptic text prompt representing either intense daylight or deep twilight, and players must quickly align the energy core to match the theme before time runs out.

Video Demo

Here is the complete 34-second gameplay loop demonstration showcasing the start screen, live gameplay mechanics, rapid synchronization scoring, and the final stabilization sequence:

https://www.youtube.com/watch?v=EfIvIQ7KimU

Code

You can explore the full React architecture, state management lifecycle, and component scripts in my repository here:

[View GitHub Repository] https://github.com/j85219826-star/june-solstice-game-jam
🌐 [Play Live Game Here] https://j85219826-star.github.io/june-solstice-game-jam/

How I Built It

The application is architected entirely using React 19 and bundled via Vite for optimized fast-refresh compilation.

• State & Lifecycle Management: Built using robust React core hooks (useState, useEffect, useRef). I utilized refs to cleanly synchronize the independent 1-second countdown interval with the 6-second cosmic prompt rotation cadence.
• Resilient Fallback Design: To prevent the user experience from degrading due to live browser network restrictions or client-side CORS barriers on public hosts, I engineered a structural fail-safe array containing 16 unique, pre-composed light/shadow riddles. If a backend request encounters an origin block, the application gracefully flags the catch-block and continuously serves random variations to guarantee 100% gameplay uptime.
• UI Design System: Designed with a custom inline layout mimicking a modern dark-mode terminal framework. It utilizes stark blue-slate variations (#0F172A, #1E293B) combined with glowing neon indicators to create a highly responsive, atmospheric aesthetic.

Prize Category

Best Google AI Usage

This project is configured directly with the official @google/genai SDK and utilizes the Gemini 2.5-Flash model. In local runtime environments, the system completely bypasses hardcoded text arrays to execute live zero-shot prompt requests, treating Gemini as a dynamic "Celestial Narrator" that generates completely unique, poetic statements about light or dark alignments on the fly.

Comments

[EL MOSTAPHA JAAIDI]

Hey 👀

Nice project, I saw you're using FastAPI + bio-related systems.

I’m building something similar but applied to agriculture:
real-time decision systems using IoT + biological models.

Feels like an interesting overlap.

Curious what direction you're taking with your projects

[FatimaZehra.Dev]

Thanks! There's definitely a huge structural overlap when it comes to handling real-time data streams and time-series logic, whether it's celestial tracking or IoT telemetry. I went with FastAPI to keep the backend asynchronous and low-latency. Your AgTech project sounds incredibly interesting— I would like to know more about your project!

[FatimaZehra.Dev]

¡Qué gran arquitectura! Usar VPD para automatizar el riego y predecir riesgos fitosanitarios en tiempo real es una solución brillante, especialmente el enfoque de tomar decisiones con datos ruidosos o incompletos. Al final, manejar el estado y la latencia en time-series es el verdadero reto técnico, sin importar el caso de uso. Le echaré un vistazo a tu prototipo en agrosentinel.dev.

[EL MOSTAPHA JAAIDI]

Thanks! Really appreciate that – and yeah, the core challenge is very similar across domains.

In our case, we use VPD as a proxy for leaf wetness because direct sensors tend to be expensive and unreliable in real field conditions. So it turns into more of an inference problem from imperfect data rather than direct measurement.

Right now we're running historical replays (~100k records) with crop coefficients (FAO-56) and time-sensitive irrigation logic, trying to keep decisions valid even under noisy inputs.

Curious how you're handling state and timing in Solstice Sync — is it running fully real-time or more like a controlled simulation?

[FatimaZehra.Dev]

Smart move using VPD as a proxy—field sensors are notoriously unreliable, so solving that in the code is definitely the way to go. Testing with historical replays against FAO-56 sounds solid too.
For Solstice Sync, it actually runs as a controlled simulation with a deterministic state machine rather than an open real-time clock.
Since the alignment mechanics need strict validation, processing inputs in discrete steps keeps the timing predictable and makes it way easier to test specific scenarios.
Good luck scaling Agrosentinel, man. It sounds like an awesome project!

[EL MOSTAPHA JAAIDI]

That makes sense 👀

using a deterministic state machine to control time
is actually very elegant for debugging and validation

I’m currently exploring the opposite direction:
trying to keep decisions stable
while the data itself is unstable

sometimes I wonder if combining both approaches could work:
deterministic state transitions
but with adaptive confidence on inputs

might be interesting for systems where timing matters but inputs are messy 🤔

[FatimaZehra.Dev]

Combining them could absolutely work. You could use a validation layer that scores the data confidence before it hits the state machine—if the confidence is too low, the state machine just holds or transitions to a 'safe' fallback state.
It's definitely a solid architecture pattern for handling messy real-world data. Best of luck getting those inputs dialed in!

[EL MOSTAPHA JAAIDI]

That's actually a really clean framing —

and yes, I haven't formalized it as a separate layer either,
but the idea is already implicit in how we handle VPD

Right now we treat it as binary-ish:
if VPD crosses a threshold → flag phytosanitary risk

but the threshold itself is static, which is where things start to break

The direction I'm thinking about is something like graded confidence:
instead of "is this reading valid?",
ask "how much should I trust this reading?"

and let that score modulate the decision rather than gate it

For example —

a noisy VPD spike at 2am with inconsistent temp readings
gets a lower confidence score than the same spike during peak hours
with stable sensor history

The state machine still runs,

but the action threshold shifts depending on confidence:
high → act normally

mid → act with reduced margin

low → hold, use last known good state

The tricky part you're pointing at is exactly right:

in agriculture, rejecting a low-confidence reading completely
can be just as dangerous as acting on it blindly

because sometimes the noise is the signal
(a malfunctioning sensor during a heat spike is still a heat spike)

Have you encountered patterns for keeping rejected inputs "in the loop"
as weak signals rather than cutting them off entirely?

[FatimaZehra.Dev]

Using a sliding scale for confidence based on context (like time of day) is definitely the way to go.
For keeping weak signals in the loop, a common pattern is running a parallel accumulator or a rolling average for anomaly detection. That way, even if an individual input is 'rejected' for immediate action, its weight still influences the broader trend.
It’s a fascinating architectural puzzle to solve.