Jonathan Beebe

Mobile app and game developer from California.

Showing 5 posts tagged game development

Skyrocketing Your Game’s Visibility

Whether you’re developing games for iOS, Android, or some other platform, it’s going to be pretty easy for your app to get lost in the vast sea that grows at an alarming rate each and every day.

If you don’t want your app to drown, however, you’re going to have to take an active role in getting the word out. Nobody believes in your game better than you do—so the difference between nobody knowing about your game, and everybody knowing about it depends on the amount of effort you put into it not only during development (which is equally as important, obviously), but the effort you put into it afterwards as well.

A common scenario is that a developer pours their heart and soul (maybe?) into creating their masterpiece, and then once it’s finished, it’s “wait and see” time… almost like a break to take a step back and see how it performs out in the wild.

Unfortunately, hoping that the initial day of visibility is enough to make your game go viral is about as dependable as planning to win the lottery. Developing your game—I hate to say it—is only the beginning (which is why a high quality rapid development SDK such as Corona is essential, in my opinion).

After releasing five games to the iOS app store, I’ve made my share of mistakes, but I’ve learned from each and every one of them. I documented what works, what doesn’t, what needs improvement, what needs to be done, and what needs to be tried with every single one of my launches from here on out.

What I’m going to share with you is my personal plan-of-attack for our next release (and I’ll be sure to let you know how it goes once the game does get released). The following is exactly what I’m going to do pre-launch, and post-launch to help increase my chances of having the next successful game.

Beta Testing via TestFlight

I’ve personally suffered from a buggy release before, where I had to scramble to fix bugs and other usability issues as soon as the game is launched, and trust me, that’s the last thing you want to be doing on the “big” day.

For my next release, I plan on gathering a small handful of people and using TestFlight (a great, great service) to administer beta testing before I’m ready to submit the game for approval. I’ll have beta testers watch for bugs, and I’ll also monitor any usability suggestions to see if they will actually benefit the game (and not just change things for the sake of someone else’s personal vision for the game) and then adjust accordingly.

Then, once the first beta testing “phase” is over, I’ll gather another small handful of people to see if they catch anything that the first group didn’t. I’m pretty impatient, especially when it comes to releasing a completed game (especially since you have to wait out a grueling approval period), but I’ve learned that testing is of utmost importance.

You don’t want your beta testers to be the first ones who leave your 1 or 2-star ratings in iTunes. Unfortunately, I learned that one the hard way :-(

Social Networking Services

Prior to doing any kind of promotion, I’ll be setting up a Twitter account and a Facebook page dedicated solely to this next release. This will give me a way to track user interest before the game is even launched (followers), and also provide a more focused platform for delivering news, announcements, requests, etc.

Pre-Launch (Coming Soon) Trailer

Either mid-way through development, or once the game has been submitted to the App Store for approval, I plan on creating a short “Coming Soon” trailer and uploading it via YouTube. This trailer will be used as the basis of most of my promotional efforts and will help build some initial “buzz” before the game is actually released.

I’m not very experienced in creating trailers, but it doesn’t have to be hollywood quality. It just needs to be short, entertaining, and show off the best of what your game has to offer. The trailer I plan on creating is going to be simple, but I think it’ll be effective in getting the viewer to want to play the game and share the trailer with others.

Here’s a short summary of how I plan on having the video play out:

  • Trailer starts with the Beebe Games logo.

  • Small animation on the logo, directly relating to the game (I won’t spoil it just yet).

  • Black screen, game logo pops up (very bold).

  • The next screen is just a few words describing a main feature (“XX Levels”), and then the next screen following that will do the same (all this happening just seconds apart).

  • The next screen will be a couple seconds of gameplay footage (not enough to let them know what’s going on, but just enough to peak their interest). The screen will flip one-two times showing more gameplay footage.

  • More features, more gameplay footage. That whole process will repeat a couple of times until…

  • Black screen shows: “Coming April 2011” (or projected month of approval), the Twitter/Facebook links, and of course a link to the Beebe Games website. A short animation (continuing from the initial intro-animation) also plays and the trailer ends there.

Once the game is released, I’ll modify the trailer (possibly include more content) but change the “Coming Soon” to “Now Available” so I can still use it for promotional purposes post-launch.

All of the above can be done relatively easily if you have a few Flash skills (or are well versed in manipulating Corona transitions), have some kind of screen recording software, and can use iMovie to cut and splice things up (and publish, of course).

Word of Mouth

While I’m waiting for the game to be approved (and also once it is finally approved), I’m going to be blogging about the game, posting to the Facebook/Twitter pages, starting new threads at the appropriate forums (not spamming, notice how I said appropriate), participating in existing threads (while a link to the trailer sits in my signature), and sharing the trailer in as many places as I can.

This is your chance to go crazy, and be evangelical about your upcoming game… just don’t participate in SPAM.

Press Release on Launch Day

Before launch day, I’ll have written up a press release that I plan on distributing on the day of launch. You can either hire someone to do this for a fee, or if you’re a decent writer you can do it yourself (there are plenty of guides online that can help you with the format and content).

Distribution will be handled through a service called prMac.com, which I haven’t personally used, but I’ve heard good things about. It’s very affordable too so I hardly consider it a risk. If you know of a better one for iOS games, please let me know.

Try Your Best to Get Reviews

This is hit or miss, because there is a vast amount of games being submitted and nearly every one of them is being sent out to reviewers. I’m going to try my best to get as many reviews of the game as possible once it’s released, and then just hope for the best from there (that’s really all you can do).

I’m not going to be too bummed out if my game doesn’t get many, and you shouldn’t be either… give it a good shot, but then move on. There’s plenty of other things to do.

OpenFeint Free Game of the Day

Since our games often use OpenFeint, I always take the opportunity to submit my games to their “Free Game of the Day” service. If you’re approved, you’ll set your game free for a day and it’ll be promoted on FreeGameOfTheDay.com, which will drive TONS (and I’m not kidding), TONS of downloads to your app.

You’ll also experience a nice sales boost (either during, via In-App Purchases) or after the promotion once you game is set back to paid (you’ll share the profits with OpenFeint for that day and for a small period of time after, but hey, they helped you out so why not?).

Not all games are approved (they are pretty strict, actually), but it’s worth a shot. I have high hopes that our next release will be featured on that site in the coming months after launch.

There’s other similar services that you should try to get featured on as well. Another great one that I’ve used is freeAppCalendar.com.

Monitor Feedback and Update!

Whether it’s via Email, your Facebook/Twitter, or even iTunes customer reviews, you should be monitoring the feedback on your game and start constructing your first update ASAP, because it could be weeks before the update is available for your customers to download.

Like I said, I’m not perfect, and not any one of our five games have applied ALL of the above, because all of that is an accumulation of knowledge I’ve gained from my current experience as an app developer.

However, you can bet our next release will apply each and every one of the things I mentioned above, and as a bare minimum, yours should too. That is, if you want others to know about your game!

If you don’t feel excited enough about your game, or don’t think it’s “good enough” to warrant that kind of energy and effort, then perhaps it’s time to go back to the drawing board and make sure your app has all the elements of a successful game before even thinking of making it more visible.

Good luck, and here’s to your next release :-)

This post is part of iDevBlogADay, a group of blogs by indie iPhone developers featuring two posts per day. You can subscribe to iDevBlogADay through RSS or follow the #iDevBlogADay hash tag or @idevblogaday on Twitter.

Mar 22, 2011

TexturePacker Review: Absolutely Essential Software

After releasing five games in the iOS App Store, it’s hard for me to imagine just how I got along without using Corona's built-in spritesheet support… that is, once I discovered TexturePacker by code’n’web.

When I worked on our original title, Doodle Dash (now Tilt Monster), I started coding the game with spritesheets, but I was running into some significant roadblocks (all of which are a result of Corona “Game Edition” being in alpha at that particular point in time):

  • Because the game didn’t have any levels and was on-going, after a random amount of time, the character’s sprite would stop animating and would get stuck on one of the frames. The only way to get the sprite animating again was to close out of the app and relaunch.

  • Actual creation of spritesheets was a tedious process, to say the least. On top of that, if any adjustments needed to be made to any of the frames, it added a whole new layer of complexity to the whole thing.

  • While there was external sprite-creation tools, Corona’s Sprite API (at the time) was very limited and didn’t support the formats and features that a lot of other tools incorporated into the spritesheets.

  • Implementation was a little confusing and still a little buggy at the time.

  • Once the iPhone 4 and iPod touch 4 came out, there was apparently no way to get spritesheets working with dynamic content scaling, and that was the deal-breaker for me (I hate the ‘blurry’ look of non-optimized games on 4th generation iOS devices).

Because of those issues, I decided to use a module called movieclip.lua for all of my animation needs because I felt, at the time, that it was really my only option because it could be modified to work with dynamic content scaling (for retina displays), and it wasn’t giving me the “freeze frame” issue I was experiencing with spritesheets.

Since then, all of the alpha-related issues above have been fixed and the Corona Sprite API has been vastly improved and expanded on (and is even compatible with retina displays now), but I was already used to using movieclips and everything seemed to be working fine so I just stuck with it.

Discovering TexturePacker

Recently, I was doing work for a client and they had a particular animation sequence where each frame took up a significant chunk of texture memory. It was bogging down the app and in many instances causing it to crash.

Someone had suggested I try using spritesheets, so that way only one image needs to load and the animation can be handled accordingly.

I was on an extremely tight schedule so I didn’t have time to create a spritesheet manually and also brush-up on the Corona Sprite API, so I asked about any recommended software that’ll help me with the process… and that’s when TexturePacker was brought to my attention.

I downloaded the Essential Version (free) and within minutes was able to create a spritesheet, export to Corona, and begin using it in my project! At that point, TexturePacker won some major points for me and I had planned on revisiting it after I completed that project.

That little experience alone got me more interested in switching to spritesheets for my own projects, but what really proved to me that spritesheets really are more superior than movieclips was that the suggestion to use spritesheets actually worked. We got the animation going and the project was able to move forward from there.

The Benefits of Using Spritesheets

I always knew that in theory, spritesheets are better than movieclips, but it wasn’t until I had done more research that I realized how they completely blow movieclips away:

  • Loading one image vs. many helps improve texture memory usage, and also speeds up your app by having to draw only one image vs. many.

  • Being able to “alias” similar image frames to be used in multiple animation sets helps to significantly reduce not only the file size of the spritesheet, but the amount of texture memory that is used while the app is running (more on this later).

  • Control the exact amount of time between each frame of animation (this is actually a limitation of movieclip.lua).

  • Creation of display objects that are associated with a spritesheet is much quicker (since no new image loads are actually taking place).

  • Eliminate a major memory leak (currently) associated with movieclip.lua by avoiding movieclip.lua altogether.

  • Probably more benefits that I haven’t thought of at the time of this writing.

However, even though there are a lot of benefits to using spritesheets over movieclips, there was still a major drawback to using spritesheets (for me anyway), and I mentioned it before:

Actual creation of spritesheets was a tedious process, to say the least. On top of that, if any adjustments needed to be made to any of the frames, it added a whole new layer of complexity to the whole thing.

And that’s where TexturePacker comes in.

Creating an actual spritesheet is as simple as importing your images into the app and clicking ‘Export’ … and while that would have been enough for me to use it, TexturePacker does so much more than just that. You can visit the product page for a list of features, but some of my favorite ones include:

  • The ability to import your images and have your spritesheet created instantly.

  • Option to use MaxRects algorithm to decrease the overall texture size of the spritesheet (as much as possible anyway).

  • Auto-aliasing. I mentioned this earlier, but it’s actually very complicated and time-consuming to implement. That is, unless you’re using TexturePacker, in which case it’s as simple as checking a box and exporting to Corona.

  • Autosizing, and the options on the left make the creation of spritesheets, exporting to Corona, and importing into your Corona project mostly effortless.

TexturePacker actually supports several platforms, but I only use Corona so that’s the only one I tested out during this review process.

TexturePacker + Spritesheets vs. Movieclips

I decided to run a little experiment to see the advantages of spritesheets vs. movieclips first-hand. The experiment consists of a simple app that displays a simple glowing star animation (looping indefinitely) in the middle of the screen.

One project uses movieclips, the other uses spritesheets (created with and exported out using TexturePacker).

The animation consists of 61 frames, so that’s 61 total images for the movieclip project and just one image for the spritesheet project.

For the experiment, I used the following code to keep track of Lua memory and texture memory for each app:

Runtime:addEventListener('enterFrame', function()
    -- watch for leaks
    print( "\nMemUsage: " .. collectgarbage("count") )

    local textMem = system.getInfo( "textureMemoryUsed" )
    print( "TexMem:   " .. textMem )

Because I used TexturePacker with the auto-alias setting turned on (and MaxRects algorithm), the exported spritesheet only consisted of 31 frames (that is awesome, considering the original animation called for 61 frames) and the dimensions came out to be 256x512.

So the results of the experiment:

Using movieclip.lua:

MemUsage: 99.8310546875 kb

TexMem: 3,997,696 bytes

Using TexturePacker + Spritesheets:

MemUsage: 83.2275390625 kb

TexMem: 524,288 bytes

So there you have it. First-hand proof that spritesheets are superior to movieclip animations in just about every way.

To put the results into a little better perspective, here are some percentages (in regards to that specific project):

  • movieclip.lua uses about 17% more memory than the same animation using spritesheets.

  • movieclip.lua uses about 87% more texture memory than the same animation using spritesheets.

Of course, your results will vary depending on your project and specific animations, but I’m confident that in any case, whether or not the percentages are the same as my test project, spritesheets will always outperform movieclips significantly.

But remember, it’s not just spritesheets.

I personally wouldn’t have the patience to manually code in things like aliasing, the MaxRects algorithm, or even just creating spritesheet images if it weren’t for software such as TexturePacker, which makes the whole process almost effortless.

If you create games and use the Corona SDK or any of the other supported platforms, then TexturePacker is not only recommended, but is absolutely essential in my opinion.

I recommend downloading the “Essential Version” for free to try it out, but I highly recommend upgrading to the Pro version if you plan on using spritesheets in your final production.

Link: TexturePacker by code’n’web

Mar 14, 2011

Tutorial: Path Finding in Corona ∞

A very nice tutorial that goes in-depth into a concept that’s very complicated (to me, anyway), but will surely come in handy for many games (the ideas are already popping into my head).

As a side note, the Tutorials+ websites are one’s that I consulted for various things in the past dealing with graphics design concepts, web design, etc. so it’s really nice to see Corona SDK tutorials showing up there.

More proof that Corona is really making headway in the mobile development arena.

Jan 6, 2011

Great Article on Indie Game Development ∞

My favorite part of the article, at the very end:

Create a portfolio of products. Any financial planner will tell you to create multiple streams of income. This industry is no different. Unless you are really lucky, one game will not bring you enough revenue to live. However, in a world with unlimited shelf space and a nearly unlimited customer base, your game can sell for a long time. Think about it, the number of shipped games compared to the potential number of players always rounds to zero. In effect, your game never ships! Marble Blast sells as many units today as it did the second month it shipped (we actually had a ship-in spike in sales), and that is without an update in a couple of years.

You need to keep ‘em coming. Every game brings you more opportunity, your company brand grows, your niche audience grows. Then, suddenly, you are making enough money that you are doing this full time. It IS your day job, and nobody can take it away from you. You own your IP, you own your code, you have a tight connection with your audience, and you can’t wait to go to work every single day. In fact, there is no such thing as a “day off” because this is what you do. It is you. And it feels good.

I believe Biffy and I are doing just that. We’re focusing our creativity, and keeping the games coming—we’re both bursting with ideas. I’m also devising different ways to market each of our titles behind the scenes, so things are definitely looking up for Beebe Games.

Sep 23, 2010

Tiny JavaScript Platform Game ∞

As a game programmer, I gotta admire something like this.

Sep 13, 2010

Copyright © 2013 Jonathan Beebe