Hey, I just posted a 30 minute tutorial video (and sample project) to the GitHub Wiki…
https://github.com/superqix/CoronaTiled/wiki
Or just click the image above… (You may want to crank the quality up to 720p)
Hey, I just posted a 30 minute tutorial video (and sample project) to the GitHub Wiki…
https://github.com/superqix/CoronaTiled/wiki
Or just click the image above… (You may want to crank the quality up to 720p)
Great!
Just to be clear, “transcript” means to write down everything you say in the video, or to create a similar version in text format?
Either way, I don’t mind 
C
Totally not word for word :D I think it’s more just listing out what’s there (and probably what’s missing too…)
Like Layers can have “physics:enabled=true” but individual objects can’t. Tile’s can have shapes, but objects can’t.
Really what we need is a documentation outline.
I’m thinking we should, come to think of it, go for a more complete internal loading method. That way, we can focus more on the “game engine” part. An idea I had was the ability to use CoronaTiled preferences (like “renderMapOnLoad”, “buildObjectsOnLoad”, etc), but then I thought there had to be some way to render/build after loading. Anyhow, I’m thinking more on the lines of a fully automatic engine; [lua]CoronaTiled:buildMapEntirelyWithoutMeHavingToDoAnythingElse(“map.lua”)[/lua].
So that’s good news and bad news. The good news is that, if we adopt that approach, you don’t have to meld them. The bad news is that any work you’ve done on melding them might not be used.
Besides that, here’s a checklist I came up with for needed (and unneeded) things in my opinion:
Rendering (tiles and objects)
Properties (tiles and objects)
Suggestion for Map Heirarchy:
map
map.layers
map.layers[1]
map.layers[1].tile[x][y]
map.layers[2]
map.layers[2].objects[“myObject”] - Perhaps a string reference for object’s titles, as well as a number reference for quick looping…?
map.layers[2].objects[1]
map.layers[“background”] - Same here; double references to everything
map.props - Miscellaneous values of the map
map.tileWidth
map.tileHeight
map.mapWidth
map.mapHeight
…
Wide Load Abilities (TMX, JSON, Lua - the others aren’t really important)
Note: I think TMX support would be great. I’ll work on it. People could open a map in Tiled, save it, and load it instantly, skipping the export step.
Culling!!!
Note: I’m already working on this…
Camera System
Isometric Maps - Very hard (harder than culling - I’ve tried both) and not needed so much
Some way to generate custom events from Tiled and/or respond to them…?
Ok, so I’ve been working deeply on CoronaTiled - cleaning up your existing code, adding a lot of my own code, fixing this, fixing that - and here’s what I have.
You load a map with the .buildMap public function (if you think :load() is better it can be changed). You get a map loaded from the Tiled map data (.json or .lua). When it’s first loaded, nothing but objects and image layers appear onscreen - you have to either manually draw them or use .drawAllTileLayers. In the future, when culling is added, it’ll draw it automatically to the screen size (speaking of which, culling isn’t that far off, what with the progress I’ve made…). You can edit the drawn portion of the map with .draw or .erase, and you can draw all or erase all from the tile layers with .drawAllTileLayers and .eraseAllTileLayers. The map has a data table (_mapData, because you won’t have to access it that often) that has the original Tiled data in it. The hierarchy is as follows:
map
map.layer
map.layer[1]
map.layer[1].tile[x][y]
map.layer[“background”] - an object layer
map.layer[1].object[“object”]
map._mapData
Tiled data (what was read to create the map)
map.draw
map.erase
map.drawAllTileLayers
map.eraseAllTileLayers
EDIT: Just added ability to “call” map and get a data value; i.e. [lua]local mapTileWidth=map(“tileWidth”)[/lua]. This’ll makes all of the internal values to be read-only, so you can’t edit them, but you can still refer to them.
Supports -
Tile layers
Object layers
Image layers
Physics (using physics: as a property prefix)
Custom tile layer drawing
.lua and .json map formats
Custom values (using tiles: and objects:; layer values may be prefixed by layer: but they don’t have to be - values without a prefix are added to the layer itself)
Probably some more, but those are the major ones
I’m looking to get at least a camera system up and possibly culling before I release this version.
Ok,
I’m not sure if this is a stupid question(if it is dont scold me), but i have an object and it has physics enabled,
I have two buttons left and right and would like to somehow be able to move the object.
I did this with lime, but lime is slow.
Thanks in advance
EDIT
A camera that follows an object is basically what i need
do you know any possible way i can do that
Camera support is coming up with the next(?) update.
@No2Games:
I just loaded a map with 3,000,000 tiles (three million tiles!) spread out over 3 layers. The only thing that was slow was the JSON reading of it (I figured out it was JSON because I tried using a dummy load function that just read the JSON file and returned a decoded table, and it took the same length of time as the entire loading of the map).
I made the map slowly pan over to the side, and I added the ability to drag+drop the map. No visible lag. Period.
Simply amazing…
ETA for next update?
And i need to move my charecter object with two buttons
I’m not able to do this like i could with lime
In lime i could use a playerSpawn and then do
local player = display.newImageRect(object.playerImage,32,32)
And then use a button onClick to move it
If you could help me that would be greatly aprreciated!
AND THREE MILLION TILES!
HOLY!
EDIT
I feel stupid
I fixed my own problem
Thanks!
@Caleb Sorry for the slow reply, I’ve been out of town for a while and haven’t been following things like I should. That said, this sounds awesome. I can’t wait to check it out. Excellent work!
ETA… Not a fixed time, but it is coming up *soon*.
@No2Games:
Glad to hear you like it 
This may come as a shock, but I thought it would be best to say it now before this project is too large; namely, “CoronaTiled” is a bit too…straightforward. I really like cool names for things (I’ve made projects with names like VIVE, Btl, Idit, or Ivy - a near[er]-english computer language that compiles to Lua I’m working on), and somehow, “CoronaTiled” is great for describing the project, but not great enough for being a cool name for people to work with. Of course, if you think it’s gone too far to just up and change the name, that’s fine - I’ll live :) However, if you don’t mind all that much, I think we should change the name to something a little more interesting. Apologies if this sounds fickle, but the name of a project is important, and for me, "CoronaTiled"just doesn’t ring a bell.
Let me know 
If you are down with changing the name I am. I did like “Ceramic” as a name and I did start adding that to some of the files and then for some reason I stopped. BTW, I’m doing a talk for Corona in July on tile game development here in NYC. So lets try to get a release organized before July 9th so I can demo the system during the talk. I’m back early next week to help coordinate.
Funny - that’s the very name I was going to suggest because of the earlier naming ideas 
So now it’s officially Ceramic Tile Engine.
Great! I’ll start using that in the files.
I’m thinking we should, come to think of it, go for a more complete internal loading method. That way, we can focus more on the “game engine” part. An idea I had was the ability to use CoronaTiled preferences (like “renderMapOnLoad”, “buildObjectsOnLoad”, etc), but then I thought there had to be some way to render/build after loading. Anyhow, I’m thinking more on the lines of a fully automatic engine; [lua]CoronaTiled:buildMapEntirelyWithoutMeHavingToDoAnythingElse(“map.lua”)[/lua].
So that’s good news and bad news. The good news is that, if we adopt that approach, you don’t have to meld them. The bad news is that any work you’ve done on melding them might not be used.
Besides that, here’s a checklist I came up with for needed (and unneeded) things in my opinion:
Rendering (tiles and objects)
Properties (tiles and objects)
Suggestion for Map Heirarchy:
map
map.layers
map.layers[1]
map.layers[1].tile[x][y]
map.layers[2]
map.layers[2].objects[“myObject”] - Perhaps a string reference for object’s titles, as well as a number reference for quick looping…?
map.layers[2].objects[1]
map.layers[“background”] - Same here; double references to everything
map.props - Miscellaneous values of the map
map.tileWidth
map.tileHeight
map.mapWidth
map.mapHeight
…
Wide Load Abilities (TMX, JSON, Lua - the others aren’t really important)
Note: I think TMX support would be great. I’ll work on it. People could open a map in Tiled, save it, and load it instantly, skipping the export step.
Culling!!!
Note: I’m already working on this…
Camera System
Isometric Maps - Very hard (harder than culling - I’ve tried both) and not needed so much
Some way to generate custom events from Tiled and/or respond to them…?
Ok, time for an update on progress.
Note: These functions are all within the map object (created with .buildMap())
Culling is working just about perfectly (no bugs, no tile “leaks”) and is really amazing. Culling works faster the (a) larger tiles your map is made of (b) the less layers you have or © the less tiles you have (obviously). It’s pretty fast anyway, but it’s not such a good idea to use solid-colored-tile tiled backgrounds (repeating a solid colored tile to make a solid colored background), because it can slow down the culling engine part. Culling supports scaled maps - set your map xScale and yScale and then call resetVisible() and it’ll internally calculate the max visible tiles.
The camera system is working well, but it doesn’t support scaled maps. The map tracks an object specified with setCameraFocus(), sets bounds with setCameraBounds(), and moves+culls tiles with updateCamera().
You can lock tiles from being culled with setLock (iterates through chunk x1-x2, y1-y2). It takes five arguments. The first four are the dimensions of the chunk, and the last one is the lock state. A lock state of [lua]true[/lua] will lock tiles from being culled, and a lock state of [lua]false[/lua] will release any lock on the tiles. The lock state defaults to [lua]true[/lua].
You can manually draw tiles with draw(), manually erase tiles with erase(), and do auto-culling with render().
Alternatively, each layer (map.layer[index/key]) has their own versions of the drawing functions, so you can do them to a single layer with [lua]map.layer[“myLayer”].render()[/lua] or [lua]map.layer[1].render()[/lua].
Individual tile and object physics and properties are supported (edit tiles within a tileset or an object’s properties). Any property can be read as a table by starting the value out with [lua]!json![/lua] and then the value. So for a collision filter, you’d use this as your Tiled property:
[lua]
physics:filter :: !json!{“categoryBits”:2, “maskBits”:3}
[/lua]
(or something to that effect).
The type and name values for objects are stored in each object as “_type” and “_name”. If no name is found, it defaults to the shape + the object number; i.e. “rect5”.
Debug messages may be shown with [lua]ceramic.showPrints=true[/lua].
Single tiles are accessed with [lua]map.layer[“myLayer”].tile[x][y][/lua]. Single objects are accessed with [lua]map.layer[“myLayer”].object[“myObject”][/lua].
Each layer has two references; a numerical index and a string key equal to the layer’s name. Objects are done likewise; each object has an index reference and a key reference equal to their name.
That’s all the framework I can think of at the minute, but if I think of something else that’s really cool, I’ll comment again.
Sounds very cool. I like the !json! bit… Maybe there’s a way to do that by checking if the data has matching braces and assuming it’s JSON.
I think the plan should be to keep the current map rendering as a Ceramic:preRender(mapdata) for people who want to get a simple map (think puzzle games) up easily and make all this new stuff the default renderer.
Also posted your documentation on the GitHub wiki here…
The updates sound great, any idea when a new release will be available for testing?
Possibly later today… possibly. No guarantees, but all I have to do is fix up the GitHub repository and do pull requests and such.
I must admit, though, it would help if GitHub would make an easy-to-use app or something - I’m more of a coder, not a terminal user 
Ugh, you’re using GitHub without the apps? That’s hard core…
Go here for Mac http://mac.github.com/
or here for Windows… http://windows.github.com/
Yeah, I never touch the command line. Are you added in as a contributor?

I never even knew about the app!
Wow… Thank you ever so much for the link. I was just slogging through the terminal 
I actually sent a pull request a few minutes ago… Finally.
(the funny thing is it took me about 2 minutes to do it with the app, while I overwrote my files several times and never completed my push with the terminal - good thing Sublime Text 2 lets you keep files open and save them and they’ll re-create themselves, or I don’t know what I would have done :()