That’s a lot of questions, lets see where to start. Modules. Yes, the use of the module() line has been deprecated. The current way is to do something like:
local M = {}
M.someValue = 10
function M.doSomething(withSomeParams)
…
end
return M
Where M stands for Module. If course you can name it what makes sense to you. This returns a table to the caller, so lets say this is my character.lua file. I would then do:
local character = require(“character”)
print(character.someValue)
character.doSomething(“Hello world”)
to access it’s members. I’m not a good person to cover doing this in a more object oriented manner, but you could have a .new() function that spawns your character and returns a unique instance. But that gets into metatables and such.
Prior to Graphics 2.0 we deprecated movieclip in favor of graphics.newImageSheet() and the new sprite API’s. When we released graphics 2.0, we also removed the legacy sprite library. The new sprite API’s are superior and handle retina graphics for you (automatically uses @2x and @4x resources if you provide them and however you have your config.lua defined). If you insist on using the old sprite library, you can get it from our github repository and if you look around hard enough you can still find movieclip.lua. But you will be way better off with the new sprite system (and I’m a huge fan of movieclip!)
As far as dealing with different screen sizes, I’m a fan of the Ultimate config.lua and it’s moderinzed version (read these in order as the 2nd one assume you understand the 1st one)
http://coronalabs.com/blog/2012/12/04/the-ultimate-config-lua-file/
http://coronalabs.com/blog/2013/09/10/modernizing-the-config-lua/
But this requires some creative positioning in particular doing tiled games. It assumes relative placement from the edges for the center and that the UI can change positioning based on the device. For instance in a landscape game where the number of lives is in the top left corner and the score is in the top right corner, they are okay to be further apart on an iPhone 5 and closer together on an iPad. Those elements stay a fixed distance from the left and right edges. Anything that needs to stay the same distance from the center has to be positioned relative to the center of the device.
This concept gives people the heebeejeebies when trying to say my bird launching sling shot has to be 300 pixels away from the pigs since you would have to draw the slingshot at display.contentCenterX - 150 and the pig at display.contentCenterX + 150. In this case you are probably better off having a fixed content area that’s centered on the screen and potentially have the ability to draw things at negative values on wider screens or at x locations greater than your content width. The key is to have backgrounds that cover the full range and you’re willing to accept that part of the background will “bleed” off screen depending on the shape of the device. Thus if you’re using a 320x480 content area, you’re background would need to be 360x570 to cover almost all current devices.
Rob