As a leading mobile game development company in India, we’re fairly happy with our success so far.

We started out as a mini-studio with a team of two in 2009. Today, we’re bit bigger - and we’re constantly adding more talented people to our team.

There’s a been a great improvement in our skills and understanding of game development.

Our portfolio of mobile games has increased and the number of mobile game downloads is impressive too.

But we’re aware we won’t remain the top mobile game development in India if this is all we measure our success by.

In fact, these factors aren’t the best things to measure how well a top mobile game development company India has done - or any company, for that.

And that brings us to a confession.

A few years back we were still growing at a heady pace. But our internal systems, the way we executed projects, were suboptimal. We didn’t realize it then, but today, in retrospect, we can easily see our efficiency was average, not outstanding.

How a top mobile game development company in India worked

It wasn’t that our team of game developers and game designers wasn’t enthusiastic or skilled enough back then. You can’t build a leading mobile game development company of India that way.

Our teams have always been a sense of pride for us. We had kept our hiring processes tough and our performance requirements demanding, so there was no scope for slack.

In other words, our teams of game development professionals weren’t the reason behind what we now recognize as average efficiency.

Neither technology was at fault - we’ve always adopted the best tools in the game development industry. We had the latest tools and a great game engine suitable for the best mobile game development company India, a top class game development company India, serving clients across the globe.

It was the model we were using.

Game development would begin when a prospect approaches us with an idea about a game.

Most of our clients came to us with very specific, very detailed understanding of what exactly what they wanted in their games. Their GDD (Game Development Document) would be precise and yet comprehensive.

A handful of clients, however, might have only a general idea of what they want in their game. Their details would often be no longer than five to six lines.

Here’s a typical example:

"We’d like to develop a game where there are two opposing forces: the player, who has some superpowers, and a team of mythical creatures. The player must destroy the creatures and their nests or dens, while the creatures want to kill the player. The game is set in a very big jungle, may be a rainforest or may be a forest with snow-capped mountains and rivers and waterfalls all around."

You will notice the general nature of the requirements. Anybody who’s ever designed games will understand this is not rare. There are so many questions, literally hundreds, that need to be answered as the game development evolves.

For instance,

  • Why is the superhero going through the forest in the first place? Is he trying to avenge his father’s death or reclaim the princess of the kingdom or win a treasure or…..?
  • Will the player/superhero be able to fly? Swim?
  • How does he go around the forest? Walk or on horseback or on a unicorn or….?
  • What is the player’s weakness?
  • Is there a king or a leader of the mythical creature?
  • …..
  • …..
  • …..

The Waterfall model

Back then, we didn’t know much about the waterfall model. Yet we were using the model all the same.

This is how it went:


Step 1 Requirements

Through discussions within the teams and with the client, we would evolve a much detailed, almost complete, set of requirements. The objective was to have requirements set out in as much detail as possible.

These requirements and stages would be finalized and documented. This document would become the single source of reference for everything in future.

Depending upon the type of game, this could take anywhere from 3 days to a fortnight.


Step 2 Design

Once the requirements were frozen into a document, the design process would begin.

Teams would be formed on the basis of skills required and understanding of the game genre. Designs and codes would be merged at the right times. The UI and UX would come to life.

This step would take 2 to 10 weeks.


Step 3 Implementation and testing

Once the game was ready and matched the requirements set in the document, it was time for implementation. Implementation would be following by testing.

Client feedback was taken in and our testers would keep probing around for potential bugs or likely room for improvement.

Likely duration: approximately 1 week to 3 weeks.


Step 4 Corrections

Depending upon a variety of things, corrections could be minimal or massive. We thought and worked like the top game development company India, so client success was and remains #1 goal.

We took, on an average, 2 weeks to 6 weeks in this stage.


Step 5 Support and maintenance

After the game was made available to the target audience, we’d keep tracking it for a time period we had agreed upon with the client.

Back then, we didn’t realize this was a problem. That was because we were getting things done. Like, we thought, iterations and post-development corrections and changes and all that were something inevitable.

So we thought it was all a part of hustle. But that wasn’t the only problem.

The problem with our model

When we worked with the Waterfall model, our efficiency was low. Very low.

When you work with a low efficiency, the quality of your work slips too.

On the face of it, things are fine.

But deep down, things aren’t smooth.

We planned out everything - last to the minutest detail - before we wrote the first line of code, or drew the first arc in the design.

That’s ok for small and simple projects, but not for large, complex projects.

No matter how much you plan, some features are sure to change or get added.

The client wants a new power added to the player ("How about letting the player fly over The River of Ice?").


Your designers feel the opposing forces lack some teeth ("The demons need the power to light fires! That’d be exciting!").

If these changes were to happen in the early stages, it’d be quite easy. But awesome ideas have a habit of popping up just when you are about to make the game go live!

These ideas are not impossible to accommodate, even in the last stages of game development.

The problem is that since these features were not planned out in advance, your coding and designs had not provisioned for them. Hence, additional features now have to be forced within the entire game play.

The result: the game turns out patchy. Rather than one single, beautiful game, it turns out to be a poorly edited mixture of two or games, all of different qualities.

It disrupts the player’s experience and hurts the features of the game that were otherwise awesome.

In one line, our model did not allow us to make additions or major changes at later stages.

Why game development doesn’t fit in the Waterfall model

It would be senseless to write off the Waterfall model as useless.

Waterfall model is, as we understand, one of the earliest models of software design. Naturally, better models have been designed since.

The strength of the Waterfall model is also its weakness. The Waterfall model is best suited for projects:

That are relatively simple.

Where you can lay down all requirements very clearly from the very beginning.

You expect to complete in max of 3 to 4 weeks.

Where you expect zero or negligible changes once you begin coding and designing.

As a leading game development company India, we know none of the above applies to game development.

Game development is complex and dynamic. A good number of features open up once you get into that ‘zone’ of the game.

Only after you get into that zone you realize which aspect of the game would provide the most pleasure or thrill to the player.

Game development is user-experience centered project. Unless you’ve tried and played the game (its first prototype) a couple times or so, you can never really, really know what are the best and worst features of the game.

Game development is time-consuming and resource-consuming. Good games take at least 3 months, but 6 to 9 months is more realistic for bigger games.

Designing a software for accounting is more about compliance to the law and is pretty much outward-focused. Game development and game designing is psychology-centered.

You must be a player first to know if the game has appeal. You must have room for moderate to huge changes even while game development is underway.

Our own model for game development

Our productivity fell gradually, as we moved on to larger, more complex games. Initially, we didn’t even notice it and we took it in our stride, thinking it was a temporary drop.

What looked like exciting hustle in the early days of our company quickly sank to desperate last-minute struggle that didn’t do much to improve the overall quality of games.

If wanted to remain the top game development company in India, it was time we improved our model.

We spent a few weeks on the drawing board, trying to understand what improvements we could do in our model.

Soon we realized we’d need to change the entire model.

If were to continue producing top mobile games, we needed a far more dynamic model. The model should allow us start with a smaller level of detailing and offer a sizeable scope for big changes at later changes.

So we laid down two requirements for the model we wanted.

We should be able to do design, development, testing and improvement in small parts simultaneously.

We should be able to respond to changes in requirements at almost all stages.

Back then, it sounded like we were asking too much.

Our Waterfall model allowed the next phase to begin only after the earlier phase was fully complete. In that, you don’t begin coding before you had listed out all the requirements in the greatest details.

In the new model, we wanted to break down the entire game into much smaller, mini-projects. These mini-projects should be outlined, coded, designed, tested and improved in one week, or max two weeks. That feedback loop would help us refine the requirements for the subsequent mini-project.

Such a model meant our teams had to be very swift and focused. They would need to hold meetings on a daily basis to keep track of what has been done till yesterday, what will be done today and what will taken up the next day.

Since the time pressure was enormous, we couldn’t spend time in 2-hour long meetings. So we cut down our meeting time to 30 minutes, and then to just 15 minutes.

The desired model for game development

Thankfully, the title of the top game development company India made us more humble. We knew the more humble we’d be, the more we’d learn. And the more we’d learn, the better games we would produce.

So, in order to produce great games, we had to be humble. We had to be swift on our feet, willing to learn, unlearn and relearn whenever necessary. We needed a model that would provide us quick feedback and also the agility to do the corrections on the go.

In some ways, it also challenged the small inflexibility that had crept in after having been a one of the best game development companies in India. To excel, we had to take in as much feedback as possible and carry out as many changes as were desirable.

We soon found what we were looking for:  The Scrum Model.

The more we studied the scrum model, the more we were convinced it was exactly what we were looking for.

We spent some time learning the model. We argued it out in our internal meetings (We created a more open culture as a result of these meetings, but that’s another story). We chalked out how we’d do things.

Naturally, the initial period in adopting scrum was part challenging, part intimidating! Since we were not accustomed to starting without all the details on paper, we were initially unsure. We wondered if we were doing the right thing.

Thankfully, we stuck to it.

Our Scrum model

We broke down the entire game into small parts. That meant that at a given point of time, we had to focus only on a small aspect of the game.

We would understand the entire requirements of the game, but focus only on the primary needs.

Is it an endlessly running game?

Is it a dragon vs superhero?

Is that a maze game?

Next we’d look at the first stage. We’d design that first part, in about 2 weeks. We’d code it, design it and then play it out.

It would be like the prototype of a prototype - something like an MVP (Minimum Viable Product).

It was extremely useful to us. The MVP would tell us all we wanted to know. Most importantly, it’d tell us if the game was exciting enough.

Once that was done, we’d delve deeper for further details - but not all details. We would need only that many details as would take us a max of 2 weeks to work upon.

We’d again through the same loop: design and develop for a very small module of the game, gain insights and feed it back into the system.

First and the foremost, we aligned our GDD.

No, we didn’t make it more stringent. Instead, we made it more fluid, more representative of the dynamic nature of game development.

We added some stuff that outlined how some elements of game design might be open to changes.

In other words, we made it receptive to changes rather than keep it watertight.

Simultaneously, the first step we took was to practice 15-minute standup meetings. Naturally that meant all of us had to come better prepared and better prepared.

After we fought off the earlier inertia, we started getting more involved than ever with the game.

The motive of these meetings is get them charged and make sure we’re keeping the focus even while we work on something with great passion.

Our standup meetings classified tasks as:

  1. To Do: What will the team be working on today?
  2. Doing: What is the team currently doing?
  3. Done: What has the team already finished?

1. To Do

Teams would tell everybody their plans for the day. It included activities that had missed deadlines for any reason. That would tell everybody else about the status of everything and remind them of the overall direction in which the game was heading.

2. Doing

While discussing what they were currently doing, teams were encouraged to seek help if required.

3. Done

Tasks already accomplished would be green-flagged as done. Others could revisit them and offer feedback if required. If there were changes, the task would go into the To Do list.

If you want to put the model in the shortest possible phrase, it would be:

Plan, Build, Test, Learn, Repeat.

What we gained out of the Scrum model

The Scrum model has given us huge benefits, some of which we hadn’t even thought possible.

  1. The first and foremost benefit is the great enthusiasm we have been able to bring in. Thanks to daily sprint meetings, things are more transparent, finding out important issue earlier on and overall a really solid communication between teammates. Teams don’t have to wait for weeks to see if a particular idea turned out good or bad. Feedback pouring back into the system helps our team members see a quick feedback of their work and scrum board is a good tracking device for motivation.
  2. It allows us to tackle the ambiguity or vague nature of game details. We understand that, as a leading game development studio, we were learning to deal with uncertainty during the game development process. Prototyping the idea checking in sprint review meeting what’s working and what’s not. Prioritizing the work in each sprint planning meeting and re-prioritizing in subsequent sprints.
  3. Scrum helps us use time and resources better. Games we had made with the earlier Waterfall model could not easily take in changes. Even if the changes were incorporated, they would be mostly noticeable and stood out as odd features, because they were never the part of original game fabric.
  4. Our clients are happier because we were producing better results in given time. And we share that feeling too, because our output is deeper and more engaging. Ultimately, employees feels good about their work, clients are satisfied. Agile - Scum has definitely produced great output for TheAppGuruz. We recommend other mobile game development companies in India or across the globe should follow this methodology if they’re not already.

Lastly, when prospects approach us for proposals, they are confident that as one of the TheAppGuruz, one of the best game dev companies in India, will be putting resources to the most efficient use. They know we will honor deadlines, work within budget and yet turnout awesome games.

If you’re are looking of a Best Game Development Studio, TheAppGuruz can be a great option for you as our portfolio speaks for itself. If you’re question is what are the best mobile game development companies of India? Well, TheAppGuruz is one of them.

Contact us if you’re looking for a proficient mobile game development studio from India.

That trust we have been able to generate is something far more valuable than any ordinary metrics.

face mask Belial The Demon Headgear Pocket Staff Magic