Started by family and pushed forward with the help of friends, EZEme is a young, ambitious, and independent company located in Russia. With five full-time employees and the help of outsourcing, they work together to create their own games. TheRainbowers is their latest product. Andrey Alishevich, PR and Marketing, tells us about the game’s development.
Andrey Alishevich, PR and Marketing, tells us about the game’s development.
How It All Began
EZEme developed gradually. We are a few mobile platform games enthusiasts with a wide geography. It all started with two sisters, Olga Wese and Tatiana Babiy, who saw the growing popularity of the app industry in 2010. Almost every social group was introduced to the mobile games market at this time. Inspired by a number of titles and possessing experience in the field as well as resources, the sisters decided to start EZEme.They got in touch with a group of friends who helped propel the studio forward. From then on, it’s history.
Olga Wese and Tatiana Babiy
Since we are a small company with a handful of employees, we all work on almost everything, but we do have primary duties. Due to the way the company was raised by family and friends, our working environment is friendly and informal. This way, we are less stressed out, as there’s no such thing as scolding. When you are this small, you can carefully choose your employees and make sure all of them are passionate about what they do. That’s what we are: a small group of individuals who grew up to be a team, driven by shared passion, same interests, and aspirations.
The Birth of The Rainbowers
The Rainbowers is a fun and brain-tickling puzzle game, taking place in a fantasy world named Rainbow Valley, where rainbows are edible and a hairy Rainbower monster family feasts on their drops. The gameplay is easy to pick up and goes into the action straight away, although the game politely offers the player a chance to master its mechanics step-by-step. The goal is to combine several drops of the same color into one bigger one so it falls from the spider web into the monster’s mouth. Players can’t drag drops across the game field, but can only merge neighbor drops of the same color. Each monster has a glass jar belly, which indicates what color he needs. In case you’ve combined a drop of unsuitable colors for any monster on the screen, you lose. Basic dynamics suggest that you touch a drop and move it around with a fingertip. A number of more complex special drops are explained upon their appearance and make the gameplay more fun and diverse.
Nikita Kolpashikov, Junior Developer at EZEme
The first thing we made for The Rainbowers were the monsters themselves. Our initial concept was wrapped around The Rainbower family, which we tagged as simply monsters at first, but that underwent a change. They now look a bit different and the initial concept for the game was different, but we fell in love with them. We had several feeding techniques which would be the future base for game concept. Alongside that, the focus of the game was the transparent water color bubbles which we wanted to make as pleasant to interact with and look at as we could. To allow the player to feel a better connection with the monsters’ lives, the family was given a name and a furry, likeable appearance. Also, we specifically chose for the game to be a casual style with its bright colors and warm palette to resemble a fantasy world of magic and make it easier to execute visually.
For the game mechanics, we had few concepts in mind. One such idea was for the Rainbowers to cry and lose fed bubbles gradually, but there were more opportunities to lose the game this way. We even passed a high score phase, but this version wasn’t quite cutting it. The base key elements around which we started to make the game weren’t fit for it. We made an emphasis on pleasant interaction with color drops and the furry Rainbower family, and we realized all the game elements weren’t fit for a fast-paced gameplay. At this stage, we had to make some decisions, so we decided it should be a match 3-based puzzle game. We took a classical match-3 puzzle concept and made it look fresh. The game mechanics are pick-up-and-go simple so the player can focus solely on the puzzle solving. It’s quite competitive and will keep one interested throughout the whole game, thanks to an interesting combination of match-3 mechanics, authentic drop physics, and adorable main characters. We added some new elements, like spider web game field, as well as polished old ones. All of this made for unique and fun gameplay, but it was a long process.
Pavel Dayneko, Lead Programmer at EZEme
Our goal was to re-introduce the general public to puzzle games, and have a project that looked unique and had fresh looking gameplay rules. Our budget for The Rainbowers was gathered from the profit of our previous projects, which limits us financially a bit, but it’s enough to keep us going on our own and pursue our dream.
The Rainbowers won the Top 5 Game Award at Casual Connect Kyiv‘s 2013 Indie Prize Showcase. You can keep up to date with EZEme by following their Facebook and Twitter.
Ukraine-based Room 8 Studio‘s mission is to break ground in the mobile games space. With the big sense of purpose and effort, they created their first game, Cyto’s Puzzle Adventure. The Room 8 team tells the story.
For about a year, the Room 8 team has been working on Cyto’s Puzzle Adventure, but the development process turned out to be longer and harder than we expected. Still, our whole team looks back on that time in a positive light, and we received invaluable experience.
A Sticky Start
The story of our game begins in late 2011. None of our team had experience in developing for iOS, or game development, for that matter. What we did have was a great desire to make a really high-quality product that we could be proud of. We came up with a great idea about a cute little creature with tentacles that could cling to different objects. Without thinking twice, we started to develop this game we called Sticky. The plan was to make it in a couple of months to be just in time for the Christmas sales, but in the end, the process was somewhat delayed.
The first demo we sent to Chillingo looked like this.
By creating the first working demo, we immediately sent it to Chillingo, our prospective publisher. There were no levels or design, just the bare prototype with a brief description and some concept art. This is a very useful practice. The mistake of many developers is that they give publishers an almost complete, or even completely finished game, when publishers can also be beneficial to noticing a promising project at an early stage. The sooner they join in on the development process, even if it is at the level of general council as to which direction to go, the better it is for everyone.
However, we were disappointed. After looking at the concept, Chillingo said that the mechanics of the game was not new or original, and forwarded us several variants of such games. Although these examples had little resemblance to our concept, we started to think about alternatives. Looking back now, we realize that the publishers helped us a lot. If development of Sticky was not delayed, it’d be lost among the other similar games, many of which have become quite successful.
If development of Sticky was not delayed, it’d be lost among the other similar games, many of which have become quite successful.
Just a couple of months after freezingthe project Sticky, Chillingo released the game Munch Time, and in October 2012, Microsoft introduced Tentacles: Enter the Dolphin. The appearance of these two games blew away the novelty effect we would have liked to achieve with Sticky. Then a new game Tupsu was released, which included some features we had planned to implement, not to mention the gameplay itself.
This happens all the time in the App Store: as long as you think through and develop some “brilliant” idea, someone has already started to implement it. Or, even worse, you can see a clone of your game in the Store just when you have done about 80 percent. You have to be ready for this and not delay the development of applications for iOS.
The main character Tentacles is almost the exact opposite of Sticky
Changes in the Concept of the Game
At the close of the Sticky project, we had approved the concept art and character, and had finished the physical model. We didn’t want to start from scratch, so as a basis, it was decided to take the ready developments and modify them qualitatively. On one hand, this limited us in making some decisions, but on the other, it saved time and, although in a different form, helped us realize what we originally intended. After several days of stubborn brainstorms, we prepared a new concept. Among the sketches of the Sticky character, we liked this one the most:
The idea is that the character itself is inside the gelatinous envelope. We can see an expressive little face with different emotions, surrounded by a deformed envelope from which the tentacles can be drawn out. Such a character perfectly suited our new concept: we don`t pull the tentacles from the outside, but rather, the character itself deforms the envelope in which he lives.
At first, it was assumed that the character would stick its shell to multiple objects and move around in this way. But after some thought, we abandoned this option because there were no interesting mechanics with it. After observing the behavior of the different elastic objects (don`t get it wrong, haha), we came to the conclusion that the best thing would be to make the skin more elastic, like a rubber band, so the character could run itself like a slingshot. Such game mechanics have already become clear and familiar to many people, but with our approach to the game, it does not look like a clone of Angry Birds. With this in mind, and with enthusiasm, we started to develop.
Microscopic World
As for the setting of the game, it was decided to put the character into the microscopic world. Its shell could stick to organic objects (cells), and float around different crystals, viruses, and other poultry. Of course, we had to abandon the backgrounds that were drawn for Sticky.
The first concept art, collected from real macro-photos
In some sense, the nature of the game world dictated the design requirements. It was supposed to be rich, “juicy”, and minimalist at the same time. So we thought to make the whole design monotonous, almost monochrome, and play with only a few shades of the base color. Also, it was planned to present levels in the form of macro photography with a deep background and a set of realistic small details. However, these locations poorly suited the cartoon character, and so it was decided to simplify them, too.
Our approved version of the concept art
Naming the Game
When we came up with the name of the game, we wanted to convey the microscopic nature of the game world, make it unique, like a biological term, but short and well-remembered. A perfect example is the term Osmos: it has all of the above, plus, in some way, a description of gameplay. There were not so many options, but among them was Cyto. This is not an independent word; it is a prefix meaning cell and is used in compound terms, such as cytoplasm.
It was a good idea for the working title of the project, so we went with it. More than once, we tried to come up with a new title, but in the process of development we got so used to Cyto that we could not imagine it being called something else. We even decided to name the main character Cyto, even though we had assumed that it would have its own name.
Revealing Cyto’s Puzzle Adventure
In the end, after many revisions and improvements, Cyto Puzzle Adventure finally came into existence. In this regard, we would like to advise novice developers to assess their strength and timing realistically. We planned to make the game in a couple of months, but spent much more time on it. We were lucky, and were able to complete the project. For most startups, unfortunately, the overestimation of the forces is equivalent to failure.
Optional, but very desirable, attributes of high-quality games are the little details, like sailing bubbles and particles on the background, beautifully appearing buttons, and all sorts of invisible (at first glance) animations and effects. For example, has anyone tried “to tap” on Cyto’s face? 🙂 Start your fabulous journey in microcosm now by downloading the puzzle!
Cyto’s Puzzle Adventure took part in Casual Connect Kyiv 2013‘s Indie Prize Showcase. To stay up to date on the workings of Room 8, like them on Facebook.
KickBack is a team of two: Nick Konstantoglou and Vagelis Antonopoulos. Unofficially formed in early 2010, the team was officially founded in 2012. Lost Echo, their first game, came out in September 2013. Nick tells us about their experience.
Overambitious
Before I tell you the story of Lost Echo, I have to tell you the story of the game we never made. I used to do architectural visualization, but stopped for a variety of reasons. Wondering what to do next, the idea to make a game, specifically an adventure game, came to mind. Of course, I made the classic mistake most inexperienced developers make: start with a very, very ambitious idea. It would be a PC game with graphics that would rival games with a budget of millions, and mechanics that would be innovative and revolutionary. While that had over-ambition written all over it, my cousin Vagelis needed no convincing to come on-board. Thus, KickBack was formed.
Nick Konstantoglou and Vagelis Antonopoulos
A couple of months passed, and one thing became really obvious: we were never going to finish. We had one area with a really detailed entrance, but really blocky surroundings, and a pretty basic movement system working, but that was about it. No puzzles, no mechanics, no dialogue system…nothing. Fortunately, we had the wisdom to realize we were in over our heads, but we weren’t giving up. We shelved the project and thought about our next move.
Adjusting our ambitions led us to creating Lost Echo
Enter Lost Echo
We attempted to adjust our ambitions to a more realistic level. We started to consider mobile games. The more we thought about it, the more sense it made. The point-and-click controls made even more sense on a touch device than on a PC, so we weren’t compromising there. Actually, we were improving the experience. We had already bought a copy of Unity Pro, so the cost of just the iOS add-on was something we could afford at the time.
So we started from scratch. And in our naivety, we just made a list of things we like. We quickly decided on the following:
1) Touch controls that made sense: If touch is the input method we have, we wanted an experience that would take advantage of that and not emulate some other kind of non-existent input.
2) Setting: It was a no-brainer: Sci-fi, near-future. We both liked Sci-fi, and the rough idea we had of the story we wanted to tell worked really well in the near-future.
3) Graphics: They had to be the best we could make on a mobile device. Since it was a mobile platform, there was a limit on what we could do already. So why not shoot for the sky? As I had experience in architectural photorealism, I was pretty confident that I could bring the style I had developed over the years to mobile devices.
4) Gameplay: We decided to not reinvent the wheel here. This would be our first game, and so before we threw out the rulebook, we explored it. The puzzles would be grounded to logic, we would have enough variety, and we would have at least a couple of puzzles that would be really fun to do on a touch device.
5) We would be done in six months.
Do you see something really wrong in the list above? At the time, we didn’t.
A screenshot from Lost Echo
Realities of Development
The first couple of months were very exciting. We were serious this time, and the project seemed doable in a short amount of time. Using the small amount of experience we gained from the previous project, we were moving very fast. We started with nothing and a couple of months later, we had a lot of things in place, much more than our first attempt. The groundwork for the movement was done, a dialogue system was in place, we had the first silly puzzle, and I had started work on a multitude of areas. Yeah, so the game crashed every so often and all the areas were unfinished and untextured, but it felt like so much was in place.
Since we seemed to be doing really well, we went into feature creep mode. Every couple of days, either me or Vagelis would go “Wouldn’t it be cool if…” and then we’d both quickly decide to do it. The story became more intricate and complex each day (and it was pretty complex to begin with).
We were working more than ever, but we had nothing to show for it.
With the deadline we ourselves set creeping ever closer, we suddenly realized that development takes much longer than we originally thought. We hadn’t stopped working, and we had put a lot of work into it, but the end product was feeling like it was 10 percent better. It wasn’t crashing as much now, the calculations were more efficient, and there was some texturing, but I had to rework some areas completely, so everything felt just as unfinished as before. I remember showing our game to a friend who said, “Wow, you really stopped developing it, eh?”. But we hadn’t. We were working more than ever, but we had nothing to show for it.
Moving On
The next months of development were not pleasant. We made progress slowly. We kept pushing the deadline back, and each time, it was overly optimistic. We started feeling that we might never be done. There was no end in sight. At the same time, this was becoming a bigger commitment than we had realized. A six-month project that then flops is not a big deal; we could rationalize it as it being a learning experience. But as we passed a year of development, the stakes started to get higher.
There were other problems. The 2006 first gen Macbook Pro I had that I did most of the graphics on was really not up to the task. It’s not a bad machine (I’m still using it today!), it’s just that it was really starting to show its age. Baking lightmaps to compute lighting should be a one hour deal, but it became an overnight thing. Testing and tweaking things also was much slower than it should have been. Even Vagelis’ laptop died mid-development.
We realized every decision had to be correct the first time, which was almost impossible, and also made us a bit scared of making decisions.
Things started to get pretty desperate. We realized every decision had to be correct the first time, which was almost impossible, and also made us a bit scared of making decisions. What if that puzzle idea is not good enough, and we have to change it? That will push us back! What if I have to change that model again? I will have to bake the lighting in all the scenes again, and that’s going to take a week! Our inexperience in other areas was starting to show as well. I was pretty confident in my graphics ability as far as environments went, but characters were not something I was strong in. I had to redo some characters three or four times to get them to a passable level.
And Then…
This is usually the point in a story were something really positive happens that changes everything…but nothing of the sort happened. We just kept going.
We had a ton of problems we didn’t have immediate solutions to, and things were looking grim. We kept asking ourselves if we were just wasting our time. But despite all that, we never even thought to give up. Call it tenacity, stubbornness, or whatever you like, but we were determined to finish Lost Echo, no matter the cost. The only thing that changed was that we started looking for a publisher. At first, this game was a fun little project. Now it had become a bigger investment, and we were starting to feel scared. So instead of our original plan of self-publishing, we searched for a publisher. And as with all fear-induced decisions, it was a bad choice. I can’t really share what happened, and it wasn’t all bad, but overall it was a soul-crushing experience, the kind that makes you lose faith in humanity.
A Cliched, but Important, Lesson
In the end, we had to put more effort than ever before. We had to change a lot of things, because many of the decisions were clearly wrong. And even though we were already developing for much longer than we thought we were allowed to, we kept revisiting a lot of the decisions we made.
If there is one thing to take from this, it’s to never give up.
In the end, we were never sure about anything. We were never sure if our decisions were right, if people would like our game, or even if we would be able to cover our expenses. We just made it up as we went along and chose to do what we wanted to do. If there is one thing to take from this, it’s to never give up. A cliche, I know, but of all the things we did, this is the one thing we did 100 percent right.
We are also sure that we can do better next time. With the sales and general reception of Lost Echo being better than we expected, it seems that there will be a next time. We couldn’t be more excited.
Lost Echo is a participant in Casual Connect Kyiv 2013’s Indie Prize Showcase. Find out more information about Lost Echo and Kickback studios through their Facebook and Twitter.
Living as an indie developer for more than five years and currently doing a weekly podcast with other indie developers, George Zarkua has created a summary of his experience in QA mode.
Working as an Indie
I believe the life of an independent developer is the choice for people who understand that in a company, they do not get what indie work could give them. He may be a loner who feels that he can grow stronger, can release a more independent product, make more money, or make better use of his time. After separating from a company, he gets all the freedoms and limitations that are inherent for indie.
The first thing you have to think about, unfortunately, is time and money. You must honestly ask yourself how much time you can share with your PC. Then multiply this figure by two. At this time, we need some minimum cash cushion, big enough to cover sickness (paid health insurance and gyms are not included in an indie life package), fun (very few people can be productive in a state of depression), and contingencies. This amount is the budget of your game. Of course, these issues are only for a full-time indie. If you are developing parallel to your main work, then it is simply impossible to calculate time.
You must honestly ask yourself how much time you can share with your PC.
When you becoming an indie, you become free. There is the freedom to choose a convenient schedule, programs, and partners. But almost immediately, it becomes apparent that indies can’t compete with the big companies. They must either create a studio with suitable rules or otherwise cheat. You are competing with studios that specialize in having spent a lot of time creating animation and content, and with a lot of people who are doing essentially the same job. In my opinion, indies should surprise the competition with ideas, unique style, and atmosphere. The ability to look to the future is the best quality for the companies; the ability to surprise is the best quality for an indie.
Making a Game
Experience helps avoid errors that you will understand only while making games.
Certainly, an indie’s first game could be a great game (Beginner’s Luck), but that does not guarantee that it will hit the top. However, the experience provides a broader view on the development of a variety of tools, working schedule, and a sense of the market. Experience helps avoid errors that you will understand only while making games. For example, you might forget to add a button of turning on sound and run into the crowd of disgruntled users who will write angry reviews and put a minus wherever possible. Or make an active area for a button on the screen, and not the button entirely. Even if your game has super cool music, particularly harmful players will not forgive you for these blunders. Welcome to the Internet! But through the experience of making ten buttons correctly, the eleventh will be done automatically. This will help you avoid a hit from a foolish fail and polishes your creation.
It is possible to gain experience without making games, but for me, this attempt turned into a failure. A long time ago, I found a great resource with a stupendous number of articles for indies. There was an incredible collection of articles on game design, development, sales as a whole, free graphics and music, and more. Almost everything was very interesting, and I read through it, trying to apply all in one game. But the negative of such articles is that they are designed for people who have some experience, and therefore were not dismantling the problematic issues that may arise for beginners. That’s because the layers are important in the experience. Layer by layer, we create an understanding of development. Reading articles about behaviorism in MMO without experience is like having a second-grader read Kafka.
In my opinion, the first game should be small and test-like. Even if you have a super idea for a super game, you still have no budget, nor the sense of the market and the audience. Postpone that idea for a while, and take up a small test project instead. When working on a small game, it is now incredibly easy to make a prototype of the game. In a worst case scenario, it could take three days.
Often, there is a sense to do it all from scratch as we learn a new technique of painting or read a book about the architecture of the code. Small games are good so that we have time to finish the game before we come to destroyable thoughts. And even if you decide to remake the game or after the remarks on the unprecedented lag of it even on the most powerful computers, you don’t rewrite as much. However, a small game does not have time to change ideologically. In any game, even the great games, it is important to keep the idea, the rod of the game. We can add features, change the appearance, but the idea of it should remain unchanged.
If you want new ideas to the game, or a second head, which will criticize you, look for a partner.
Increasing the quality of the game and leaving the level of “small games”, you will be competing with the big companies and studios. If you start to feel that you can not make a competitive game - look for an assistant. The type of the assistant should depend on your confidence in the game. If you feel the game itself is lame or you poorly see the idea, it is better to find a partner. If you want new ideas to the game, or a second head, which will criticize you, look for a partner. The only difference between an assistant and a partner is that the partner is involved in the development of the game, not just doing the job, but that difference is huge. Choosing a partner for a long project is like choosing a partner for a flight into space. If something goes wrong after six months of work, replacing will be very expensive.
Surviving as an Indie
I think an indie’s significance is hard to overestimate. Now is the era of indie developers. Indie games are no longer for hipsters. Steam introduced an indie games section where you can buy them on a par with the games from bigger campaigns. Apple Store gives indie games the same privileges as games of big companies. Sony and Microsoft are also looking for indie cooperation. The market does not reject that talent. There are sites for people looking for a direct link with the customer, such as Kickstarter, as well as conferences and meetings.
Now is the era of indie developers.
The issue of earnings is always painful. Each platform has their own rules and profits. There is practically no limit. For example, Minecraft earned about 100 million for 2012. But not all situations are so smooth. According to the well-known statistics of mobile applications, the top 25 developers received half of all profits in 2012. 80 percent of developers get three percent profit. 19 percent of apps earn $24k, and for the 80 percent, $300. Even if your mobile game will earn 100k on iOS, 30 percent of it you give Apple, 30 percent to your publishers, and then you have to divide the rest with your partner and tax.(source: The Game Bakers)
To start receiving more than you would have received in office and still do it all the time, you have to be strategic. I’ve learned to think about games in terms of categories. The first category are the games with new ideas, mechanics, and games with the new features of the devices. These are usually hits. Next on the list are quality sequels of old hits, complete with a bunch of fans and games that can be headed by a certain niche of the market. Finally, there are the games that cover some deficiencies of hits with new features. After that are the clones and trash.
To succeed, you must either make a game out of the first category (like Minecraft and Journey), or make one or two games from the second category (like Shank 2, the successful continuation of the epic Shank, and Limbo), or make lots of games from the third category. Surprisingly, some studios are ready to cope with it. For example, Berzerk Studio, a group of six people, provides great games month after month, almost always on the old mechanics. They have over 20 games. Berzerk Ball 2 went for 100k , and their new one went for 50k, so we can assume that the guys with such strategies have success.
I’ve learned to think about games in terms of categories.
However, I think everything in a game shouldn’t be unique. What should be exclusive is the idea and style. Freedom of game elements is a vise, and there is the possibility of being misunderstood. The human brain is based on past experience, so to enhance the audience’s understanding of the game, you should use images with recognizable patterns. Choose a technique for illustrations, so that it strengthens the idea inherent in the game and matches the audience. If you want to reach the maximum audience, then you need to learn from movies/cartoons with a maximum audience (Shrek, Pirates of the Caribbean, Cut the Rope). Use recognizable patterns and be moderately predictable. In the case of niche games, rules are dictated by the specific audience. Use references for the drawing and screenshots of successful games for the understanding of the principles of drawing, but do not copy.
Games are remembered for their distinctive features: Ideas, graphics, music, and easter eggs. In Alien Anarchy, I did a lot of content, but almost all the comments were about the Easter eggs from the movies that I left. When the player is done with the game, he remembers what can be shared with others: a tough situation, a high score, and funny stories.
Use recognizable patterns and be moderately predictable.
Food for Thought
Indies should remember that an end product is expected. Without a good product, no one cares how much effort and energy was put into the game. The game is above the developer; this is important. If you want everyone to know your story, then place it in the game. Independent developers are asking questions and answers themselves, rather than just doing tasks. This gives them the opportunity to show off their own look. But be prepared for the fact that your opinion is not shared by all, and your game will not be the second Minecraft .
Before you finish the game, it is best to show it to a test group - your friends, family, and colleagues. Do not ask them what needs to be changed in the game. This is the number one mistake. Never ask them. You need to watch how they play. Just watch.
Creating a successful game is consistently making the right decisions, from the selection of the engine and the platform to the last pixel. The secret to being a successful indie is to do what you like. Otherwise, what is the sense of been indie? Make your strong brands stronger and new games cooler.
Currently, George is working on a mobile version of his strong brand, Alien Anarchy, Jim’s Dream, and the new version of Dream Symphony, which will be available to play at Casual Connect Kyiv 2013‘s Indie Prize Showcase.
