After running an indie game development studio for several years which lead me to the development of 6 MMO games, 2 serious games and 5 training simulators (except one of the projects all of them where locally-published projects) I took a break to take a good look at the path that brought us to the current moment. I wanted to know exactly what we did right and what we did wrong before starting the next project. And most of all, I was searching to find a framework on “How to define your next project”. Something that could fit the indie team size.
I searched a lot, but all I could find was papers, post-mortems or articles about how to plan your project. To me, it’s like everybody talks about what should happen after you and your team decided what to build, and nobody talks about how to choose the project you want to start.
Then I remembered a documentary on youtube I saw a long time ago. The video was about a Japanese concept named “Ikigai” which means “a reason for being”. The word ikigai is usually used to indicate the source of values in one’s life or the things that make one’s life worthwhile.
According to this concept, there are 4 circles in everyone’s life:
- The things that you love (Love).
- The things that you are good at (Ability).
- The things that you can get paid for (Money).
- The things that the world needs (Reason).
Whatever you do and the reason you are doing it, can be placed at least in one of those circles (unless what you are doing is non-sense.) And if you want to be happy and feel fulfilled and successful, you should try to do the things that can be placed in all of those circles or in other words, in the center of the intersecting area of those circles which is the ikigai.
The first moment that I encountered this philosophy I fell in love with it. It’s very elegant (like lots of other Japanese concepts), very practical and enlightening. To me, it really looked like a framework for a worthy life.
I measured my life and the things that I was doing with this concept and by that, I could tell what I’m doing right and wrong or I could tell why I feel unhappy about some of the things that I do and happy with some others.
That was the moment in which this idea came to my mind that with some tiny changes, this concept can be applied to game development as well. At least for indie gamedev teams which in many ways they look similar to an individual’s life. So, I named it GemuKai as “Gemu” in Japanese means game and “Kai” has many meanings like the result, worth and meaning.
What is GemuKai?
GemuKai is a framework for indie game development teams to choose and develop their ultimate project. The project which has the best chance to become successful. With GemuKai you can define a project which is the best fit for you or if you are already in the middle of a project, change the project by removing some elements or adding some new elements to it which causes the project to get to GemuKai.
According to this approach there are 4 circles for every game development process:
- The things that gamedevs (the team) love.
- The things that gamedevs are good at.
- The reasons that the game could make money.
- The game that users need.
According to ikigai at this point, you need to sit down and get a pen and a piece of paper and write down 4 lists for each of these circles, but I think we can do better than that. So, I’ll try to come up with an explanation for each of these items and the approaches that may help you to get to better final lists, so you can find the intersection area precisely and therefore you can get to a better GemuKai.
The things that gamedevs love:
Nobody can deny that game development is a tough thing to do, and only a great passion can drive the developers to the end. I saw many projects failing because the developers didn’t feel the urge to play the game and that was because they were not in love even with a single thing in the game. There was not something in the game that make them play none-stop. The developers of a game should play the game before it’s even playable and they should do that not because they have to, but because they enjoy doing that. Of course people play games for different reasons and they get their enjoyment from different things, but there is a fact which is everybody in the team should at least be able to find something in the game to really fall in love with. Because that’s the only good reason which makes a soul continue working and sweating on the project until the last moment.
To do this step, every person in the team should make a list of all the game-related things and ideas that she loves. From the high level concepts to the art style, from the story or game mechanics and gameplay ideas to the coding and technical parts. And by “all the things” I mean almost everything which somehow can be related to a game. Then you should come up with an integrated list which is the sum up of all lists.
The things that gamedevs are good at:
Like every other complex and inter-disciplinary kind of project, development of games will always face unpredictable risks for many reasons. It’s not possible to start a game and to know all the problems which will happen down the road and also to know all the solutions. There might be something new in the tech, an unpredictable technical problem that leads the game designers to change a mechanism, another huge company announcing a new project with the same art-style and I don’t want to talk about chaotic, dynamic and mostly unknown user behavior which never works perfectly as expected and always force us to change the marketing plan or to try new marketing channels. There are always all types of risks, waiting for us.
So there is no need for us to bring more risks to the production by including something in the project which we don’t know how to do. You may ask me, so where is the place for new game design ideas, technologies and art styles? And my answer would be the R&D phase before you start a project. IMHO, there is a huge common misconception among developers about the pre-production phase. Most of the developers think this phase is a place for R&D, while IMHO it is not. It’s a place for building the prototypes and putting them together to see the results.
Imagine someone is going to build a house, she gathers a bunch of architects and engineers and asks for a plan and maybe also a 3d prototype. But they will never risk the time and budget of the construction to check if they can find a new better formula for concrete or to check if they can replace the metal pipes by pipes with a completely new material. I know, some of you may think this example won’t apply to the creative process of game development, then I ask you to consider it more carefully, Think again about the possible consequences of doing something that you don’t know how should be done. Think about how much the estimations can go wrong. And for game development’s sake, do the R&D before you start the project.
One who knows and knows that he knows…
His horse of wisdom will reach the skies.
One who knows, but doesn’t know that he knows…
He is fast asleep, so you should wake him up!
One who doesn’t know, but knows that he doesn’t know…
His limping mule will eventually get him home.
One who doesn’t know and doesn’t know that he doesn’t know…
He will be eternally lost in his hopeless oblivion! (Ibn-I Yamin)
Let’s be the ones whose horses of wisdom reach the sky.
So what do we do when we need to add a new feature to the game in the middle of production which requires a new technology which we have no experience with? My first answer would be: don’t! But if you really need to do that, first of all, inform everyone in the project about that and the possible consequences and then do it as quickly as possible. Don’t let an unanswered question stay in the project for a long time. Do your job and add the feature to the project or make a decision to remove it as fast as possible, so no one will attempt to build a castle upon the sand.
To do this step, make a list out of all the things that at least a member in the team can do without any struggles. Coding and features which technical guys know how to implement, game genres and game mechanics which designers know how to design, art style or assets which artists know how to create, business model which you have used before or at least you think you know everything about it and you dedicated enough time to study it before.
The reasons that the game could make money:
To have a successful game, it should be making money, and to make sure a game concept will turn into a financially successful result, we need to spend descent time on defining its Unique Selling Point or USP. USP is the reason which you can pitch and sell your idea to a publisher or you can promote the game to the audience or the reason people play your game and pay for it. There are tons of articles out there about what USP is and how to define it, also you can find many examples about different games USPs. In GemuKai the reason we are trying to define the USP, is to make sure that the game has a unique selling point and at the same time it’s aligned with the other 3 circles.
The important part of this step is to pay enough attention to the possible ways the team believes they can make money out of the game, and to get to that point they should think about their competitors, their competitive advantages, the thing/things that might be different from other games and the element which makes the game distinguished, and many other things that one should take care while creating a USP.
In this step try to come up with some high-level USPs and don’t put too much time to define it precisely as it will be very time-consuming and that may change the main goal of the step which is alignment. It’s very important to know that you will come back to this step iteratively until the moment you make your decision about the project, then you should prepare the detailed final USP document.
The game that users need
IMHO, this step is the trickiest one. How one can come up with a game that users need? Is it even like that, which users need games at all? And the answer is yes. But the important thing about this question is not about “the game” that users need. It’s about “the user” who needs the game. It means that we should first come up with a definition of the user, and it means that we need to know; who is the target audience which we want to build this game for. After we choose the target audience we can talk about what they exactly need and how they are going to use it.
To make this part, the best solution I know is the STP marketing approach which you can read more about it here. STP which stands for “segmentation”, “targeting”, and “positioning”, is a way of defining your end-user. For the segmentation part, you will define different categories for users according to different aspects of their behavior. For example you start segmenting the users by their obsession for game genres, themes and settings or you can segment them by their characteristics like age, sex, job, playtime, session count and APM or the reasons they might play games like “play to turn off the brain and do mantra” or “to play an immersive game to get hyped”. I’m pretty sure you can come up with more segmentation categories about your game idea. After segmenting the market you can define your target audience by picking the right segments. Just remember that, the better you define your user, the closer you are to know “what she needs”. And the last part is to position the game idea according to other competitors and to get to a position in the market that looks more like a blue ocean. By doing this step, you can answer many questions that pop up in the middle of development because then you know the user and you know what makes her happy. So it would be easier to decide which way is better to do something or to implement a feature whether if you should add a mechanic to the game or not.
Another benefit of doing the STP for your game is that you can find better-suited channels for promotions and user acquisition after launch, as you know who is your user and how to find her and where.
How to get to GemuKai?
The best way to get to GemuKai is to start with step 1 and 2 to limit your choices from “all games in the world” to a handful of ideas which the team loves and can build at the same time. And make sure there is at least one thing in the final concepts for everyone in the team to love. Then try to define/find their USPs. The final step would be a detailed definition of the user and what she needs, and to do some minor refinement of the idea according to the user definition, segmentation, targeting and finding the best position for the game. You should do this routine in many iterations for each one of the ideas.
I started to put our previous projects in those circles and the result was very interesting. Each project which could be put into all circles was among the ones which we consider a successful project and each one that would not fit, turned to be a failure.
In the end, there is no strategy or methodology or framework which guarantees the success of a product and GemuKai is no exception. But I think using GemuKai to define your next project, or considering some small changes to the ones that are under development according to it, may lead to better results. This framework decreases the number of risks on the project and prevents many wrong decisions to happen and causes a happier development experience for all of the team members. GemuKai brings synergy in oneself and in the team and finally, this is an approach to match the player and the gamedev team, upon their interests and the recognized available resources (time/skills/money) in the team.
Please feel free to send me any kind of feedback about this article.