Showing all entries for: October 2010
Using a Table to Pass Function Parameters. Outstanding Lua advice from Steffen Itterheim.
I just discovered his site,
Learn-Corona.com, through my logs, started browsing around, and found some great stuff. Needless to say, I’ve subscribed to his feed.
another gem that talks about iterating efficiently over a Lua table (confusing concept for Lua beginners).
This update is currently “In Review” and is expected to be approved within about a week or so.
Please note that the stuttering and skipping in the video is due to recording directly from the device and is not present during actual gameplay. This method of recording was my only option for semi-high-quality footage because the controls are tilt-based.
The new update has tons of new features and improves upon 1.0 in almost every way, and fixes some performance issues and bugs.
Went to a party and had a great Halloween with Biffy and all kinds of family.
When we returned home, I checked our new twitter account and to my surprise, I have been put on the waiting list for idevblogaday (I requested to be put on it yesterday).
I’m #49 on the waiting list, and not exactly sure how everything works from here, but hey, it’s a start! Looking forward to sharing my “iDev” advice soon.
Two weeks ago, an explosion happened over at the GameSalad community when the folks behind the company announced that a new service, dubbed “GameSalad Direct”, would be replacing their existing subscription model.
In short, the new system would require GameSalad users to go through GameSalad’s iTunes Connect account to publish their games in an attempt to waive the Apple Developer fee from GameSalad members.
Well, GS subscribers were infuriated by the announcement. From what I observed, I’d have to say 99% of their members didn’t like the idea (most were outraged), and the reason is because this new business model would do the following to existing GameSalad developers:
Once their current subscription lapsed, they would have to transfer their games from their own Apple Developer account to GameSalad’s if they wanted to continue updating and creating new games using the GS software, thus ridding developers of their “real” brand and identity—this is what most GS user’s biggest complaint was.
Good games would be lumped in with the multitude of bad games within GameSalad’s iTunes profile in the App Store, thus decreasing the perceived value of the more professional games made with GameSalad (ouch).
I saw some people defending GameSalad saying that Chilingo is a publisher and has made a lot of apps successful. I hate to be this blunt, but that argument is just downright stupid. The GameSalad brand itself has a horrible reputation among game reviewers and pretty much anyone who doesn’t use GameSalad, so I shouldn’t have to explain why most developers wouldn’t want their games listed under GameSalad’s iTunes account. There have been good games created with GameSalad that have done well, but I think it’s safe to say that the GameSalad BRAND itself didn’t contribute to that at all (if anything, it made the games less successful than they could have been).
The GameSalad company is horrible at even basic communication. If developers had to go through GameSalad’s iTunes account, it adds another layer of stress to the—already stressful—App Store process when they come to rely on GameSalad for payments instead of Apple.
Of course, people had more negative things to say (I’ve personally been keeping up with the entire 55-page thread) about the new GameSalad Direct service, but the four points above encompass the major things.
And it’s not even GameSalad Direct that they really have a problem with, it’s that it was supposed to completely replace the existing subscription model. Basically, GameSalad was going from being a development tool (what current GS users want), to a mandatory publishing service with a tool included.
As a result, many people shunned GameSalad and left, moving on to look at other SDK’s such as Corona and Unity. And since most GameSalad developers are looking for simplicity, naturally most started looking more closely at Corona because it’s the easiest option apart from GameSalad.
For many, it was a breath of fresh air because Ansca Mobile has much better communication than GameSalad, and apart from a tool that is easy enough for them to use, communication is something GS users were starving for.
Of course, veteran GameSalad members say that Ansca took advantage of the GameSalad situation and started communicating with their own members at that point to make themselves look good, and to make GameSalad look worse, but I personally don’t believe that’s the case. And here’s my argument:
I Switched to Corona from GameSalad Prior to All This
I was a former GameSalad user. I decided it wasn’t for me, found Corona, and have been using it ever since. This was all WAY before this “GameSalad Direct” fiasco happened. Apart from my gripes about performance and limited features, one of my major complaints about GameSalad was also communication.
And on the other hand, I’ve never had a communication problem with Ansca Mobile, and since this was way before the GS fiasco, they had no situation to “take advantage” of, per say. In one particular scenario, I emailed the Ansca CEO (Carlos Icaza) about some concerns I was having and received a VERY quick courtesy response (on the weekend!) stating that he received my email, but had some family over so he was going to wait until Monday so he can give me a more detailed response. Come Monday, I got a very detailed email addressing everything I mentioned in my original message.
Now, Ansca Mobile being the smart company they are, of course took advantage of lots of new prospects looking at their SDK and gave out 50% discount incentives, training videos, live webinars, etc. but that’s all just good business. It doesn’t matter that most of the new visitors were coming from GameSalad, it’s the fact that a lot of new people (mostly people inexperienced when it comes to coding) were looking at their product and THAT’S what they took advantage of. Once again, that’s just good business.
As far as Ansca Mobile suddenly communicating because GS user’s were complaining that GameSalad was not, I don’t buy it. Like I said, I came from GS long before all this happened and my communication expectations were highly met by the Ansca Mobile team.
GameSalad Revises Their Plan
Recently (about a day ago), GameSalad announced a change in their plans due to all the complaining:
GameSalad will be launching a new subscription and membership program that will continue to allow developers to publish under their own Apple developer accounts. Under the new program, there will be no “per app” submission costs and no revenue share. For those of you who valued having GameSalad manage the publishing process, GameSalad will still offer to publish some titles under a different program.
Next week, we are also launching a new “Professional” tier subscription, replacing the current “Pro” subscription. Further, the current “Express” subscription will also be seeing significant tweaks as well. We are pricing the new subscriptions competitively and users will be given a fast and cost effective way to upgrade from their current subscriptions.
The new memberships will go live concurrently with GameSalad 0.9.0, coming soon.
I half-way expected the above to happen, simply because a company has to see impending doom when most of their once-loyal customers are cursing them and looking at competitors—who wouldn’t make some changes?
Just about all of the GS members are happy about the announcement, as anyone would expect. But what about the one’s who purchased a Corona subscription?
Some Will Stay, Some Will Go
I don’t really see GameSalad as a competitor to the Corona SDK. I think they both target completely different audiences, so I think whatever members Corona does retain from this whole situation can be looked at as a bonus.
The bottom line is, GS users generally don’t like code, and some are even afraid of it—this doesn’t strike me as the audience Corona was targeting to begin with. More on that in a moment.
For developers who DO code (which is all developers who don’t use GameSalad), Corona is a much faster and simpler solution than anything else out there, so that’s who Corona is targeting.
If someone is familiar with an existing scripting language such as PHP, ActionScript, etc. then Corona is a great way for those developers to produce top notch apps without having to climb the Objective-C mountain and stray too far from their current skill-set (or sacrifice performance).
And for those who have climbed the “Objective-C mountain”, then Corona provides a way for those developers to reduce development time by up to 90% without sacrificing the performance.
Corona and GameSalad Target Different Audiences
I look at it this way. From a structural standpoint, with Corona you get a blank slate as with Objective-C and just about any other programming language. As a programmer, you have complete freedom to do whatever you want, however you want.
GameSalad, however, is like a coloring book page. You are bound by the confines of what’s placed in front of you. You have full control of how well the final piece turns out, but you must do it a certain way.
Is this a better option for those who don’t know how to draw? Absolutely! But for artists who have their own way of doing things, a coloring page—no matter how well it’s put together—is simply not something that’s going to allow an artist to use their creativity and express themselves in ways they are used to (or ways they’d even want to, if they were to get used to it).
In the above analogy, GameSalad would target non-artists who either are afraid to learn how to draw, or simply don’t want to, but still want to produce artwork. Corona’s targeting the artists who simply want to get things done quicker and easier while sticking to a medium that’s both familiar and reliable (e.g. Corona’s performance is comparable to that of apps programmed natively in Objective-C, and code is written using the same tools).
What if GameSalad Fixes Performance?
Even if GameSalad matched Corona in performance one day, I would still use Corona because I prefer being able to easily type or copy/paste code (and easily re-use it later) than dragging and dropping “behaviors”. I personally find dragging-and-dropping to be very limited compared to what I’m used to, and it also wears on my overall focus.
I think most programmers would agree, so once again, I think GameSalad is in a completely different ballpark.
The only way GameSalad and Corona would cross audiences significantly is if GameSalad included some kind of scripting capabilities within their software. Of course, that’s if and ONLY if they were to match Corona’s performance, graphics, networking, and physics capabilities. By the time they were to do that though… well, let’s just say I can’t wait to see where the Corona SDK is by then :-)
And all of that isn’t even taking pricing into consideration, which this article assumes GS will be fair with—but I could be wrong about that.
Corona is for Programmers
Corona is targeted for 99% of programmers who would see it for what it really is: EASY. Not non-programmers who are afraid of it and don’t like the idea of writing code.
On the flipside, however, Lua + Corona does make a great first language for those who want to learn a programming language and SDK.
So for the GameSalad users who went to Corona and then BACK to GameSalad after the company’s recent announcement, I think those users didn’t really want to use Corona, they simply felt like they had no choice because it is the next easiest option. That strikes me as the type of subscriber that might have not had the passion to learn to code and therefore probably wouldn’t have renewed their subscription anyway.
I don’t see GameSalad’s recent announcement as a blow to Corona because as I mentioned before, I think any new subscribers Corona DOES retain from that whole mess can be looked at as a bonus—customers from an audience they weren’t even targeting to begin with (the non-programmer audience).
UPDATE Nov 1, 2010: The promotion mentioned below has ended.
While I’m on the subject of Corona, today is the LAST DAY to take advantage of their generous 50% discount they are offering to new subscribers. If you want to get Corona for half-price, visit the Corona website and use the following coupon code upon checkout:
This article covers some of my basic practices in code optimization and memory leak prevention while programming in Lua using the Corona SDK.
Following this advice won’t provide a fail-proof way of preventing memory leaks and performance issues, but it’ll definitely help minimize them.
Prevention is Key
Rather than hacking away at all your code and then going back to check for memory leaks later once you discover something’s not right, it’s best to take as many measures as possible before ever getting to that point. That way you don’t find yourself in a “needle in a haystack” situation when your game/app is crashing for unknown reasons.
Object Reference File
For every project, I usually create separate text files for each module, where I’ll keep track of all the display objects as I create them. This helps me out a lot when it’s time to free things from memory and prevents me from being unsure if I’ve somehow missed something.
So for example, whenever I call a
display.newImage() (or something similar), I simply write the object’s name in the text file as a new line. That takes me to my next point.
Create a removeObjects() Function
Somewhere towards the bottom of your module, I find it useful to create a
removeObjects() function where I manually call
myObject = nil for every single display object that has been created. If that object has any event listeners attached to it, I also remove those listeners before calling
After I manually write all of the removal code for each object, I then loop through the display groups and remove everything as described in the Corona documentation. Once all this is complete, I have a nice function handy for whenever I need to completely remove everything from that particular module—and I can feel good about it.
Common scenario: unloading a screen completely to move onto a different one.
But all that seems a little like overkill right? Since, after all, looping through the display groups and calling
child = nil should get the job done, right?
Perhaps, but I find that putting in the extra work is more efficient and helps ensure that listeners are stopped, and that objects really ARE removed from memory so your app runs as smooth as possible. On top of that, I hate feeling insecure about things, and the extra measures makes me feel a lot more secure about my code.
Here’s a tip: don’t wait until you’re done with everything before going through your reference text file to create the removeObjects() function. Instead, when you create your display object, go ahead and add the “removal” code to the removeObjects() function as you go—that’ll decrease the overall workload.
Be Mindful of Event Listeners
A common mistake people make is ONLY removing display objects when unloading modules and/or screens in their app; don’t forget about your event listeners!
For example, if you have a main enterFrame listener, or an accelerometer listener running, those functions will continue to eat up memory and cpu until you remove them. They can also cause critical errors and crashes if the listener functions require objects that you have already removed.
The best thing to do is treat your event listeners similar to how you would with individual display objects and call
Runtime:removeEventListener() in either your
removeObjects() function or a similar one that specifically deals with your listeners.
Don’t Forget to Unload Globals
It’s recommended you make as many variables “local” as possible, but in some cases, you might need to create non-local variables—for example, when you need to access a variable from another module.
As long as it’s kept to the bare minimum, that’s fine, but don’t forget that Lua won’t garbage collect (aka “clean up unused resources”) globally scoped variables unless you set them to “nil”. So when you’re finished with a global variable, don’t forget to do this:
If you’re using globals strictly for accessing data from other modules, it’s best to store that data as a local variable to speed up your calls to that data when you can.
For example, say you have main.lua and screen1.lua. There’s a variable, myGlobal within main.lua that you need screen1.lua to have access to. So rather than always calling myGlobal from within screen1, you can create a local variable that copies the existing data from myGlobal like so:
local myGlobalCopy = myGlobal
That way you’re only using the global variable once within screen1.lua and the rest of the time using a local variable. This is significant because in Lua, using local variables is much faster and takes up less memory than using globals.
Once again, those tips aren’t going to prevent memory leaks and optimization issues 100% of the time, but they do serve as general “best practices” to consider when coding your apps.
They will—at the very least—minimize potential memory and performance issues in your apps, so that alone should make it all worth it.
What do I think contributes to the overall success of a game? Below are four important points that I think every developer should consider during the development process.
Of course, any one might not be a good fit for your particular project (especially if your game wouldn’t fall in the realm of “casual”), but as a general rule of thumb, I try to consider each of the following when developing Beebe Games projects.
1. Low Attention Spans
iPhones, iPod touch, and even a number of iPad owners are a different breed of gamers: the kind with absolutely no patience.
Of course, every game—no matter what genre or target audience—should always strive to have the lowest possible load times, but that’s not what I’m talking about here.
I’m talking about how many steps it takes to get from point A to point B. When they open the app, can they jump right in and start playing if they wanted? When the round ends, can they start a new one, hassle free?
Those are some things you should consider when creating games for people with low attention spans. It’s no coincidence that the most popular games in the app store have the word “simple” in a large majority of the positive reviews. Simple to learn, simple to play, simple to start playing.
Which leads to my next point…
The most popular games in the app store are one’s that can be considered “addictive”—games that keep their players coming back for more, round after round. Designing for low attention spans helps this area out a lot, but there’s other things to consider as well:
How easy is it to learn your game mechanics?
Are you providing an easy, but challenging way to increase their score? If the game is too hard to raise the score, the addictiveness factor will go down. That’s not to say your game should be too easy, either (that’ll only give the same effect). You have to test, test, and test some more to hit that perfect balance between easy to play and challenging all at the same time. Take the wildly popular Doodle Jump for example. It’s easy to play, and easy to raise your score, but it’s also easy to make a mistake and fall to your “doom”. As much as possible, ensure the player has the most control over their “game over” (make them feel like it’s their own fault for ending the round and they’ll feel compelled to “Try Again”).
If your game is score-based, is there an incentive for beating their previous high score? Can they show off their scores online or on some kind of leaderboard (more on that in point #3), or do they unlock special features that were previously unavailable? Incentive, no matter how big or small—as long as it’s effective—is another major contributor to the overall “addictiveness” of a game.
3. Social Features
I touched on it a moment ago, but I’ll delve into this one a little more. Today’s atmosphere, both online and offline, is extremely social. There’s even plenty of folks who would otherwise be considered “anti-social” chatting away on services like Facebook and Twitter all day long, so it’s understandable that this social culture has bled into the atmosphere of mobile gaming.
With that said, if your game can possibly call for it, you should provide a way for players to take advantage of social elements in your game. For the players who will use social features, this provides
And by social features, I’m not talking about including chat-rooms in your games or forums (though those are fine too). So what exactly am I talking about?
Leaderboards. A place where they see their score against others (preferably their friends, with an additional option to see some kind of global ranking). Your game has the potential to become an extremely competitive environment when you get some friends tapping away for a higher score.
Social posting. Services like Twitter and Facebook revolve around posting updates to some kind of wall or timeline, so likewise, if they enjoy playing your game they’ll also appreciate being able to share their current achievements within your game (whether it’s the level they achieved, or the score they earned). This also has a double effect: not only does it help provide satisfaction to your current customer, but it’s also a mini-endorsement of your game from someone who’s playing it. The status they’re posting is viewable to all of their friends, and the most interested will be those who haven’t yet bought (or even heard of) your game.
Proof of Concept
Before I developed iPhone games, I didn’t even consider the fact that I might like social gaming. I heard about leaderboards, friend score boards, posting scores on Facebook/Twitter, but none of it appealed to me.
It wasn’t until I found myself playing some games and trying my hardest to beat out some of my family members that I realized how fun it was—many of your game’s players will be in this boat too, so make it EASY (as seamless as possible) for them to be “social” with your game (even if it means simply posting their score to a leaderboard so they can see where they stack up).
When it comes to #2 and #3, free services like OpenFeint take care of a lot of things for you automatically (achievements for incentive and leaderboards for the social aspect of things).
As a side note, Corona allows you to implement OpenFeint into your games with just a few lines of code (Btw, their 50% discount offer ends in a couple of days! Visit the Corona website site for more info).
While the above things are by no means a sure-fire way to make your game a #1 hit (nor will all apply to every type of game you’ll want to make), they can be thought of as useful guidelines that will—at the least—increase your chances of it.
Undoubtedly, it’ll make your game even funner for those who DO download it, and for that reason alone, the points I mentioned are worth looking closely at. After all, it’s the main reason we’re making GAMES right?
The newer version of Dragon’s Keep is available in the app store now! And guess what? ITS FREE!!..but only for a week!! So get your copy now! :)
Official Beebe Games Twitter Page. Brand. Spankin. New.
In my previous Corona SDK Review (when both versions were still in beta), I gave a little rundown of some of my requested features, but that’s not what the focus of that post was.
I decided, it won’t hurt to “voice” my realistic wants for upcoming and future versions of the Corona SDK, so that’s what this post will do.
The features I’m listing aren’t just things that would benefit myself and current Beebe Games projects, but would greatly improve the Corona SDK and help position it even better among competing products (my opinion, of course).
1. In-App Purchasing
I believe this is currently in the works, but still stands as the #1 feature I want that Corona currently lacks.
The app store is a tough place to be in right now. We get an initial sales boost on the first day or two after approval, but after that, each app makes peanuts unless we get lucky. In app purchasing would help our business a lot, as well as a lot of other developers which in turn will help Ansca Mobile retain more customers—it’s a win-win for everyone.
What about Android developers? In app purchasing is HUGE on iOS, I think Android will adopt something similar eventually. If the API is included for iOS, then when something similar comes out for Android, everything will be in-place for it. There’s plenty of things in the API that say “for iOS only at the moment” (such as OpenFeint), I think In App Purchasing should be one them.
2. External Library Support
I know the Ansca folks are tired of hearing this one, and they already know what all the benefits are to having it available, but it’s one of my personal requests which is why it’s on this list!
But seriously, the engineers at Ansca figured out how to bring us the awesome SDK that is Corona, so I wouldn’t put it past their ability to include a way—that won’t expose Corona or put it at risk—to extend the SDK with external libraries (such as the In App Purchasing API, Game Kit, more OpenFeint features, etc).
The beauty of this request is that, unlike requests such as offline builds, etc. that could potentially put Corona at risk from a marketing (and source-code security) standpoint, this feature would actually be even more of an incentive for people to use the Corona SDK, because limitations would be very few.
As Corona becomes more popular, it would be almost inevitable that any new API that Apple comes out with would be ported over by some third-party, in a very short amount of time at that.
The ability to extend Corona using external libraries would also relieve the Ansca engineers of a lot of pressure and feature requests because they can TRULY focus on the cross-platform side of things and let the developers worry about platform-specific features such as In-App Purchasing, Game Center, etc.
And yet ANOTHER benefit is that Apple would look highly upon Corona because the reason why Apple isn’t so fond of third-party SDK’s is because they HATE the fact that their cutting-edge features that set them apart from competing platforms can’t be used by folks who use SDK’s that don’t support them.
With the ability to extend Corona (without exposing or putting Corona at risk), the Corona developer community would find a way to implement most (if not all) of important platform-specific features without bombarding Ansca with feature requests to support them (e.g. this feature, in app purchasing, etc).
3. Improved Sound and Music
Right now there seems to be a few bugs and general quirks in the way Corona handles sound effects and music. For example, I can set the volume of music, but not for sound effects. Sound effects volume goes by device volume that’s set BEFORE they enter the app.
Also, when music starts playing, THEN the sound effects volume adjusts to the level the music is playing, but as soon as the music stops, the sound effects volume goes back to the level it was before (sometimes quieter, but usually louder).
I think just including something like OpenAL (or something similar) would be Corona’s best option, similarly to how they used Box2D for physics. Physics is Corona is awesome—it was a great decision to integrate Box2D into the SDK as they could focus on what Corona is really about, and take advantage of advancements made from a more specific library.
I doubt physics in Corona would be what it is today if they decided to build it from the ground up on their own. Not because Ansca engineers aren’t capable of doing so (I’m sure they are), but because Box2D has been around longer and has had time to refine their physics capabilities.
Bottom line: how Corona implements physics is how I think Corona should implement sound.
4. True Background Operation (Multi-Tasking Events)
It’s the future of iOS, and it’s already available within Android (though I’m sure the way Android does it, it already works, but I’m not 100% sure about that).
I personally think it would greatly improve many games and apps if pushing the home button DIDN’T exit the app every time (for those running iOS 4+ that is).
5. Access to More Device Functions
Specifically, the device Contacts and Music Library. I would love to be able to allow players to select music from their OWN music library if they want, and would also like to build apps that allow people to access their personal Contacts list.
6. Game Center Integration WITHIN OpenFeint
I’m not asking to include Game Center integration separately, because the OpenFeint version that Corona currently runs actually supports Game Center, it’s just a matter of enabling it. And for Objective-C developers who already have OpenFeint integrated into their app, I looked at the steps it takes to get Game Center “turned on”—it’s downright easy—I encourage Ansca engineers to take a look at it, I think if they do, I think it’ll definitely be included as an option in the next Game Edition release.
My best guess is, since the right OpenFeint version is already implemented in Corona, it shouldn’t be too difficult to include that feature in the next release.
7. Build for Mac Option (eventually)
I know Corona is all about mobile development, but it seems more about being cross-platform and easy to learn/use. In light of the upcoming Mac app store (read Marco Arment’s predictions, it got me a little pumped), it would be nice to build a Mac version and submit it to the new app store as well.
This isn’t anything urgent for me personally, as I enjoy developing for iOS and eventually Android, but it would be nice to NOT have to resort to using a different SDK when it comes to porting my apps over to the Mac app store.
And that’s it! Of course, there are little things I’d like to see included here and there, but everything above pretty much encompasses all I really want to see included in the Corona SDK at this point.
If all of the above, or just half of the things listed were to be implemented, not only would it make A LOT of people even happier with the SDK, but I think there would be no question about what SDK to choose when it comes to potential customers choosing Corona over the competition (mainly Unity, as I don’t think GameSalad can even be seen as a competitor anymore). In other words, Corona would GET and KEEP a lot more subscribers.
I want to stress that the above aren’t gripes or complaints I have about the current Corona SDK. Ansca has done a more-than great job so far, and I know most (if not all) of the above is already on their list of things to do. The Corona SDK is succeeding, and I only want to see it succeed even more. I think the features in the above list would pretty much guarantee that.
The Corona SDK is still 50% off for the next few days (offer ends November 1st), so if you think you might be interested in purchasing a subscription, NOW is the time to do it!
CORONA4YOU coupon code at checkout to take advantage of the generous discount offer.
Marco Arment on the Mac App Store. When I first heard about the Mac app store, I thought, there’s no way this could work. Well, I think I’m right in a way: there’s no way it could work with the way the current Mac app scene is right now; however, I was betting the folks at Apple knew that… they had something up their sleeve.
Marco Arment brings some pretty good thoughts on how the Mac app store will work, and ultimately, how it will succeed. I agree with what he says.
Earlier this evening, Ansca Mobile had an event in Fremont and generously allowed me to “appear” via speakerphone for their audience of roughly 50 people for a quick Q&A session about Doodle Dash, our development process, and future projects.
Evan Kirchhoff, software architect at Ansca Mobile led the Q&A session (and possibly the event?), so special thanks to him for having me on board.
It was quick, but overall a pleasant experience. I wish Biffy and I could have made it to the event live, but I’m glad to have had the opportunity to make a brief appearance via speakerphone nonetheless.
Extremely Generous 50% Discount on Corona from Carlos Icaza, co-founder of Ansca Mobile:
We wanted to let you know that, from now until Nov 1st, 2010, get 50% off the
regular subscription price of Corona Game Edition.
Get Corona GE at $174.50 instead of the regular pre-release pricing of $349.00 a year.
This is great for anyone wanting to build mobile apps for iPhone, Android, or both. Lua is very easy to learn in terms of programming and the team at Ansca Mobile go out of their way to help anyone who needs it via online tutorials, webinars, and live events!
If you’re interested in giving Corona a shot, I highly recommend taking advantage of their extremely generous 50% discount offer (you only have until the 1st of November to take advantage of it!).
Use this coupon code at checkout to get Corona Game Edition for $174.50/year instead of $349/year:
Dungeon Tap had 52 sales it’s first full day in the App Store… not too shabby.
I want to experiment with different promo methods in the future. OpenFeint’s Free Game of the Day proved to be very successful (for Doodle Dash!), but you never know when/if your game is approved so it’s hard to rely on it as a stable promotional source. I submitted Dungeon Tap and I’m hoping it will be approved.
I can’t wait for in-app purchases to be available in Corona. I’ve already started work on a side-scrolling, Mario-esque platformer that Biffy’s directing (titled Antsy Pantsy), and when we’re finished with that one, I’m going to be working on a sim game that’ll use a “freemium” strategy (which is why I need in-app purchases!).
For now, I’m going to resume development on Antsy Pantsy and hope Dungeon Tap makes Apple’s New & Noteworthy :-)
We’re pleased to announce that our 3rd game, Dungeon Tap has been marked ‘Ready for Sale’. Please take a moment to visit the iTunes page and download it if it looks interesting to you:
Special thanks to Ansca Mobile for their Corona SDK, which allows us to create high quality games in record time.
Dragon’s Keep 1.1 Finished. Biffy and I did a lot of work today and finally got everything complete for Dragon’s Keep 1.1.
Some of the changes:
Lots of new retina graphics and a completely re-designed menus and character selection system.
Lots of the graphics have been redesigned completely (mainly the trees).
Added a new obstacle: Cliff with Bridge
Enemies are now segmented (instead of all appearing at once).
Facebook Friends Leaderboard added for 1:00 Fury Mode (we still kept OpenFeint for global leaderboards and Survival mode leaderboards).
No more physically running over keys to unlock characters—the act of passing a dragon will mean you “picked up” a key.
Survival mode is faster.
We plan on submitting the new update for review really soon and then getting started on our next app right away… hopefully we’ll get done with that one before our Anniversary celebration (it’s next month on the 7th, but we’re going out of town to celebrate at the end of this month).
A new Corona Game Edition version has been released.
It was actually put out about a week ago, at which time I managed to wake up early one morning and download it before anyone else had a chance to. Due to a recent upgrade to the bundled OpenFeint version, however, there was a small bug I discovered and quickly reported to the Ansca staff. Eric Herrmann (Ansca Director of Engineering) found the problem and quickly fixed it—so kudos to Eric on that one!
They decided to wait until their new website theme was complete before releasing it again and it’s now available for everyone to download.
Game Edition 2010.109
I noticed there wasn’t a lot of new things added, but there were a lot of bug fixes. When I rebuild Dungeon Tap I noticed several improvements, the most noticeable were:
No more flickering on text that were involved in a transition.to function (it wasn’t a huge issue before, but it was a little annoying, so I’m glad it’s fixed).
The OpenFeint notifications appear at the top now (and look much better thanks to OF being upgraded from 2.4.x to 2.7.2).
Web Popups have been greatly improved. Not only do they load faster, but the progress indicator shows in the center of the screen (instead of at the top left corner, halfway out of view). The best improvement is that when you load a new web popup, the previous web popup content is now cleared. So now, web popups can be even more tightly integrated and made to look even more “part” of your app.
Overall I’m very happy because lately, I’ve been using a lot of Web Popup in our games. So congratulations to the Ansca team for another great release!
…and I can’t resist mentioning it at least once in this post: I can’t wait for in-app purchases :-)
Just a few more things on the checklist and Dragon’s Keep 1.1 will be ready to be submitted!
Once I finally figured out how to create the Facebook Friends Leaderboard, I realized I needed some kind of personal resource to keep track of “how to” do all of these different things in Corona that aren’t in the official documentation—because frankly, I can’t remember every single step of the process. Figuring it out was a long, hard road of trial and error.
So the idea of creating a separate website for Corona tutorials to explain step-by-step how to do things such as the Facebook Friends Leaderboard, scene management, and anything else that’s not covered by the official Corona documentation/examples sounded like a great idea. That way I could look back on it everytime I need a “refresher” on how to implement something. At the same time, it could be a useful resource for other Corona developers.
Sure, I could post all that here, but I don’t want to have to sift through a bunch of news and personal updates to find what I want, so I decided to create the website and yesterday it went live with the first tutorial.
The site is called
iDeveloper and the first tutorial is on creating a Facebook Friends Leaderboard.
The site can also be accessed from CoronaSDK.com.
Ansca CEO Carlos Icaza Assures Us That IAP is Coming. This is great news. Hopefully it comes out in the next release so Beebe Games can start taking advantage of it right away!