Amy Smith Muise participated in a session about user testing during Casual Connect USA 2014. “Testing is not something we do at the end of the day after everything has been completed,” she said. “Testing is part of our design process.”
Amy Smith Muise, Partnerships Manager, NMSU Learning Games Lab
Amy Smith Muise manages partnerships for education, distribution, and educational use of the products of the Learning Games Lab at New Mexico State University. The Learning Games Lab, part of Media Productions, specializes in designing and testing educational tools. Their products are research-based and developed for a variety of audiences, including youth, college students, the research community, policy makers, and workers in particular industries.
Appreciating User Needs
Muise has worked in college level teaching and curriculum development in a number of fields. As a result, she appreciates the needs of educational users. She also loves the opportunities her job gives her to learn about various subjects. Past topics include astronomy, animal science, biology, English, food science, and mathematics.
At the Learning Games Lab, they believe parents and schools are becoming increasingly savvy consumers of educational games. Ninja Kitchen, a food safety game, is one example of how games can help kids learn.
At the Learning Games Lab, they believe parents and schools are becoming increasingly savvy consumers of educational games. Muise maintains, “Demand will soar for games that support conceptual learning and engage users in exploration, not just drill and practice, and not just surrounding traditional ways of presenting information with nice graphics and animation.”
Muise began her career creating more traditional educational media and online learning modules. But she feels these materials cannot compare to game-based learning, and insists, “It’s incredible how games can support leaps in conceptual understanding.”
The most interesting place Muise has played a game herself is probably out in the middle of rugged country, since she lives on a working ranch in New Mexico. She gives her children mobile devices with strategically loaded games to keep them safely occupied while she and her husband are working to accomplish something tricky like roping and branding a calf or scrambling up a cliff to mend a broken fence. But she does point out that she has to be careful what games she gives them, or they will come wandering over asking for help solving a puzzle just as she is tied up with something.
The most interesting place Muise has played a game herself is probably out in the middle of rugged country, since she lives on a working ranch in New Mexico.
These days, Muise and her children are playing Jacob Jones and the Bigfoot Mystery on iPad and the educational history game, Time Tribe, in browser. They are eagerly waiting for its release to iPad. For herself, she is playing the narrative game TheORPHEUS Ruse from Choice of Games, on iPad.
Other than gaming, her hobbies include playing old-time fiddle and cello in a string band.
Since 1999 (the founders are old or, as they say, “seasoned”), Ian Jardine, Craig Martin, Julio Carneiro, Steve Parkes and William Gibson (who provided the story and background) have wanted to get into the game-making business but lacked time, funding, and expertise. By building a successful web application consulting company over the past seven years, they were finally confident enough to start their dream company. They had an inkling of what they wanted to build: namely a multiplayer tank-based game that harkened back to Bolo from the ’80s. “We wanted to make the game hard. We felt that too many current games make it too easy for players to win. We wanted the player to explore their surroundings and get that “aha!” feeling upon discovering something new and weird inside the game. We were missing one key ingredient: Game Company Expertise”, Skunkwerk Kinetic’s CEO and founder Ian Jardinerecalls.
Drive and Ambitions Above All, Experience Not Necessary
We aimed to build our team around a talented group of developers who had drive and ambition, though not necessarily game industry experience. Provided below is a brief description of three team members who we think represent a good cross-section of the overall spirit of our company.
Jonas, the lead engineer: a promising Belgian ready to take big risks, with a passion for strategic games and a coding background.
You always remember your first hire, and we picked our lead engineer Jonas, a beaming Belgian with a passion for strategic games and a rock-solid coding background. At our first meeting, Jonas told us his story: upon graduating from an obscure university in Belgium, he and his lovely girlfriend (seriously, how did she get stuck with Jonas?) packed up all their belongings and moved to Vancouver. That showed us he was willing to take risks and take giant leaps of faith…very good qualities to have in a startup.
Upon graduating from a university in Belgium Jonas and his girlfriend moved to Vancouver. That told us he was willing to take risks.
Jonas is also very good at asking questions…lots of questions. He forces us to really think through all of our crazy ideas, not hesitating to bring up the myriad technical difficulties associated with an ambitious new feature. It has been a real pleasure watching Jonas grow into his role as head engineer, and as a person (new dad!!).
Erik, the game/audio designer: a team member adapting to the ebb and flow of the ever-changing company’s needs.
Erik, the game/audio designer, is a good example of a team member adapting to the ebb and flow of a company’s needs as they change over time. Erik was hired as our ‘sound guy’ early on, but we were too busy making art assets and solving the technical issues of creating an online multiplayer game from scratch to spend too much time on audio. Erik’s passion for games and insight into game design were evident from the start.
Erik was hired as the “sound guy”, but we were too busy making art assets and solving the technical issues of creating an online multiplayer game from scratch.
He became our primary game designer and produced all the internal documentation needed for feature design in both the Art and Dev departments. He still has his hand on sound design, managing our sound consultant and offering advice on thematic audio design in the game.
Kevin: an undergrad in Japanese Studies turned into a game developer
Kevin, the lead engineer, is a good example of how an undergrad in Japanese Studies turns into a dev at a game company. He is fluent in French, German, and Japanese. He plays guitar. He sings. He can do Flash….oh, and he is a helluva coder. Realizing that the Arts degree was not quite enough to land for a full-time work in a game company, he went back for a second degree in computer science.
An Arts degree was not enough for a full-time job in a game company, so Kevin got a second degree in computer science.
Kevin came to Skunkwerks as a co-op student, worked his way up to a key member of the team, and we never want him to leave.
Multi-talented Flexible People: A Solution for Small Teams
If the game idea doesn’t work, we’ll hit the road as a hair metal band called “The Skunkwerks 5”.
We refer to our team members as “Swiss army knives”. Our company is too small to have a specialist in every department. Instead, we need people who are flexible and multi-talented; it also helps if you’re a musician (our backup plan: if this whole game thing doesn’t work out, we’ll hit the road as a hair metal band called “The Skunkwerks 5” or whatever number of members we can rope in!).
Through two years of development and working with a small team, we have felt the sting of developers leaving our team for larger companies (*cough* Amazon *cough*) with much more money to throw around than we do. Our entire server team was demolished within two months leading up to a critical release, forcing our downsized client team to pick up the slack within a number of weeks. The remaining dev team not only learned about the server-side codebase, but was also able to fix a number of longstanding issues with the server architecture. Lemonade out of lemons, baby! The good news is that the people left are in it for the duration, while all we lost is “deadwood” - like pruning a tree makes it healthier.
Before Legit Game Engines Started Suggesting Affordable Deals
When we decided to make a mobile game, it was about six months to a year out from when legit game engines began offering more affordable deals to indie developers in a meaningful way. After initial research, we decided to string together our own custom engine using a variety of open-source and licensed components. This proved to be a double-edged sword in the long run, although we learned a great deal about each part, including Scaleform for UI, FMOD for audio and Sparrow for texture rendering.
After initial research, we decided to string together our own custom engine using a variety of open-source and licensed components.
The ease-of-use and implementation took much longer than expected, compared to a more conventional approach using an all-in-one engine. Moving forward, we now know how to be able to fully utilize a commercial engine should we choose to use one and also roll our own if necessary.
Why just Apple?
“Where is the [insert any platform other than iOS] version of your game?” We get this question quite often, as our game is currently an iOS exclusive title. We chose the iPad as our primary device for a number of reasons: we liked the development pipeline and usability of the Apple mobile framework, and the lack of variability in screen size amongst the various retina and non-retina iPad models.
The team decided to make the game primarily for iPad due to lack of variability in screen size amongst the various retina and non-retina models.
While we agreed that Android would be a good choice for the type of game we’re making, we were wary of the expansive device list and the necessity of making our game experience work consistently across many different screen sizes and resolutions.
Apple’s 30 percent cut of profit from App Store revenue was quite steep from a business perspective, although we did appreciate the distribution platform as a service.
The submission process proved to be frustrating during our initial release of MEG:RVO - we ended up getting rejected for minor UI issues (like where to place the “Restore InApp Purchases” button), and then felt like we got approved without any actual human verification. It felt like dealing with an amorphous gatekeeper at times, and unpredictable release and update schedules proved to be a challenge for our server-based game (we didn’t want to make updates to the server until the App Store update goes through, for fear of breaking previous versions).
MEG:RVO ended up getting rejected for minor UI issues, and then got approved without any actual human verification.
After our PAX East experience this year, we have received significantly more support from Apple, and the whole process has become somewhat smoother. It seems that as our app started getting more attention and updates on a consistent basis, the review timelines have shortened substantially.
Buying/Selling Wasn’t Fun - So We Removed It
One of the many things we learned from PAX East 2014 was that our game was suffering from lack of polish and usability in terms of the HUD design. PAX attendees who came to our booth approved the concept and look of what we had going on, but by the end of the three-day expo, we were all hoarse and exhausted from having to give a detailed explanation of the game mechanics to each person who stuck around to play.
By the end of PAX East 2014, we got tired of explaining the gameplay in details
We then decided to re-design our menu and in-game UI in order to present all controls and information our game contained in a simplified and concise format. We removed some features that we felt were too complex or not fleshed out enough to belong on a release version of MEG:RVO. For example, we decided to get rid of the Marketplace for the next release, since buying/selling items didn’t seem that fun and in fact might have had a negative impact on first-time players. Instead, we built a combat training mission that we strongly recommend new players to try out before getting into a match with other players.
We now give players all the weapons upfront, and people gain experience the more they play and participate.
The incentivization process was altered as well; we ended up giving players all of the weapons upfront. It’s now a balancing practice rather than a “pay to buy better weapons” system. Players gain experience the more they play and participate. Leveling up unlocks more maps, but the gameplay remains generally the same.
We hope that these changes along with our focus on user experience will allow users to stick around a bit longer and appreciate the depth and relative complexity of our game compared to more casual mobile games.
We’d Better Have at Least Someone With a Gamedev Experience
Have we made mistakes? Yes…quite a few, but no fatal blows.
Hiring people with no prior game knowledge had its pros and cons. It would have been nice to have at least one person with prior industry experience. This might have helped us avoid some common pitfalls in our design, and reckless ambition in terms of what we wanted to create.
Should we have hired people who were passionate about games instead of people who just wanted a job? Definitely. Did we assume that most people would “just figure out” how to play our game without any guidance? Yes. We have since realized that we need to show people how the game works first, and then let them explore. This has shifted to our primary focus over the last few months and we hope that this will be reflected in our next release around August 1st this summer.
“We have since realized that we need to show people how the game works first, and then let them explore.”
The value of our team comes from learning from these mistakes, and we feel significantly more prepared to deal with design and implementation of features than we did at the outset. Our website tag line “Doing things the hard way” is very apropos. We’re looking forward to making more mistakes in the future and further sharpening our expertise through them!
Grants: A Framework for the Business Plan
What we did right was to apply for grants (CMF) as it forces you to think through your game-plan. We used those grant applications as a framework for our business plan which we then used to to raise money. Have a proper budget and stick to that budget! Do not assume you launch the game and get an instant cash-machine. This is not going to happen. Plan for no money, but hard work, loads of “impossible” problems, and all for a very long time.
Plan for no money, but hard work and problems.
Be adaptable to changing situations; the only constant is constant change: “We adding dragons today? - No wait, robots, yea, more robots and some sparkly stuff…”
Probably the most important thing we did was to be naive. If we knew all the pitfalls from a suspect iTunes market (bots much?), technical problems (server down again..ack), personnel problems, and day-to day operational problems (why are there plants in the bathroom? payroll is due today?), we would never have started the journey. And that would have been a shame as everybody is having a blast doing what they want to do.
MEG: RVO - Battle for the Territories has been approved by Apple, and will be released July 31st. The Skunkwerks Kinetic team is now working with the Unreal4 engine to expand their reach. It will be the same universe/setting as MEG: RVO: Battle for the Territories but using the Unreal4 platform, that will provide reach to the desktop/console and Android markets, and vastly improved graphics. MEG: RVO has been Initially released as a single player game, but multiplayer is high on the list.
You’ve heard the story so many times that it’s hardly worth repeating: A few buddies get together to start a gaming company. They begin as a work-for-hire studio, land a big-budget deal, grow by 400 percent and then collapse when the deal falls apart. Enter anger, bitterness, regret and shame, and sprinkle in a dash of despair. The team dissolves, the dreams are dashed and that unique combination of talent and know-how swirls away like water down the bathtub drain. This heart-breaking scenario has played out hundreds of times before. The great sea of game development is littered with the rotting hulks of sunken teams.
Boo-hoo. Epic failure is just part of the game of games. In fact, many will tell you that it’s an essential part. Any seasoned gaming vet will tell you that great studios sometimes do emerge from disaster to become something better than they might have been had they not suffered early adversity. Spacetime Studios, the makers of Arcane Legends, is just such a phoenix, having risen from the ashes of its own demise not just once, but twice in the span of four years.
Cinco Barnes, Jake Rodgers, Anthony Sommers, and Gary Gattis were the principal actors in this drama. They started Spacetime in 2005, jumpstarting the studio with a sweet deal from NCsoft to build a large-scale MMO. The four were close friends who shared a dream that many of us can relate to. They were just hoping to build a great game for someone else, and to eventually make enough in royalties to build their own IP. In the words of Gary Gattis, “This plan did not work.”
They shopped the IP around to “everyone on the planet,” but no one wanted to take on an expensive, large-scale MMO that had already been cancelled.
After staffing up to seventy-five people under the auspices of NCsoft, their funding was pulled and Spacetime was set adrift. Fortunately for them, they were able to retain the rights to the technology and the intellectual property so though they were cut loose, they were cut loose with a very high-powered MMO client/server technology in their pockets. But nobody likes a second-hand bride. They shopped the IP around to “everyone on the planet,” but no one wanted to take on an expensive, large-scale MMO that had already been cancelled. The Spacetime staff dwindled down to fifteen people and survived on work-for-hire gigs. In 2008, they signed another big deal that allowed them to scale back up, but that project was cancelled too and they were now reduced to six employees - the original founders plus two core developers.
It was looking bleak for Spacetime. Their cash reserves were dwindling. It was time for something new and bold. At that time, they were all riding in a van on their way back from yet another failed publisher meeting. The whole team was playing games on their iPhones when the spark hit: Why couldn’t they be playing together? They began to brainstorm. These devices were all connected, they were powerful enough to run serious software and people were used to making micro-transactions. Just because no one had done it before did not mean that it couldn’t be done. It was the perfect storm. Pocket Legends was born.
“We wanted a pick-up-and-play MMO,” says Gary Gattis. “Something that you could play in line at the movies, or in the dentist’s chair.” Production went on as planned for the first five months, but then Apple saw the game just before it shipped and thought it would be perfect for a mysterious “larger-screen device” they were working on. So Spacetime modified the game significantly to launch with the iPad debut on April 3rd, 2010. Pocket Legends became a hit.
“Our vision then was to build the world’s first 3D mobile MMO”, Gattis says. This particular plan did work, and it worked so well that Spacetime then launched three more highly touted MMOs - Star Legends, Dark Legends, and their most popular title to date: Arcane Legends. It’s a formula that so far seems to be working very well for a studio that suffered what Gattis calls the “soul-crushing” experience of having that first NCsoft game cancelled. “In retrospect, it was probably the best thing that could have happened to us. Funny how life works sometimes.”
In addition to a penchant for coming back from the brink of death, one of the things that sets Spacetime apart from other studios is their approach to crunch time and office hours. They strive to eliminate the need for working long, grueling hours altogether. “Mandatory overtime is a blight on the game development industry,” Gattis says. “I can’t understand how it is still an acceptable practice. It is a fundamental management failure, a sign of over-promising, or under-planning, or poor development practices, or inefficient pipelines, or any number of things that the people that crunch are not responsible for.” It’s remarkable how Spacetime has managed to release hit after hit without the obligatory long hours. And it’s a formula that seems to be working. Gattis says, “Do your eight hours, and then go home. Spend time with the family. Relax. And come back tomorrow refreshed and at the top of your game.” According to Gattis, that’s a law the studio lives by.
Spacetime also seems to have figured out a crucial technology hurdle. The Spacetime Engine is a remarkable piece of technology. It was built for mass-production of content to be delivered continuously on a global scale. They have continued to build on it as the environment has evolved, so they now have a platform where iOS, Android, and desktop users can all play together, in the same server, all around the world. And they can play on extremely slow connections as well, so they are seeing deep penetration into foreign markets with high latency networks. It truly is play with anyone, anywhere, anytime.
Spacetime has pushed the mobile MMO envelope pretty much as far as it can be pushed, and is now working on something they feel will appeal to fans of RTS fans on mobile. With the success of the Legends games, they can finally afford to experiment a little and enjoy the fruits of their labor. When asked what one thing they’ve learned from all their near-death experiences, Gattis had this to say: “Once you are out of cash, you are dead. Manage your burn.”
You can bet that Spacetime Studios will do just that moving forward. Third chances are rare and fourths rarer still. But this is a studio that has been tempered by flame and has emerged wiser, humbler and more grateful. If they can hold onto to that, Spacetime will be around for long, long while.
Sean Clark has worn many hats during his time in the games industry. From designer to studio director and everything in between, Sean’s passion never seems to run out. He worked at Playdom, Electronic Arts, and LucasArts before settling as Director of Content Production at Big Fish Games. He enjoys everything he does in games, but what is most important to him is the fun of building entertainment experiences. “I get a rush from being a part of something coming together through a creative and collaborative effort, and I still get that rush working on great games at Big Fish,” he says. We were able to catch up with him to discuss his view on creating and producing games.
For the Love of Games
Growing up playing Pong and Atari games on the old family TV, Sean learned to love games early in life. When Atari released a Basic Programming cartridge, he immediately began learning the language and realized that programming consisted of a series of logical instructions. He discovered that building games could be an actual job.
Still, he did not plan for a career in the games industry. He graduated from Sonoma State University with a degree in Computer Science knowing he liked building things in software, especially games. LucasFilm Games (later LucasArts) happened to be hiring junior level programmers at that time. Up to this point, Sean had only created games as a hobby, but this sounded like the perfect opportunity for him. He was right: it turned out to be a great time to join the company.
Sean Clark at LucasArts
All of a sudden, he was working with a group of people just as passionate about games as he was; real artists, musicians, programmers- talented professionals who could bring unique creative elements to the product. “It was a blast!” Sean says. “It was also an experience that has helped me through my whole career, right up to today as 3rd-party Director at Big Fish, working to bring fun game content to the company.” In all the roles he’s done, he’s always shown his love of games. He looks for the same passion and excitement for a game from developers, both internally and externally.
Point and Click Adventure Games Anyone?
Having been involved in multiple projects in a variety of roles, Sean has a soft spot for point-and-click adventure games. While at LucasArts, Sean helped develop The Secret ofMonkey Island in 1990, a popular point-and-click adventure. It was a great experience, but problems always arise, and the solutions were often unique. Sean learned a lot about problem solving and creatively mitigating issues during this project.
“I blame it on 3D. At the time, real-time 3D was such an amazing new capability that the faster computers and video cards enabled, it became the sexy new thing.”
However, point-and click adventure games started to slip into the background. In an interview with adventuregamers.com, Sean stated that the popularity of point-and-click adventure games would return. When we asked why he thought they had fallen to the background in the first place, his answer was emphatic. “I blame it on 3D. At the time, real-time 3D was such an amazing new capability that the faster computers and video cards enabled, it became the sexy new thing.” While 3D opened new areas of design, it also started a graphics arms race. Everyone focused on 3D graphics, with a game like The Dig being compared to Dark Force or TIE Fighter. But eventually, people realized that adventure games were a different genre to other games, like first person shooters.
He points out that in 2002, Big Fish took advantage of the 3D distraction and built a successful business recognizing and catering to the adventure gamer audience. Even Escape from Monkey Island still managed to do well in the “Adventure Games are Dead” era. Although there are not many classic 3rd person point-and-click adventure games coming to market, there is the very successful line of Hidden Puzzle Adventure Games that Big Fish is so well known for. These, Sean asserts, are a modern version of adventure game storytelling, similar to those he started his career with.
Another reason adventure games seemed to go dormant was the fact that retail space is both limited and competitive. Because attention was so focused on 3D games, it was challenging to interest retail chain buyers in adventure games. The big factor in changing the situation was the internet. Brick and mortar stores were no longer the only way to purchase games. Sean attributes Big Fish’s success largely to its creation of an online place to find and purchase great casual content, including adventure games.
Adventure Game Evolution
This new cycle of adventure games has evolved, bringing lower-priced games, which are also shorter in length, and tend to tell stories in chapters or episodes. According to Sean, these new games are still high-quality, well-polished games with great artwork, and compelling stories, although the format is different.
Big Fish created a new format for adventure games, brought them to new audiences, and gave consumers a way to try the game before committing to a purchase.
Sean believes Big Fish has been instrumental in bringing more attention to adventure games in a number of ways. They created a new format for adventure games, brought them to new audiences, and gave consumers a way to try the game before committing to a purchase. They figured out how to make adventure games easier to find and consume, at a time when retailers had all but abandoned support for the genre.
Sean is just as excited about the future as he is about the present. “We expect 2013 to be a year of innovation in game, content, and delivery, with games on almost every device and in nearly all casual genres,” Sean says. “In March alone, Big Fish launched 2 highly acclaimed mobile games: Fetch for the iPad, an adventure about a boy on the search for his dog; and Match Up! By Big Fish, the first iOS game to have real-time, 16-bracketed tournament play. Add to that the world’s largest interactive streaming casual game service and continuing franchises like Mystery Case Files, which has been downloaded more than 100 million times, and you can see how there is something to excite all types of gamers.”
Sean reminds us that Big Fish is an incredibly talented and creative company, with exclusive partnerships with more than 140 developers all over the world. He expects Big Fish to continue bringing fun and innovation to the games industry.
Critical Force Entertainment Ltd is a new game development studio founded in Kajaani, Finland. The studio created Critical Missions: SWAT, a first-person shooter available for iOS, Andriod (released under Studio OnMars) and playable on Kongregate. The company focuses on developing premium and free-to-play crossplatform games with a special focus on the Asian market. So far, the company is self-funded, but investors are welcome.
Veli-Pekka Piirainen is CEO and founder of Critical Force Entertainment Ltd. He is a former studio manager of Supercell North as well as a lecturer and head of Kajak Game Development Lab. Piirainen is also co-founder of NMP Games Ltd.
A student’s hobby project
Veli-Pekka Piirainen
In December 2011, I hired Igor Levochkin – one of the students at a school I taught at – as a programmer in my new startup company after following his work for the past two years. Igor and I would make games for the Apple AppStore, and we started making a prototype of a game called BomberBall. At the same time, Igor put his hobby game project in Kongregate. Early January 2012, Igor showed me that there were hundreds of players playing his hobby project game, but I didn’t pay much attention to it. I just thought it could be a good marketing channel for our iOS game.
However, at the end of January 2012, there were a couple of thousand players playing it and I started to get more interested in it. I gave Igor a Sony Xperia Play phone and told him to port the game to that device. Igor managed to have it up and running in a matter of days. Next, I told Igor to port the game to iOS; this was bit more difficult since he was not familiar with Mac and Xcode. After a week, the game was also running on iOS. Now I really started to see some potential in the game. Despite all this work on Igor’s project, we also continued to develop BomberBall because I wanted to have a good prototype for the GDC in San Francisco. I demonstrated both prototypes at the GDC and Igor’s project, Critical Strike Portable, gained more interest from the public. After that trip, we decided to concentrate fully on Critical Strike Portable.
Keeping up with high popularity
Igor started fulltime development on Critical Strike Portable by adding new weapons and features. I still worked part time at the university and couldn’t fully concentrate on the game development. I trusted Igor and also a team of Russian volunteers, who supported us in the growth of the user community as well as map creation. Another important task was to make a proper and more user friendly User Interface (UI) for the game. Unfortunately, Unity 3D’s tools for this job were pretty limited and we didn’t have any artist or UI specialist in our team to design a nice, good-looking and functional UI. So Igor made a “coder-style” UI with many different settings and options inspired by Counter Strike style menus. That UI was easy to use with a mouse, but for mobile phones with touch screens, we needed a different kind of UI.
The user interface of the mobile version.
Because I was inexperienced in game marketing, I hired Teemu Riikonen in April 2012 to lead the studio as well as take care of publishing and marketing of the game. Our next employee was Thanabodi Thongchat, a 2D artist from Thailand. She started designing backgrounds and UI graphics for the game in June 2012. Igor implemented more and more features to the game like new game modes, zombies, graphical effects, as well as fixing bugs. We released new versions on Kongregate weekly and got feedback from players on how to improve the game. At the end of June 2012, we had nearly 30,000 daily average users playing the web version of our game, but we were still growing.
We got over 1 million downloads in one month.
On June 26th, we released a free Android version of our game with exactly the same UI and almost the same features as the web version. Even though it was not so easy to use and the menu elements were pretty small on a phone screen, its popularity surprised us. We got over 1 million downloads in one month.
But the problem was that many players didn’t continue the game after their first try. Only hardcore players did so. We decided to create a totally different and simpler UI for mobile devices, because the current quality was not good enough for Apple’s AppStore to sell it as a premium game.
At the end of August 2012, two game development students, Olli Lahtinen and Aapo Lehikoinen, started their internship in my company. They started to build a totally new UI, added new controls for the iOS version of the game with a new NGUI toolkit we bought from the Unity Asset Store and started to design new maps for the game with Hammer editor. We also needed new character models, guns and animations for the iOS version. Modeling and animations were outsourced to freelancers in Thailand and our Thai artist was leading that work. Unfortunately, the quality was poor and delivery was very late. After that, all animations were outsourced to two Finnish startup game studios and for the modeling of guns, I hired another student.
A screenshot of the zombiemode in Critical Missions: SWAT.
Unfortunately, we had to remake all maps done with the Hammer editor (16 total), because our lawyer said we probably weren’t allowed to use that tool, since it’s licensing agreement is not clear enough. Our lawyer also recommended us to change the name of the game from Critical Strike Portable to something else, because that name reminds too much of Valve’s Counter Strike (Critical Missions: SWAT was born then). Our original plan was to release the iOS version in the end of September, but it was released in the end of November due to these difficulties. A new Android version was released just before Christmas, a Lite version in the beginning of January 2013 and the Mac version is in the review process as of this writing.
The iOS market is very competitive
At the end of the year, the amount of our players had increased dramatically. We had almost 200,000 daily players on the web and over 100,000 daily players on mobile devices, but all were playing our free versions. Monetizing with premium version seemed to be much more difficult than we thought it would be. The iOS market is very competitive and full of games, so getting visibility is very hard. We also had bad luck with a very important review, because the reviewer didn’t like our controls at all (many other not so significant reviewers did like them, however). Because of this, we didn’t start to get income fast but our server costs rose dramatically due to the massive amount of users. We also had some trouble with one specific server provider, who just calmly cut off the lines to our map server without any warning due to dramatically risen network traffic.
Looking back
Our biggest mistake was to save money in wrong places and get low quality from our international freelancers. We trusted our own artist’s capabilities to handle leading of the outsourcing, but she was too inexperienced for that. Of course, rates a quarter of the price compared to local studios were very attractive, but then the harsh reality revealed we had to do everything over again after that miserable trial period. It would have been wiser to use more professional outsourcing studios in the very beginning.
Our second mistake was not to solely focus on Critical Strike in the very beginning, but to also make the BomberBall prototype. Something else I would change was not to have a tighter management; everything went forward more or less without proper planning and scheduling. A fourth mistake was not to take a professional publisher to publish the premium iOS version. We thought it would be easy to self publish, because we had such great success with the free Android version, but we were wrong. A last mistake was not to pay enough attention to the server capacity, but that was more or less because of our inexperience with servers and also our idea to save money.
The team is currently working on a new game, called Critical Missions: Space. It has the same nostalgic fast paced FPS gaming experience as Critical Missions: SWAT, with the addition of space rangers, space pirates, laser guns, aliens, space themed maps and more.
Next to that, they keep adding more to Critical Missions: SWAT. They’ve scheduled new guns, characters and maps as well as unlockable content for the next update of their very popular shooter.
TAGS is a brainchild of Rajat Ojha and he is supported by the incredibly talented and driven Atul Sharma and Ajay Singh. There are 10 others who joined the talented team of TAGS. Team TAGS is considered as the most experienced team in India and the only team which has experience in mobile, PC and console game development.
When we started The Awesome Game Studio (TAGS) in April 2012, we had just branched out of a behemoth where we had been doing some serious console stuff and defense simulators. Some unacceptable decisions were made and we ended up with the idea to continue our journey in the game industry only and keep making awesome games. Coming from a console background, it was challenging because we had been completely ignorant about mobile market. The choice we had was doing something we already know or doing something new. Somehow in our case the latter would take less time than doing something we already knew, so we decided to try this. This was the first decision in the development of a game that would later be known as Wobble Bobble.
Minimalism is a good thing
The next challenge was to decide what exactly we wanted to do. We decided on two important things: minimalism and simplicity. Minimalism is a good thing, because you don’t have to go overboard with graphics in order to create a nice game. We focused on a game that was simple to play, in a way that it would benefit from the possibilities of a mobile device. The advantage of having a simple game also means that you can count on it to be almost bug-free. This all would turn out to be a big lesson for the entire team, as we had always been thinking of big games and big platforms. Going back and trying to do something really basic was a big challenge for all of us.
The entire team was assigned to think of an idea that would fit the above points and within a couple of days we had 15 ideas to choose from. After some discussion, we decided to do Wobble Bobble, an idea by our physics programmer, Ankur Aggarwal.
Some of the criteria we had while brainstorming:
1. Short, but addictive gameplay
2. Developed specifically for the device - it should not look like a port
3. One hand controls
4. Iterative - we wanted to focus on one simple game mechanic and focus further development on adding different pickups, modes and themes to keep the title fresh. Nothing deviates from the core mechanic, but the game constantly improves.
Expectations grow, Scope grows
When we showcased the game to gameplay testers (including some industry leading people), they found the Arcade mode to be more fun.
When we started our work on Wobble Bobble, it was a very small game. The goal, our one simple game mechanic, was to keep the ball in the center of the table for as long as possible. By keeping the ball in certain circles in the game area, the player would earn points. We kept this feature and started thinking about expanding the gameplay mechanics to make the game more challenging. There was an immediate need to add fun to the game, and we took a routine path of adding new modes to the game. We added Challenge and Arcade modes and renamed the first mode to Classic mode. When we showcased the game to gameplay testers (including some industry leading people), they found the Arcade mode to be more fun. Because of this, we decided to make the arcade mode the standard.
Mistakes made, lessons learned
Since Wobble Bobble was our first attempt to do a true mobile game, we faced our own share of problems. Luckily, every problem taught us something we can incorporate in the development of new games.
One of our biggest mistakes was only checking the performance of the game on the latest iPod Touch and iPhone 4S. The game was working absolutely fine on these devices. When we tested on older devices, we found out the speed of the game was too slow. The speed of the ball used to depend on the processor of the device. When developing for PC, we take great care of issues like this, but we never bothered while developing a mobile game. We managed to fix this issue using Delta timing. In short: delta timing is used to handle complex graphics or a lot of code, by defining the speed of objects so that they will eventually move at the same speed, regardless of processor speed.
Another problem came from testing the Android version of the game on a Samsung S2. On the S2, everything worked perfectly fine, but on a Samsung Note the game would crash. We decided to do some quick ‘n’ dirty resolution tweaks so it would run on Samsung Note too. However, when we launched the game, we realized these tweaks were temporarily solutions for a bigger problem: Cocos automatically resizes the screen for Android. After more tweaking, we got everything working, both speed and resolution were permanently taken care of.
It was still a near perfect project
Though there were issues related to the shift, a lot of things went in favor of the project.
Though we improved the basic gameplay mechanics of Wobble Bobble, no major changes occurred.
No major feature changes – Up until the development of Wobble Bobble, we had never worked on a game where the basic planned features never changed. Though we improved the basic gameplay mechanics of Wobble Bobble, no major changes occurred. Throughout the production, we were always aware of the exact scope of the game and things were neatly planned.
Our strong project management roots - Coming from large game projects, we always relied on strong project management. This worked in our favor as we had Microsoft Project, MantisBT and SVN running on our server, helping us to stay close to reality and allowing us to always have an up-to-date version of the code. There were stand up meetings every day and all the tasks were regularly updated in the Microsoft project. All the bugs were tracked in MantisBT and everything was accessible from home as well, so we always had access to what was going on with the project from anywhere.
Iterative Implementation - We never had a huge game design document written for the game, so we approached each module of the project as totally individual. Frankly, we didn’t even know what additional module will be added next, while working on the current one. We focused on perfecting one feature before even thinking about what the next feature would be.
A solid team - The biggest achievement of this project was that the entire team stuck together and kept sharing and debating ideas. Nobody in the entire studio was away from this project and everybody participated willingly. In most of the studios, the Pareto principle is in effect, i.e. 20% of the people doing 80% of work. In our studio, it seems like we only have the 20%, in a way that everyone is productive and 100% focused on the game.
The development of Wobble Bobble also saw people coming out and taking responsibility at an extraordinary level. For example, our QA manager took the responsibility of managing daily stand-up meetings and making sure things were transparent.
Playing games - In our earlier setup, we used to have at least 1 hour of Team Fortress 2 or Call of Duty LAN matches a day. We used to encourage everybody to play games whenever they were free, so there used to be a lot of single-player games, game-related discussions and showcasing in the office. When we started TAGS, we were busy working on games or game pitches, rather than spending time playing games. Most of the guys used to play 3 hours a day, but the initial struggling period left us wanting to focus more on development and gaming took a hit. We weren’t happy about it, but we had no choice. However, there was one thing that we religiously maintained: to stick to a five days a week schedule, so that the team could spend some time at home and play. It was a tough decision but we were spending more than 12 hours a day in the office. We all knew that it was a temporary phase and currently we are back to being normal, and normal people play videogames!
Post Release
China’s numbers were unexpectedly huge
When the game got launched on June 27, 2012, it immediately caught the attention of a lot of people. We got decent review from gamers, even though we didn’t have the money for decent PR. Still the game spread with the word-of-mouth publicity.
We developed Wobble Bobble Pro, but it didn’t pick up sales at all. Anyhow, our focus was not to make money with this game, so we immediately made the pro version free. Surprisingly, it became a huge success in some countries like USA and China. China’s numbers were unexpectedly huge. Many people like it so much, that they asked to have a tournament for the game, so we set up a separate Facebook page for players and the contest. We were actually really shocked to see people scoring millions, scores which a lot of our developers couldn’t get (except our QA manager).
This contest helped Wobble Bobble to establish itself and establish the all new brand The Awesome Game Studio.
Wobble Bobble is available on iOS and Android.
Right now, TAGS’s hands are full and they say they feel like those typical Indian Gods with 4 hands. They are working on one of their most ambitious mobile IP which is called Alphaman and will be released in Q1 of 2013. TAGS has signed a three-year contract with USA-based toy manufacturing company Imagability Inc. to develop games across all the platforms. TAGS is working for a Fortune Five company on one of their brand IP. In all these projects, they strive to maintain control over the game design and processes which gives them complete creative freedom.
Apart from all these, TAGS is also working on a console game which is in Pre-Production right now. They hope to continue their awesome journey.
Arges Systems is a micro-studio doing game consulting and application development in Unity – their specialty is on game logic and AI. Arges Systems has been partnering with companies specializing in 3D graphics and visual design, as well as doing contracting for companies building games with Unity. In this article, Ricardo J. Méndez (founder of Arges Systems) shares some insights on their just-released Hairy Tales.
I initially founded Arges Systems to take advantage of my experience running remote teams and projects. We had been doing contracting on various game projects for a couple of years before I decided to switch gears and start working on our own stuff. I had just decided to pull the plug on a turn-based strategy game for which I realized the scope was too ambitious and was chatting with Yuriy Mazurkin, our concept artist, about possible themes for a follow up game. The conversation drifted to Russian illustrators - somehow we ended up talking about Ivan Bilibin and it got me thinking about action/adventure games.
A sword-wielding octogenarian riding a warhorse charges forward from a hill. Nordic forests and evergreen trees spread before him. He’s also butt-naked.
It was a simple, straightforward picture by Russian illustrator Ivan Bilibin, from his Marya Morevna series, and my first encounter with Koschei the Deathless. He’s an archetypal antagonist of Slavic folklore, an even more evil version of their better-known Baba Yaga.
I took one look at it and with its combination of adventure and absurd, I thought “damn, this would make for an excellent slavic Zelda-like game”.
You can’t get there… from here
I wanted to do a game that was different, and this wasn’t it.
I experimented with gameplay styles while Yuriy drafted some concepts. We drafted several ideas for scenarios, including a story, but it quickly became apparent I had nothing new to say about the adventure genre. I wanted to do a game that was different, and this wasn’t it.
Partly as a way to cleanse our creative palate, I started experimenting with mixing puzzles in. You had to maneuver the main character through a corrupted land, frozen in time, but elements got un-frozen as you approach them. This had pros and cons, since you could activate machinery just by being near it, but enemies also came alive. The puzzle aspect was to figure out what to do when. I decided to discard this version as well. It seemed like a one-trick pony, with the sort of read-the-designer’s-mind approach that I hate, and lacked replayability - once you know the solution, that’s it. Also, the game was taking on a somewhat stoic tone that I felt dragged it down.
You will notice I haven’t mentioned anything about the modeling side of things. We had overenthusiastically already started modeling before I was done with the design, because I wanted to get the time-consuming assets out of the way - or at least properly estimated. Despite it being a bad strategic decision, it had a positive side effect: it made me realize early on that the 3D artist we were working with just wouldn’t cut it. The quality of his work had been in decline, he wasn’t paying attention to details, and both Yuriy and I kept having to bounce work back to him with notes. Eventually I had to let him go and start looking for a new hire. Fortunately we found Ash Barnard, from the UK, who meshed with the team perfectly. He has an eye for detail, very expressive animations and more importantly, just the right sense of humor to make the Hairy Tales animations memorable and peculiar. Ash also brought in a good eye for gameplay, and helped criticize mechanics as I was coming up with them.
Through several experiments and iterations, I ended up landing on something close to the current approach. The first few iterations were fixed stages, based around arrows that directed them and fences that made them turn two sides to the right. It also featured a first draft of the spreading corruption, with the twist that if it spread to a tile with a fence, then it got corrupted and the fence turned into a deadly wall of flame. I can hear the thought gears as you try to figure it out. Playtesters weren’t getting it, and even when they figured out stages the reaction often was “I know this is how it’s supposed to be, but don’t know why”.
That would not do.
Concept art for Hairy Tales
Dragging it there
I started paring down the elements. At this point we’ve been in a production iteration limbo for months, and all the associated hair pulling is starting to take its toll on me. Everything is self-funded, so Arges is hemorrhaging cash while we experiment, and my focus is split between the game and the client work that is funding the process. I started trying different games to relax - mostly playing demos, so I didn’t get too involved and lost track of the project. One day I was playing a demo of Atlus’ Catherine, moving Vincent around, pulling and pushing blocks into place, and then a light bulb went on. After simplifying the elements, the stages had felt too straightforward, and the new levels depended mostly on size for their complexity. What if players could drag tiles from one place to another?
I didn’t tell the team, just sent them a build where some later stages required them to move tiles. They were rather surprised at first, but immediately saw the possibilities, like tiles that drag Hairys from one place to another, weapons you can re-use or teleporters. So finally, after months of iterations, we had a design we were happy with.
The 90-90 rule
It took a lot to get from a game’s design to the final product, of course. We still had to design the look for the various tile elements as we were going, which kept Yuriy involved while Ash created the models and I both coded the behavior and came up with the stages. Yuriy was also helping with the texturing. His true love is painterly work, however, so he came to me when we were about to enter the final stretch and brought up that he wanted to move on.
As sad as this made me, since I enjoyed working with him, I helped coach him for interviews and gave him a sterling recommendation. He ended up getting employed by Yager in Berlin, who recently published Spec Ops: The Line, and I expect is right now working on their next project.
At about this time I brought on board composer Levan Iordanishvili as a contractor to work on the game’s music. He liked the game and offered to take care of the sound effects as well. To ensure both were cut from the same cloth - he did a smashing job of re-creating the sound that Ash’s animations made in your head when you looked at them, and his scoring of the three worlds and bosses was top notch.
One of the levels in Hairy Tales
Calling it
I had initially planned to release with five worlds and five bosses worth of content, for a total of 75 levels (15 per world). Playtesting had demonstrated that players needed a gentler level progression than the breakneck pace we initially had, so each world had increased to 24 stages. If we kept the same number of stages per world, we were looking at 120 stages total, plus the extra time it would take for the two other bosses and possibly new enemies to keep things lively. The scope was getting out of hand.
I made a judgment call. We would be launching with 72 levels and three bosses, using some minor characters as mini-bosses. Once we saw the initial reactions to these levels from our players, we could release a couple more worlds as add-ons and expand on those qualities that players enjoyed the most. The team agreed, and we geared up for polishing the worlds we had fully designed.
The initial stage sequence introduced one concept after another, presenting a more concentrated experience which gave the player little respite, with no stages that they could use to experiment with the mechanics they had just learned before throwing a new set of concepts at them. After various rounds of playtesting, I introduced some intermediate levels that presented the concepts they’d just learned in different contexts, so that they could play around a bit more, which made the initial learning process smoother. However, it also led to the initial stage sequence feeling a bit drawn out, so I then had to adjust the sequence once again. This process went on over several iterations, even after we had released.
Launch and everything after
We wrapped what we considered to be version 1.0, went back to talk to some publishers we’d been in contact with, and settled on Forest Moon Games and BAM! The game was out the gate.
The game is currently sitting at a Metascore of 81
It was exceedingly well received by reviewers - sites like TouchArcade, EuroGamer and Gamezbo gave it glowing reviews, praising its flexibility, difficulty and character. The game is currently sitting at a Metascore of 81, the highest Forest Moon Games has gotten (and one of the highest of its less-experimental sister brand Crescent Moon Games). Apple picked the Mac version of the game as an Editor’s Choice on the Mac App Store, and gave it a humbler New and Noteworthy feature on iOS.
However, commercial reception was merely lukewarm. We were aware that the characters, not being your traditional cute-and-cuddly puzzle game stars, would be an issue. But we were not sure what was the main problem. The initial game difficulty was rather high - a throwback to the old school puzzle style - which might be turning off casual game players who get it expecting an easier time and hurting word of mouth. At the same time, the visuals are cartoonish, which leads players who would appreciate the challenge to dismiss it as a merely a casual game. Once we get it in front of players they usually love it, but doing so takes a fair amount of effort.
We’ve also had an overwhelming amount of piracy - 95% piracy rates on iOS and Mac, with Windows being well over 99% (Windows sales are comparatively a rounding error). It’s great that players are enjoying the game but having gone with a design oriented towards making it a premium app instead of a freemium game means we get no benefit from those playing it for free - not even a ranking increase.
We have continued supporting the game, releasing so far three minor and one major updates, including an adjusted difficulty curve and 12 new tutorial levels (bringing the total up to 84), but as of this writing that update has only been out for a couple of weeks - it still remains to be seen what effect it will have.
Lessons Learned
Where do we begin?
Target it, goddammit - We focused too much on the gameplay and on crafting characters with a personality we enjoyed, without considering if we were sending out mixed messages that could confuse players, alienating precisely those we wanted to rope in.
Cut the dead weight early - the initial modeler and animator just wasn’t working out, and keeping him on board for longer than I should have was not only an expense I could have saved, but risked losing us an invaluable team member. Deal with these problems sooner rather than later.
Be ready to trim - we have a plethora of characters and elements we just didn’t get to use because we simply had no time to properly develop them. As much as you love your designs, chances are a lot of them will end up having to be left out.
There doesn’t seem to be a middle market on iOS apps anymore
If you’re indie and working on a premium app, reconsider - there doesn’t seem to be a middle market on iOS apps anymore - it’s almost all either huge AAA-quality projects, or simpler one-mechanic freemium games (and some freemium games have been getting shinier and more elaborate). Do you really want to bet the house on a business model with a piracy rate higher than 90%, when the market is flooded with competing titles that players can get for free?
Where to go from here
Stubborn as we are, we find ourselves already working on our next title, after going through multiple prototypes and even more concepts - this time applying the lessons we learned from Hairy Tales. I expect we’ll manage to retain the spirit of experimentation and sense of humor that we imbued the game with, while setting it into a game design more fitting for today’s game climate. Wish us luck!
Hairy Tales is available for the iPhone/iPad in the AppStore. It can also be purchased on Desura for Windows. Check it out on Steam Greenlight.
The Global Game Jam and beyond series sheds light on the few brave Global Game Jam (GGJ) teams that have decided to take their GGJ projects to the next level and continue development after those challenging 48 hours. We ask each team to tell about their experiences, share learned lessons and offer advise on their attempt to turn their Global Game Jam project into a full fledged commercial product.
Last year’s edition of the Global Game Jam saw its biggest entry of games yet. Combined with the rather obscure theme of Ouroboros, the ancient symbol of a serpent or dragon eating its own tail.
Based on the Oroborus theme for the GGJ2012 the team behind the quirky one-button arcade game Catch-22 wanted to make a game in which your actions bite yourself in the ass. This resulted in them not only winning the local competition at their jam site, but later also won a prize for being the best Dutch Global Game Jam game. Catch-22 also later became one of the PAX 10 selected indie projects to be showcased at the PAX Prime event in Seattle back in August 2012.
Catch-22 has been in development for iOS ever since.
After we finished the game we realized we made a game in which there is no AI entity or anything attacking you in the game, but yourself. Contrary to normal arcade games, Catch-22 doesn’t pump you full of adrenaline with upbeat music and flashy stuff, or send in hordes of enemies towards you to defeat. You do that by yourself, because this game is all about the endless battle you have with yourself. That idea was truly unique and something that we hadn’t seen before ourselves, so we decided to continue developing Catch-22.
What triggered your initial consideration that your game was worth to continue development?
We didn’t have the idea that our game was worth continuing until after the GGJ ended. We only came to insight on what our concept was worth after the Jam, when we won first place in the national Dutch Global Game Jam. During the Jam itself, we were really just focusing on making the game, were exhausted afterwards and just glad we finished it.
Since our game is a one-button game it’s really easy to port it to any platform since you don’t need a controller. We also made it in Unity 3D, which gave us the power to port it to handheld devices (iOS and Android) instantly. So we figured; why not?!
Catch-22’s AppStore logo
What do you believe was the main element of your game that allowed it to be commercially viable?
After the jam we had a working proof of concept and it only need a lot of polishing. Next to that the game doesn’t require a specific input device such as a controller so it’s easy to port it virtually to any system. And again, Unity 3D gets you a long way.
What really got things in motion was that we got the Dutch “Gamefonds”, a local subsidy for creative projects, to financially support the development of the game just one month after the GGJ. I’ve seen enough projects die young because of the lack of funds, and our project almost suffered the same fate. The funding enabled us to finish the game, fly our butts over to A MAZE IndieConnect, PAX Prime and IndieCade, and hire the necessary artists to work on the game. We simply couldn’t have done it without this initial starting money.
How did you manage the step to go commercial in your team?
We have a really simple way of working which translates to this line; Drink beer, smoke cigarettes and make video games. Rinse and repeat this until the fat lady sings. Really, just flip the switch and go for it, because there is only two ways of doing things; Do them really well, or leave it for someone to do it really well. Because making games is hard, tedious work and you, my friend, are not a robot.
What were the three most important experiences/learned lessons and/or challenges that you had while further developing your game?
Make some solid agreements beforehand
First of all, make some solid agreements beforehand. If you do get in a situation where there is a conflict within the team, you can still have a level of conversation where you can clear the air. If you don’t do this, then be prepared for some hard loving from your close friends. For example in our team, team member Roel had spend a lot more time into the project in the beginning stage and wanted to be compensated for it. I agreed, but team member Marlon didn’t and had his own reasons for it. In the end we arranged to have a team leader (aka a neutral party) who overlooked the project and could talk to us as a supervisor. This made all the difference for the balance within the team. So unless you have really, really good agreements, you can’t simply overcome the possible conflicts that arise within your team. There are one too many teams who think they can do without a good agreement, and it just doesn’t work like that in any kind of game development setting.
Make sure you get your long-term focus right
Second, make a plan to where you want your game and/or company to be in a few months. Make your goals achievable, because just talking about it with your team will not just make it happen by itself. Things change over time and personal situations can get the upper hand if you don’t. I got de-motivated by the fact that things took too long or just simply weren’t done during a certain period of development. Motivation is the only thing that keeps you going when making games, whether it’s money or just finishing your game. So get your mind straight and make sure to get your long-term focus right. Nearing completion, we would regularly go out for drinks and enjoy ourselves from time to time. Having the release of the game within reach, things got a lot less stressful. Most conflicts took place at the beginning of the project. In retrospect, we also stayed motivated by the achievements we got in the meantime; from winning the GGJ to getting 25k honored, to being selected for PAX10 and IndieCade, and finally the release ahead. Having stuff to look forward to is great, especially finishing your game.
In your case, what did you learn from getting the game out to the public?
Start doing this as soon as possible. You will be surprised where it can take you and your game! We can’t stress people enough to do this. If you feel uncomfortable doing this, talk to some people, practice and work on your pitch. Because the public doesn’t see your game like you do and their opinion is the most valuable one you can get. It’s also a really good way to test if your game is commercially viable. If you get some reactions from people who ask you if it’s already for sale or available, Ka-ching! You got game!
What kind of tips would you give to other GGJ participants who might decide to continue developing their project?
It takes time for your game to pick up momentum
Stop crying and making excuses to not release your game or get it out in the open right now. It’s the first sign of failure and I witnessed this in person at the company where I did my traineeship.
It takes time for your game to pick up momentum if you haven’t released any games before or are a well known game developer. Don’t think people will be jumping and begging for your game, because there is a lot of competition out there.
Last but not least, get accustomed to the Nike mentality; just do it! And that goes for everything in your project, from making your game to marketing and PR. Best practices come from experience, and it’s ok to “fail” on your first go.
Cath-22 for iOS can be downloaded in the AppStore.
Great games can come from the most unexpected corners of the globe, sometimes years in the making before finding their rhythm. Brazil’s D’Accord Music Software started ten years ago. “We were doing music education software,” recalls chief executive Americo Amorim. The company made mostly PC-based downloadable products, which were very successful in schools.
By 2007, he says, “We got bored with only doing educational stuff.” So, the company created a division called MusiGames. It started with ten people, hired more along the way, and has reached thirty people so far. Amorim reports, with a touch of pride, that almost all of his company’s current development efforts are in games.
Legacy of games
The original idea for Drum Challenge came from one of the D'Accord's own software engineers.
“In Brazil, we had a lot of experience with SEGA consoles,” says Amorim. “But our team’s background is PC development and mobile development studios, like traditional J2ME development.”
Before making a game together, they started with research, attending developer conferences, and meeting publishers. “We weren’t sure what platform we were going to work on,” says Amorim. “Of course, the team wanted to do Wii games, Xbox games, PlayStation games. But it didn’t really make sense for a start-up company at that time to do those kind of things,” he says.
They found the smartphone market to be open in 2008, and there were even fewer music games on the market.
Proof of concept
D’Accord’s first game was Drums Challenge for the iPhone. When they released it in June of 2009, it managed to sell 500 copies in the first three weeks. “With the public we drove to the game,” explains Amorim. “And what really happened was that Apple started promoting it. So when Apple started promoting it, the sales skyrocketed.”
“What our experience says, what really matters, is Apple promoting your iPhone game.”
The initial price was $2.99, and is $0.99 today. “What our experience says, what really matters, is Apple promoting your iPhone game,” Amorim reveals. “If they promote,” he laughs, “you’re successful.”
“And, of course, they don’t promote crappy stuff.” Amorim says that Apple doesn’t have room to promote everything that is great.
“On our side, we’re focusing more and more on the quality.” Last year, the company produced five games to create a portfolio. “For this year, specifically, we’re focused more on quality. So we’re doing only two games, and we’ve been developing them for six months.”
“Right now, we are focusing on smartphones: iPhone, iPad, Android, Symbian, and Facebook.” says Amorim. When asked about budget, he replies: “It’s usually $50,000 to do a nice music game.”
For MusiGames, both iPhone and Android development are done with the same budget. “That’s where we are improving,” Amorim points out. “It’s not a very high budget, but it’s a complicated budget for a small developer.”
Key learnings
Released right after the iPad launch, Drums Challenge became the bestselling iPad music game in its release month.
Some games, Amorim’s team promotes on their own. On others, they’ve tested distributors like Chillingo and I-play. “Some of those guys have more access to Apple, and that makes it easier for us. But, of course, they get a share of the game. So it’s really a decision that depends on the game we are talking about.”
The company decided to aim for a global audience, because the game market in Brazil is still growing. Amorim reports that the marketing is “starting to happen right now. Two years ago, it didn’t make sense to do smartphone games in Brazil.”
Today, they’re developing a title for Google-owned social-network Orkut. “Orkut is the Facebook of Brazil,” Amorim explains, adding, “Our first experience in Brazil will be this Orkut game. I really have high hopes for it.”
Playing social
The idea for iMusicPuzzle came from one of the company's artists.
While social games have been a strong trend in recent years, Amorim says: “We are really trying to focus on music games — because our expertise is in this. This social game is really musical,” he adds, about their upcoming product.
It could mark the first cross between the music genre, and a game for the social network platform.
When asked what a music game on a social platform would look like, Amorim smiles. “You’ll see in a couple months.” And that raises the question of whether it’s even possible. “Yeah, it is. The challenge is to get the friend’s interactions. You have to interact with the music, and you have to interact with friends.”
Amorim considers the question of whether music is universal on a global scale. “It really depends on the songs that you have in the game. So as we try to do games that you can play with any song: that makes them universal. So if you have ten-thousand songs in your library, you can play with them: that’s great.”
Market growth
Something they’re investing in more and more is letting the user play with their own songs. It saves the hassles of licensing, and the company had developed chord-recognition tech from their education software days. “We have a very good technology and we started applying this to games,” says Amorim.
This year, the company managed to get some VC funding. It allowed them to grow their development capabilities, and as Amorim adds: “We grew our marketing team, which we didn’t have before the VC guys came in.”
“We want to be known as the music games studio, and the Brazilian leader.”
Amorim says the strategy for MusiGames is to position themselves as “the big independent music game studio.” Beyond that, they want to have a strong position in Brazil. Amorim reveals: “We’re seeing the market grow a lot there.”
Which is why they’re investing in that growth. “We want to be known as the music games studio, and the Brazilian leader.”
Sound advice
The MusiGames team celebrating the company's anniversary with some freshly printed t-shirts
And when it comes to what other developers can do to achieve success, Amorim has a few pieces of advice: follow game-business news, follow the market, and try something different with your game.
MusiGames’ best successes weren’t radically different, he says, but all “had something really unique.” And having a specialization is a great way to keep from losing good ideas along the way.
“What’s our guideline? If it’s a music game, we’re interested,” Amorim says. “And if it’s a platform we already know how to develop for, we can even study the idea. If the idea’s really good, we may do it. But, on the other side, we try to keep the focus.”
MusiGames is currently working on a music game for the Orkut social-network.
