The new two-minute walkthrough below starts on the ground, opens the full report and follows a controlled demonstration through its matchups, pitch map, technique and progress. The sections after it explain the numbers and views in more detail.

Detailed Batting Analysis connects every delivery with its bowler, speed, length, outcome, bat contact, timing and player movement. You can start with the full session, find a weak area, and keep narrowing the data until you understand what needs to improve.

#It starts with every ball you played

The walkthrough uses a controlled demonstration session of 120 deliveries: 115 legal balls, two wides and three no-balls. The no-balls also include three runs from the bat.

That line at the top of the interface matters. Percentages such as strike rate and control need to use the correct legal-ball count, while wides and no-balls still belong to the complete session record.

Each delivery stays connected to the information CricketX already had while it was being played:

• Bowler type
• Batting side
• Delivery side
• Length
• Speed
• Outcome
• Ball landing position
• Bat contact and swing timing
• Headset movement and viewing direction

This is the foundation of the whole report. You are not looking at separate numbers that happen to come from the same session. You are looking at the same deliveries from different angles.

So when the report shows a problem, you can investigate it instead of guessing.

#First, understand the full session

Overview gives you the quickest answer to a simple question: how did this session go?

Control shows how often the batter stayed in control of the shot. A legal-ball miss, an OUT, poor contact or a badly mistimed swing lowers it. It is not a label for “safe” shots, and it is not another name for dismissals. It combines the parts of a delivery that show whether the batter controlled the bat and the result.

The other cards show:

• Strike rate
• Dot-ball percentage
• Boundary percentage
• Scoring-shot percentage
• Bat contact
• Swing timing

These numbers answer different questions. Strike rate shows scoring speed. Bat contact shows how often the bat met the ball. Timing shows whether contact was early or late. One good number cannot hide every other problem.

The lower panel turns the report into Strengths, Needs Work, and Focus Next. These notes come from the current session. Their purpose is not to praise or criticise the player. Their purpose is to give the next practice a clear starting point.

That is the real value of Overview. It does not leave you with “55% Control” and expect you to decide what that means. It shows you where to look next.

#Use filters to find the real problem

Filters apply to the whole report, not only the open tab.

You can narrow the session by bowler type, delivery side, length, speed or outcome. Training sessions can also be separated by batting side. CricketX only shows filter options that actually exist in the session, so the player is not searching through empty categories.

The controlled session in the video gives a simple example:

• Across the full session: 55% control and a strike rate of 72.
• Against right-arm fast bowling: 80% control, a strike rate of 147, and no OUTs.
• Against right-arm leg spin: 47% control, a strike rate of 7, and two OUTs.

The full result says the session needs work. The filtered result says something much more useful: pace was handled well, while leg spin caused a clear problem.

The player can keep narrowing it. Select deliveries at 120 kilometres per hour and above to study faster bowling. Select Good Length to study one landing area. Combine filters when the question needs to be more exact.

Every other tab follows those active filters. This means the same leg-spin problem can be inspected through Matchups, Pitch Map, Technique, Scoring, Profile and Progress without losing the selected deliveries.

This is the point where broad feedback becomes a specific training target.

#See which deliveries changed the result

Once you have found a weaker area, Matchups helps explain what created it. It starts with a direct pace-versus-spin comparison and places strike rate, Control, boundaries and OUTs together.

The lower panel then provides four comparison views.

#Bowler

Bowler compares every bowling style faced in the session. It is the clearest place to see whether the batter performed differently against right-arm pace, left-arm pace, off spin, leg spin or another available type.

#Delivery

Delivery compares the actual ball types that appeared, such as leg breaks, yorkers, full tosses and top spinners.

Two bowlers can belong to a similar category while asking very different questions of the batter. This view moves the analysis closer to the delivery that caused the result.

#Length

Length compares where the deliveries pitched: yorker, full, good length, short, or any other length present in the session.

This helps separate a bowling-style problem from a landing-area problem. The batter might be comfortable against leg spin in general but struggle when it lands on a good length.

#Speed

Speed compares pace ranges, from slower deliveries to more than 140 kilometres per hour.

It shows whether control, scoring or OUTs changed as the pace increased. Because the same filters remain active, the batter can study speed across the whole session or only against one bowler type.

These are not four unrelated charts. They help you move from “I struggled against spin” to something you can actually practise, such as “good-length leg breaks reduced my Control and produced two OUTs.”

The closer the report gets to the exact delivery, the easier it becomes to build the right drill.

#Put the weakness back on the pitch

Pitch Map places the analysis back on the pitch.

In Control view, every zone shows the percentage of legal balls played in control from that landing area. Every dot is a delivery. Every marked OUT is a real wicket from a ball that landed there.

Those OUT markers are important. They are not general warnings and they are not every false shot. They show the landing positions of deliveries that actually ended in a wicket.

The panel on the right groups those OUTs by length, pace or spin, and delivery type. The map shows where the problem happened. The breakdown helps explain what produced it.

Open Strike Rate and the same pitch zones show runs scored per 100 legal balls. A zone can have good control but weak scoring, or quick scoring with poor control. Looking at both views prevents one number from hiding the trade-off.

Together, the views answer two practical questions:

1. Where did the batter lose control?
2. Where was the batter able to score?

Now the next practice can be built around a real location and delivery type. A weak good-length area against leg spin is much easier to practise than a vague instruction to “play spin better.”

#Check what happened in your technique

Two shots can finish with the same result for very different reasons. Technique looks at the movement behind the outcome.

#Ball Tracking

Ball Tracking measures the angle between the player's viewing direction and the ball at contact. A larger angle means the ball was farther away from where the player was looking when the bat met it.

This does not try to replace a coach's judgement. It gives the player a repeatable measure of whether the ball remained in view through contact.

#Head Discipline

Head Discipline shows head drift and the horizontal distance between the head and the ball.

These are related but different. A batter can keep the head fairly still and still finish too far away from the ball. The two measures make that difference visible.

#Swing Timing

Swing Timing shows whether contact happened early or late. The demonstration session contains many early swings, which gives the player something specific to work on rather than only seeing the final scoring result.

#Bat Contact

Bat Contact measures how well the ball met the bat. A swing can make contact and still be poorly middled. This view separates simply hitting the ball from hitting it cleanly.

In the demonstration report, head movement and position are reasonably strong, while ball tracking and early timing need more attention. Instead of trying to rebuild the whole batting technique, the player leaves with two focused areas to work on.

The data does not replace a coach. It gives the player and coach repeatable evidence they can use together.

#Understand what your shots produced

Scoring contains two connected views.

The Wagon Wheel uses the real direction and distance of each legal-ball result. Scoring shots extend into the field. Misses, leaves and bowled balls remain near the stumps because the ball did not travel as a scoring shot.

The Delivery Outcomes panel separates dots, singles, twos, threes, fours, sixes, OUTs, wides and no-balls.

The wagon wheel shows where. Delivery Outcomes shows what happened.

Together, they can reveal whether the next session should focus on placement, strike rotation or boundary scoring. They can also show that a high strike rate came from one scoring area rather than control around the full field.

#See the complete shape of your batting

Profile condenses the session into six batting traits.

• Control uses the same control result explained earlier.
• Timing measures how close contact came to the moment of peak bat speed.
• Power uses bat speed at contact.
• Intent uses scoring rate to show how actively the batter scored.
• Placement measures the spread of scoring directions.
• Watching uses the angle between the player's viewing direction and the ball.

The radar chart makes the overall shape easy to read. It might show strong timing and placement beside weaker watching or control. The detail remains available in the earlier tabs, but Profile makes the balance visible in one place.

The panel on the right shows control at each difficulty level. That prevents a strong overall number from hiding a large drop when the session became harder.

Profile gives you the summary. The earlier views give you the evidence behind it.

#Measure whether the practice is working

Finding a weakness only matters if you can check whether it improved. In Training mode, Progress follows your performance as the session continues.

Control is a rolling percentage over the latest 12 legal balls. It reacts to improvement and sudden drops instead of flattening the whole session into one average.

Runs is the cumulative team total after each legal ball, with extras included.

Contact is the rolling average of contact quality across the same 12-ball window. Misses are excluded from the contact calculation, because this graph measures the quality of contact when contact happened.

The active filters also apply here. Filter the report to leg spin first and Progress becomes a chart of the leg-spin drill. Filter it to Good Length or faster bowling and the graph follows that question instead.

This closes the training loop. Make an adjustment, face the delivery again, and see whether the result changes.

#Match-style modes follow the innings

Training mode uses Progress. In Chase and other over-based modes, the report opens Overs instead.

Runs per Over groups the score into blocks of six legal balls and includes extras.

Trend shows those over totals as a line, making strong and weak overs easier to compare.

Worm keeps a cumulative total after every over, showing the scoring journey across the innings.

These views connect the technical report with match rhythm. A player can see not only how a delivery was played, but also how control and scoring developed across an over-based challenge.

#Turn the report into the next session

The best use of Detailed Batting Analysis is a simple loop:

1. Play a session.
2. Use Overview to find the strongest and weakest areas.
3. Apply filters to isolate the problem.
4. Use Matchups, Pitch Map and Technique to understand what caused it.
5. Build the next practice around that exact situation.
6. Return to Progress or Overs to measure what changed.

For the demonstration session, that could mean filtering right-arm leg spin, checking which lengths caused the two OUTs, reviewing ball tracking and early swing timing, then practising those deliveries again.

The instruction is no longer “face more spin.” It is clear, testable, and connected to the next report.

#What VR adds to the training

Traditional net practice remains valuable. It provides real bowling, a physical environment and direct coaching that a simulator should not pretend to replace.

VR adds something different: the system already knows the delivery that was sent, where it landed, how the virtual bat moved, where the headset was facing, what contact occurred and how the ball finished.

Collecting the same connected record in a normal practice session can require several cameras, sensors, radar, careful notes and time spent joining the information afterwards. Inside the simulation, those events can be measured together and the same problem can be repeated on demand.

That is what turns a session into more than time spent facing deliveries. You can see what worked, find what held you back, and return with a clear plan to improve it.

CricketX is live on Meta Quest.

🥽 Try CricketX on Meta Quest

🌐 Learn more about CricketX

This is the part I left out.

I did not give an AI agent one huge prompt and wait for two games to appear. I divided each game into small stages. Every stage had one clear goal, one way to test it, and one question for me:

Does this feel right when I play it?

I decide → the agent builds → I play → I correct → the correction becomes a rule.

The agent handled the repeated work: writing code, rebuilding systems, generating levels and running tests. I stayed with the part I enjoy most: playing, finding what felt wrong and deciding what should change.

I used this loop for Arrow Jam first, then reused it for Grid Patch. These were the seven steps.

#The workflow in one look

1. Build the main gameplay.
2. Make one playable level easy to create and test.
3. Turn the feeling of difficulty into rules.
4. Design how difficulty should change from level to level.
5. Let the generator create, solve and reject levels in bulk.
6. Make the UI fit the game.
7. Keep changing the small interactions until the game feels good to play.

I moved to the next step only when I could play the current one and understand what it needed next.

#Step 1: Build the main gameplay first

Before thinking about hundreds of levels, menus or animations, I needed one action worth repeating.

For Arrow Jam, that action is tapping an arrow.

If the straight path from the arrow's head to the edge is clear, the arrow flies out. If another arrow is in the way, it hits that arrow and costs a life. The puzzle is to remove free arrows, open new paths and slowly unlock the board.

For Grid Patch, the action is drawing a rectangle.

You drag across the board to create a patch. It must contain exactly one clue and follow that clue's shape and number rules. The level ends when the patches cover the full board correctly.

One test board was enough. The question was not “is the game finished?” It was “do I want to make this move again?”

#Step 2: Make one level easy to create and test

Once the main action worked, I built a small Level Lab for each game.

In Arrow Jam, one level starts as a recipe:

• Choose a shape.
• Choose its size.
• Choose the arrow length and how much the arrows can bend.
• Choose the number of lives.
• Change the variation number to get a different board.

I can press Quick Test without starting the full game. I can play the level, reload it after a change, or watch the solver remove every arrow in the correct order.

Grid Patch has a similar testing space, but its generator starts with a complete solution. It divides the board into rectangles, then creates one clue for each rectangle.

The AI agent could build one change, the tools could prove that the level was valid, and I could immediately play it.

Fast feedback kept the work fun.

#Step 3: Turn the feeling of difficulty into rules

“Hard” is a feeling first. The code only understands it after I explain that feeling using rules and numbers.

#Arrow Jam: difficulty comes from blocked paths

My first Arrow Jam difficulty system cared too much about board size.

At one point, it called a level with 13 arrows Hard. I played it and said:

“This is literally really easy.”

A bigger board can mean more work, but not always more thinking. So I changed what the code measured.

Arrow Jam now looks at how deeply the arrows block one another. The code removes all currently free arrows in groups and counts how many groups are needed to clear the board.

It also checks how many taps are safe at each point. If many arrows can leave, the player can move quickly. If only a few are safe, the player has to stop and read the board.

That gave every tier its own feeling:

• Easy keeps moving. Most taps are safe.
• Normal asks for a short look before the next tap.
• Hard makes the player read the board.
• Super Hard makes the order of the taps important.
• Nightmare can have lock chains around 40 layers deep.

Every level still has to be solvable and look clean. Difficulty should create thought, not visual mess.

#Grid Patch: difficulty comes from tempting wrong choices

Grid Patch needed a completely different system.

Here, a rectangle can look correct at first but leave another clue with nowhere to go. The player has to understand the problem, remove or redraw the patch, and try a better choice.

The generator creates puzzles with exactly one solution. Then a human-style solver counts the easy moves, the choices that lead to a dead end, and the reasoning needed to discover each problem.

An Easy puzzle asks for almost no correction. A Nightmare puzzle can contain 30 to 40 tempting choices that the player must rule out.

The board can grow, but size is not the main source of difficulty. The real difficulty is how often the player has to stop, think and reconsider.

Two different games. Two different ways to measure “Hard.”

The workflow stayed the same: decide what the player should feel first, then teach the code how to recognize it.

#Step 4: Build the difficulty curve

A difficulty system can judge one level. A difficulty curve decides how hundreds of levels should feel together.

Too many hard levels in a row become tiring. Too many easy levels in a row become boring. A good campaign needs both pressure and rest.

For both games, the opening levels teach the rules. Hard first appears at level 20, Super Hard at 50 and Nightmare at 100. Harder levels do not sit directly beside one another. Normal levels around them give the player time to recover, and Easy levels return less often as the player improves.

The level number also changes the intensity inside each tier. Two levels can both say Hard without feeling exactly the same.

#Step 5: Generate and test many levels at once

Only after the gameplay, Level Lab, difficulty rules and curve were ready did I create levels in large numbers. Generating 1000 levels before knowing what a good level feels like would only create 1000 problems faster.

For Arrow Jam, the level number creates a recipe: difficulty, shape, size, arrow length, bendiness and variation. The generator builds a board, then the tools ask:

• Is it solvable?
• Did it reach the requested difficulty?
• Does the picture shape still look complete?
• Is it too similar to another level?
• Does it contain rows of same-facing arrows that become boring repeat taps?

If a level fails, the system tries another version.

Grid Patch starts from its requested tier but needs more reasoning checks. One solver proves that the puzzle has exactly one solution. Another follows a more human way of thinking. It rejects puzzles that need unfair guessing, miss the difficulty, repeat another board or lack the planned wrong choices.

During one rebuild of 995 Grid Patch levels, the generator made 573,807 attempts.

Only 995 were accepted.

Exactly 7 levels worked on the first attempt. Level 984 needed 11,078 attempts by itself.

I did not press a button 573,807 times (thankfully). The generator and agent handled that work. Tests checked every accepted level, while I played a smaller selection from the easy, middle and difficult parts of each tier.

The code catches a broken level.

I play the levels to catch a boring one.

That is the balance that made this workflow useful for me.

#Step 6: Make the UI fit the game

Arrow Jam is fast and energetic. Arrows fly away, blocked arrows hit the piece in front, difficulty badges are strong and the win moment has movement and confetti.

Grid Patch is slower and more thoughtful. Its board uses soft colours, painted patches and clear clue shapes. The player should be able to study the full board without the UI fighting for attention.

Both games build their UI in code instead of separate layout files full of hand-placed elements. This made it easier for the agent to apply one design change across the game.

But the decision still came from playing.

Arrow Jam first used arrow-shaped life indicators. They matched the theme, but they did not feel like lives. So I changed them to hearts.

The first idea was clever. The second was clear. Clear was better.

#Step 7: Make every touch feel good

The game can now work, create levels and look good — and still feel bad in the player's hands.

This was not about expected puzzle-game controls. It was about finding where the player had to wait, repeat an action or wonder what happened — then removing that friction.

#Grid Patch

• Turn a redraw into one move. At first, changing an area meant removing the old patch before dragging its replacement. Crossing several patches meant removing each one. That was too much work for one thought: I want this area to be shaped differently.

  Now I drag directly over the old patches, and they fade under the preview. A valid release replaces them all; an invalid one leaves the board untouched. The redraw is saved as one decision, so undo restores the old arrangement in one step.

• Guide the drag without revealing the answer. The preview starts neutral. Once it contains a clue, it takes that clue's colour and brightens when its area and shape follow the rules. It checks only visible information, never the hidden solution. It confirms the shape, not the answer.

#Arrow Jam

• Never stop the player's rhythm. While one arrow is still flying away, the player can tap the next. Its cells leave immediately, input stays open, and only the win waits for all movement to finish. A quick solution becomes one smooth chain instead of tap, wait, tap, wait.

• Let a wrong tap explain itself. A blocked arrow moves forward until it hits the arrow in its way. The blocker shakes, and the first arrow returns in red. The board shows the cause where the player is already looking. Tapping the same blocked arrow again does not take another life for the same mistake.

• Make arrows feel like different weights. Short arrows leave with a bright, quick sound. Long arrows sound deeper and last a little longer. Connecting sound to body length helps a large arrow feel larger.

• Offer help when it becomes useful. The first large board teaches zooming and moving in two steps. Later boards wait until progress stops, then show only the gesture that fits the current view. Help disappears when the player acts. Menus, adverts and time outside the app never count as being stuck.

None of these changes added another level. They removed an extra action, a forced pause, an unclear mistake, a flat response or an unwanted interruption. That is what made both games feel better to play.

The AI agent could implement each correction quickly. It still needed me to play, feel the small problem and describe the better experience. That loop — play, notice, explain, rebuild — is where a working game started to feel like mine.

#What the AI agent actually changed for me

The agent wrote most of the code. It created tools, added tests, rebuilt systems and repeated jobs that would have taken a lot of manual time. But it was never one perfect prompt.

Every useful correction became part of the project as code, a test, a design rule or another generator check.

That is also why Grid Patch was faster to build after Arrow Jam. The second game reused the project structure, the testing pattern, the Level Lab, the campaign tools, the UI systems and the build setup. Its gameplay was new, but the way of working was already there.

AI did not remove the thinking. It shortened the distance between a thought and a version I could play.

I spent less time creating levels one by one, moving UI pieces or checking the same rules again. I spent more time playing and asking:

Does this feel right?

That is the workflow in one idea: make one thing fun, make it easy to test, turn the feeling into rules, then let the system repeat the work.

It is the workflow I would use again for the next game.

Arrow Jam is live and free on Google Play:

🔗 Play Arrow Jam

Grid Patch is live and free on Google Play:

🔗 Play Grid Patch

Wanna give one a try? I'd genuinely love to know which level felt too easy, too hard or simply not fun. That feedback can become the next rule.

Ps. The plan was to keep enjoying games while another game was being built. I think that part worked very well HeHe :P

I'd come into Game District as a trainee, on lower pay than everyone around me, with a simple deal: prove what I could do, and my pay would follow. Then they handed me the test that would decide it.

This is the part where everything that came before — the broken laptop, the rejections, the interview I froze in — finally added up to something. This is part 3, the last one.

#The test

The deal was simple, and a little terrifying. In 3 months, build 10 of 12 small games from scratch — real, playable ones, each with its own set of levels. Clones of the hyper-casual hits everyone knew back then: a Helix Jump, a Snake.io, a 2048-style 3D merge, a Bridge Race. The games themselves weren't really the point. The point was to see what I was made of — how I thought, how quickly I learned, what I could actually ship on my own.

Most new hires weren't expected to finish all of them. The whole thing was built to push you past your limit and find out where that limit was.

I should have been intimidated. Instead, I couldn't believe my luck. They were going to pay me to sit and build one game after another, all day, every day? That wasn't a test to me. That was everything I'd ever wanted, handed to me and called a job.

#So I disappeared into it

Every game was a new puzzle, and I loved each one. How does the ball actually punch through the rings in a Helix Jump? How should a snake grow and turn so it feels right under your thumb? I'd build one, polish it until it played the way it should, and go straight into the next — not because a clock was ticking, but because I genuinely couldn't wait to start the one after it.

When I finally looked up, I'd built 11 of the 12. It had taken me 2 months and 15 days.

I wasn't chasing a record. I just loved the work too much to stop.

#What it led to

That stretch was meant to take a full 3 months, and most people weren't expected to clear it at all. I'd done more than was asked, in less time than was given — and after that, things moved quickly.

They took me off the practice games and put me on real ones: production titles with actual players waiting. I started designing core systems — the architecture underneath a game, not just the surface. And before long I was being pulled into concept meetings for the bigger projects, sitting in the rooms where the real decisions got made.

A few months earlier, I'd frozen on a single line of code in an interview. Now I was helping decide how whole games would be built. I still think about that gap — how short the distance really was, and how impossibly far it had felt.

#The thing I never saw coming

Months in, a new group came through the studio on a visit — students from GameTrain, the same program I'd come up through, touring the partner studios in Lahore to see real game development up close. It was the exact trip I'd once been too poor to take.

This time, I was on the other side of it. The head of HR called me into the meeting room — just me — to meet them, and to show them what excellence in this work could look like. Or at least, that's how it was put to me.

Then, with me standing right there in front of all of them, they turned to the room and said:

"Sheeraz might not even know this yet, but he's one of the best game developers we've ever had here."

I didn't know what to do with that. I'd been making games for a matter of months. Not long before, I'd been one of them — a gamer from a village with a broken laptop, getting turned away by everyone I asked for a way in. And now I was the example they were holding up.

I won't pretend I'd found some secret. I hadn't. All I ever really did was love the work enough to keep going at it — past the rejections, past the freeze, past every good reason to give up. I didn't have the degree, or the right city, or the safe path. I just had the one thing that turned out to matter most: I couldn't stay away from it.

#Where it became real

That's the whole story — from a broken laptop in Ghotki to a studio I was proud to build games for.

I'm still on this road, and I think I always will be. There have been other studios since, other kinds of games, things I've gotten to make that the kid with the cracked screen could never have pictured. But this was where it became real — where "I want to make games" quietly turned into "I make games."

If you've read all three parts, thank you, truly. I wrote this for anyone sitting where I once sat: wanting something badly, with no clear way in, and every reason to believe it just isn't meant for people like them. I promise you it can be. You don't need permission, or the perfect background, or the safe path. You only need to love it enough to keep showing up — and to keep going when the answer is no.

It took me a long time to hear my first yes. But it came. Yours can too.

I'd loved playing them my whole life. But making them turned out to be a different kind of joy entirely — and it became mine the instant I started. Learning it was never going to be the hard part. Getting someone to pay me to do it was.

In part 1, after a year of trying with nothing to show for it, I'd finally landed a seat in a game development course I never thought I'd get into. This part is everything that came after — the interview that fell apart, the weeks of silence, and the gamble that changed everything.

This is part 2.

#3 months to prove it

The course was run by GameTrain, a software training studio in Lahore. 3 months, fully online, 9 to 6 every day. At the end, the best students would be sent to interview with real studios. That was the whole prize — not a certificate, but a real shot at a job.

I'd joined a week late, but catching up never felt like a chore. I was obsessed. The class ran 9 to 6, but mine ran past midnight — not because anyone asked me to, but because I couldn't make myself stop. I'd finish the day's lessons and keep going on my own, chasing down anything about games that caught my eye, building little things just to see if I could. Some days were 16 hours long and they flew by. For the first time in my life, learning didn't feel like studying. It felt like play.

I wasn't starting from nothing — but I wasn't far from it, either. I'd built Discord bots before, sure, but mostly by gluing together snippets and answers I found online. I didn't really understand the fundamentals, and I wouldn't have called myself a real developer. C# was a whole new world. I started at the very beginning — what a class even is, how to write a function, how all the pieces fit together. It came quickly, faster than I'd expected, because I simply couldn't put it down.

What carried me was my own curiosity. I was so into this that I kept wandering off the course path — reading about things we hadn't reached yet, breaking stuff, trying ideas that had nothing to do with that week's lesson. And whenever I got stuck, my mentors were there: Muhammad Hadi, Wasim Akram, Aqib Shafiq, and the rest of the staff at GameTrain. They stayed back after class, again and again, and patiently helped me understand whatever I'd gone off chasing — even the things that had nothing to do with the course. I owe them more than I can say.

My very first build was tiny: a little car on a floating road, straight out of the course's opening unit. You steered it with the arrow keys and tried not to hit the obstacles. The first time I wrote a line of C# and watched that car actually roll forward across the screen, that old "Hello World" feeling came rushing back — but bigger. I had made something move. By the end of those 3 months, making games had stopped feeling like a course I was taking. It felt like the thing I was meant to do.

There was only one part I couldn't be part of. Near the end, my class got the chance to visit real game studios in Lahore — to walk in and see, with my own eyes, how the games I loved were actually made. I wanted that more than I know how to put into words. But the trip cost money I didn't have, and my parents had even less. They would have found it for me somehow if I'd asked — and that's exactly why I didn't. I couldn't put the weight of a want, just a want, onto people who were already giving me everything they had. So I stayed home while the others went, and I told myself my turn would come.

#The interview I froze in

Then the course ended, and the calls started.

One by one, my classmates were getting hired. My first interview was with the studio I wanted most — I'd had my eye on it from the moment I learned the course could lead there. Just being on that call felt like a dream. And the person interviewing me was someone I genuinely looked up to: a team lead with the kind of game knowledge and industry experience I could only hope to have one day.

I sat at my desk back home in Ghotki, nervous and hopeful. We talked about games and engines, and that part went well. Then they asked me to write a small piece of code, right there on the call — a simple function that returns the power of a number.

And here's the part that still gets me: I knew how to do it.

But my mind started racing. Should I use Unity's built-in Mathf.Pow? Or write it out with a loop — wait, a loop, for something that already has a built-in function? That's wasteful, they'd never like that. And what if they didn't like my approach either way?

The more I overthought it, the less I could do. I couldn't type a single line. I just sat there, frozen, staring at an empty screen. My first real game development interview, at the studio I wanted more than any other, in front of someone I admired — and it was all too much. I just wasn't in my senses.

I knew I'd lost it before the call even ended. They never called back.

#The silence

Then came the part I wasn't ready for: nothing.

A week passed. Then another. One by one, the rest of my class got hired, and my phone stayed silent. Slowly, I understood why. Most of them had computer science degrees. I didn't. They lived near Lahore, where the studios were. I was a whole province away, back in my village. On paper, I was the easy one to skip.

I had come so far — found the work I loved, fought my way into that course, poured every hour I had into it. And now it looked like it might all end right here, quietly, just short of everything.

#The gamble

So I did something that scared me.

If every studio was in Lahore, then I would go to Lahore — the same city I couldn't afford to even visit a month before. Except this time it wasn't for a tour. It was to go and find a real opportunity at a real studio.

Because deep down, I believed the passion I'd found for making games had to lead somewhere. I didn't know where yet. What I knew was what I wanted: to be a game developer at a studio that would actually pay me to make games. To earn a living doing the thing I loved. To get better at it the only way that's real — by building actual games on a real team, and learning what it truly takes to finish and ship one.

It was a risk, and it was the only move I could see. So I took the bet.

My parents didn't have much, but they put together around 15,000 rupees and pressed it into my hands — more than they could really spare. I knew this was my one shot, and that somehow, with that little, I had to make it work. I packed one bag and left for a city where I knew almost no one. My older brother's old roommate let me sleep on his floor.

Then I made that money stretch as far as it would go. For days I walked — kilometres at a time, studio to studio — instead of paying for rides, because every rupee had to cover rent, food, and the next day of trying. It was the same thing I'd done years before, walking street to street to find someone who'd teach me to code. Only now I knew a little more, and I had a lot less to lose.

#The phone call

One of those studios was Game District. The interview felt good — really good. And then, again, silence. Days went by with no answer, while my 15,000 rupees kept shrinking and every day in the city cost money I didn't have.

I was almost out of money, and almost out of hope. So I went back to the people who had never let me down — my mentors. I met Wasim in person for the first time, and within a day he'd found me another lead and set up a new interview, a couple of days away. A backup. A reason to hold on a little longer.

The evening before that backup interview, my phone rang.

It was Game District. I had the job.

I still can't describe the sound I made. What I remember is how hard it was to get the words out when I called home — how my voice broke in the middle of telling my parents that the money, the bag, the floor in a stranger's house, all of it had been worth it. After a year of trying — after every rejection and every silent week — I had finally found my opportunity: a real chance to make something out of game development, the true passion I'd discovered in myself.

#One last test

I had the job — but I came in as a trainee, on lower pay than the others. I didn't settle for that, though. I'd worked out a deal: from there on, what I earned would rise with how well I performed.

And to measure that, there was a test waiting — a run of work most new hires weren't even expected to finish in the time they were given, built to show exactly what someone could do. I didn't fully grasp that yet. All I knew was that I hadn't come this far to let it slip.

What I did with it — and how fast — is the part of this whole story I'm proudest of. But that's part 3.

For now, I'll leave it here. If you're somewhere in the hard part right now — sending out your work, hearing nothing back, wondering if your turn is ever going to come — I hope this one stays with you. I'm not special. I was just someone who got told no, again and again, and kept going anyway. If that's you too, I'd love for you to keep going — and to come back for the last part, where all of it finally paid off.

Today, I make games for a living.

This is the story of how I crossed that distance. This is part 1.

#I was a gamer first

Before any of this, I was a gamer — and not a casual one.

For more than 16 years, I played to win: top 10% in most games I touched, mostly shooters like Counter-Strike 1.6 and CS:GO. For years, I had one dream — to go pro.

But deep down, I knew it would never happen. Where I lived, professional gaming wasn't a career — no teams, no tournaments, no way in. And even if there had been, I was far too poor to chase it.

I grew up in a village in Ghotki, in Sindh, Pakistan, where fast internet was a luxury. My laptop's screen was cracked and dead, so I ran it on an old monitor — a basic machine with no graphics card, playing whatever it could.

So I knew games — how they feel, why some just work. I just had no idea how anyone actually built one. That world felt impossibly far from mine.

#Teaching myself to code

On Discord, I noticed a few people building their own bots — little programs that run tasks on their own. I'd never pictured myself making software. But watching them, a quiet thought crept in: maybe I could learn this too.

So I Googled "best programming language to learn." The answer that kept coming back was C++. With no teacher and no plan — just YouTube and time — a free course by Code with Harry became my classroom.

At the end of January 2021, I wrote my first real program. All it did was show two words on a black screen: "Hello World!"

I know how small that sounds. But I still remember staring at it. I had given a computer an instruction, and it had listened. Something clicked. I wanted to build things.

Then the road got steep. The deeper I went, the harder it got — and with no one to ask, the excitement slowly drained out of me, until one day I simply stopped.

#The door that didn't open

After a while, I decided I needed a real teacher — a person, not a video.

But the computer centers in my city only taught the basics: Microsoft Office, a simple web page. I joined one anyway, sat through spreadsheet formulas until the boredom won, and left.

Then I heard about a man in my city who built websites for a living — someone people respected. Nobody had his number, just a rough idea of his neighborhood.

So I went to find him. I walked through streets lined with hundreds of houses, asking, guessing, hoping. And somehow, I found the right door.

I knocked. He opened it himself, half-asleep — I think I'd woken him from an afternoon nap. Standing on his doorstep in the heat, I told him I just wanted to learn to code. I offered to pay him whatever I could. I offered to work for free. Anything, if he would only teach me.

He said no. He couldn't help me. We never made it past his doorstep, and I walked home with nothing.

That rejection broke something in me. I stopped completely — no tutorials, no code, nothing — for almost two months. As far as I was concerned, that part of my life was over.

What I didn't know was that the thing that would pull me back was waiting in the last place I'd have thought to look.

#Finding my way back

It was Discord — the very place that had started all of this.

For those two months I'd been there again, not to learn, just to be around other gamers and forget coding entirely. But little by little, I drifted into other rooms: ones full of developers, sharing what they built. And there I found a language I'd never tried — JavaScript.

JavaScript made sense to me in a way C++ never had. I didn't need ten lines of code just to see a result. Without quite noticing, my excitement came rushing back. I started building my own Discord bots and putting them online, free, for anyone to use.

The one I'm proudest of is Sherry Music Bot. Other bots locked their best features behind payment — audio effects that turn an ordinary song into a calm "lofi" version, or a slowed, echoing remix. I built all of it and gave it away for nothing.

It spread fast. Soon, in a community of more than 10,000 people, my name was known for the things I'd made. I wasn't earning money — but I was earning something I valued far more: a real name among other developers, the kind of respect that only comes from building something people genuinely love to use. That kept me going.

#The video that changed everything

Then, in September 2021, a single video changed the direction of my life.

It was called "Game Development in Pakistan," by Mooroo, a famous Pakistani vlogger, sponsored by a training program called GameTrain in Lahore.

Until that moment, I had no idea people even made games in Pakistan — it had never once crossed my mind. Suddenly there was a door I didn't know existed, in my own country. I clicked, and I couldn't look away.

So I applied. A GameTrain mentor named Muhammad Sufyan interviewed me. He was a Counter-Strike player too, so we spent most of it talking about games. (To this day, the best interview I've ever had.)

But then came the bad news. I was about a week too late. The program had started, every seat was full, and there was no room unless someone dropped out. I said I understood. I hadn't expected much anyway — I'd applied just to see what might happen.

#The door that opened

Two days later, my phone rang again.

One of the chosen students couldn't join. A single seat had opened — and they were offering it to me.

I think about that moment often. I had done everything I could, and still been turned away, again and again. There was nothing left to try. And then, out of nowhere, the door opened on its own.

I've come to believe that what's truly meant for you finds its way to you — often through a path you never planned, at the moment you've stopped expecting it. Call it destiny, call it God's plan — I only know it wasn't me who forced that door open this time. All I had to do was say yes.

So I did. With everything in me — yes.

And just like that, after a year of dead ends and closed doors, after almost giving up for good, I was in. To this day, I thank God for that one empty seat.

This was where it truly began — though nowhere near the end of the hard part. Inside GameTrain, I'd have to learn an entire craft from nothing, fast. And the hardest battle was still ahead: getting a real studio to take a chance on someone like me. That's part 2.

But that night, none of it mattered yet. After every door that had shut in my face, one had finally opened — not by my hand, but somehow, right on time. And this time, I walked through it.

If you've ever wanted something so badly it hurt, with no clear way to reach it, I'd love for you to walk the rest of this road with me. The hardest — and the best — parts are still to come.