HomeBearStudio is an indie team based in Breda, Netherlands. “Just two! You Miichi, the artist, does all the art. I’m in charge of everything else”, says project lead Joshua van Kuilenburg. Right now, this is a full-time job for them, and trying to keep it this way is one of reasons for their Kickstarter campaign. The debut game NAIRI is a cute point-and-click adventure where you follow Nairi, an abandoned upper-class girl, and a rugged scholar rat named Rex, as they uncover a dark mystery within the exotic oasis city of Shirin. In addition to adorable visuals and challenging puzzles, there’s a strong narrative. So the developers say it would appeal to both casual and hardcore players. Joshua sheds some more light on the development experience and some future steps.
Tweens are at the crossroads of crucial debates like F2P design versus the ethical monetization of children, kids’ online safety and more. Nine months ago, WildWorks launched a mobile version of Animal Jam, its web-based social game for tweens. Tune in to, CEO of Wildworks, Clark Stacey’s talk at Casual Connect Europe to find out what they learned about tween games and moving millions of players from web to mobile with an innovative but unproven business model. Some specific things to note from Clark’s talk include: “The top grossing games for kids are not in the kids category.”, “Parents are not friction in our payment flow, they are our customers.” and “Rule for IAP: Don’t sell disappointment.”
Rusty Lake is both the name of a studio and the eerie and surrealistic world Robin and Maarten have created. Their indie studio, based in Amsterdam, has been creating mysterious room escape and eerie adventure games since May 2015. With a total of 9 games launched on iOS, Android and web and 2 new games in development they try keep their community involved as much as possible.
SpeedRunners recently sprinted across the finish line to a full release after five years in development. It’s been a long process, but after a few years using Steam Green Light, awards from SXSW and Indie DB and various play-throughs by famous YouTubers, it’s now fully released for Steam, with an Xbox One release coming later.
We talked with Gert-Jan Stolk of DoubleDutch Games about SpeedRunners. They detail how publisher tinyBuild helped with the game’s aesthetic, how SpeedRunners eventually became an eSport and why indie developers should have a back up plan because their first game probably won’t be profitable.
Two veteran RTS players create a company to capture the excitement of hardcore RTS and bring it to a wider audience. A few weeks after their successful Steam release they look back at their original goals and discuss if it is possible to make a small-scope game in a genre that is dominated by elaborate and highly developed flagship titles. The studio’s executive producer Casper Bodewitz shares the experience.
So, you’ve just finished your casual game. Spent 6 months of development, setup social media channels, and gathered contacts. It’s going to be awesome! Your head is buzzing: acquisition, discoverability, monetization, retention rates. Yet, you’re stuck with a limited budget and the challenge to find and attract players. You need this to be a hit! Yup. I’ve been there. What if you could get valuable insight from players after only one day of development? Bart van den Berg, Co-founder and CEO of Blue Giraffe presented a postmortem at Casual Connect USA on how they use focus testing, play testing and bonded with players over prototypes. He advised,”Start playtesting from concept. Players love the connection, give great feedback and evangelize your game!”
Opening your indie game studio only one day a week may not be the most productive way to run things, but these days it comes with a clear advantage.
“You hear lot of talk about the ‘indie apocalypse.’ Well, we really don’t care about that, because we have a steady income,” says Peter Heil of Crimson Owl Studios. At this, co-worker Pascal van Beek laughs and adds: “I do care about it, because I do want to make a lot of money.”
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. Gamesauce recently featured a post-mortem on their first game Kids vs Goblins.
Early 2011, everyone at Stolen Couch Games was still in school developing our exam year project Kids vs Goblins. Jay van Hutten, a fellow year mate, was developing a game of his own called Ichi. It was a elegant puzzle game that utilized a one-button mechanic in a way that didn’t feel gimmicky. The goal of the game was to guide a ball past a number of rings on the screen. By touching the screen you rotate bumpers, which caused the ball to change in direction. You could also hold your finger down to draw a line, once the ball hit the line it would travel back in the direction it came from.
About a half year later we spoke to Jay at a congress were he was demoing his game. I (Eric) shared my interesting in redeveloping Ichi for multiple platforms and making it a really great commercial product. Jay loved the idea and the day we finished Kids vs Goblins we were working together to make a bigger and better version of Ichi.
No developers were harmed during the making of this game
Redeveloping a game is nothing new to us. Stolen Couch Games actually started in 2010 when we got an assignment from Zoë Mode to create a multiplayer version of their hit game Chime. The multiplayer demo we made eventually led Zoë Mode to develop Chime Super Deluxe, which featured some nice multiplayer modes. While the programmers were re-creating Ichi in Unity, Jay and I were designing new features to add to the game. Because the core of Ichi was so sound, it wasn’t hard to come up with dozens of new puzzle ideas to make the game better. The final product had teleporters, splitters to create multiple balls, objects that could disappear and a few more things. Nothing too fancy, but it all worked great. The best thing we added was the level editor that allowed players to create their own levels and share them online. Since then, 11,000 levels have been shared, quite a bit more than the 50 levels we originally included with the game. Ichi launched in June, after 3 months of development, which went mostly smoothly. The actual problems started right after we launched the game.
We knew that many people would consider Ichi as just another puzzle game, so we had to let people know how special the game really is. We spent about a week contacting the press about our game and we got a nice amount of coverage. But press alone won’t make your game a hit. If you read any guide on marketing for mobile games you always get to the point were the importance of getting a feature by Apple/Amazon/Google is expressed. We already got a feature on the Mac app store for our first game, but our published arranged that. We didn’t have a direct contact within Apple, so we had to come up with a way to contact them.
Luckily we had a few device IDs that belonged to Apple employees on our Testflight account. So we found out the matching email addresses and we send separate emails to every one of them. 2 of them, responsible for the iOS AppStore, loved the game and showed the game to the rest of the team. Our contact from the Mac AppStore was in love with the game. We Skyped for a few hours and everything was set.
We’ve seen developers doing no marketing at all for their games because they believe they’re games will sell themselves. This is mentality is wrong. Just look at the top grossing games on iOS. Almost all of them spend enormous amount of time and money on marketing. Only by spending time and money, will you actually earn money.
The launch of Ichi went great. We were selling thousands of units a day and those numbers were actually increasing the days after the launch. But than something went wrong. Suddenly the game would crash once it has launched. This had never happened in any of our tests before. Why did the game crash all of a sudden? It turned out that the firewall at our server provider, which hosted the user created levels, was malfunctioning. Since we had never encountered this before we weren’t prepared for this. As you can imagine we were pissed off, but the gamers were even more pissed off. The 1-star ratings were poring in, so we had to work quickly. Within a day we made a quick patch that made the game run again. We submitted it and Apple was kind enough to approve it in record time. But the harm was done. The sales momentum the game had was gone. Sales plummeted because of the bad reviews. Instead of getting thousands of sales at $4.99 a piece we were down to hundreds.
The lessons we learned from this is that you should be prepared for something you can’t predict or test. We expected our server to send just numbers to the game, instead it was sending lines of random code. For our next games we’re making sure that the game handles these rare cases the correct way. One day of extra development time is better than losing thousands of dollars in revenue.
We wanted to use in-app purchases in the game to earn some extra revenue post-launch. We were thinking of putting an in-app purchase on the level editor. So if you wanted to make your own levels you had to pay a dollar extra. But we opted against this because the editor would generate content for the game. Content is important so we couldn’t make the overall package weaker to earn some money. Instead we asked for an in-app purchase when the player played more than 10 user-created levels. We guessed that only 5% of the players might create a level and 70% would play user created levels. More people means more revenue. Unfortunately this tactic didn’t work.
We launched the game with 50 built-in levels and player could play 10 user created levels for free. At the end of 2012 only 300 people out of 400.000 bought the in app purchase, an insanely low percentage. Why did almost no-one buy the in app purchase? We think it’s because people were done with Ichi after playing 50 build in levels. Nobody is going to play 10.000 user created levels, let alone 100. Ichi’s retention wasn’t high enough.
Getting a lot of players, quickly
A few months after the release of Ichi sales were basically dead. We were making about $15 a day, which didn’t get us one step closer to world domination anytime soon. So we had to do something. Instead of letting our game die we looked at “free app of the day” deals. The first free app of the day deal we did was Free App A Day (FAAD). In one day Ichi was downloaded 130.000 times. We were blown away by this number. After this we contacted Amazon USA if they could feature us. They loved Ichi and featured it as their free app of the day. After that, Amazon Europe featured Ichi as well. AppEvent did the same, resulting in another 30.000 downloads from mostly the Netherlands
Free app of the day promotions are great. Unfortunately it is unlikely that your app will become super popular once the promotion is over. We earned only $80 from the days after the FAAD promotion. But still it is better than nothing. One good tactic might be to get a lot of downloads using these promotions and then switch to a freemium model. You will have hundreds of thousands of players who will generate revenue though ads and/or in app purchases.
Critically, Ichi is a great success. We’ve gotten wonderful reviews and players seem to love the game. But commercially the game hasn’t done that well. We barely broke even on the development costs. Most of the revenue came from the Mac version, mainly due to the feature by Apple. iOS came in second, revenue-wise. The Android, PC and Linux versions didn’t make more than a few hundred dollars. Despite all of this we feel that Ichi was worth our time, it was great developing it and we delivered something we’re proud of.
Ichi is available in the Apple AppStore. Stolen Couch Games is also working on third game, Castaway Paradise. Check out the trailer here. Vote for Castaway Paradise on Greenlight and support Stolen Couch Games.
Stolen Couch Games will also be sharing more in-depth insights and numbers on Ichi during their indie-postmortem talk during the Casual Connect Europe conference in Hamburg, Germany.
Digital Dreams is a Dutch indie game developer that designs and develops playful experiences. It was founded by programmer Thijmen Bink, level designer Roy van de Mortel and game designer Geert Nellen. Currently, Digital Dreams is focussing on creating games for the downloadable console market, However, this post-mortem is about Cowbeam: their first, and probably last, iOS game.
How everything got started
Let me start by saying that Cowbeam had virtually nothing to do with our former and current business strategy and portfolio. That is not meant as a disclaimer, but it is important to note because from the start this was an important factor in the decision-making processes during the production of Cowbeam. The idea came together due to very circumstantial and coincidental factors and it just seemed like a cool project to do at the time. In hindsight, this is not the way you want to make important decisions.
We started out doing an assignment for another company somewhere early 2011. We were developing a hidden object game with a twist for them, of which the design document and assets had already been handed over to us. Let’s call it Project S. Without actually signing any contract yet, we naively started development of Project S because we basically thought everything was settled and done.
Our team was quite excited about Project S, because not only were we struggling to make money at that point, this was not some lame technical job. We were developing an actual game that we were enthusiastic about, although it was not something we would normally do. That’s why it seemed wise to let one of our team members start with Project S in advance. He created a technical backbone, so production could start off swiftly once we signed the contract.
Two weeks later we received a call from the other company. We were told they had to cancel Project S because of budget cuts. Now we were left with a half-finished game with which we obviously could not do anything due to copyright infringements. We were disappointed. Not only had we already invested time and resources in this project, we planned around the development of Project S. So basically we had nothing else planned in the upcoming period.
So with nothing on our hands, we thought about what code we could potentially reuse to make it not a complete waste of our time. One of the things we already developed for Project S was a simple but elegant system to show the player new objects he/she needed to find, and along with it, a way to arrange, dispose and organize these new objects in the HUD. New items would come into play sliding from the right until they bumped into a previous item that was already in place. Whenever an item was completed it would disappear and all remaining items would slide and arrange themselves into place. This system eventually led to a gameplay mechanic that resulted in the current hint system of Cowbeam, located at the top of the screen.
The new concept was called Cowbeam. A quirky little casual puzzle game, which puts the player in the shoes of Hank, a cow-hoarding alien. The player had to navigate a small galaxy and collect hints, which eventually showed on which planet a cow could be found. When the player finds the cow, the level is completed and the cow is shown. A big hook of the game were the cows, which resembled the planet they lived on. For instance: if the planet is red, the cow is red; if the planet is close to the sun, the cow would wear sunglasses or a sombrero, etc. We thought this was fun to see, and it was interesting for the casual audience on iOS as well.
Bringing Cowbeam to life
After the new concept was pitched internally, it took quite a few weeks for the idea to sink in and the team to pick it up and start prototyping the concept in Flash. The first few weeks of development went swiftly and the game came along quite nicely. We started building Cowbeam in Actionscript 3 with the idea to release it as a free browser game and get our money from advertisements. However, after 2 months of development we had to start thinking more about our future and the monetization of our projects. This meant for us we wanted to start using Unity3D. Another reason to switch to Unity3D was that the game felt not quite right on Flash. Mainly because you needed to swipe through galaxies which just feels weird with a mouse. We thought about releasing a Flash and iOS version simultaneously for a while but a Flash version just seemed redundant somehow.
We threw away everything we had so far in Flash and started the Cowbeam project all over again with a new engine to build with, a new language to write it in, a new platform to build for and even some new interns to work with. This was the first big change we made to the initial concept. Luckily Unity 3D is an easy engine to learn but this shift really put us behind schedule for quite some weeks, if not months. As an indie studio our deadlines were never really set into stone. However, we did know that by the time we started developing Cowbeam in Unity, we had planned on having the game completed in Flash.
Obviously, moving the game to the iOS platform pretty much meant a complete redesign of the concept as well. This forced us to rethink the game and strip it down to its bare essentials, which is using hints to narrow down your choices of picking the right planet. It cost us a lot of time to figure out what the most fun aspect of the core mechanic was for the player, which was a direct result of making something unique. We could have prevented this if we paper prototyped more, or incorporated playtests from earlier on.
It didn’t really feel like the game was complete and fun to play yet, so we had to make more design changes. A lot of features were cut at this point to make the game fun and suitable for the casual iOS market. These cut features include:
– Resources that could be gathered from planets;
– A currency system to buy hints;
– Time based gameplay and score system;
– Selecting and writing off planets.
Also using Unity3D, which as the name suggests is essentially a 3D engine, meant a complete redo of the graphics as well. Other than the menus and such, Cowbeam was now a 3D game instead of 2D.
This shift to 3D actually turned out great for the game itself because we were now able to rotate around the planets. We experimented with this rotation in combination with a number of features. We found the most interesting use of 3D was hiding certain characteristics from the planet out of plain sight. 3D also gave us more space and freedom to make the planets features more visually appealing and identifying.
Mistakes made, lessons learned
The doubt we had with Cowbeam started to reflect on the team after a while in production: Is this game really going to be worth our time? Is it going to be fun enough? Is it even profitable in the end? Should we release this under our Digital Dreams brand when it’s this different from the stuff we want to make? Eventually it was a casual game, something completely different from the hardcore indie games we liked to make. The most important reasons to complete and release Cowbeam anyway were the amount of time we had already invested, everything we wanted to learn about Unity3D during the rest of development and wanting to have an actual finished game in the App Store. Especially the time we had already invested was a big factor in completing Cowbeam, it was hard to think about killing our darling.
Not playtesting enough fueled the doubt we had. Because we ran so far behind schedule, we somehow, without even really thinking about it, decided to scrap most of the playtesting and finish Cowbeam as soon as possible so we could start with our next project. In the end, we only playtested with visitors at our office and at the Festival of Games, a large Dutch event for people from the industry.
The doubt we had perhaps also lead to not properly marketing Cowbeam. All we really did was send out a pretty standard press release to our press network and hope they would pick it up. Of course we knew about the horror that is standing out and getting noticed on the App Store. But somehow we hoped it was going to be different for Cowbeam, because the concept was very unique and we believed it could stand out on itself. This wasn’t true. Sales were disappointing to say the least. On the other hand, it felt good to know we successfully published a game on the App Store ourselves and raised the bar for ourselves with the GUI and user-friendliness. Our primary goal with Cowbeam was to master Unity3D and we succeeded at that. Therefore we weren’t that disappointed about the sales in the end.
Just a few months ago we accidentally came across some little kids of around 12 years of age playing and really enjoying Cowbeam. This was actually the first time ever we saw anyone genuinely enjoying our game. Although it was a very cool moment it also brought us to the conclusion we should have seen this coming. We should have marketed and playtested for this target audience and maybe even design the game specifically for them.
Our biggest pitfall was, as usual as with us indies, the lack of marketing knowledge and execution. Get someone to do this for you, find a good partner or really plan ahead and take your time to do this properly yourselves.
We should have considered micro transactions, freemium or other means of monetization over a somewhat outdated simple pay once model which we ended up going with. The reason we went with this is mainly because of the extra programming and design effort it would take to implement micro transactions. We did try to weave it through the design when we were redesigning the game, but couldn’t really make it click when we did. Again, in hindsight, this time might have well been worth our effort.
We think the chances are very slim we’ll ever return and develop for the App Store. The market is too competitive for a small developer and the marketing power of big companies is killing for us. We believe the only way you can succeed on the App Store as a small developer is to have a really original and well-executed game and marketing plan. Even then, every investment is a very risky one.
Currently we shifted our focus to bigger projects for the downloadable console market, which was the goal of our company from the start. We worked on a prototype for a downloadable console game in the meantime and we are very happy we have an opportunity to work on that project now.
We hope you’ll pick up Cowbeam and let us know what you think!
Cowbeam is now available on Mac as well and has dropped in price in the App Store. Digital Dreams recently moved to a bigger office and is currently working on a new unannounced downloadable console project. They will also be sharing more in-depth insights on CowBeam during their indie-postmortem talk during the Casual Connect Europe conference in Hamburg, Germany.
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
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.
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,” 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
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.”
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
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.”
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
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.”
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
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.”
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,” 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.