Warning: filemtime(): stat failed for /nfs/c08/h03/mnt/115263/domains/backabit.com/html/wp-contenthttps://backabit.com/wp-content/themes/backabit/less/style.less in /nfs/c08/h03/mnt/115263/domains/backabit.com/html/wp-content/plugins/wp-less/lib/Stylesheet.class.php on line 196
, Page 2

Author Archives: Tim, Page 2

Thank You Friends For One Million Wonderful Games of Ramps

I just checked our analytics this morning, and noticed that we passed the one millionth game played in just under three months of being on the App Store. We have now surpassed the number of times the original Ramps for Flash was played in its three years of life on the web, and that version was free!

Thank you friends for playing our game, for continuing to play it, and for loving it as much as we do.

We have so much more in store for you this year, and can’t wait to share more!

Marketing Ourselves Into the App Store Top Ten

top ten app storeToday marks the two month point since Ramps was released on the App Store. In that time, we’ve had a crazy ride that neither Tyler or I could have expected, including five consecutive weeks of prominent App Store features. One of those weeks, Aplle gave us an iPhone Game of the Week mega-feature that catapulted Ramps into the US overall top ten.

Ramps also saw favorable press coverage from industry-leading outlets such as IGN, Appolicious, Download Squad and Slide to Play. We’ve been completely humbled and awestruck by the response, particularly because it’s the first game we’ve released (it’s actually the first game I’ve personally developed, too!).

We’ve had a lot of interest from our peers about how we managed to pull this off and what sales have been like, so I wanted to write a follow-up to share some stats and lessons learned from the process. Hopefully it will help other aspiring game developers achieve similar results.

Sales recap

A picture’s worth a thousand words, right? Tyler and I don’t want to share specific revenue results publicly, but hopefully this chart from Flurry will give you a good idea of how we did. To give you a frame of reference, a Saturday at #8 in the App Store is worth about 10,000 units. I’ll let you do the math from there.

We’re pleasantly surprised by how well we’ve retained our users. People play Ramps again and again, which keeps us motivated as we develop our first major content update. As of today, Ramps has been played more than 850,000 times.

What went well (and what didn’t)

Obviously, Apple’s feature was our single biggest success contributor, but it took a ton of work for us to get there. I’ll focus on our marketing tactics below, starting with the most important:

Polish, polish, polish!

The best marketing you can do for a product is to make it as good as possible. Amazing products practically sell themselves.

We didn’t just settle for things looking and working right, but things had to feel perfect, too. As you can see from Tyler’s most recent post, which is a great example of how we went through several iterations of choices before settling on one, we wanted to make sure we only added what was right for the game, and that we executed flawlessly.

Early on, I started realizing how much work it took from a development perspective to bring some of Tyler’s visual ideas to life. I quickly adopted a “Why the heck not?” mantra. Tyler devised some wild ideas, often mentioning in his descriptions that he would totally understand if the effort level was too insane to justify.

The title screen (with world selection and the credits) was one such example. Tyler had this awesome idea that your initial encounter with the game would be this seamless experience where menu transitions were just camera movements up and down. It took more than 60 hours and 2700 lines of code to bring it to life, but our title screen experience became unique and interesting, so it was totally worth it.

Additionally, part of the polish is also in paying attention to details so tiny, that people might not even notice.

  • Tyler really wanted to see parallax scrolling somewhere in the game, and we added it into the title experience.
  • We change out the backgrounds and include scrolling stars when you’re playing at night (this pops up in other parts of the game, too).
  • The blue ball’s eyes follow the world tiles as you swipe left to right to select a world.
  • The world tiles scale dynamically based on how far you scroll them.
  • You can actually swipe to move up and down throughout the title experience.
  • The entire screen actually bounces when you move down in the experience.
  • Our ball avatars in the credits move and animate randomly, like they have a little life of their own.
  • The Game Center icon is custom-designed to actually look like it was made just for our game.

world select

These are just a few examples from a single scene. The entire game is chock full of little details we would get excited about and add unquestioningly, because we knew it would make the experience a tiny bit better. I believe that’s why we were noticed. We made this game with love, like artisan experience creators, because we couldn’t settle for shipping a game that would be anything less than something we would be proud of for years to come.

Media coverage went well, but not at first

We shipped Ramps right before Christmas, and had enthusiastic support from our family and friends, many of whom were also beta testers. Our instinct was that shipping before Christmas would give us a sales spike. We were right about that (though it was small), but it also meant that every outlet was buried in coverage of new releases from the major players in iOS gaming (EA, Gameloft, etc.).

Rick Turoczy of Silicon Florist, a local Portland blog covering the startup scene here, was gracious enough to cover us and nudge us in the right direction in terms of media momentum. We’re both incredibly grateful for what Rick does for the tech community here, and that he persevered to actually play through Ramps and review it even while he was sick with the flu. Hopefully we kept him entertained while he recovered.

With other outlets, we made a list of about 50 media websites that we felt were a good fit in terms of their voice and content, and had a reasonable reach to help spread the word about our game.

I hate press releases. I think they’re impersonal and don’t enable you to really tell your story.

Based on this wild-hair belief, I somehow convinced Tyler that we should carefully craft a pitch e-mail describing who we are, that we’re scrappy, that we love what we’re doing, and that our first game Ramps is super awesome. I wrote the first draft, and Tyler edited it (he’s an amazing writer, by the way). The mail ended up being pretty long, but some of the writers we heard back from commented on how much they appreciated the coolness of our story. We included treated screenshots, our app icon, and a link to our promotional video.

Circulating the release didn’t go as smoothly as we hoped. I was using a Gmail plugin that allowed me queue all of the emails, sending them at the precise moment we launched. Tyler and I both have day jobs, and it’s generally a good idea to launch a product on a weekday (we chose Tuesday), because it fits in better with the weekly press news cycle. We needed to have a way to send out 50 emails while we were at our day jobs. This plugin worked well (I tested it first, I swear!), with the exception that it sent between three to eight copies of the e-mail to about 12 of the outlets! I was pretty heartbroken that I had just sabotaged our chances of getting any coverage. Fortunately, Tyler had a great idea spur of the moment (on a pivot—more on pivoting later) that we should quickly send a brief mail to the outlets apologizing for our mishap.

It took a while, but the reviews started rolling in—even from some of the sites I accidentally spammed!

One of my favorite stories in all of this is that Tyler wrote a special pitch to Download Squad, as they covered his original game back in 2007. The original review was mixed, but it was great to see them cover Ramps with glowing acclaim after we addressed every critical comment they had made years earlier.

Having a $0 marketing budget went well

I’ve never had any success paying for advertising or other forms of marketing on any of my previous side projects. If you’re smart and resourceful enough to create a mobile game, then you should be able to market your product in the social era for cheap, maybe even nothing.

We didn’t invest any capital into marketing, and instead opted to be resourceful. Tyler built this blog, and our website, as he has killer web development chops. He created a lot of additional marketing collateral to support our social effort so that we’d have a branded Twitter presence.

I created our promotional video with screen capture software and iMovie. I spent time lurking and contributing to the Touch Arcade developer forums reading posts like these to learn from the marketing successes of others. It was there I identified an opportunity for us to participate in the New Year’s App Blowout, an annual sale organized by indie developers to get under-appreciated titles more exposure.

Tyler and I have different strengths, and we both found and executed on our marketing niche. I feel fortunate that I’m lucky enough to be working with someone who greatly complements the gaps in my skill set.

As many others before me have stated, your best shot at success is getting noticed by Apple. Your best shot at getting noticed by Apple is through the press. Do your best to make yourself interesting, and the press will write about you.

Our pricing strategy went pretty well

We shipped Ramps at $2.99, and we got some criticism for it. Mobile app consumers aren’t too thrilled about paying this much for casual titles, with the exception of premium titles from big-name shops. We read about the Canabalt story, and how they took a risk and stood-up to the race-to-the-bottom pricing of iOS gaming, and decided to take our own shot at higher pricing. Ramps has a lot of content, and while early sales were promising, we weren’t too thrilled with what reviewers were saying.

After our Apple features, we dropped to $.99 where we stayed for several weeks to ride the App Store ranking wave. We’ve since raised our price to $1.99, and sales have continued their inevitable decline at roughly the same rate as they had at the $.99 price point. I think $1.99 for our game is something customers can grok a lot more than $2.99 for a casual title because they’re getting an experience with more content than many quick, casual time wasters.

Loose planning, measuring, and pivoting went great!

I was blown away with our ability to make quick-twitch marketing decisions based on data. We use a number of tools for monitoring coverage and getting alerts, monitoring social channels, as well as app utilization, sales and ranking analytics. Some of our favorites include Flurry, App Annie, MajikRank and appFigures.

Tyler is currently making me read Rework, and my favorite takeaway from that book so far is to avoid overplanning. You can’t anticipate what is going to happen with your product or a market, all you can do is prepare the best you can to pivot in the right direction when change and adversity happens.

Our first release received some negative reviews from users who had crashing issues. After some research, we discovered it was from players on older devices who didn’t have enough memory available. In order to pivot, we improved the issues and also added a prompt to periodically encourage players to rate the app. The result was our following release received more favorable user reviews, and a significantly lower percentage of them were negative. This really helped us, as having positive user reviews helps improve your app’s perception, which in turn drives more sales.

For next time

We have a wicked-awesome roadmap planned for Ramps, but eventually, we’d love to create another title. The next time around, I think we should start the marketing process sooner. This seems to be a common lesson-learned amongst indie game devs, as marketing is often the most overlooked phase in the process.

Being more active in the indie game community, and approaching the development process in a public forum gives you the best shot for organic exposure. Doing this gets gamers excited about the work you’re producing, and gives them the ability to give you feedback on development as it’s progressing.

This was a major opportunity we missed this time around, and while things worked out great for us anyway, if we want to repeat our success, we’re going to need to explore more marketing channels.

Overall, we couldn’t be more stoked about how Ramps has turned out. Tyler and I are both excited to be continuing to push forward with our continued plans for Ramps, and are looking forward to sharing much more of our progress this time around.

IGN iPhone Game of the Day

We are absolutely thrilled! IGN, quite possibly the largest game media property on the web, not only reviewed our casual indie title today, but they also sent out this e-mail to their subscribers naming Ramps their iPhone Game of the Day!

As a longtime reader of their website, I couldn’t be more excited and honored for this selection. Tyler and I are also incredibly grateful and humbled for their favorable review of our little game!

IGN iPhone Game of the Day

Three Days Into Ramps

Someday soon we will share the story of how Ramps for iOS came to be. If you work with Tyler and I at Waggener Edstrom, you’ll likely get a taste of this story sooner than others. For those loyal faithful of you who enjoy our game and our blog, you’ll now get a look at what Ramps looked like after just three days of development.

After Tyler and I first discussed the project, Tyler sent me some art assets he had been saving for a rainy day. Sadly, the right day came without rain and in early August 2010, and rather than go out and play in the sunshine, I found myself pursuing a new addiction: touch gaming.

In our early development days, I was experimenting on both iPhone and iPad with the game engine. Seeing as Tyler and I both love our iPads dearly, there is a great chance we’ll venture back to that device family at some point. You’ll notice that even at this very early juncture, we already had functionality in-place to let you move and rotate ramps, and spawn balls. It just goes to show that the real work is in the details — we spent a tremendous amount of time on polish, creating beautiful menus, animations, and transitions, and fixing bugs from our beta.

Please pardon the jerky camera, as this was originally filmed to show Tyler what I was up to. Also: major brownie points to the first gamer to guess what game my wife Erika is playing while I worked on this. Your hint: listen closely to the background music!

File → New Startup

We’ve put a lot into Ramps, and it shows. Our contributions have exceeded 850 hours of work over a duration of 18 weeks. Comprised of 347 design assets and 43,284 lines of code, we wanted to make our first game the absolute best experience possible and neither of us were willing to compromise on much (in fact, we accomplished nearly everything we set out to do!) Tyler and I have both participated in collaborations in the past, some successful and some that haven’t quite got off the ground. So what made Ramps different? Naturally, we put our heart into it and were incredibly pumped to make it happen, but doesn’t every collaboration start out that way?

In my opinion, the biggest contributor to us being able to ship Ramps (which is easily the biggest side-project-turned-Company I’ve ever been apart of) was our investment and buy-in to our process. Though our process developed organically, in hindsight, it wasn’t a pre-conceived effort. Tyler and I have both worked in the tech industry for a long time, and I gravitated towards an agile methodology which is something I’ve grown accustomed to working with during product development for my daytime employer.

filenewstartup

Because we were so focused on the product, we never really sat down face-to-face and said, “Okay, let’s put a process in-place and hold each other accountable to it.” I’ve never worked for a full-fledged startup (until now!), but I’d like to think we adopted an approach that many other tech startups take. What worked great for us was to adapt components of a process as they become necessary.

Ramps started out as more of a feasibility exploration and evolved organically. We never really said, “Hey, let’s go make this game!” Tyler and I had chatted about doing a port of his original Flash game, and I spent some time exploring (see also: dinking around) with cocos2d, which is a popular open-source 2D iOS game development platform, and box2d, an immensely popular, open-source, cross-platform physics engine.

Tyler mentioned to me recently that at one point our work, “…stopped existing as merely a tech demo and really became a game.” Once we reached that epiphany, everything started to kick into high-gear. We started gaining momentum, and with that we utilized a number of tools to help us manage the gigantic flow of tasks, bugs, assets and various forms of communication that flew fast and furiously. In hindsight (and foresight.. there’s still a lot more of Ramps left to build!), we adopted a light-weight process that I believe was a hybrid of Scrum and Lean.

The most prominent elements of Scrum we used were daily communication and a consistent feedback loop. Tyler and I chatted online and exchanged e-mails almost every day for the last five months. At the end of each day, we’d give our daily update via e-mail. We’d provide each other code or assets as they were completed, and give each other feedback as soon as we could. If we ran into roadblocks, we’d resolve them immediately by making a joint decision.

Most of our process really embodied the seven principles of Lean, a flavor of Agile.

Eliminate Waste

Don’t make stuff for the sake of making it! From a development perspective, I tried to only create layers of abstraction if I knew for a fact that they would be repeated. As I discovered patterns and found myself in a repetitive rut, I’d re-factor code. Early on, I actually spent an entire weekend (20+ hours) just re-factoring because I saw a more efficient way of working with box2d that I knew we would benefit from long-term. It was nice to really get this right, though because this is the first game I’ve ever developed, I also made a lot of mistakes that I can learn from the next time I use cocos2d and box2d for a new game.

Other elements of eliminating waste we used included quick-turnaround communication and maintaining clear requirements. I felt our successes here pointed back to establishing momentum and being engaged every day. Since we were both thinking and talking about Ramps all the time, this came pretty naturally for us. If we weren’t regularly wired-in, it could have hurt the project.

Amplify Learning

To me, this principle just meant that we needed to always having working code. I fixed bugs early and often, and always had something demo-ready on my iPhone. I treated crashes as show-stoppers. I would literally stop everything I was doing and focus on fixing a crash once it was discovered. This way, Tyler and I were both always playing Ramps, and if something wasn’t a good fit, we could change it immediately to improve the experience.

Decide as Late as Possible

This is the principle of lean I agree with the least, as decisions often go hand-in-hand with trial and error. We were very organized on when we made decisions, in that we’d start the process of making a decision while anticipating how much time we would need to make that decision. For example, we started engaging with Essa, who wrote the super killer awesome score for Ramps, about two months before we launched. This worked out great, as it gave him plenty of time to be creative and produce, but it also gave us enough time to provide feedback and iterate.

Deliver as fast as possible

Really, every night was a delivery for us. We set a target date early-on (Christmas), and went for it (and we made it!!). Instead of worrying about the big picture and over-managing the project, we tackled the project in milestones. I would work on developing a feature, a world, or a set of physics objects. Tyler would focus on designing a character or a scene. As Tyler completed designs, I would implement them. We added a lower-level of project management about six-weeks before launch to make sure we were prioritizing work items in order to hit our target date. We also made sure that we gave ourselves enough time between each milestone (alpha, beta, app submission, etc). Often, our communication mechanism for project management was informal e-mails, but we’d tweak target dates on-the-fly and we both always knew where the project was at.

Empower the Team

I am by no means a designer, but I know when something looks cool and when something looks off. Likewise, Tyler is not a Developer (with a capital D, as he puts it), but he has an eye for what feels right in a game and has plenty of technical expertise to think like a (D)eveloper. That said, in our process there were no stupid questions, no bad feedback, and no impossible ideas (some of them are just really hard/time consuming!). We both own this product, and while we had some definite high and low points, the ownership of making it a great product was on both of us. Keeping cool and remaining optimistic was essential!

Build Integrity In

At first glance, this might seem like Lean is referring to ethical integrity, but really it means the perceived integrity of the system by the customer. As long as the player has a good experience, and that all of the moving parts move well together, then the product has good integrity. To us, this meant that we were putting the customer first and that the experience they interact with is, “solid.” It meant that we wanted you to get lost playing the game, and minimize the number of times you say, “Hmm.. that seems weird.” Seeing as I’m writing this two days before we ship 1.0 (edit: Yes, I spent an insane amount of time on this post), I’m naturally a little nervous about this. But, as Matt Mullenweg says, “If you’re not embarrassed when you ship your first version you waited too long.”

We did a week of beta testing with about 12 people, and fixed over 50 “weird” things people observed (and a couple of show-stoppers), so we feel pretty good about this one. We’ll be fixing more “weird” things as we keep discovering them, as well.

See the whole

Like the Empower the Team principle, this one is really about owning the product. I don’t usually like to sub-contract work unless I have to, and when I do, I’m the most receptive to people that are extremely enthusiastic. We only subcontracted one part of Ramps (the music), and I don’t think we could have found a better fit with Essa. We found him at 8bc.org (Eight-bit Collective), and we were both immediately excited by his work. He only had two tracks posted on the site, but his musical style reminded us both of a classic 16-bit game we both grew up loving.

Ultimately, relationships and the team dynamic truly shape a product. For Tyler and I, and our work with Essa, we were able to consistently portray the experience we wanted to create, and I think that enabled each of us to make key decisions independently and then solicit feedback rather than waiting for a group decision before executing. Maybe that’s why so many people compare Ramps to Sonic the Hedgehog. All three of us grew up loving those games.

Communication is a huge bottleneck for any project, and while we still needed a ton of it for Ramps (and we handled it well), being engaged and iterating often helped strengthen our individual intuition to help us do what’s right for the product.