ContributionsGame Development

Post-Mortem: Digital Dreams’ Cowbeam (iOS)

January 10, 2013 — by Mariia Lototska


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.

Digital Dreams from left to right: Thijmen Bink, Roy van de Mortel, Geert Nellen
Digital Dreams from left to right: Thijmen Bink, Roy van de Mortel, Geert Nellen

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 naively started development of Project S because we basically thought everything was settled and done

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 arrange, dispose and organize-system that resulted from the left-over code of Project S
The arrange, dispose and organize-system that resulted from the left-over code of Project S

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

We had to start thinking more about our future and the monetization of our projects.

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.

Development of Cowbeam, after switching from Actionscript to Unity3D
Development of Cowbeam, after switching from Actionscript to Unity3D

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.

On the left: The Flash version of Cowbeam; on the right: The iOS version of Cowbeam
On the left: The Flash version of Cowbeam; on the right: The iOS version of Cowbeam

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

It was hard to think about killing our darling

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.

Our primary goal with Cowbeam was to master Unity3D and we succeeded at that

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.

Development tips

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.

BusinessExclusive Interviews

D’Accord Music Software’s Americo Amorim on playing the music game, being a startup, and the importance of being lucky

January 6, 2011 — by Gamesauce Staff


Great games can come from the most unexpected corners of the globe, sometimes years in the making before finding their rhythm. Brazil’s D’Accord Music Software started ten years ago. “We were doing music education software,” recalls chief executive Americo Amorim. The company made mostly PC-based downloadable products, which were very successful in schools.

By 2007, he says, “We got bored with only doing educational stuff.” So, the company created a division called MusiGames. It started with ten people, hired more along the way, and has reached thirty people so far. Amorim reports, with a touch of pride, that almost all of his company’s current development efforts are in games.

Legacy of games

The original idea for Drum Challenge came from one of the D'Accord's own software engineers.

“In Brazil, we had a lot of experience with SEGA consoles,” says Amorim. “But our team’s background is PC development and mobile development studios, like traditional J2ME development.”

Before making a game together, they started with research, attending developer conferences, and meeting publishers. “We weren’t sure what platform we were going to work on,” says Amorim. “Of course, the team wanted to do Wii games, Xbox games, PlayStation games. But it didn’t really make sense for a start-up company at that time to do those kind of things,” he says.

They found the smartphone market to be open in 2008, and there were even fewer music games on the market.

Proof of concept

D’Accord’s first game was Drums Challenge for the iPhone. When they released it in June of 2009, it managed to sell 500 copies in the first three weeks. “With the public we drove to the game,” explains Amorim. “And what really happened was that Apple started promoting it. So when Apple started promoting it, the sales skyrocketed.”

“What our experience says, what really matters, is Apple promoting your iPhone game.”

The initial price was $2.99, and is $0.99 today. “What our experience says, what really matters, is Apple promoting your iPhone game,” Amorim reveals. “If they promote,” he laughs, “you’re successful.”

“And, of course, they don’t promote crappy stuff.” Amorim says that Apple doesn’t have room to promote everything that is great.

“On our side, we’re focusing more and more on the quality.” Last year, the company produced five games to create a portfolio. “For this year, specifically, we’re focused more on quality. So we’re doing only two games, and we’ve been developing them for six months.”

“Right now, we are focusing on smartphones: iPhone, iPad, Android, Symbian, and Facebook.” says Amorim. When asked about budget, he replies: “It’s usually $50,000 to do a nice music game.”

For MusiGames, both iPhone and Android development are done with the same budget. “That’s where we are improving,” Amorim points out. “It’s not a very high budget, but it’s a complicated budget for a small developer.”

Key learnings

Released right after the iPad launch, Drums Challenge became the bestselling iPad music game in its release month.

Some games, Amorim’s team promotes on their own. On others, they’ve tested distributors like Chillingo and I-play. “Some of those guys have more access to Apple, and that makes it easier for us. But, of course, they get a share of the game. So it’s really a decision that depends on the game we are talking about.”

The company decided to aim for a global audience, because the game market in Brazil is still growing. Amorim reports that the marketing is “starting to happen right now. Two years ago, it didn’t make sense to do smartphone games in Brazil.”

Today, they’re developing a title for Google-owned social-network Orkut. “Orkut is the Facebook of Brazil,” Amorim explains, adding, “Our first experience in Brazil will be this Orkut game. I really have high hopes for it.”

Playing social

iMusicPuzzle HD
The idea for iMusicPuzzle came from one of the company's artists.

While social games have been a strong trend in recent years, Amorim says: “We are really trying to focus on music games — because our expertise is in this. This social game is really musical,” he adds, about their upcoming product.

It could mark the first cross between the music genre, and a game for the social network platform.

When asked what a music game on a social platform would look like, Amorim smiles. “You’ll see in a couple months.” And that raises the question of whether it’s even possible. “Yeah, it is. The challenge is to get the friend’s interactions. You have to interact with the music, and you have to interact with friends.”

Amorim considers the question of whether music is universal on a global scale. “It really depends on the songs that you have in the game. So as we try to do games that you can play with any song: that makes them universal. So if you have ten-thousand songs in your library, you can play with them: that’s great.”

Market growth

Something they’re investing in more and more is letting the user play with their own songs. It saves the hassles of licensing, and the company had developed chord-recognition tech from their education software days. “We have a very good technology and we started applying this to games,” says Amorim.

This year, the company managed to get some VC funding. It allowed them to grow their development capabilities, and as Amorim adds: “We grew our marketing team, which we didn’t have before the VC guys came in.”

“We want to be known as the music games studio, and the Brazilian leader.”

Amorim says the strategy for MusiGames is to position themselves as “the big independent music game studio.” Beyond that, they want to have a strong position in Brazil. Amorim reveals: “We’re seeing the market grow a lot there.”

Which is why they’re investing in that growth. “We want to be known as the music games studio, and the Brazilian leader.”

Sound advice

The MusiGames team celebrating the company's anniversary with some fresh t-shirts
The MusiGames team celebrating the company's anniversary with some freshly printed t-shirts

And when it comes to what other developers can do to achieve success, Amorim has a few pieces of advice: follow game-business news, follow the market, and try something different with your game.

MusiGames’ best successes weren’t radically different, he says, but all “had something really unique.” And having a specialization is a great way to keep from losing good ideas along the way.

“What’s our guideline? If it’s a music game, we’re interested,” Amorim says. “And if it’s a platform we already know how to develop for, we can even study the idea. If the idea’s really good, we may do it. But, on the other side, we try to keep the focus.”

MusiGames is currently working on a music game for the Orkut social-network.