Recently, a lot of csl users have been asking questions about the saving/loading features. So, we have decided to do an official writeup on the topic.

To get started, load the library into your code. (You can find it here)

require "crawlspaceLib"

For this demo, we are going to keep track of “points” using the data features of the crawl space library. Csl has a fuction called Defaults that sets everything up for us. We just need to pass in a table.

Defaults ( {

} )

On the first run, that code will set up everything we need to use saving and loading functionality. Now we need to load any existing data.

Load()

After that, we can use setVar() and getVar() to read and update the default data.

setVar( {'points', 100} )

Save()

That will increment “points” by 100 every time it is run. You can verify this by printing out the variable.

print(getVar('points'))

That is all there is to it. The crawl space library makes saving and loading data a breeze. Here is the code all together:

require "crawlspaceLib"

Defaults ( {

} )

Load()

setVar( {'points', 100} )

Save()

print(getVar('points'))

Let’s look at a more practical example. Here is a high score system made with csl:

require "crawlspaceLib"

Defaults ( {

} )

Load()

local gameStart = function()

end

local addPoints = function(points)

end

local gameOver = function()

end

-- sample gameplay

--

print("Points: "..getVar('points'))

print("High Score: "..getVar('highScore'))

Save()

Breaking this into pieces, first we set up the defaults and load existing data.

require "crawlspaceLib"

Defaults ( {

} )

Load()

Next we make a few functions to help us out:

We are going to track our current points with csl. addPoints() simply uses setVar() to add to the “points” value.

local addPoints = function(points)

end

We also need to be able to reset the points at the start of each game. The gameStart() function uses csl to set “points” back to 0. Now normally, setVar() will increment itself if it can. In this case, we need to pass true as a third parameter. This parameter tells setVar() to set the variable instead of adding to it.

local gameStart = function()

end

To wrap up the game, we should check if the current “points” are greater than “highScore”. If they are, we need to update with the new high score.

local gameOver = function()

end

Next we have a simple loop that demonstrates what a game might look like:

gameStart()

gameOver()

First we reset “points”. Next we randomly add to “points”. Finally, If there is new high score, we set it.

Now we can wrap it all up by saving our data and printing it out.

print("Points: "..getVar('points'))

print("High Score: "..getVar('highScore'))

Save()

Hopefully this gives a pretty clear picture of the power and ease of the data functions in the Crawl Space Library. This is just scratching the surface of what csl can be used for. There are even more features in the Save/Load functions, such as saving any table and saving to a non-default file:

local levels = {1,2,3,4}

local filename = "levels.txt"

Save(levels,filename)

There you have it, an easy way to store data using the Crawl Space Library. There are tons of uses for these features, and I am looking forward to seeing what you come up with. Go checkout csl if you haven’t already. It has a lot of cool stuff and more just around the corner. Again, you can find that here. Feel free to drop us a comment below and share what you have been using the library for.

Enjoy! –Lance

We recently had a painful experience and wanted to share it with the game dev community so you can learn from it and not make the same mistake we did. Do you ever have problems keeping track of your keys? I’m constantly misplacing my keys and asking my wife if she has seen them. If you’re an app developer you have a set of virtual keys that are just as important as your physical keys and those keys are your keystore files for Android and provisioning profiles for iOS. I don’t know how much you know about the differences in the signing processes between iOS and Android, but they are quite a bit different. Apple holds your hand and helps you manage those provisioning profiles in the developer area of their site. Android, on the other hand, completely turns you loose and gives you full control of managing your own keystores. Its a kin to two different parenting styles, where the Apple dad knows that their children are going to mess up sometimes and believes its good to have a safety net, so they don’t completely screw up their lives. While the Android dad believes that kids should live their lives and learn from their mistakes and nudges them out of the nest to fly on their own. You can argue the merits of each approach, but they are different and those little magic files you sign your apps with are different as well. If you misplace your iOS provisioning profile, papa Jobs has a spare copy for you to download. If you misplace your keystore, in the words of Walter from Big Lebowski…”You’re entering a world of pain”.

We entered that world of pain recently. Two of our computers died and the keystore for signing the Nook version of Float could not be found. We had all of the other files for that game in our repo, but for the life of us we could not find that keystore file. The kicker of the whole story is that we pushed an update to Float where we added more modes and signed it with a different keystore than the first time. We didn’t realize that we had signed with a different keystore and Barnes & Noble didn’t catch it either. When people when to update Float, they couldn’t get it to work. Not only couldn’t they get the update to work, but they could no longer play the old version either. Emails from 20,000 mothers informing me that their children could no longer play the game that they loved quickly started to pour in. …”A world of pain.” That isn’t a situation any app developer wants to be in. So we did some research to see if we could extract the keystore or recreate it in some way and needless to say—keystores are like beautiful unique snowflakes. There is absolutely no way to fake or recreate the keystores used to sign your apps and thats the point. Its a security measure and a very good one.

Long story short, after some back and forth with B&N, which I must say they were very helpful and they have an awesome team, we submitted Float HD. We had to submit a completely new app and allow it to be free for one week so all the people having problems could switch over to the new version and the old version of the app was removed from the store. The solution was kind of a bummer because Float was the second highest rated game just behind Angry Birds, but if you do some research on lost keystore you will find that our story is far better than some of the horror stories people have gone through. For example, one developer signed twenty of his paid apps with the same keystore and his laptop was stolen. He now has twenty apps that he can no longer update…ouch. Moral of the story? Hold on to your keystore file kids. Store them in a repo, email them to your self, send them to a friend, put them on a usb key and stash it in a safe. Whatever you do, just make sure you have it backed up somewhere.

Also, if you have a Nook go get Float HD, which is free for one week.

When I got up today the sun was shining, the birds were singing, the loud garbage truck was banging around outside, and I was inspired. Now, I don’t want to sound like a d-hyphen-bag motivational speaker, but I want to share some interesting bits of information that have encouraged me. I don’t know what types of games you are creating or for what platforms, but I make mobile games. So naturally I look to the games that have climbed their way to the top of the charts and have remained there. Doodle Jump and Angry Birds are two shining examples of success in my industry. Did you know that Doodle Jump was Lima Sky’s 12th game and Angry Birds was Rovio’s 52nd game? We’re working on our fifth game now, so we know we have a long way to go, but we remain hopeful. Keep your heads up indies. It doesn’t matter what game number you’re on or how your past games have done. Keep learning and improving your craft and you never know, that next game could be the one to catch fire and burn up the charts.

Porting a game from the desktop to mobile devices can be a challenging balancing act. The tension comes in that to create a great mobile version of a desktop game, certain alterations need to be made to the game. However, with each alteration to the game, you run the risk of tweaking its balance or even worse—losing the very fun that the desktop version was able to create and alienating its fans.

We recently have had the blessing and pleasure of partnering with the Flash game developer JackSmack (www.jacksmack.com) to port the hit online game, Globs, to iOS, Android, and Nook Color. Globs has had over 70 million plays online since its release. The last couple weeks we have worked on bring this game to mobile and we would like to share with you some of the challenges and design considerations we worked through in the process of porting Globs.

Touch Changes the Game

This may be a painfully obvious statement, but the way you interact with your computer is much different than the way you interact with your mobile devices. On a computer where a mouse and keyboard drive your interactions it makes sense to have UI (user interface) elements like navigation and buttons at the top of the screen. This is largely due to the fact that in the western world we read from top to bottom and left to right. So we put the important stuff at the top and left sides of the screen. On a mobile device those conventions don’t work as well though because you are holding the device. Have you noticed on your device that there are a lot more navigation bars at the bottom of your screen? Don’t feel bad if you haven’t noticed, it took a while for my brain to actually catch that fact because intuitively it just made sense to my hands. Why is that? Some people have coined this the rule of the thumb. Because we hold these devices in our hands while interacting with them our thumbs become the main drivers. From typing on the keyboard to clicking on links, your thumbs do the majority of the heavy lifting on mobile devices—which brings us back to Globs.

From the screenshots above you can see that game controls were flipped from being anchored to the top of the screen in the desktop version to being anchored to the bottom of the screen in the mobile version. The desktop version gave players freedom to choose how they wanted to play by either clicking on the globs in the control area or to pressing the corresponding keys on the keyboard. On the mobile version we did not have such freedoms. We obeyed the rule of the thumb and kept the buttons within thumbs reach. We also had to take into account that the most popular smart phones have abandoned keyboards all together in favor of full sized touch screens. We increased the size of the buttons to accommodate thumb presses and tried to give as much room between them as we could to minimize accidental button presses.

Smaller Screen Sizes

Out of necessity mobile screens are considerably smaller than computer monitors. Its true that smart phone displays are starting to catch up to their desktop cousins in terms of resolutions, but mobile screens will always be relatively small in comparison. To accommodate smaller screen sizes certain concessions need to be made when porting a game to mobile devices. In the case of Globs we tried simplifying the game to its core gameplay elements. You can see from the screen shots that we removed the busy tiled background and went with a solid blue. The look of the game board also had to be simplified, so a solid off-white colored board was chosen to help the globs pop on smaller screens.

When designing for smaller screens its important that the elements in your design pop. Increase the contrast in the graphics from the desktop version so elements are easily distinguishable at the smaller sizes. This might be weird to designers from other mediums, such as print and web, but for games its better to error on the side of overly contrasty bright bold graphics. In Globs, bright saturated colors were chosen and highlights and shadows were added to all the elements through the game. Readability can also be an issue on smaller screens so we went with with text and black drop shadows for the hud (need to explain the same way you explained UI) elements and white text with black outlines and drop shadows for popup elements. Through the colors and treatments chosen we were able to give the game a visual hierarchy where the white board has prominence while the black bar of buttons at the bottom and the hud weigh in second and third.

As I mentioned at the beginning, when porting a game over to mobile you don’t want to change the core experience of the game. Glob’s square grid system is one of its core game elements and we quickly realized that any changes to this system would need to be handled with gloves. Because the mobile version of Globs is in portrait orientation, we toyed with the idea of changing the proportions of the board to better fit the space. After some discussion we came to the realization that moving away from a square grid would actually change the strategy of the game. To remain true to the original version we had to keep the square grid, however, to accommodate the smaller screen size and to simplify the experience for new players, we opted to start the game with a 6×6 grid instead of the 9×9 grid. We feel that this makes it easier for new players to quickly understand the game and gives them a chance to ease into it, while keeping the core game play experience intact for existing fans.

Shorter Play Times

If I’m like most mobile gamers, my play times are considerably shorter than when I’m on my computer or console. My typical usage pattern is a few minutes here and there when I have some down time. Mobile games should be built with these short play sessions in mind and not penalize players for needing to quit. In the mobile version of Globs we always allow you to continue from where you left off, no matter which mode you were playing. If you loose a level you can simply retry the level. As a gamer, one of my top frustrations is investing a good amount of time into a game and then being forced to start completely over from the beginning upon losing. We made it a point to constantly save the players progress to make it easy to resume play and encourage player to pick up the game again and again.

It’s yet to be seen how well Globs does in the mobile space, but we have worked very hard to preserve fun experience JackSmack created in the online version of Globs and we have done our best to improve the experience where we could. I believe there are great opportunities for mobile developers who are willing to work with flash game developers to port their games to mobile. This is especially true since Flash has still not been able to match the performance for mobile as other platforms such as Corona SDK.

You can play the original version of the game at www.jacksmack.com/games/550/globs.html

If you’re interested in playing the mobile versions of the game you can download from the Apple Appstore and Android Marketplace below.

Purchase Globs on Apple AppStore

Purchase Globs on Android Market

We’re very excited about our next game Bounce to Win. We’re working real hard on it and we hope to have it done by the end of this month. Here are some work in progress screenshots.

The dismal sales of Zombies Ala Mode and the success of Float has really taught us a lot about the business and process of making mobile games. Our ideas have drastically changed in a short amount of time and I want to share with you our approach. Side note, this post is not our recommendation on how you should approach making games, rather its simply our thinking on the subject and what you can expect from us in the future.

I’m not sure how people perceive our company, but here is the truth…Crawl Space is a side company that we are trying to make our full time gig. We own a small design studio doing branding and web design for clients. We are making games in the time between client work and we are working very hard to make the leap to full time game development.

Prior to the release of Float, none of our games have been able to recoup the development costs. Lots of time was spent learning the software, developing our process, and all of the ins and outs of making mobile apps. Some of that is to be expected with venturing into a new industry, but some of it was bad business decisions. On Zombies Ala Mode in particular we threw a lot of time and money at a game that yielded disappointing numbers. Float on the other hand is a simple game developed in the course of month that will most likely bring in around $40,000 this year. Not bad for a silly little balloon game.

So we are approaching making a mobile game business in the following ways. First, we have made the decision to limit the scope of our games to something we can create in one months time. Two, our games will be simple games with one or two mechanics. Three, the games will be 2D. Four, we will spend as little as possible on assets for the game upfront.

We came to all of these decisions based upon our need to lower the risk of making games. Like all indie developers, we have very limited time and resources, so we need to make wise decisions to really maximize them. For example, the one month time limit was self imposed to help us fight feature creep. Its very easy to keep coming up with cool new features and ideas for a game and before long the scope of the project has ballooned way past the original game idea. This happened to us with Zombies Ala Mode. We added more modes, and art, and cool little touches that extended our development time by a couple months.

The choice to make 2D games comes from the simple fact that 2D games are easier to create and take less time. Our first game, Knife Toss, was made in 3d using Unity. Since that time we have focused on 2D games because its a lot faster. Modelling, texturing, rigging, and working out the camera system all take time. 2D games are simpler to make and more approachable for casual gamers. Take a survey of the top selling mobile games and the majority of them are 2D.

The funny thing about all of our constraints, self imposed or otherwise, is that they force us to be more creative. The fact that we choose not to spend very much money for assets forces us to create our own. Our self imposed one month time limit forces us to find the fun in an idea and focus on that. And the very fact that we are limited to making simple one or two mechanic games is actually perfect for the mobile market. We’re taught to fight constraints and think outside the box, but by embracing the constraints and thinking within the limitations of the box actually produces better products.

So what can you expect from us this year? Currently we have five games sketched out and all of them fit in the model I have described. And if we can make a few games a year that do around the same success level as Float that will enable us to cover a few salaries and hopefully make the leap to full time game development.

Are you an indie trying to make the same leap? Let us know your plan we would love to hear it.

We’re getting ready to start contacting review sites about reviewing our newest game and I wanted to share some of our hard work with you the community. We put some spreadsheets together for iOS and Android review sites. The link below is shared through Google Docs and I have given you the ability to edit the doc. If you know of any sites not on the list please add them, so the community can benefit.

App Review Sites Spreadsheet

How do I market my app? Should I hire a marketing agency? I’ve bet you probably heard these questions or seen them posted online. If you’re an app developer you’ve probably even asked them yourself. We have published a few games now and have tried many different marketing techniques. We actually make it a point to try new marketing “experiments” with each new app. We’ve hired marketing agencies before and we’ve also done it ourselves. It is our conclusion that if you’re willing invest the time and effort—marketing your app yourself not only costs far less, but also produces more exposure.

Hiring an app marketing agency can be costly. On the low end you’re going to be spending $3,000 and the high end runs into tens of thousands of dollars. Most of them have different packages that include submitting to review sites, tweeting, managing your  Facebook page, putting out press releases, etc. To most independent developers an app marketing agency is not a luxury that can be afforded. Other developers, like us, even though we could afford an agency we choose not to because in our eyes increases the risk of developing the app. So what do I mean by that? The lower the cost to bring an app to market, the lower the risk to take of developing that app. If you spend $10,000 in real money or opportunity costs, your app has to make that money back before it is profitable. If you add a few thousand more dollars of marketing costs after the development costs you just added more to your total investment and risk.

Now let me be clear about one thing—you have to market your app. Marketing can have a huge impact on the success or failure of an app. It is not option, it has to be done. Before you point to apps like Tiny Wings and Bubble Ball let me point out that those are exceptions or flukes. For every Tiny Wings app, there are thousands and thousands of apps on the app store that no one has heard of. And they receive only a few downloads a year. You can’t just put out your app and wait on people to discover it, you’re going to need to invest in marketing. The good news is that investing in marketing your app doesn’t have to cost you a lot of money.

Before we talk about where to spend your time and money marketing your app, lets start with what doesn’t work. In our experience investing in ads doesn’t work. We have seen absolutely no up tick in our sales based on ads we have bought. It might work for larger developers that can afford to canvas review sites with their apps, but if you’re a little developer don’t waste your money. The only possible exception to this rule is what I’m going to call a payoff. There are some sites that offer a deal where if you purchase ad space they will review your app. That won’t guarantee you a good review, but it will get your app reviewed in more places and that has been worth it to us in the past.

So where should you invest your time and resources? First, we spend a lot of time making sure all our marketing materials are polished. This includes the app description, screenshots, trailer, and website. Writing should be brief and enticing, written for normal people and stripped of all marketing speak. A few sentences to a paragraph is plenty for the description. Include a bulleted list of the features. Screenshots and trailers go a long way to convince people to check out your app. The idea of a trailer may intimidate some people, but it can be as simple recording yourself using the app. If your app is a game this is especially true, people love to see game play footage.

Second, invest your time in trying to acquire app reviews. We believe that app review sites are the second place people go to find out about new apps. The first place is the app store. We have not control over the app store lists, but you can have impact on the review sites. Spend time compiling a list of all the top review sites. Here is a list of the top ten to get you started. There are many many more sites out there, put them in a spread sheet and include contact information/submission guidelines. Each site is different in how they want people to contact them for app submission/reviews, so make notes on the spreadsheet. Develop relationships with reviewers at these sites. Don’t overlook the lesser trafficked sites, many will jump at the chance to review a cool new app. Finally when it comes to reviews, don’t forget about youtube. Do a search on youtube for app reviews. You’ll be surprised how many individuals review apps—its not just companies. Make a list of those reviewers and contact them as well.

What do you say when contacting reviewers? When emailing reviewers it is important to    polite, brief, and provide them with enough information to entice them into making a decision to review your app. Here is an example of an email we sent out for Float.

Would you like to review our new game Float for iOS devices? Its current on the New and Noteworthy list and its starting to get some good attention. Let me know and I’ll send you a promo code. Thanks.

Description

Float is a game that makes you feel happy. Try to keep the balloons in the air and off the spikes. Tap, bobble, and bump your way to fun. With multiple games modes, achievements, and leader boards there is something for everyone.

4.5 out of 5 – Appsmile.com

4.5 out of 5 – CrazyMikesapps.com

4 out of 5 – Appspy.com

Trailer

http://www.youtube.com/watch?v=QxnH3aWf38

iTunes

http://itunes.apple.com/us/app/float/id409855273?mt=8

Features

• Multiple Game Modes

• Retina Graphics

• Open Feint & Facebook Leaderboards

• Over 40 Achievements

• Post Your Scores to Facebook

• Increase Your Fun with Game Mode Packs

Price

$0.99

More Info

www.floatgame.com

On some review sites there is another opportunity to market your app and that is in the fourms. One of the most vibrant hubs of app discussion is the toucharcade.com forum. Most of the app forums have dedicated channels where developers can announce their new app. Similar to the email example above, post important information about your app like pricing, screenshots, and trailer links. Encourage feedback in your post and don’t be afraid to give away promo codes. Don’t forget to subscribe to the post, that way you will be notified when someone posts a comment and you can keep the post activity going.

Third, get involved in social media. With over 600 million people on Facebook and 100 million registered users on Twitter these are clearly online hubs of communication. Since most people in your social circles are presumably interested in you and the things you are doing its low hanging fruit. But go the extra steps, especially in the case with Facebook. Not only setup a facebook page for your company or apps, but develop your apps with social integration in mind. In the case of our games, we give the player the opportunity to post their score to their facebook stream, compete against their friends in Facebook leaderboards, and like our company and the game. If people like the app and you give them the tools, they will market it for you.

Fourth, always develop a lite or free versions of the app. People want to try before they buy. Even if the price is only $0.99, there will always be a portion that people that just won’t purchase without trying it first. Like a digital drug dealer, give away a taste for free and then when people are hooked charge them for more. We have done both free and lite versions of games. Both work well it just depends on your strategy. We have made more money off the free version of Float that serves ads than the paid version in the Apple store. Our strategy going forward is to release the paid version with a lite version that drives them to the paid version. Depending on how well the paid version performs, we will then remove the lite version and put out a free version with ads. You can always put out a free version later, so hold off and see how well your paid version does.

Finally, consider doing giveaways. There are lots of ways to do this, as I mentioned above giving away promo codes through forums, review sites, twitter, etc is a great way to spread the word. Consider large giveaway programs and sites. Most of them require revenue sharing or a fee upfront, but they can get you a huge amount of exposure. One example is FreeAppADay.com. It has a large amount of followers and can be used as a calculated risk. We used them to promote Float Free. We paid them $3,500 to participate in their give away and it catapulted Float Free to the top of the free charts. This calculated risk paid off for us through $12,000 in ad revenue. Another great give away program is through Open Feint. If you use Open Feint in your app you can participate in their give away program. The terms for their program are revenue share or an upfront payment. If you don’t want to spend any money, you can always just change the price of your app to free in the store. Simply by making the app free will get your app on quite a few sites’ radars, which can lead to new reviews and increased exposure. All giveaways and free periods need to be thought out though. Making your app free will increase exposure and downloads, but your app’s ratings will suffer. People don’t value free so you will get a lot of people downloading your app just because it is free, not because they have any real interest in it. Bad comments and one star reviews are sure to follow, so be prepared going into it. One good strategy is to have an update ready to roll out after the free period to wash away the bad reviews and get your ratings back up. Calculate your risks and plan ahead to make the most out of giveaways.

Hopefully this has given you some ideas to try. Having little or no marketing budget doesn’t mean you can’t generate exposure for your app. We believe using these techniques that we can do a better job marketing our apps for far less risk, enabling us to continue to make games.

Preface: on Twitter, Peter Baily @peterbailey encouraged us to write about marketing and developing apps, so from Peter’s encouragement here is the first of a series of blog posts on those topics.

Recently I’ve been reading several business books and one book in particular has given me several nuggets of wisdom. Founders at Work is comprised of a series of interviews with founders during their startup years. In the first two chapters, Max Levchin (Paypal founder) and Sabeer Bhatia (Hotmail Founder) talk about how their businesses had built in virality. In the case of Hotmail, when someone sends you an email from Hotmail at the bottom of the email is a little advertisement letting you know that the email came from Hotmail and you can get a free account there too. From a business standpoint that is absolutely brilliant. Free advertising built into every single email sent. That little link was a huge contributing factor of why Hotmail went viral and it turned into the success it has become.

So here are some questions I’ve been wrestling with lately—How do we make our games more viral? How do we reward people for telling their friends about our game? How do we build a fan base/community around our games? If you’re a game developer I’m sure you have asked yourself the same questions. As I look around our social media landscape, its obvious that Facebook is the big player. And whether you like it or not—their “Like Button” has become a very powerful tool to spread the word about something cool or believe in. With that in mind, I’ve spent the last few days diving into the Facebook Api trying to understand all the ways we can use Facebook to encourage virality and setting up a system which we could use in all our games going forward.

Right now we have decided there are four actions we want to encourage users to take within our games. That is to say, we want to encourage four other actions in addition to the standard post your score to Open Feint and Facebook, which are standard fare. We want to encourage players to Like Crawl Space on Facebook, Like Our Game, Rate the Game, and Tell a Friend About the Game.

Lets jump into some code. In our main.lua file we define some variables. The code below shows our default variables being defined using the CrawlSpace Library.

Defaults{rateGame=false, likeUs=false, likeGame=false, tellFriend=false}

These variables come into use during our game through two classes. The first class is adBar.lua. The adBar class allows us to place an ad bar wherever we like on the screen. You can define if you want to show external ads like AdMob or “house” ads which in this case is what we want to do. If you understand how to make text or graphic with a listener then you understand the adBar class. I’m not going to go into all the code, but I will show you one of the listener functions in the class.

openLikeGame = function(event)
    if event.phase == "began" then
        local url = websiteUrl.."likegame.php"
        easyFB:showLikeBox(url)
    end
end

As you can see its a pretty standard listener function. We are listening for a touch phase. The if statement is looking specifically for the beginning of the touch phase, so the function isn’t called multiple times. After declaring our variable, url, we pass it into the work horse class “easyFB” where we call the showLikeBox function.

All Facebook interaction is handled in our easyFB.lua file. The easyFB class stands for “easy Facebook”. We took the Facebook example code included with the Corona SDk files and made a class that we reuse across our games—which I’m giving away today to all our lucky readers. Easy FB handles logging in and out, posting to wall, showing leaderboards, checking likes, and show like boxes. We will only touch on a few of these functions for this article, but feel free to post any questions you have or send me an email.

The first function, easyFB.login(), does what is says…it logs you into Facebook. You pass in your Facebook App Id and an optional callback function. The callback function will fire after you are logged into Facebook. The important part to highlight in this function is that we are requesting a few permissions from the user when they connect. They are giving us permission to see their likes and publish to their stream. We obviously don’t want to abuse these permissions, but they are needed to be able to post high scores to their wall and to check if they like our company and our game.

easyFB.login = function ( event, facebookAppId, cb )
    callback = cb
    facebook.login(facebookAppId, fbListener, {"user_likes", "publish_stream"} )
end

When logging into Facebook we attached a listener called “fbListener”. This function handles all the event login for the communication between facebook and the game. I apologize that the function is a little long and complex. The listener is the listener in the Facebook example code, bundle with corona, with a few additions.

fbListener = function( event )
    if ( "session" == event.type ) then
        -- event.phase is one of: "login", "loginFailed", "loginCancelled", "logout"
        if ( "login" == event.phase ) then
            setVar{"fbLoggedIn", true}
            facebook.request( "me/likes")
            if fbCommand == SHOW_DIALOG then
                facebook.showDialog( {action = "stream.publish"} )
            end
            if fbCommand == POST_PHOTO then
                facebook.request( "me/feed", "POST", attachment )
                Achieve("share")
            end
        elseif "logout" == event.phase then
            setVar{"fbLoggedIn", false}
        elseif "loginCancelled" == event.phase then
            callback = nil
            native.cancelWebPopup()
        end
        -- if there is a requested callback function, execute it
        if callback then callback() end
    elseif ( "request" == event.type ) then
        -- event.response is a JSON object from the FB server
        local response = event.response
        -- if request succeeds, create a scrolling list of friend names
        if ( not event.isError ) then
            response = json.decode( event.response )
            local data = response.data
            for i=1,#data do
                local name = data[i].name
                if name == company then
                    setVar{"likeUs", true}
                elseif name == game then
                    setVar{"likeGame", true}
                else
                end
            end
    elseif ( "dialog" == event.type ) then
    end
end
end

When someone successfully logs in to Facebook the login event.phase runs and we first set a variable to let the game know that the user is logged into Facebook then we request the users likes. Within this same listener, at the bottom half of the code, we see a check for “request”. This code receives the json data, decodes it then we loop through the users likes and check if they like our company or our game. We set respective variables to true accordingly.

elseif ( "request" == event.type ) then
        -- event.response is a JSON object from the FB server
        local response = event.response
        -- if request succeeds, create a scrolling list of friend names
        if ( not event.isError ) then
            response = json.decode( event.response )
            local data = response.data
            for i=1,#data do
                local name = data[i].name
                if name == company then
                    setVar{"likeUs", true}
                elseif name == game then
                    setVar{"likeGame", true}
                else
                end
            end

At this point we have determined if the player likes our company and if he/she likes our game. For illustration lets assume they have not liked either our game or company on Facebook. At this point we would provide the player with an enticing offer to like us, such as unlocking extra content if they like us on Facebook. The player clicks on the ad and it calls this function:

easyFB.showLikeBox = function(self, url)
    local urlPath = url
    local showLike = function()
        callback = nil
        native.cancelWebPopup()
        native.showWebPopup(centerX - 150, centerY - 200, 300, 400, urlPath, {urlRequest=webListener})
    end
    callback = showLike
    if retrieveVar("fbLoggedIn") == true then
        showLike()
    else
        facebook.login( facebookAppId, fbListener, {"user_likes", "publish_stream"}  )
    end
end

The showLikeBox accepts a url parameter, which is the url for the web page that we will popup. That web page contains a title, Facebook Like Button, and a close button. You can load all the code at the bottom of the post.

Anytime we call a web popup in the easyFb class we attach the same listener called “webListener”. This listener listens for three events, “corona:close”, “corona:likeUs”, and “corona:likeGame”. If a user clicks like in the popup, we have a javascript listener that will hide all content except for a thank you message a link to return to the game, which our webListener in the game listens for.

webListener = function( event )
    local shouldLoad = true
    local url = event.url
    if 1 == string.find( url, "corona:close" ) then
        -- Close the web popup
        if externalAds == true then
            adBar:openAds()
        end
        shouldLoad = false
    elseif 1 == string.find(url, "corona:likeUs") then
        setVar{"likeUs", true}
        shouldLoad = false
    elseif 1 == string.find(url, "corona:likeGame") then
        setVar{"likeGame", true}
        shouldLoad = false
    end
    return shouldLoad
end

We will be rolling out this system in all our games going forward starting with Globs and Bounce to Win both coming out in June. If you have any questions about the code let me know and I’ll be glad to assist.

Download Source Code

We just recently found out that Float is #5 on the Nook App Store. Here is the Top App List for the opening month. Nook Color has reportedly sold over three million units so far and we expect it to continue to do well. Right now it is one of the most reasonably priced Android tablets.

A big thanks to Barnes & Noble for selecting Float as one of the 125 apps for launch. And and a big thank you Ansca Mobile for making its most wonder product Corona and helping us work out bugs for the Nook version.