← Back to list

I turned a scene from the Mahabharat into a mobile game — here’s everything it taught me….

Timeline goes as follows

Parthvaidya · 2026-05-10 15:54 · 3 claps · 9.4 min read
#indie-game-dev #mahabharata #unity #storytelling #india
Open on Medium ↗
Wiki topics: LIT · Literature & Writing 🎮 · Gaming

I turned a scene from the Mahabharat into a mobile game — here’s everything it taught me….

Timeline goes as follows

The Spark

Every game starts with an idea that sounds brilliant at night and impossible by morning.

Mine started with Draupadi’s swayamvar.

If you know the Mahabharat, you know the scene — Arjuna, the greatest archer (which is also my name meaning ) in the world, looks up at a rotating fish, sees only its reflection in the water below, and shoots it clean through the eye. I wanted to build that. A game where you line up the shot, read the reflection, and release. Something that felt mythological and precise and satisfying. Also had a liking for Indian Mythology.

Except I had no idea how arrow mechanics worked in Unity.

I spent days trying to get a bow string to pull back, an arrow to follow a physics arc, to feel like weight, which I couldn't excel at yet, but at least my arrows go in the direction of dots.

Meanwhile, the swayamvar idea quietly died — not because it was a bad idea, but because I wasn’t able to make it a game like scenario. I filed it away. That game will come. Next time, with a proper string pull and everything hopefully.

But the arrow mechanics stayed with me. I knew something was there. I just needed a different story.

My father, in the way fathers somehow always know the right moment, sat me down in front of the Mahabharat. Not the scene I was chasing. An earlier one — quieter, smaller. Dronacharya in the courtyard with his students. Young Pandavas and Kauravas, still children, learning to shoot. Fruits hanging from trees. Arrows flying. Joy in it, before the war, before any of the weight that comes later.

I watched that and thought, and my father said that’s the game.

Not the epic climax. The practice. The learning. The childhood version of something that would later change the world.

I contacted a talented 2D artist. Described what I was seeing in my head. A few weeks later, the first characters came back to me — Arjuna, hand-drawn, distinctly Indian, beautiful in a way I hadn’t expected, which I then rigged myself, gave it movement from waist above, and gave it life for movement.

That’s when DRONARCHERS stopped being an idea and started being like a game.

Making it look right

The first mechanic was simple. Embarrassingly simple, actually.

Three fruits. Coconut, orange, tomato. Coming up from the bottom of the screen like Fruit Ninja. Arjuna is standing there, bow ready. You tap, he shoots, the arrow flies — and if your timing is right, it carries the fruit clean off the screen with it.

Kachhh.

That sound. I don’t know why it hit different the first time it worked, but it did.

But before that sound existed, there were days of nothing working.

The rigging came first. Taking a hand-drawn 2D Arjuna — a real artist’s work, not a placeholder — and giving him bones, weight, and movement. Making his arm pull back as a real archer would. Making it feel like the character was choosing to shoot, not just triggering an animation. That alone took longer than I want to admit.

Then I had to marry that rigging to physics. The fruits needed real arcs, real momentum coming up from the bottom. The arrows needed to actually intercept them — not just play a hit animation, but physically collide, catch, carry. Unity’s physics and a rigged 2D character don’t naturally want to cooperate. I was essentially forcing two systems to shake hands that had no reason to meet.

Some builds launched fruits through walls. Arrows that fired sideways. A version of Arjuna whose arm detached from his body mid-shot and I still don’t fully understand why.

But then one evening, on an Android build on my actual phone — not the editor, not a simulator, my phone — I tapped the screen and Arjuna drew back, released, and the arrow cut straight through an orange on its way up.

Kachhh.

I shot a hundred arrows that session. Just stood there in my room tapping my fingertip against the screen, watching a rigged 2D character I had built from scratch rip through fruits in a scene that looked, genuinely, like something from ancient India.

That was the moment I knew this game was real and something i was building.

Making It Actually Work

Here’s the thing nobody tells you about game development.

Getting it to run and getting it to matter are two completely different problems.

The flow came together first. A loading screen that breathed — transitioning into a tap-to-start page where the story of DRONARCHERS scrolled past in text built for a generation that reads in three seconds or skips entirely. Then the main menu. Five characters lined up, swipeable, each with their own description, their own weight. Arjuna. Bheem, Duryodhan, Ashwatthama, and Karna. The others. You could stand there and browse them like you were choosing a legend to carry into battle.

Four scenes. Loader. Story. Menu. Game. Simple on paper. Months in reality.

Under the hood, the architecture was the most ambitious thing I’d attempted. Object pooling for the fruits — coconuts, oranges, tomatoes juggling up from the bottom in endless waves, recycled and relaunched so the game never choked on memory. Addressables to find and load each fruit dynamically, with Scriptable Objects defining every property — size category, point value, and the exact force it launched with. Separate pools for arrows. A Game Manager holding the session together. An Audio Manager conducting the background score and every kachhh like a tiny orchestra. MVC keeps the UI clean and decoupled. SOLID principles threaded through everything like load-bearing walls.

I was proud of it. Genuinely proud.

Then the bugs arrived.

UI that looked perfect in the editor exploded across different screen sizes as it had never been seen on a phone before. The arrow pool ran dry mid-session — players pulling back their shot and finding nothing there, the dots showing one direction while the actual arrow flew somewhere completely different. Points that ticked up with no soul behind them, no escalation, no drama. Just a number going higher for no reason that felt real.

I fixed them after work, sitting late nights after a tiring office and a full day of the same grind, officially. One by one, session by session, the kind of debugging that happens at midnight when the rest of the world is asleep, and you’re staring at a line of code, asking it why.

And then I sat with the finished build.

And shot a hundred arrows into a hundred fruits.

And felt nothing.

That was the moment I had to be honest with myself. The systems were solid. The architecture was clean. The code would make any senior developer nod respectfully. But the game — the thing a player picks up for thirty seconds on a Tuesday and either keeps or deletes — was boring. A hundred arrows into floating fruits with no stakes, no escalation, no reason to care what happened next.

But the real wall wasn’t technical at all.

The Levels

Boring games don’t need better code. They need better design.

I knew the fruit mechanic alone wasn’t enough. A hundred arrows into floating fruits with no consequence, no story, no escalation — it was a tech demo wearing a game’s clothes. Something had to change. Not the architecture. Not the pooling or the addressables or the carefully structured MVC. The soul of the game thing.

The answer came from a free medieval asset pack.

Shields. Spears. Weapons from another era entirely, nothing to do with ancient India on the surface. But one asset stopped me — a shield. Simple, circular, the kind of warrior carries into battle. I looked at it and thought: what if that’s what stands between the arrow and the target?

The spears got shelved. The shield stayed.

And suddenly I had five levels.

Each level has a character. Each character got a personality expressed entirely through how that shield moved.

Ashwatthama opens the game — Dronacharya’s own son, trained from birth, but still a student. His shield rotates slowly, disappears, and returns. A rhythm you can learn in thirty seconds. The game teaches you its language gently before it raises its voice.

Bheem gets the fruit level — the chaos I’d built first, repurposed. Bheem was never about precision. He was about power, about volume, about overwhelming force. Fruits flying from every direction felt right for him. The earliest mechanic finally found its character.

Duryodhan’s shield swings like a pendulum. Steady, predictable, but heavier somehow. There’s arrogance in that movement — a warrior so confident in his defense he doesn’t feel the need to surprise you.

Karna breaks the pattern entirely. His shield moves without logic, without rhythm, without mercy. Unpredictable in a way that feels personal — because Karna’s whole story was unpredictability, a great warrior dealt an unfair hand, fighting anyway. You can’t memorize his level. You can only react.

Arjuna is last. His level takes everything before it — the rotation, the pendulum, the chaos — and combines them. Because Arjuna wasn’t just talented. He was complete. The best archer in the world didn’t specialize in one thing. He mastered all of them.

Five characters. Five shields. One scene handling all of it — Scriptable Objects swapping levels, characters, backgrounds, enemies in and out without ever loading a new scene. Five levels running in the same memory space, optimized down to nothing wasted.

But levels alone still weren’t enough to make the game captivating.

So I added coins. Every clean hit earned one. Enough coins bought a slow motion ability — arrows dropping to half speed, the world going quiet, giving you the precision of Arjuna himself for a few perfect seconds. Suddenly, every shot had stakes. Every miss had a cost.

Then a daily reward system. A small thing. A reason to open the game tomorrow, even if you’d already beaten everything today.

The hook that keeps a player isn’t always the game itself. Sometimes it’s just the promise that something will be different when they return.

DRONARCHERS had finally stopped being mechanics. It had become a game.

[embed]

The Bigger Point

Here’s what a courtyard scene from the Mahabharat taught me about game development.

Every story already exists. The work is seeing it.

Dronacharya teaching children to shoot fruits wasn’t a major scene. It wasn’t the Kurukshetra war, nor was it any of the grand dramatic turning points the epics are remembered for. It was a quiet Tuesday in ancient India — a teacher, his students, and some fruit hanging from trees. Blink, and you miss it.

I built a whole game out of it.

And that’s the point I want every Indian developer to sit with for a moment. We are swimming in source material. The Mahabharat alone has more characters, more moral complexity, more dramatic tension than most modern fiction could dream of generating from scratch. The Ramayan. The Puranas. Regional folklore that hasn’t even made it to mainstream consciousness yet. Thousands of years of stories sitting untouched, waiting for someone to pick them up and build something.

The world is hungry for this. Not a reskin of an existing Western game with Indian names pasted over it. Something that could only come from here — characters with real weight behind them, mechanics that mirror actual mythology, levels that feel like chapters from a story your grandmother knew by heart.

Nobody is building it. Not at scale. Not with intention.

That gap is an opportunity disguised as an empty market.

But let’s be honest about the hard part as well.

Games are brutally difficult to monetize. The market is crowded, the algorithms are expensive, and organic discovery on the Play Store is largely a myth unless you already have an audience. Paid acquisition works but costs real money to learn. AdMob revenue requires session depth and volume that a solo developer building their first title simply doesn’t have yet.

The stories are free. Everything around them costs something.

Which means Indian developers who want to tell these stories need two things that game school doesn’t teach — marketing instincts and distribution channels. How to reach the diaspora that grew up with these names and would feel something seeing them rendered in a game. How to reach international audiences curious about mythology they’ve never encountered. How to build a community before the game launches instead of after.

The creative case for Indian mythology in games is obvious. The commercial case needs building, deliberately, by developers willing to treat marketing as seriously as mechanics.

DRONARCHERS was my first attempt at both.

It’s imperfect in ways I can list precisely because I lived through building it. The monetization needs work. The marketing was expensive schooling. There are mechanics I’d redesign and systems I’d architect differently.

But there’s a rigged 2D Arjuna on the Play Store and the App Store, shooting arrows through fruits in levels named after warriors who lived in stories my father made me watch for inspiration on a quiet evening at home.

That scene from the Mahabharat became a game.

The next one will be bigger.

This is the question I would like to ask: “What scene from Indian folklore do you think is a hidden gem for a game mechanic?”

Link to Game Android: https://play.google.com/store/apps/details?id=com.Kreedathon.Dronarchers

iOS: https://apps.apple.com/in/app/dronarchers-the-legends/id6755245581

Do try and let me know how the game is….


메타데이터
post_id
0abc82d2cda0
slug
i-turned-a-scene-from-the-mahabharat-into-a-mobile-game-heres-everything-it-taught-me-0abc82d2cda0
url
https://medium.com/@parthvaidya99/i-turned-a-scene-from-the-mahabharat-into-a-mobile-game-heres-everything-it-taught-me-0abc82d2cda0
canonical_url
https://medium.com/@parthvaidya99/i-turned-a-scene-from-the-mahabharat-into-a-mobile-game-heres-everything-it-taught-me-0abc82d2cda0
author_url
https://medium.com/@parthvaidya99
status
ok
fetched_at
2026-06-09 15:37:30