I'm just going to leave this here.

1. Download CoronaViewer code
   
2. If necessary, add your custom build.settings code to the CoronaViewer build.settings code. DO NOT OVERWRITE THEM. Add your code to the existing code. Also, replace their config.lua file with yours.
   
3. Build the CoronaViewer app
   
4. Install the CoronaViewer app on your device
   
5. Authorize CoronaViewer to access your dropbox account
   
6. Shut down the CoronaViewer app
   
7. Go to your dropbox account either through the desktop or web interface
   
8. Locate the Apps folder, and drill into it
   
9. Locate the CoronaViewer folder, and drill into it
   
10. Place ALL of your files into this folder. Basically, drag and drop your entire file structure from your project folder into this folder
    
11. Start the CoronaViewer app on your device
    
12. Allow the app to sync the files from your dropbox account
    
13. The CoronaViewer app should now run as though it is your project
    

Note that you don't need the desktop Dropbox app in order to use the CoronaViewer project on your device to update. You can use the web interface to drag and drop your files.

I know Rob put up the definitive post on non-physics collisions in Corona, but I've collected a few other methods that I wanted to record for posterity. They might be redundant in some cases, but I feel that one option is better for certain applications than another. Do with them what you will:

This is hardly groundbreaking, but I thought I'd throw this explosion logic out there, to save someone a couple of minutes or hours of experimenting with physics explosions in Corona SDK.

https://github.com/pancsoftware/explosionlogic

You could add some G2 filters to the pixels to make it really fancy, but I kept it bare-bones for reference purposes.

I’ve been tinkering with some rotation of objects by axis, and I’m starting to like the results. I don’t know how applicable it will be, but I like the animation I’m getting from messing with the logic. I got the idea from a link in the CoronaLabs forums, and I thought I’d catalogue what I’ve discovered so far (github link can be found here).

Below, some simple rotational logic by axis:

This is just some super-simple rotate logic that can be used in a wide array of applications. The rate of rotation can be slowed down/modified so that the rotation can be a bit smoother, but other than that, I find it very useful. I actually used this in the inventory logic of Infiltration, just because I (like the rest of the world that owned a first or second generation iPod Classic) find the spinning mechanic therapeutic. Something about an added ratchet sound is great. I need to remember that…


Here is some interesting rotation logic with staggered movement:

According to many, touch devices are no place for on-screen controls. Putting anything on a screen that will permanently obscure the game field is solidly "doing it wrong" territory. 

I am not one of these people. I think on-screen joysticks and controls have their place and can be used to great effectiveness depending on the application. That generic statement aside, it's absolutely possible to make a joypad on a touch screen work the way you want it, and make a fun game in the process.

I have a few games in the pipeline that will be incorporating onscreen joysticks to play  them, which I don't believe will decrease enjoyment while you're playing. The gaming public will be the judge, but I don't see it as being a huge problem when you're looking for an experience that can only be replicated with a bunch of arrows and buttons.

https://github.com/pancsoftware/gamepadlogic

I have always been a huge fan of Peach Pellen. Her tutorials on the now-defunct techority were integral for allowing me to learn the best way to handle simple sprite movement in Corona. Unfortunately, I started learning in the complete backwards way to accomplish my intended goal: how to identify if a player object touches a "physical" stage object.

<DISCLAIMER START> The views expressed below are my own personal opinion. This is very likely not the best way to accomplish the desired result, and you may very well think that I am a brain-dead, low-life idiot for even suggesting that my code is an option. You are entitled to your opinion as well. Feel free to flame the comments and/or close this browser window if you're not smelling what I'm cooking. Also, all assets are products of my own effort. They aren't that great, so I don't know why you would want to steal them anyway. Keep an eye on my opengameart profile to see what I'm posting and the corresponding license(s) </DISCLAIMER STOP>

I've included the full tutorial zip below. I'll be first talking about the main chunk of the sprite control schemes in the main.lua file. As we go on, I'll be posting updated main.lua files, showing our progression as far as how I feel to best implement Sprite movement. 

If you load up the main.lua, you'll find a very simple game screen: you've got your man in the middle, surrounded by trees and grass tiles. I'm not going to go into how I got to the PCG tiles right now, but I will in future installments. 

Anyway, once loaded you'll see the sprite assets. Ground, character, directional arrows, you get the idea. Touch an arrow to make the player move in that direction. However, if we take a look at the code within main.lua, we'll see that the character itself isn't moving around the background, we're moving the background display group around the character.

This can be useful in some cases, and in RTS/TBS games, you might be able to get away with the below workflow (this is all taking place within a touch event):

1. Identify that a movement is about to take place (began phase)
2. Confirm direction of movement
3. Test completed movement logic to confirm that movement can take place (no enemies/barriers/obstacles)
4. Perform movement so that the player can see movement taking place
5. Perform actions that completed movement may have initiated.

This option would work fine with the above, but it's not very sound practice when dealing with fluid movement. And since fluid movement is what we are all striving for, I didn't stop there. I'm going to point out that I struggled with this for quite some time before I found something that works for me. What I finished with isn't the end result, and it took me a lot longer to get to the finish line than I wanted, but I got there!

I fooled around with my code until I got to the main1.lua example, which incorporates some interesting logic into the movement phase. Instead of redrawing the map, character and all that, you are now moving the character, and the gameview moves within a pre-defined set of bounds. I also added in some bells and whistles, so now, the player can move freely, but will not be able to move through trees. Not bad for a super-novice! Check out the code and let me know what a moron I am in the comments!

Welcome back to our fifth installation of Corona SDK tutorials. 

Fifth Tutorial: Balloon Popping game

Hello again! In the last tutorial, we talked about different methods of spawning objects on screen, and how to keep track of those objects. This time, we are going to talk about collisions, and what to do with them.

One of the many attractions of Corona SDK is the fact that physics comes built in, and there is a lot of logic that comes with a physics implementation. We have talked about physics a bit, but only as it pertains to the game world we have created. Now, we can talk about writing functions that DO SOMETHING when an object collides with another object. Collision functions can make things very interesting in our world, and certainly more interesting than they are already.

Let's revisit our code:

Now, we are going to write another function, but this one is going to be a collision function. If you're still a bit foggy on the listener/event system that Corona uses, please read this:(http://www.coronalabs.com/blog/2011/06/16/the-corona-event-model-explained/)

So, what we have above is our spawning function, which creates 5 balloons. You'll notice I modified the x and y coordinates a bit, so that the balloons are a bit spread out when they are created. Next, we have our touch listener function, which changes the colors of our objects when we click on them. Last but not least, we have our newly-created collision listener, which changes the color of the balloon that has affected the collision, and will print out the name of the balloon that has affected the collision. Be prepared to see a good amount of text printed to the terminal. 

This is a very simple example of what can be done with a collision listener and objects. Let's get a bit more complex. I'm sure you all have been looking at the spawning code and thinking to yourselves "What's going on with that 'testBalloon1.id = i' bit?" Well, here's where it comes into play: 

Declaring the id's of the balloons makes it much easier to identify which object is being acted on, and is doing the acting. Punch in the edited code above, and reload the project.

Now, every time our third balloon collides with anything, it changes color. You can still change it's color by clicking on it, but it will change back every time it collides with something. This makes things a bit more interesting, and all manner of functionality can be derived from this. 

For more technical information on collisions, please see Corona's collision documentation here(http://developer.coronalabs.com/content/game-edition-collision-detection). It explains it far better than I ever could. 

Next time we'll go over some info on graphics interaction and best practices for sprite functionality. See you then!