Note: This is essentially a repost of information that is located deep within archived posts of the Corona forums. I thought I would report them here, to make them a bit more accessible. To be fair, this isn't revelatory info, but it is useful as a barebones guide for testing your apps on iOS devices.
And that's it! You're ready to start testing your apps and games on your mobile devices.
Note: This is essentially a repost of information that is located deep within archived posts of the Corona forums. I thought I would report them here, to make them a bit more accessible. To be fair, this isn't revelatory info, but it is useful as a barebones guide for iOS certification generation.
And that's it! you're ready to start generating your provisioning profiles.
Anyone who has taken a passing glance at this site knows that I have a healthy obsession with procedural generation, pathfinding, and cellular automation in general.
I've been messing around with Roland Yonaba's Jumper (my fork here) and getting it to play super-nicely with Corona SDK. Lua is a great language, and in my opinion, lends itself well to allowing developers to produce quality PCG in an intuitive way.
The logical next step is to see how well my Jumper modifications can scale. I've been testing with culling and enemy AI when applied to a random gameboard. I'm liking the results, and I plan on putting out a few games based on the tinkering I've been doing these past few months.
The GIF below shows off a bit of enemy AI independently moving about a grid, avoiding non-walkable structures and the main player. As a sidenote, I recently saw a note saying that Jumper doesn't optimize memory usage when calculating paths. I haven't seen a negative impact when using my Jumper implementation, but to be fair, the individual referencing the issue was generating a map that was much, much larger than anything with which I've been testing.
I've long expressed my enjoyment of Roguelikes and Procedurally Generated Content. The original sandbox games allowed you to explore a world that was never the same between each play through. The genre has seen a resurgence of late, and I couldn't be happier.
If you want to make your own roguelike, the bar is relatively low. There are assets that are free-to-use everywhere and tutorials for gameplay exist all over the web. I first started with game development in general, and Corona SDK specifically, by trying to develop a roguelike in order to learn Lua. I realized I was biting off a bit more than I could chew, having very little experience with either Lua or game development, and I backed off to learn from more simple projects.
But I’m back in full effect and wanting to learn more about this whole PCG thing. And if you’re anywhere close to Lua and want to implement some pathfinding logic for movement, you are going to be using Roland Yonaba’s excellent library, Jumper.
In Roland’s words:
“Jumper is a pathfinding library designed for grid-based games. It aims to be fast and lightweight. It features a wide range of search algorithms, built within a clean interface with chaining features which makes it very friendly and easy to use.”
Makes sense, looks good, tastes great, and will mow your lawn all for the low price of free. It works as advertised with the code provided in Roland's github, however, we want it to work right away with Corona. It takes a few steps before you see something interesting in the debug terminal, let alone the simulator window.
I recently forked Roland’s Jumper github and updated the main.lua to work out-of-the-box with Corona SDK. My additions were made to allow for player movement with touch functionality, and simple PGC GUI level creation.
The moving parts here are relatively simple, but I wanted to explain them so other folks can benefit. To start, the below is just creating the grid map upon which the pathfinding is based:
Next, we’re going to talk about the modified callNewPath function from Roland’s library. It collects the steps in the path, sticks them in tables (setX for movements on the X axis, setY for the Y axis) and illuminates the path set by the function itself. A quick note here: I changed the pathfinder algorithm to DIJKSTRA, but changing this doesn’t really break anything.
The below basically takes the character’s coordinates and relates them to the next movement cell, which has been stored in the setX/setY tables in the callNewPath function:
And here is what ties it all together. This steps through the path with the player using the movePlayer function on a timer loop.
That’s it in a nutshell. Pretty straightforward, but it’s always good to document. I’m working on remembering commenting my code, and this project benefits from a timer on my machine reminding me to put comments after all forward declarations and functions. Hopefully it will help other folks.
I'm just going to leave this here.
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.
You could add some G2 filters to the pixels to make it really fancy, but I kept it bare-bones for reference purposes.