DORANAV
An Unnecessarily Serious Engineering Logbook
"Because asking whether Dora was blind turned into building a graph-based dynamic A* navigation system in Flutter."
The Spark of Absurdity
Most hackathon ideas start with market analysis or fintech problems. Ours began with an Instagram reel asking:
"Is Dora actually blind, or does she just not care?"
— Seen on a Reporter Live Instagram postInstead of scrolling away like sensible human beings, we paused. What if Dora wasn't careless? What if she simply lacked an algorithmic navigation engine with dynamic recalculation, mood weights, and Swiper evasion heuristics?
When TinkerHub's Useless Projects 3.0 was announced, we took this absurd premise and decided to treat it with ruthless, uncompromising engineering rigor.
Dora Needed a Way Out
It started with a surprisingly simple problem: Dora has places to go, but she does not really have a navigation system. While scrolling through Instagram, we came across a Reporter Live post asking whether Dora was actually blind. Instead of simply scrolling past it, we started wondering what it would look like if Dora actually had a system that could guide her through her world.
TinkerHub's Useless Projects 3.0 gave us the perfect excuse. We initially approached the problem like a miniature Google Maps: give Dora a map, let her select a destination, calculate a route, and guide her there.
The first solution was straightforward: create a custom map of Dora's world with important destinations connected through navigable paths. That sounded reasonable.
A Map Alone Wasn't Enough
Once we started designing the map, we realised that simply displaying locations would not actually solve the navigation problem. A static map can show Dora where places are, but it cannot tell her what to do when the world changes.
So we pivoted from building a map interface to building a real navigation system. We created a custom Dora world containing destinations, intermediate locations, roads, bridges, rivers, and mountains.
- • Locations → Mathematical Nodes with coordinates (x, y)
- • Roads & Rivers → Directed Weighted Graph Edges
- • Path Properties → Distance, Difficulty, Safety, Swiper Risk
Instead of treating these as drawings on a screen, we represented them as structured navigation data. This gave us something much more useful than a pretty map: we had a world that could actually be processed by an algorithm.
How Does Dora Find the Best Route?
The next problem was obvious: once we had a connected world, how would Dora actually find her way from one location to another? Hard-coding a route for every destination would have been easy, but it would not really be navigation.
We needed an algorithm that could inspect available paths and calculate the optimal route dynamically. We approached the problem using graph-based pathfinding and selected A* (A-Star).
"At this point, the project had officially gone from 'Let's make Google Maps for Dora' to 'Okay, now we need to implement A*.'
Orpichu A* mathiyenn 😂"
The Route Cannot Be the Same Every Time
A single shortest path was still not enough because Dora's journeys were supposed to feel different depending on what she wanted from the adventure.
We changed the route-selection model so that A* remained the underlying engine, while path weights shifted according to selected preferences:
Balanced speed & distance
Avoids risky thief zones
Easier, friendlier paths
Longer paths for discovery
What If the Road Suddenly Becomes Unavailable?
This was where the navigation system became genuinely dynamic. A route calculated at the start assumes the world is peaceful, but Dora's world is notorious for surprise obstacles. Bridges collapse, roads get blocked, and Swiper sneaks in.
"We tried to implement dynamic obstacle rerouting, but we messed up 😒. When obstacles started spawning, everything came in our way, every single path got blocked, and Dora was unable to find her way!"
"To note, we were doing this during the last 3 golden hours of our hackathon and everything fell apart! Dora started behaving like a mad girl wandering anywhere and getting deeply disappointed in us for not reaching her destination. We were ashamed as hell since we messed it all up..."
Swiper Is Not a One-Time Event
Once we had basic rerouting, another question emerged: what happens if the alternative route gets blocked too?
We refused to hardcode fallback paths. Instead, we architected the system to repeatedly re-evaluate the graph whenever any obstacle state toggles:
Navigation Should Understand the Journey
Finding a path was great, but we wanted DoraNav to understand the context of the adventure. This sparked the Backpack System.
Instead of displaying a static set of tools, the app examines route properties, biome, and terrain:
- 🚣 Water Routes: Recommends raft, safety rope, life jacket
- 🔦 Cave Biomes: Suggests high-beam flashlight & lantern
- 🧤 Snowy Peaks: Suggests thermal parkas & climbing picks
"It was supposed to be a tiny fun feature. Somehow, Dora now has better, more intelligent travel preparation than most of us on our college trips."
Building Was Harder Than Designing
The biggest hurdle wasn't coming up with crazy features—it was making them actually compile and cooperate in Flutter.
Our previous Flutter experience was modest. Building a complete application with custom map projections, pathfinding algorithms, live obstacles, audio engines, and animations was a whole different trial by fire.
The Ending Needed to Feel Like an Ending
After spending all that sweat and coffee getting Dora to her destination, simply flashing a boring "Destination Reached" dialog felt like an insult to the journey.
When destination is reached, background music fades out and the Fiesta Trio celebration kicks in! Recreated natively in Flutter using animation controllers, bouncing tweens, confetti particles, and character fanfare.
The Adventure Report
After the celebration, the application compiles an Adventure Report containing distance traveled, turns taken, bridges crossed, Swiper encounters, and overall score:
"Because reaching a fictional castle now requires enterprise-grade analytics."
Tears, Panic & The Broken Trio
Now reached the submission deadline... and I was going through an absolute storm of emotions.
"I was not able to complete the features that I had in my mind. Sufiyan was constantly trying to console me:
But nothing was sinking into my head. Tears started rolling down my cheeks. But because the core event team was actively walking around videographing our desks, njn athokke pidichu vechu (I fought to hold it all inside)."
And Then... 2nd Place! 🥈
We pushed the code and submitted with whatever screenshots we had. The presentations began. People had thought of brilliant and deeply useless ideas!
Then came the moment of our college's result announcement:
A wild surge of emotions erupted—pure disbelief, relief, joy. All the tears, the 3 AM debugging, and the stubbornness gave me the confidence that we could build anything.
Was Any of This Actually Necessary?
Dora probably did not need a custom graph-based navigation engine. She probably did not need mood-based route selection, contextual backpack recommendations, dynamic Swiper rerouting, voice navigation, background music, or an Adventure Report.
"But that was never really the point."
The project began with a completely unnecessary question and became an opportunity to take that question seriously enough to build something real.
The Story Continues...
Finishing off the hackathon doesn't finish our potential limit. Dora's journey has just begun: