bits.toPixels()

Ice Trap is getting closer to release. The game engine is almost complete and runs really smooth on all the devices I've tested on so far, including a crappy old Asus Android pad. The number of levels are increasing at a steady pace much thanks to the new level editor, and the graphics are also starting to feel really good and fitting for the overall atmosphere of the game. Some work still remain, such as adding music and sound effects, some social media features, and finalizing the levels design, finding just the perfect overall difficulty curve. Today I felt that it was time to spend some hours on polishing the exterior of the game, so I decided to create a brand new app icon, and also set up a simple landing page allowing people to register for email notifications about important news such as release dates. Ice Trap app icon If you visit the Ice Trap landing page , please let me know what you think about it. Especially if you notice any problems displaying it on you

I just received an e-mail saying that GameAnalytics has released an updated plugin for the Corona SDK. This is great news! In my last game Dragonflies I used the GameAnalytics plugin and was planning to do so in Ice Trap as well. It's an incredibly easy and efficient way to track your users' behavior, and if you're not doing it already I strongly recommend you to have a look at GameAnalytics. I haven't had time to test the new plugin yet, but will definitely do so in the near future. You can  read the full news about the plugin here .

One of the mistakes I made during the creation of my first mobile game Dragonflies was to not spend some time building a level editor. I figured the time it would take to finish the editor would be better spent just implementing the levels the fastest possible way. In my case this meant playing around with pieces of colored paper on a hand-drawn coordinate system, and then manually do the conversion from paper to json files. It actually worked out quite well in the beginning, until I started making more complex levels... Not only did it take a lot more time than expected, but designing levels became so incredibly monotonous and tedious. That's not exactly what you want when you're trying to be creative and come up with cool, new level ideas. Lesson learned. For my upcoming game Ice Trap I started out the same way, by just hand-crafting the level files in json format. But this time I knew it was only going to be temporary. When I got to the point where the gameplay felt soli

Ok, so you're working on a game and you have some objects that you need to configure how they should (or shouldn't) collide with each other. If it's the first time you're doing this you'll probably end up at the Corona Labs page about collision detection pretty soon. You read through the section "Collision Filtering" and can't help but wonder: Does it really have to be this complicated? No, it doesn't. There is absolutely no reason to force knowledge about implementation details like category bits and bit masks onto the developer. All you want to do is specify if objects of type A should collide with objects of type B or not. But to do this, you need to assign unique bit identifiers to each object type, calculate the bit masks yourself, make sure that two colliding object types cross reference each other and so on. It gets really nasty as the number of object types grow. Consider the example from the Corona Labs documentation in which there

I like many things about Corona SDK, but one thing I don't like very much is the API provided for handling of image sheets and sprites. In my opinion it is difficult to use and very fragile because of poor encapsulation and coupling, including things like: No common way to create images and sprites from the same image sheet. You're left using display.newImage() , display.newImageRect() and  display.newSprite() . Selecting frame from an image sheet is done using frame number, for example display.newImage(sheet, 1) . Not only does this expose implementation details, it also makes the code really hard to read since you don't know the meaning of the integer unless you examine the image sheet and actually count the frames. Imagine having a large image sheet with 20+ frames trying to figure out what image will be displayed by display.newImage(sheet, 13) ... And if you ever want to change the frame order within the sheet, you must also change every call to display.newImage()

A really useful online tool that I came across during the making of Dragonflies is the free sound effect generator Bfxr found at http://www.bfxr.net/ . As the author describes it: Bfxr is an elaboration of the glorious Sfxr, the program of choice for many people looking to make sound effects for computer games.   You have full rights to all sounds made with bfxr, and are free to use them for any purposes, commercial or otherwise. This is truly awesome to get for free if you're looking to create cool 8-bit sound effects for your game such as exlosions, powerups, coins etcetera. I used Bfxr for almost every sound effect in Dragonflies , and I'm pretty satisfied about the end result. At least I know I couldn't have done better without spending way more time or having to pay someone else to create the effects for me. Bfxr online sound effects tool   So if you haven't already tried Bfxr , I think you should definitely give it a shot. Besides being a very useful

A couple of weeks back I wrote this post about how to calculate the actual frame rate of your game rather than just hoping that the target frame rate found in display.fps will be met. Back then I only used it as en experiment, but today I wanted to implement it in my game Ice Trap to be able to reduce or disable some animations on slower running devices. I ended up rewriting the frame rate calculator in an object-oriented fashion to make it cleaner and more reusable. It should be very easy to use. Just create a new instance of the FPSCalculator, passing in a callback function and some optional configuration parameters. In the callback function you'll have access to the current FPS as well as the FPS ratio, i.e (actual_FPS/target_FPS). If none of the optional config parameters are specified the callback will be invoked once every second, regardless of whether there's been a FPS drop or not. Check out the whole source code below, including some example usage code, and make m

Just the other day I needed to create a "swipeable menu" for my next Corona SDK game called Ice Trap, where I want the player to be able to swipe left/right to select among a number of chapters in the level selection scene. Basically, what I wanted to achieve was this: 1. Have a number of display groups, each one representing one of my game's chapters 2. Only one chapter (display group) visible at the screen at a time 3. Allow for the user to swipe left/right to select chapter 4. Prevent swiping too far left or right 5. Use transition effects to slide the chapters into place nicely 6. Display a clickable thumbnail for each chapter, allowing the user to quick jump to any  one chapter. Also highlight the currently selected chapter Here's a simple sketch of the idea: After scanning the Internet for half an hour or so I still hadn't found a complete solution for this, so I decided to roll my own instead. What I did find was this small tutorial from Co