Blog

Latest news

Top Rated Products

adsLib, Corona SDK Libraries and free source code updates!

We’ve previously announced it in our newsletter, and now it’s here: a Corona SDK Libraries section in our store.
The first product we’re featuring is one that most of you are already familiar with, the Ads Mediator adsLib. It’s the exact same library that you can find in all our templates, except now updated with 5 more ads providers, including inMobi, Inner-Active, AdBuddiz, Vungle and the Gremlin Interactive version of the Chartboost plugin. The only difference is that this product is going to be updated more often than the one contained inside our templates, which will be updated every time we release a new update for that specific template.

You can check it out here.

We’re also pushing out new updates for all our templates, starting with Flappy Bird, Don’t Touch the Spikes and Swipe the Arrows.
All have now a remove ads option (complete with a restore iAp button) that can toggled on and off easily. They all come with the new adsLib version, which includes the above mentioned 5 new providers, for a total of 11 ads providers, and each one of them has specific new gameplay features that I’m sure will make the players happy!

You can check out the new updates in the videos below, and don’t forget to head to the product pages to check out what’s new!



Amazing Thief V1.0 Available to Members

Third and last template of september (but more to come in the early days of october), Amazing Thief Source Code challenges you to run through huge colored platforms without missing a step, or it’s game over.
As always, online leaderboards, ads, and social share plus the level of customization that is expected from all our templates.

This source code is available to all Members thanks to the 3 day early access benefit. All our other users will be able to get their hands on it the 3rd of October.
Become a member now to access 17 full game source code and benefit of a 25% discount on all reskin and ready for store services. The membership can be cancelled at anytime while keeping all the templates downloaded.

Amazing Brick V1.0 Available to Members

 

Here’s another awesome game. The Amazing Brick source code includes everything you need to make your own mobile super hit: online leaderboards, ads, social share, and it’s entirely customizable.
It’s a quick and fun game. Tap on the left or right side of the screen to make the brick jump in that direction. Avoid the colored blocks (which are fully customizable) and make the highest score possible!

This source code is available to all Members thanks to the 3 day early access benefit. All our other users will be able to get their hands on it  the 3rd of October.
Become a member now to access 17 full game source code and benefit of a 25% discount on all reskin and ready for store services. The membership can be cancelled at anytime while keeping all the templates downloaded.

Make Them Fall Full Game Source Code V1.0 now Available to Members!

Here’s one of our most requested templates yet, Make Them Fall.
In its V1.0, it includes everything you need to make your own awesome hit. 5 different difficulties (more can be added), online leaderboards for each, ads, share, rate, and iPhone 6 ready.

It’s also made using Composer, instead of Storyboard. In the next few days, all our templates will be updated (some for small fixes, others with entirely new features), switch to Composer included.
If you don’t know what Composer is, don’t worry, it’s just a different scene manager that’s going to be supported more from CoronaLabs.

The Make Them Fall Template is, as always, available with 3 days early access for all our Members, and it will become available to everyone the 29th of September 2014.
If you wish to access it sooner, become a Member! Members have full access to all our source codes, and a 25% discount on all our services. The membership can be cancelled at any time, while keeping all the templates you downloaded.

Corona SDK: Improve your game performances with Object Pooling

Performances have always been a recurring problem in game development. It’s true that the newest devices have so much juice that you could even ignore most optimization tricks (especially if supporting older/lower end devices is not in your plans), but there’s one technique that should always be followed, even if it all seems to run fine: Object Pooling.

Say it again?

Object Pooling. It consists in avoiding continuos creation and destruction of objects, by recycling the already existing ones. This produces several benefits that no one should pass on. First of all, there’s less “garbage” that the LUA garbage collector must take care of. This means reducing sudden FPS drops for apparently no reason. If you don’t use spritesheets for that specific object, you will also avoid the texture loading time that could occur when creating a new object that doesn’t have the image already loaded in memory, which freezes your app for a couple of noticeable milliseconds. It’s a quick and painless process that should be used in all the required situations.

So I should ALWAYS use it?

Wait. I said required situations. If you’re going to spawn just 2-3 copies of the same object, it might really not be worth it. Object Pooling becomes necessary when you have a ton of objects that you keep spawning in your game. Take for example bullets, and think of how many bullets will be shot in a generic shooting game. What about enemies in an Endless Runner game, that keep on spawning on top of platforms until it’s game over? These are the kind of cases where you should consider implementing an Object Pooling method.
Fortunately enough, it’s not particularly hard to do so. All you need is a “create” function, which will store the code used to create the object you wish to put in a pool, an “activate” function, which is called when you take the object from the pool and spawn it on your screen, and a “deactivate” function, used to get rid of an object on the screen by putting it back in the pool, ready to be used again. Oh, and don’t forget our Object Pooling code snippet, which will do all the dirty work for you.

How does it work?

The first thing you should do, is saving the above code into a LUA file called ragdogLib.lua. Next, we’re going to create a pool for several bullets that will be spawned on the screen when the user taps it. The bullets have different colors so you can see the recycling at work. Once spawned in the center of the screen, they will move towards the tap coordinates, while fading out until they completely disappear, ready to be used again.

As you can see, we call the initObjectPool function, passing it the number of objects we want in it, and a table that contains the 3 functions we already mentioned (create, activate and deactivate), plus an enterFrame function that will be used by all our objects. You can set any kind of additional function, it will always be automatically added to all the created objects. It’s important that the first argument of each function is “self”. Also note that you can completely remove a pool with the pool:removeSelf() function.

That’s it. By following the example you can increase your performances even in particularly intense scenes, without compromising on flexibility.

Corona SDK : One way to support different screen resolutions

Every developer has dealt with it at least once and it’s one of the first hurdles that needs to be addressed when developing a mobile game: screen resolution.
If Apple has made (before iPhone6 and iPhone6 Plus) this relatively easy, with just a couple of different resolutions, when it comes to Android and its fragmentation, it can become quite a daunting task.
Fortunately for us, Corona SDK has made dealing with these kind of things a walk in the park.

There’s several ways to approach the issue, it really depends on your preferences and your coding style. What we’re going to describe here is just our way of doing it, not necessarily the best one, but the one we have used for quite a long time and for which we never felt any need to update it. It also makes sure that all our templates support the widest range of devices possible.

How’s it done at Ragdog Studios SRL

It all starts by defining the coordinates of 4 major points: top, bottom, left and right sides of the screen. Once you know these, you’re able to position objects relatively to a specific side of the current screen, no matter what screen it is. For example, to keep an object always at the top-left corner of the screen, with 10 pixel from each side, you would write:

That’s it. There’s also a couple more numbers we need to run down. The full width and height of the screen. Since we’re already there, let’s localize two more variables for the sake of it. These define the exact center of the screen.

This can be used to stretch images all the way from one side to the other, or to all four sides. Stretching images is not always a good thing, but it really depends on the image itself. If it’s made up of just one color, or if the quality is still good after a bit of a stretch, knowing the exact sizes that would fill the entire screen is pretty useful.

What about config.lua?

We still like to work with a width and height of 320×480. Corona SDK makes it very easy to use 640×960 as a base, since you can define when to use @1x, @2x and @4x images, and it might not be too far off the day when we’ll switch to it, but there would be limited advantages, if any, in doing so. As you can see, we use “letterbox” for the scale parameter. “zoomEven” is also a viable option, but we feel that keeping the width size the same across all devices is more predictable compared to doing the same with the height.
There are also, once again, many other ways of doing it. For example, some users sets width and height dynamically, depending on the actual device resolution. This has the benefit of avoiding “half pixels” completely (or almost so), since the width and the height Corona SDK works with is an exact copy of the device resolution. If you use a ton of strokes in your vector objects, it helps making each stroke consistent, no matter the size or where you position it.
It ends up requiring a bit more planning though.

To wrap it up

The code that defines topSide, bottomSide, leftSide, rightSide, totalWidth, totalHeight, centerX, centerY should be placed at the top of each of your composer/storyboard scene files, and generally anywhere you’d like to have that kind of data to position your objects. The settings in your config.lua file won’t affect the outcome of these variables, so they can be used in any kind of situation. Obviously always make sure to do a round of testing with the Corona SDK Simulator, which offers several device views to try out in a breeze.