Run Sheeda Run — 10th Anniversary Postmortem

Raheel Yawar
14 min readOct 5, 2024
The Game’s Logo

Run Sheeda Run is ten years old today (2024). It was the first game I published. This article is a treasure trove of what the team learned while making the game and what I have learned after more than a decade in the games industry.

The Game

Run Sheeda Run (Android, iOS) was developed by weRplay. The game was about a kid trying to save his pet chicken from a butcher who wants to have his way with it. In the opening animation, Sheeda snatches the chicken and runs away with the butcher on his heels.

It is a three-lane endless runner with 90-degree turns. The goal is to avoid obstacles by jumping, ducking and strafing to score as high as possible. There are several power-ups in the game, like a magnet that pulls coins, a rickshaw that makes you invulnerable for a few seconds and others. Coins are the in-game currency used to buy characters, skins, consumable power-ups, and upgrade the in-game power-ups.

How it Began

The Studio’s Logo

I remember a few of us sat down with the company's CEO, who told us we wanted to create a game targeting the Pakistani market. We were going only to get three months. We were given complete freedom to decide what that game could be. weRplay had recently published Dream Chaser, its biggest title at the time, which happened to be from the Infinite Runner genre. The only way to make a three-month timeline happen was to stick with what we knew and what the studio knew, so we went with another Infinite Runner game.

The Tech

We developed the game using Unity Engine. The artists used Autodesk 3DS Max for modelling and Maya for animation. Adobe Photoshop was used for UX and texturing. We used C# as the gameplay programming language. It seems obvious now, but back then, Unity Script (Javascript) was a popular language among indies. An extensive benchmark I ran made it clear that C# was the most performant language.

I faced a choice when a team I was on picked the Godot Engine for a project. Again, between Godot’s GD Script and C#, the latter was a better and more performant language, even though it has weaker support than the former.

The Team

There were five novice game developers on the team, including myself. I was the Lead Programmer and, for a while, the only engineer in the team. We fired on all cylinders from the very first week while working on the prototype. Two artists were working on the concept art and the LookDev. Another group was working on the characters and storyline. We also had mentors guiding us.

Two full-time programmers were added to the team towards the end of development when my mentor saw that there was no way I could work on the gameplay programming and the various SDK integrations. Several others also worked part-time to provide us with art, playtesting, and quality assurance resources.

In a matter of weeks, we had an art prototype that we could share with the rest of the company. We had more or less nailed the LookDev. The game was a buggy mess, but it was a good start. People were excited.

A screenshot of the first playtest build

Promotion

We wanted Sheeda to be a franchise. Parallel with the game's development, we started publishing humorous comic panels on social media. A set of artists only made comics, and a social media manager drove our media strategy and engagement. We created the protagonist, antagonist, and the whole Sheeda family: father, mother, sibling, friend, and grandparents. And, of course, there was also the sidekick, the Chicken, who had a quirky personality.

During development, we even brought in an influencer (which wasn’t a term back then) who specialized in making promotional content.

A panel of the Run Sheeda Run comic

Art Style and the First Pivot

Some of the Reference of Old City Lahore

The artists spent quite some time perfecting the art style to their vision. The game’s environment was to be set in the streets of the old city of Lahore. We wanted a toon look, broad strokes, and heavily painted textures. We were inspired by Borderlands and Telltale’s The Walking Dead, and the look of the game naturally went in that direction.

Telltale’s The Walking Dead and Borderlands were early art inspirations

When the artists were satisfied with an art prototype, we launched a playtest. We were excited to show off the hand-painted textures that captured interior Lahore’s look, but we got mixed reviews. A few testers gave us feedback that said that “the game looks low quality” and “the graphics are bad.” We were quite puzzled. “The game should look great,” we thought. Based on the references and our inspirations, it had exactly the look we wanted. We tried to understand why the “graphics” looked bad to people. We were told that the environment is grey and “too textured.”

We went into war room mode, and the artists started stripping away the details that went into the texture. It was painful because the art looked great, and the lead artist had spent weeks diligently getting to a point where we could be satisfied enough to release his work. After each Photoshop layer was turned off, I would make a new build and show it to the playtesters. All the layers were peeled off one by one until only solid colours remained, and that’s when the testers were satisfied.

It was strange, but it also made sense. Due to the fast-paced game, the detailed, dusty, and grimy textures would get muddled together, and in the end, on the small phone screen, the player would only see browns and greys. It took us an entire day, but we threw out our previous notions of what was good and went with very simple textures.

The textured look was scrapped for a much cleaner art style

Art Pipeline

Another month went by, and by now, scope creep had made it clear that our three-month deadline would be unmanageable. The work we needed to finish seemed endless, and we started seeking help from people outside the team. Seven full-time members and ten part-time developers worked on the game at its height.

Even with all our resources, it felt that nothing was getting done. Every day, so many assets were sent my way that my entire 8-hour workday was spent verifying them as soon as possible so that I could send them back with feedback. I would begin my actual work after everyone had already been done for the day. It was soon pointed out to me that this was an easily solvable mistake. Each artist and the animator was told to install the Unity Engine, and I set a workbench scene for them to verify assets and animations themselves before sending the exported FBX to me. We were met with resistance since Unity was a new tool to many artists who had never worked on an actual game project. It also added another step in their workflow, slowing them down initially. However, after the second day, everyone was already used to the workflow, and I got hours back to focus on actual feature development.

Lessons in Project Management

The game team at we.R.play usually were up to three people. They would sit in the same room and needed no producers or software engineering practices to streamline their work. This, however, didn’t work with our team’s size, and in the beginning, we didn’t realise that a lack of project management methodology was the problem.

We had three volunteer producers on the team, but that was the problem: they were volunteers. They would do their primary work first, and if they had time left over, they would help out. This was not working for us. Meanwhile, after our art prototype, we hadn’t released another build of the game for playtesting in weeks. Everyone’s morale was low, and it seemed like the project would be cancelled before we got to the finish line.

It started getting clear that we needed more formal project management, but I also knew I would meet resistance because people were too used to the lack of management. One day, I brought my Software Engineering book into the office and asked one of the producers to read the entire chapter on agile development and tell me if I was wrong about shifting to agile. She came back and confirmed what I already knew: we needed a variation of Scrum.

I requested a team meeting and presented my simple plan to turn things around. We needed one-week sprints. We would have daily stand-ups, and at the end of each sprint, we would release a build for playtesting. As I had expected, people weren’t thrilled about the idea of daily meetings. To them, it seemed backwards that more meetings and frequent releases were what we needed to move faster. Also, putting their work-in-progress creations out there each week made them nervous. I got my way because the company’s co-founder was in the meeting and agreed with the idea.

As we started doing weekly sprints, we saw drastic improvements. We were figuring out problems within a day instead of weeks. We were releasing weekly builds and getting valuable feedback. We diligently started using Trello as a project management tool. With things falling into place, morale and interpersonal relationships started improving. We were a well-oiled machine again.

To put it simply, four is a crowd. Three people self-manage quite easily, but as soon as you add another, you need a system. It could be a spreadsheet tracker, regular meetings, a sticky note board, or Jira, but you do need a system.

As I write this, companies are partially or entirely ending remote work. Throughout my years working in-office and remotely, I have observed that having everyone in the same place is more productive, especially if you are working on a start-up or an indie product. Our employer was completely flexible about our working hours, granted the work gets done, and the most productive hours at the office were when the entire team was together. Exchanging ideas, solving problems and getting a stream of passive knowledge and updates about the project helped make things faster and smoother.

Pivoting on Random Level Generation

When we started making the game, its level generation was no different to Temple Run or Subway Surfer. We would pick a random map piece and append it to one the player was on. A few months into development, the co-founder and the UX Lead sat me down and suggested we develop a static map and a mostly static level design. We would keep adding to the map to create an entire city, and we could later add actual landmarks to the game. The players will have an incentive to explore and travel the whole map.

I loved the idea, but we already had a perfectly working level generator, so I pushed back, quoting that we would need another month if we went that route. The co-founder approved, and I had no reason to pass up on giving the game more character. This allowed the level designers to create detailed handcrafted maps and, in later updates of the game, add Pakistani monuments like Minr-e-Pakistan.

Optimizing for Low-end Devices

We are talking about 2013/2014 when mobile phones had rendering capability close to the PlayStation 2, but most people in Pakistan couldn’t buy the next iPhone or Samsung Galaxy. The market was flooded with Chinese Android phones with wildly varying hardware specs at the time. One would have a good screen but not the hardware to use it fully. Another would have a good memory but a terrible CPU. We had to optimize the game to run on reasonable low-end phones. The artists had annoyingly strict vertex and polygon budgets, and we were severely limited in what we could put into the game.

We decided to use the PC games approach and make the best game with the most content a high-end phone could support. We would then turn off the content, like random NPCs, environmental props, particle effects, etc., based on the capability of the lower-end phones. I created a table of hardware specifications. This would have the CPU, GPU, RAM, screen resolution and pretty much everything I could find out programmatically about a user’s phone. When the user first launched the game, I would compare their phone’s specifications to the table to determine what I could show and what features to turn off. If they had a good GPU and high memory, we could show all environmental props, but if the CPU weren’t great, I’d hold back some of the particle effects.

Then, we tested the game on every device we could find to tune our hardware specification table. Occasionally, some players would say the game was laggy or crashing on their devices. We would ask them what phone they were using, pull up the specifications, and then re-tune the specification table.

A side story about cheap Chinese phones is that a batch would share the same IMEI number. If the Pakistan Telecommunication Authority had to ban an IMEI number, it couldn’t do that without banning all phones that shared it. After a while, they informed the public that they would no longer allow phones with non-unique IMEI numbers, stopping countless nameless phones.

Knowing your Audience

During development, I would frequently hand my phone to friends or anyone curious about my work. At the time, mobile games were booming. Every week, a new game with a unique design element would appear on the App Store or Play Store. The most common feedback I would hear was, “But there already is a runner game out there. Why don’t you do something unique.” I would ask, “What kind of games do you like to play?” They would tell me that they usually play a so-and-so arcade game. Infinite runners would be pretty common in that list. This is how I knew that my team was on the right track. There is a difference between what people think they would like to play and what they actually play.

Although initially, we dropped the ball on getting the game out early, often, when we fixed our project management, we started getting it into the hands of people. I would pay attention to what people did rather than what they said while playing the game. For a while, the game just wasn’t good and wasn’t very fun. At the tail end of the project, however, everything started coming together; people, while playing, would forget that they were testing an unfinished product. Even the developers finally started liking playing it, which is an excellent sign. That’s when I realised we had what we were aiming for.

Closed Beta

About a month before the release, when the QA thought that the game was ready for external eyes, we released a call for participation in a closed beta program. At this point, the game was definitely not in the beta phase; instead, we were working on the last bit of polish. We used Google Play and Google+ (which had some good uses) to give all signees early access. We initially planned only to let in a few hundred players, but eventually, we ended up giving access to anyone who requested it. We received bug reports, device-specific issues and a wealth of feedback. The beta program also made us more confident in the game’s successful release now that actual players vetted it.

Release

After a few weeks of crunch, the game was released on 5th October 2014. It was an instant hit. People loved it. The reviews were glowing, and first-week retention was high.

We initially only released the game on the Google Play store. Sticking to one platform saved a lot of development time. As expected, the number of iPhone users in our target market wasn’t significant. Off and on, we would get requests to port the game to iOS. We did eventually release it on the App Store.

Opening Screen of the Game. Sheeda

Monetization Strategy

When we released the game, we knew we were targeting a market that doesn’t like to spend money on software. We integrated in-app purchases anyway, for completion. We also knew that almost all ad networks had very few ads to show for the South Asian region. So few, in fact, that whenever we would test ad integration in our games, ads wouldn’t show up, confusing us if there just wasn’t an ad to show or if there was a bug in our code.

An alternative idea we had was to put ads inside the game on the various billboards and signs the player would pass by. We were so short on time that the lead 3D artist, who had a computer science background, whipped up a PHP webserver to serve the ads, and I worked on displaying the ads in-game. The system worked, and we started cross-promoting our other games. In the end, we couldn’t do much with that idea. It would have taken an entire team to work on the tech and approach businesses to sell ads in our ecosystem.

Ultimately, the game launch was delayed too long, and the first release didn’t even have interstitial ads. In-app purchases, as expected, generated almost no revenue. The lesson here is simple: have a monetization plan earlier in development. The studio absorbed the project's cost and added a game and a franchise to its portfolio, but were it the first project of an indie team, it would have ended them.

How to Handle Reviews

You will get negative reviews. Some of them will be unfair, some of them will be from people who don’t enjoy the type of game you made, and some of them will be from people who think they would be able to develop a better game solo in 1/10 the time and some of them will be critical but fair. Only focus on the reviews that can help you fix or improve something. Even then, it would be best if you didn’t listen to all the advice.

Conclusion

Run Sheeda Run taught me a lot about game development, applied mathematics, psychology, game design, project management, and more. It also allowed me to have a career in game development. I am glad that a huge number of people played and enjoyed the game. Moreover, I’m pleased that Pakistanis appreciated that, for once, a game was made by taking a small piece of their culture. As the game is fading away, it has reached over a million downloads.

Run Sheeda Run Concept Art

--

--

Raheel Yawar
Raheel Yawar

No responses yet