James Prucey provided information on creating a game without coding knowledge at Casual Connect USA 2014. “The first thing is define what your game is. You have to have a clear understanding of what you want to make, what the genre is,” he advised. “Part of that is also understanding what platforms you want to target.”
James Prucey can be described in one word — exuberant. Prucey is the owner of Canned Bananas, LLC. His hobbies include poker, painting, and photography.
James Prucey (right), Owner, Canned Bananas, LLC
Record-Setting Gamer
Prucey holds the world record at Star Castle, playing for 63 hours on one quarter. Because he cannot control himself, he no longer owns a console. As a result, he can now leave the house and actually get some work done. Nowadays, the iPhone is his favorite gaming device, where he enjoys playing casual games.
His greatest success came with Lock N’ Roll, which was the number 1 dice game in Japan for a year and was nominated for the Best App Ever Awards in 2009 and 2011.
He has been developing iPhone games since 2008. Since then his company, Canned Bananas, LLC, has developed numerous apps on several platforms, including Facebook, Android, Windows, and iOS. His greatest success came with Lock N’ Roll, which was the number 1 dice game in Japan for a year and was nominated for the Best App Ever Awards in 2009 and 2011. The game has now been downloaded over three million times.
Prucey has just finished designing and building a prototype for a fast-paced and action-packed variation of Poker. The game is designed for short and rapid sessions, which are ideal for mobile. He hopes to bring this to market by the end of the year.
Oliver Miao recounted an experience of how they helped a player of their game, High School Story, after she expressed a desire to commit suicide. “We ended up exchanging messages with her for about a week,” he said. “It was one of the most nerve-wracking weeks I’ve had. But at the end of that week, she told us she was finally getting professional help, and she also said that it was because of High School Story that she was still alive. And that moment showed us how powerful a game could be.”
Oliver Miao, the co-founder and CEO of Pixelberry, emphasizes, “Gaming connects people. Gaming has always connected people, but nowadays, the connection is happening at deeper and deeper levels.” He maintains that certain things in a particular game resonate strongly with players. It could be a character, or sometimes a funny feature, or just that everyone is playing the same game at the same time. And because people feel so connected to games, they are becoming the social platform of the future.
Creating The Connections
As a result, Pixelberry is working on features that will make people feel more connected as they play. One feature, launched in June, is called “Your Voice.” It allows players to share their thoughts on pop culture as well as more serious events. Miao believes that seeing what their friends think about the latest trends will make the game world feel alive to players. He also hopes it will make players pause and consider topics that they don’t often think about, like net neutrality or what’s happening with Syrian refugees, .
Their game, High School Story, connects players to each other, but they are also using the game to connect players to non-profits. Pixelberry has partnered with The Cybersmile Foundation and the National Eating Disorders Association to make more of their players aware of what to do if they or their friends encounter cyberbullying or body image and eating disorder issues. In response, their players have sent messages of appreciation, knowing the game they are playing is helping people.
Their game, High School Story, connects players to each other, but they are also using the game to connect players to non-profits.
Earlier this year, Miao’s high school invited him to talk during their Yellow Ribbon Week, which is focused on mental health for teens. He relates, “It was incredible standing in front of a gym full of high schoolers, talking about my experiences growing up, getting into the games industry, and working on this game that many of them had played. The room was quiet as I told them about a player who told us that they were planning to kill themselves. And it erupted into relief when they learned that our game had saved a life.”
Miao says that he loves making games, and combining that love with making a difference is absolutely amazing.
Rising From The Ashes
He started his first game company with college friends in 2000, just before the dot-com crash. For a year and a half they lost money while, at the same time, learning a lot. Finally, just as they were closing the company, they were saved by a contract to make games for cell phones. They realized that their failure was not focusing enough attention on business, so Miao switched from mainly doing programming to concentrating on business full-time. He admits, “Cold calling people and talking to strangers at conferences was far beyond my introverted level of comfort. But it worked.”
The Pixelberry team having some fun
Today he works with an extremely creative team that really cares about what they do. Some of them have worked together since he founded that first company, Centerscore, through its acquisition by Vivendi and sale to EA. And they are still together at Pixelberry. He finds it especially rewarding to work with these people and see them grow together.
Connecting at Home
A couple of teens in High School Story having fun.
Growing up, Miao always enjoyed games: games at recess, board games with friends, and the Famicon console in the family room. But these were always different games at different times. Now cell phones have changed the way people play games. They can play the same game whenever they want. And he is certain that for many people, the total time they spend with one mobile game outweighs the time they have spent with any other game ever.
Miao owns an iPhone, a Nexus tablet and a Kindle, claiming these may be the most prolific devices ever in terms of variety of games available. These days he is most often using his iPhone to play Plants vs Zombies and Plants vs Zombies 2. From the original game, his favorite level is the “It’s Raining Seeds” minigame. In the sequel, he keeps playing level 24 in the space theme, figuring out ways to beat the level with interesting permutations, like only using Kernel-pults or Bok Choy. He says, “If their analytics show one crazy person who has played that level more times than anyone else in the world, that’s me!”
On weekends, when Miao is not working, he likes to take his five-year-old twins bike riding on the campus of Stanford where they learned to ride bikes. They love to pedal to the top of a hill and coast down as fast as they can while he and his wife follow them on roller blades.
Asia is an important market, so we developed Super Badminton, a sport which is particularly popular in this region. Anuj Tandon is COO for Rolocule Games, a company based in India which specializes in the creation of popular sports games, including Flick Tennis, Super Badminton and Touch Squash. When Flick Tennis won the International Mobile Gaming award, Anuj felt so much pride in the work he is a part of at Rolocule Games. It was the first completely Indian-created IP to do so.
Screenshot of our IMGA award winning game Flick Tennis: College Wars
Video games have been an important part of Anuj’s life as long as he can remember. He knew that he wanted to get into gaming as a career somehow. As a qualified engineer, he worked for some time with Infosys in the UK where he became experienced in business development. Now, for Rolocule, he runs the operations, is responsible for marketing and also does game design. These are difficult roles to coordinate, but he manages to do it successfully.
Two events have altered Anuj’s view of his product and company. These were Casual Connect Seattle and the Apple World Wide Developers Conference, where he learned about freemium and disruptive tech within the Apple system. Both these concepts have proven to be valuable to the company. He points out that he believes the persistence of delivering new and disruptive experiences to gamers is very important.
Rolomotion
Because Asia is so important to the game market, Rolocule has developed Super Badminton, referencing a sport which is particularly popular in this region to create a deeper sense of locality. According to Anuj, the significance of Asia is huge, particularly as the company forays into Android. Rolocule has also released information about its new technology, Rolomotion, which brings motion gaming to the iPhone using Apple TV. At Casual Connect Asia, Anuj announced that the first Rolomotion powered game, Motion Tennis is set for release in May.
This is an exclusive image of our new product Motion Tennis in action. We are bringing motion gaming experience to mobile and Motion Tennis is the first game on that.
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.
Stolen Couch Games is a young Dutch game studio formed by six alumni from the Utrecht School of Arts who decided to continue working together after their college projects. A part of the team came together to make a multiplayer prototype for XBLA and PSN title Chime made by developer Zoe Mode in collaboration with the One Big Game initiative. Stolen Couch Games then reformed and expanded the core team with an extra programmer and artist. Their first big title fresh out of the Utrecht School of Arts was Kids vs Goblins.
Building Kids vs Goblins
The Kids vs Goblins team from left to right: Bart Delissen, Casper van Beuzekom, Arthur Koopmans, Daan Boon, Eric Diepeveen, Selma Oors and Bjorn Spies. Not featured in this image, but equally important, is sound designer Rutger Muller.
When we initially started out Stolen Couch Games, we wanted to make something that would appeal to a large audience and show our potential as a start-up game studio. It was important for us to use our first product as a kick start into full time game development. After a prototype and concept phase, we formed the core idea for Kids vs Goblins. We decided to go all in on it, and for eleven months we poured our time, energy, and above all love, into this project. We strive for high quality in all our projects, but this one was particularly important for the team. Unfortunately, attaining perfection is impossible. Sometimes things went right and sometimes things went wrong, and then sometimes things just went completely awful. We would gladly like to share some of these moments with you.
Most of this experience took place in a learning environment where many mistakes and blunders were accepted as a normal part of an educational project.
Our team has had plenty of experience with designing and developing videogames, from concept to completion. Most of this experience took place in a learning environment where many mistakes and blunders were accepted as a normal part of an educational project. Transitioning to the real world was hard, as commercial game development can be very harsh and unforgiving. Our team had experience with Unity 3D before starting the Kids vs Goblins project and the Unity engine was a logical first choice that fit our requirements neatly. We also worked with software such as Photoshop, 3DS Max, and SVN along with a free A* pathfinding plugin as well as a series of commercial plugins by Prime 31, such as the StoreKit, iCloud and Etcetera plugins. We worked on Kids vs Goblins for slightly more than eleven months in total. Pre-production, or the design period, lasted about one month.
A Light and Casual RPG is born
The player controls the three characters with simple finger movements while attacking the enemies. Dragging spells on the enemies will give the player total tactical control over the combat situation. The goal of the game is to defeat the waves of enemies and surviving the different level conditions. For example the Roulette mode is a variant in which you get random spells which you need to use to win the game. But do not use too many because for each spell you use you pay a couple of stones (the in-game currency). You can use the stones you gather during the game to buy spells and thus customize your characters and define the strategy for the next battle. The RPG elements in Kids vs Goblins are very light and casual. With over 60 spells and 6 different levels and 30 missions, Kids vs Goblins gives the player at least 3 hours of gameplay.
What went wrong during the making of Kids vs Goblins?
Choosing a target platforms & compatibility: Tackling a hard decision
The movie Labyrinth, featuring David Bowie as the evil goblin king, inspired the team. “We love the scene where David performs his magic dance and struts around like a king, so we knew we had to make a homage to this moment in the movie,” they explain in their official art book. The end result is the Spell Caster character in Kids vs Goblins.
We got a lot of 1 star reviews from people discovering the game didn’t work on their devices.
A couple of months into the project, we decided to make Kids vs Goblins for the iPad2. This decision was based on the possibilities the Unity engine gave us to port to iOS devices. We removed the controller support and started work on touch interaction. From a game design perspective this was a great step towards making Kids vs Goblins more approachable for a wider audience and it enhanced the speed of control of the game by just simply dragging your finger across the screen. But, as young enthusiasts often do, we overlooked the importance of checking the compatibility of every device after we ported to IOS, even the devices that were almost depreciated by their age such as the iPhone 3Gs. The difference between the different generations of devices became a big problem for us at the very end of the project.
During the first months of development this compatibility problem was not yet clear to us. But, around the time we wanted to submit Kids vs Goblins to Apple for approval, the question arose if it would run smoothly on older devices. We tried different optimizing processes, such as atlassing the textures and removing lots of particle effects. But in the end we had to make a big decision: Would we exclude the old devices and still release Kids vs Goblins only for the iPhone 4s and iPad 2?
We made a pros and cons list and decided to go on with only releasing the game on the newest devices, against the advice of our publisher. The game got really nice reviews from the press.
Resolution dependent art: Thinking Ahead
Our art pipeline was built up by trial and error. This was something that ended up costing us a lot of time and energy to fix.
We all want to make a product that the player enjoys in the end, but sometimes things do not end up looking like they did on the drawing board. Therefore, thinking ahead and planning your implementation of art assets during these kind of big projects is a must to save time and energy.
Our art team made some great artwork for Kids vs Goblins. This makes a great contribution to the quality of the game and shows off the talent of our artists. But during the production, we never thought through the art asset exporting process. Our art pipeline was built up by trial and error. This was something that ended up costing us a lot of time and energy to fix. We made the 2D art resolution dependent on top of that. Later on, when porting to the iPhone, this proved to be a problem. We had to redo a lot of GUI work which cost us weeks.
We realized we would have to plan and think ahead more for our next projects. For example, if we would have thought about making the 2D interface resolution independent from the start, it would take us a lot less time to fix it later on. The graphical part of the interface as well as the programming part of the job should have been thought out more thoroughly. All our newer games have resolution and aspect ratio independent GUI’s. Everything scales, repositions like you expect and it’s super easy to setup.
We just took a big leap with Kids vs Goblins and realized our mistake far too late along the way. You can make your pipeline so much more efficient and save a lot of time during crucial times if you just take some time before you start to think about the applications and the different ways the assets need to be used in the future.
Planning: Getting a Producer
Making use of every talent in the team at its best at all times if possible, a dedicated producer would have saved us loads of time and energy.
For a big project such as Kids vs Goblins, planning is key to make it a success. We tried to make schedules for all the different stages of the project and mostly worked with sprints of a couple of weeks, mostly 2 to 3. These sprints worked just fine in a team with clear goals. These sprints are great for the small parts of a planning and almost part of a bigger entity. But the bigger picture for Kids vs Goblins was not set into a planning and thus we had some major delays solely based on bad or insufficient planning.
To give the responsibility of planner or dedicated project manager to one of the team members was not possible because we all had plenty of work in our own fields. But a producer during these long compelling projects with different disciplines is essential, not only to finish the product in a predefined set of time but especially to maintain the level of morale and motivation of the team. During the stressful moments in crunch time, somebody that keeps track of every process in the game development can make a big difference in not only the quality of working but the quality of the product as well. This remains an outcome based on the employability and the mental health of the team, after all.
If we would ever again work on a big project that last for the bigger part of a year we would assign a dedicated project manager to secure the quality and pleasure of making games at this scale. It would be someone that is not involved in the creative process of game development and he/she would only be focused on making the process as efficient and streamlined as possible. Making use of every talent in the team at its best at all times if possible, a dedicated producer would have saved us loads of time and energy.
Bringing the message to the masses: Share often, but don’t rush announcements
We launched with a huge warning text in the app store “Only compatible with iPad 2 & iPhone 4s”. However this didn’t stop gamers with incompatible devices to buy the game. We got a lot of 1 star reviews from people discovering the game didn’t work on their devices. This is a problem a lot of developers are facing and there is little you can do about it.
To get the audience to notice your product you need to reach your target audience in a compelling way. The Apple Appstore as it works now makes it very hard to get noticed without being directly featured by Apple. All the apps are thrown on the same pile and thousands of apps keep getting added daily. It proved very beneficial to get Apple on our side and get a feature of some sort in the Appstore. But besides this feature from Apple, it is important to keep the attention of your audience tight and release enough information on a regular basis.
We did this completely the wrong way. We waited too long to show of the game while we were waiting for the game’ graphics to get just a little better. And yes, it is a good thing to show off with the best of the best, but to give your audience the feeling that they grow with you is a good way to get them involved with your project. Clarity is also important. If you don’t know the exact release date of your game yet, don’t share it with the world until you do. If you’re dependent on release dates set by Apple because you hope for a feature like we did, then just wait until it is approved. Even when that happens, be very careful because there are still a million things that can go wrong. In the end Kids vs Goblins got a little feature on the iOS app store and a huge one on the mac app store. This didn’t give us the amount of money we thought it would, but it would’ve been worse if we didn’t have those features. Our relationship with Apple has been great since day one.
What went right during the making of Kids vs Goblins?
Designing the theme: Stick close to your concept art
One of the marvelous sky boxes that was designed for the game.
When we started Kids vs Goblins, the design of the graphical layer went pretty smoothly. It was almost developed independently from the core game. Our design team would work out the game’s mechanics without sticking to a predefined declarative and narrative structure. This meant that our artists were almost free to do what ever they wanted. So they got their inspiration from movies such as Labyrinth and The Dark Crystal, and artists like Anton Pieck, Rien Poortvliet, Brian Froud and Paul Bonner.
Starting with the basic story, we expanded the game’s entire theme from thereon. The story led the creation of the game world in shaping the architecture. The science and the technology the goblins use give the world its credibility. The shapes of the enemies were very important because they should tell you what kind of enemy you have in front of you. We believe cartoony approach combined with the painted style of environments make the graphical layer of Kids vs Goblins one that speaks to many different kind of players.
The thing that especially went right with the design of the graphical layer was how the ambiance on the island was communicated to the player. The concept art our art team made for Kids vs Goblins was absolutely beautiful. People seemed to really like to our style and the world they created. When creating assets we stayed very close to these concepts so that we maintained a consistent style throughout. Even-though we had to cut texture resolutions in half to save on RAM, we’re still very happy with the end result.
Iterative design process FTW!
The attention to detail caught Apple’s eye, resulting in Kids vs Goblins being repeatedly featured on the iOS App store. This giant feature on the American App Store was a great surprise after the game’s release.
To make a product that will be enjoyed by your target audience, constant iteration is invaluable for the success of your company
At the Utrecht School of the Arts, we were always taught the importance of an iterative process in making games. This is a great way of thinking and dealing with problems you encounter when making a product for a large group of people. Our iterative process is not only driven from within the team (we’re all very, very critical of our own work), but mostly driven from the feedback we gathered from test players. To make a product that will be enjoyed by your target audience, constant iteration is invaluable for the success of your company.
Kids vs Goblins started out as a turn based-shooter with a cover system. It was a cross between Gears of War and Company of Heroes. When we switched to the iOS platform we believed the target audience had to be adjusted as well. So we changed the gameplay accordingly. Kids vs Goblins became a game that could be played by casual as well as hardcore gamers, instead of just the latter group.
We also took play testing rather serious. We used several techniques to gather feedback from testers that played the game. We started play testing early on in the project and continued even after the release. We used Testflightapp.com to send out build to testers around the globe. We also did play tests where we invited several testers to come and play in our office so we could directly observed their player behavior. Both ways gave us different kinds of information. In addition we developed a system that tracked what players did in the game. Every spell they used, every step they took was recorded and put in a database. Within days of release we got data from tens of thousands of play session. We used this data to balance our game in an update.
This iterative process was quite a success. We iterated on every aspect on the game and got a product that was way better than we would have gotten if we stuck to our initial ideas. Our approach is definitely a keeper for our future projects.
A team that is attuned to one another: Trust matters
At moments where one of the team members fell ill, the team could still function and we actually never stood still for more than a couple of days in the worst of cases.
Besides a good product and a bit of luck, a tight team is always the beginning of any success story. The team is the core and determines the potential of the final product. If a team member is off or cannot do the job, the whole team gets affected. The fragile relationships inside a functioning team are important and should be looked after. Our team had a structure where everybody had their own little island of responsibilities that was based on a lot of trust. We trusted each other to do their best in the time given with the vision we had set ourselves. There isn’t a typical hierarchy in our team. Even-though there are three artists not one can be considered the “lead” artists. Everyone has his own discipline and is responsible for that part of the development.
At moments where one of the team members fell ill, the team could still function and we actually never stood still for more than a couple of days in the worst of cases. Every talent was employed to the max and we had defined what everybody’s area of expertise was at the beginning of the project. We used Mantis, which is actually a bug tracking system, to give each other tasks. So everyone would know the status of a ticket and would know what to do. This is basically a digital scrum board. It worked on for Kids vs Goblins. But since then we have created a better system with a physical and digital ticket system combined.
There were of course a couple of setbacks that had to solve with the team dynamics, but nothing that couldn’t be solved by talking things through. Building a team as attuned to each other as ours takes time. We still need to grow to perfect our dynamics, to get all the creative juice flowing at optimal efficiency and still have fun in the process. Having our team bond by growing together from a team of students into professionals is a rather rare thing that we strongly value and which has shaped our studio culture.
Stolen Couch Games will be releasing their third game Castaway Paradise in 2013. You can also vote for Castaway Paradise on Greenlight and support Stolen Couch Games.
Brandon Wu is the founder and CEO of Studio Pepwuper. Brandon’s previous career includes strategic consulting at Sony and leading a testing team at Electronic Arts. In a previous life, he was an MBA, a economics major, and an owner of an office supply company. Now he spends his time making games, writing blog posts, and dreaming of a world where everybody loves games. In his first contribution for Gamesauce, he will talk about how he learned his way to building his first iPhone game, Megan and the Giant, without prior knowledge of programming and art-making.
A little more than a year ago, I was working in the strategy division at the Sony headquarters in Tokyo, busy making financial forecasts for new ventures and evaluating business deals. I had a typical MBA job, working with spreadsheets, writing feasibility studies and business plans, and meeting with executives to discuss high level strategies for one of the largest consumer electronics company in the world. My job couldn’t be further away from what I am doing today.
Armed with an education only in Economics and Business, I had no experience with programming a game, creating 2D and 3D art assets, or making sound effects and music for games. Not to mention my lack of proper game design experience. In the beginning of 2010, when I quit my corporate job, I had nothing but a desire to make games, and an idea for the first title. Insane? Maybe, but at that point, I had already decided that, no matter what it took, that game had to be made. Here is the series of events that led to the birth of “Megan and the Giant.”
Conceptualization
Early sketch of the stealth gameplay. Tools used: imagination, pencil, notebook.
In December 2009, I went to England for the first time to visit my in-laws for Christmas. My wife and I went on the Duck Tour - an amphibious bus that takes you around the city, and transforms into a boat that goes into the River Thames. While on the Duck Tour, I saw a road sign near the River Thames that resembled a giant creature, with a red line crossing through it. We couldn’t figure out what the sign meant, and I had the idea that perhaps there are giant creatures living in the river, and that the sign is saying “No Giants Allowed”.
I decided it would make a pretty interesting story, and spent the next few days sketching out ideas of how the story would unfold. I imagined England at war with another country, and these giants were thought to be secret weapons from the enemy, but eventually they became friends with a little girl and helped defending London from an invasion at the end.
The story was modified over time, and eventually I decided to stay away from a war-themed game to keep the game family-friendly.
I kept having this idea where in one scene, Megan would have to help the Giant escape from the police. Eventually I decided that that is what the game would be about, a simplified stealth game with elements from Metal Gear Solid and Pac-Man.
After I had a rough idea of what the story was about, I started thinking about gameplay. Initially I imagined a game similar to Professor Layton, where puzzle game is the main gameplay with stories in-between play sessions. But I kept having this idea where in one scene, Megan would have to help the Giant escape from the police. Eventually I decided that that is what the game would be about, a simplified stealth game with elements from Metal Gear Solid and Pac-Man.
Concept Art
One of the early concept art made by Yu Chen Wang. Tools used: Facebook (messages, contact)
After the basic concept was in place. I decided it would be great to have some concept art for development, and to help explain to people what the game is about. I asked Shawn Yu from Yu’s Art Adventure to help me with the concept art. This is when I finalized the look of the Giant and his personality.
Design Doc: DEMO
I plotted out the main story timeline on Keynote (simply because I am more familiar with presentation tools than anything else). This is when the story was still about the war, with an epic scene at the end where hundreds of giants show up to fight against the enemy. EPIC! Tools used: iWork'09 - Pages, Keynote, Game Design Document Outline
I decided to make a short demo for the game first so I could get some early feedback on the game. I used to write business plans, and I thought having a design doc, even though this is a small project, would help me think through the design and find details that I’d missed. So I wrote a design document that described the story, the gameplay, the visual, the target audience, and the purpose of the demo.
Outsourcing…?
After the design document for the demo was done, I wanted to outsource the development to a third party since I didn’t have the skills (programming, art, sound, etc.) to make it. I talked to many studios around the world, and found several talented studios interested in the project. However the development cost was too high, and I also decided that having the knowledge of how a game is made is crucial for me if I want to lead Studio Pepwuper to success. After one month of business development activities, I put my head down and started learning how to make a game from scratch.
Game Engine
After a few weeks of intense studying and experimenting I was able to set up a scene in Unity 2.6 that contained the basic gameplay.
Fortunately there are some great game engines available on the market. I had been paying attention to these middleware since 2009 and knew what my options were when it came to developing an iPhone game without having to do all the ground work. Among the choices were: Torque, Unity, ShiVa, and Cocos2D, and I eventually decided on Unity 3D for it’s ability to publish to multiple platforms and it’s supportive community. I bought the only Unity book available at the time (Will Goldstone’s Unity Game Development Essentials) and spent one month studying it day and night. The book does a good job of introducing the engine to beginners, but due to my lack of programming knowledge, I had to supplement my study with lots of reading online to learn programming and scripting with Javascript. I had a new found respect for all the programmers after that intense month.
What’s Next?
It took me three months from the moment I had the idea of making a game to actually seeing the prototype on screen, with the majority of the time spent on learning how to program and finding my way around Unity. It was great to finally see the idea come alive, and to know that maybe, just maybe, I can actually make games!
It was great to finally see the idea come alive, and to know that maybe, just maybe, I can actually make games!
A prototype is not a game, and the game was still 7 months from completion. Armed with my new-found confidence in self-studying, I continued my journey into more topics involved in game development. In the next part, I will talk about 2D and 3D art, sound/music, level design/boss fights, play-testing, getting the game onto an iPhone (Xcode), and the final crunch to the finish - the much juicier - and rewarding -parts of game making.
Stay Tuned!
Brandon can be reached at brandon.wu@gamesauce.org
Codeglue’s CEO Peter de Jong and CTO Maurice Sibrandi recently celebrated the very special occasion of running their studio for an entire decade. The two founders have been friends since highschool and went to higher technical college together to study computer science. Their close friendship led them to create their own game studio in the Netherlands, Codeglue, with a focus on mobile games and applications. We recently sat down to talk with both gentlemen about the celebratory occasion, developing CD-i games, early adopting XNA and balancing passion with need.
The Dutch pride of CD-i
De Jong: "Our collection of hand-held LCD games. Most of from our personal inventory. Yes, we are old-school."
Back when De Jong and Sibrandi were just starting with their technical engineering degrees, the Dutch company DIMA (‘Dutch Interactive Media Associates’, red.) paid a visit to our department and gave a presentation about internships to make games. “Maurice and I had similar interests, so we quickly decided to both do it,” De Jong recalls. “There was no Dutch game industry back then. There were some studios making CD-i games, that was it.” Already making games themselves on their Amigas, De Jong and Sibrandi didn’t have a breakthrough by themselves yet. In 1993 both decided to take on that internship and work on CD-i titles.
After graduating from university, the duo continued to work at DIMA. Back then the company became well-known for producing some of the more popular CD-i games. The studio’s main objective was to produce low-budget CD-i games in relatively short production times. While at DIMA, de Jong and Sibrandi worked on titles such as Family Games, Christmas Chrisis and Christmas Country. The studio would later go independent and rename itself to ‘Creative Media’ after Philips pulled the plug from it’s CD-i production.
Glued together
Codeglue's artist Tom Rutjens hard at work
When CD-i became unpopular, De Jong and Sibrandi spent a couple of years working IT jobs. In 2000, the dynamic duo took the step to found their own company and started working in the evening hours. In 2002, they finally took the step to go full-time with the company and focus on mobile game development. A lot of games were developed in cooperation with Dutch developer Two Tribes, who gained international fame with their Toki Tori franchise.
“We were always lucky that we were allowed to concentrate on the main reference handsets, which were only between 6-12 different types,” De Jong recalls. “The publisher would then deal with the other 380 types.” The number of handsets would later end up reaching far beyond 12, which forced De Jong and Sibrandi to seriously reconsider the company’s direction.
“We spent more time porting and adapting games than working on the gameplay.”
“We spent more time porting and adapting games than working on the gameplay,” he added. Codeglue would also start focusing on mobile multiplayer games. “We tried it together with a publisher, but the market clearly wasn’t ready for it. The operators had a lot of problems between them, communication went wrong, problems. The attempt did show a lot of promise.”
In 2007, the Codeglue team started working on Rocket Riot, their award winning XBLA title. “We spent the first half year trying to make it a mobile title, but it didn’t really fit with the concept,” De Jong recalls. “So we decided to turn it into a Xbox Live Arcade title.”
The team continued to build a prototype, pitched it to several publishers and Microsoft. “After the third time we talked to Microsoft, we were green lighted and received a slot on Xbox Live arcade,” At that time, we could’ve just published the game ourselves, but we needed the money to develop the game in the first place. We talked to publishers such as Ubisoft, THQ and Konami. All three were interested in the game, but also because we scored a slot with Microsoft. THQ was the fastest and most concrete with their contract. Their conditions were ok, so we partnered up with THQ.”
The XNA early adopter
The original Rocket Riot team standing inside the Microsoft booth during a Dutch game event. Rocket Riot was playable on 8 displays. Gears of War 2 only had 2.
When Codeglue actually started working with XNA, the toolset was barely out of it’s beta stage. “It’s a very cool technology and we had no problems making the game, but we experienced some serious delays during development.” Riot eventually took two years to develop.
Due to the delay, the project also became a financial challenge for the studio. With a full focus on Rocket Riot, alternative revenue streams were also found in making iPhone games. “Apple changed the market in one blow,” De Jong argues. “Offering fast mobile Internet made it a common thing with a flat fee.” Tackling the upcoming market, Codeglue used it’s mobile game know-how to dive into iPhone development. “While the industry was in a heavy dip, developing for the iPhone helped us get through that gloomy period.”
“While the industry was in a heavy dip, developing for the iPhone helped us get through that gloomy period.”
Codeglue currently spends a hefty portion of their office hours working on Playstation Home assets. “This also was the result of the financial crisis at first,” De Jong explains. “It became more serious and we’ve developed more things in Playstation Home.” Codeglue recently also received their own store inside Sony’s online service to sell their assets. The plan is to continue with developing for PS Home while it is still generating a satisfying revenue rate.
One would think that there is no real market for micro transactions on Home, but Codeglue has proven otherwise. The service packs quite the crowd. “Very few numbers have been made public,” De Jong admits. “We can’t tell you anything about the ones we know, but you’d be amazed how many people use it.” For Codeglue as a small developer, the hundreds of thousands of monthly unique visitors is good enough to keep developing for Sony’s virtual world.
“We’ve always worked with the publisher/developer model.” De Jong says. “But small developers like us have to focus on reaching the consumer directly instead.We have to start making sense of marketing and other things to go from developer to developer/publisher.” The Playstation Home store one of the first baby steps that is bringing the company closer towards that goal.
Balancing passion with need
One of Codeglue's special Playstation Home items for Christmas was the popular 'Santa on a Reindeer' costume
The work on Playstation Home has changed from a financial supplement into a creative output for Codeglue. “We’re in the phase of going back to devote ourselves to developing what we want,” De Jong confirms. “It’s been a tough period. We’ve talked to the entire team about the need to sometimes work on things that are less fun than developing your own game. Everyone knew about the situation and the financial crisis. I’m just happy we were able to keep everyone together and avoid any problems.”
De Jong sees Codeglue’s future in expanding the studio’s horizon to other platforms, creating separate units that focus on either PSN, XBLA, mobile and Facebook. “Our ambition is to develop a cross-platform game,” De Jong admits. “Not something stand-alone on the iPhone, but something that really connects.”
“Having one successful XBLA title in their pocket sadly isn’t enough to give any publisher enough confidence to work with you.”
Codeglue second step towards becoming directly connect with their consumers is their development of Ibb and Obb in cooperation with the small Dutch indie studio Sparpweed. “It’s our first project on PSN, so it will be quite the learning experience,” De Jong admits. “Having one successful XBLA title in their pocket sadly isn’t enough to give any publisher enough confidence to work with you.”
Going the digital way
Ibb and Obb are actually named after two characters in Jasper Fforde’s novel 'The Well of Lost Plots'.
The adventure to build their first XBLA title with an unfinished XNA toolset brought about some wise lessons for Codeglue. “Next time we’re working on a project and a fancy new technology strolls by, we’ll make sure it’s proven before,” De Jong says. “We could’ve chosen to use the Unity engine to make a PSN title, but something like that hasn’t come out yet. I’d like to wait see one or two Unity based games come out first, so I know for sure that the worst wrinkles in the software are dealt with. Somebody else will have fixed it, saving you a lot of time and money in the process. My advice to other small devs is to wait and use technology that is already proven. If you’re the first and can experience the marketing push from Unity as well, it might result in something positive. Then again, that’s not a luxury we can all enjoy.”
“I’d like to wait see one or two Unity based games come out first, so I know for sure that the worst wrinkles in the software are dealt with.”
The Rocket Riot project ended up teaching their technical staff a lot as well. “It was very stimulating for our programmers,” De Jong admits. “They were able to work directly with the technical staff from Microsoft, you’re involved both technically and innovatively with the toolset. But if you have to run a company, it’s not the wisest of decisions.”
Over the hill
Co-founder and CTO Maurice Sibrandi enjoying some coffee from his 'limited edition' Rocket Riot mug.
After ten years, it becomes clear the way De Jong and Sibrandi shaped Codeglue was strongly based on the ups and downs they’ve had in their personal working experience after they spent their initial entry in games within small multimedia studios with small creative teams. “We even ended up rolling into IT for three to four years,” De Jong recalls. “We had a company phone, car and laptop, the works. The environment simply didn’t fit us.”
With founding Codelgue, De Jong and Sibrandi strived to have a fun workplace where creative people would feel at home. The original Rocket Riot, published by THQ, sadly did not receive a very big push by the publisher itself. As a result, De Jong and his team decided to connect with the game press themselves. With success. Rocket Riot ended up attaining critical acclaim, a solid 8.0 on Metacritic and very positive reviews by media outlets such as IGN, Gamespot and Giant Bomb.
“We tried to connect with the game press ourselves, arranged a lot of reviews and competitions,” De Jong recalls. “We were lucky to also receive great reviews.”
The experience with THQ have given De Jong a solid idea of how he would do it himself. In this day and age, a direct connection with the consumer isn’t that hard to attain anymore, even for a relatively small studio as Codeglue. The consideration to self-publish has culminated into the development of Ibb and Obb. “We operate very openly and show our audience the first prototypes on Facebook, trying to get people to follow us,” De Jong says. “With Rocket Riot, we were relatively late with this and tried to still hype the game after launch.”
Self-publishing
De Jong and his colleagues recently moved to a cozy new office in the center of Rotterdam.
Pitching the original prototype for Rocket Riot and building up a relationship with Microsoft in the first place wasn’t a typical walk in the park for the studio. Luckily, the deal with THQ allowed Codeglue to keep the rights to the IP and resulted in Rocket Riot coming to Windows 7 Mobile and an upcoming version for the iPad.
“We walked around with the prototype for almost a year.”
“We walked around with the prototype for almost a year,” De Jong admits. It took us quite some time. Do visit the big international events like the GDC, E3 and Gamescom. Approach the publishers. That’s where you get the most business, especially if you want to work with a major publisher.”
De Jong simply reached out to different publishers by e-mail, with success. “It always works,” he says. “There’s always someone at an event looking for a new project. It’s never impossible to end up with the right person there.”
With the desire to take over publishing themselves, the need for Codeglue to find the necessary funds and internal structure to facilitate that is higher than ever. De Jong hopes that the sales on Playstation Home will fuel that desire significantly.
Codeglue is currently working on Ibb & Obb for PSN in collaboration with Sparpweed.
Image credits: Else Kramer assigned by the Rotterdam Media Commission
