I thought 30fps was standard for mobile games o.o

Yeah it'd be nice but Ashley already said this probably won't happen. In a case like this I'd put enemies & bosses in the same family and have a family variable to differentiate them.

digitalsoapbox This thread is about the future and potential of the new tilemap object & features. C2 is on the brink of having a very powerful level editor that is actually designed around the rest of the program, unlike Tiled, and we're just trying to figure out the best way to get there. There is no need to be so insulting about it or provide examples - further bloating & derailing this thread - as many users, including myself, already utilize Tiled & The TMXImporter and know all the "tricks" such as pasting tiles into a canvas. You are correct; it's not that difficult. Fact is, using C2's own layout editor allows you to do many things Tiled cannot, while at the same time Tiled allows you to do things C2's layout editor cannot. In the end, you can use whichever you prefer, but both need to be good options.

The short answer to all of this discussion is, really, use Tiled/TMX Importer. A majority of the feature requests are already implemented, and the big one that isn't - using big custom collision areas - is so inefficient as to be unnecessary.

Place tiles and use other, invisible tiles to set up collision in Tiled. If you want to build a tile-based game, that's the way it's done, and if you want it to be easier to build without having to wait on new C2 features, that's the way you should do it.

TELLES0808: You can do animated tiles with Tiled already. Have a single tile with custom properties set up in Tiled that tell C2 (through events) that the tile is animated and the name of the animation to use. Using multiple tilesheets works in a similar way.

Dude, no. While Tiled has a bunch of tile-based features it's overall kind of a crappy editor.

You have to hard-code every single object, property, background, tileset, effect

You need to keep a giant hand-typed list of object names, types, properties

You get no visual representation of the objects you're working with and can only edit them one at a time

You have to use sprites acting as tiles which is awful on performance, drastically increases loading times, and takes like 8 steps to update a single set.

You don't get a single feature/object C2's layout editor provides

You have to import every .tmx unless loading externally with node webkit

I have been using Tiled/TMX Importer for my last few games and it has the worst workflow imaginable. It was simply a workaround until C2 got its own tile support.

We, at long last, have a WYSIWYG level editor with both drag 'n drop AND tile-based functionality. With only a month or two of extra work C2's layout editor can be one of the best out there.

No problems yet!

Ashley

1) It's really not that bad for simple platformers or top-down games, but as soon as slopes and other shapes are introduced, using sprite objects for collisions can become a real hassle.

2) Ok cool. Just making sure!

3) Yeah, kind of ^^; I always got complaints on my earlier level editors not having these features, so I made sure to always add them. I even went so far as to rotate/flip/mirror groups of tiles like tetris pieces..although that was a bit much!

4-5) Glad to hear it :)

I completely understand not wanting to reinvent the wheel, and it makes perfect sense not to dedicate so much time on a robust image editor when tools like PS exist. However, I feel that tiles are one of the few exceptions here. Levels are arguably the most important part of the game and we need to be able to work on them quickly and efficiently to get all of our ideas in there and make changes, no matter how large, as needed.

Having used Tiled, Ogmo Editor, DAME, GM editor, Stencyl editor, and a handful of my own custom level editors throughout the years, I feel that the features I mentioned are quite essential and in no way "fluff". They will definitely be used by everyone!

Also I know it's a big list and everyone is making their own suggestions - we just want to voice our concerns before it is too late and you decide to move on to the next big feature!

Massive thanks to Ashley for finally adding tile support!

I'd like to discuss the future of the tilemap object / some features that will make building levels with it more practical...

1) There appears to be built-in collisions for the tiles, which is pretty cool, but they're just squares. Are there any plans to assign some sort of collision map so that we can have slopes and other shapes as well? I think that's how Stencyl does it. Usually you have one layer for your graphic tiles and another for collision tiles but without per-pixel collisions I'm not sure how that'd work here.

2) I assume a tilemap object is the equivalent of a big sprite object with a level image. Seeing as you only get 1 tileset and 1 layer per tilemap object, wouldn't it be extremely inefficient to have entire tilemap objects just for, say, a foreground layer of plants or a few tiles from a different set? Will anything be done about this in the future? It'd be great if a tilemap object can have multiple tilesets and maybe layers of its own.

3) Are there any plans to add tile rotating, flipping, and mirroring?

4) Will we be able to "copy" tiles that have already been placed (like right-clicking a tile in Tiled)? This is very useful for laying down certain patterns to place elsewhere, and keeps you from having to go all the way to the tileset to pick a tile.

5) Will there be hotkeys for the tools? (At the very least right-click to erase tiles?)

Would be very useful, actually, I just don't think it can be done with the way tiles have been implemented. Some uses...

Destructible tiles like in Metroid

Pinning tiles to moving platforms & interactive objects

Making tiles transparent/invisible to reveal hidden paths

Well, now that I think of it you can just use a separate tilemap object with your tile(s) of choice. Not the easiest way to go about it but whatever..

Depends entirely on the game and its existing mechanics..

Usable save data. I personally avoid the persist behavior, built-in save functions, etc. because you don't really have any control over it.

I haven't actually tried it but...You make a container with your player and a dictionary. When the dictionary is created, add 1 key per stat and a default value like

-Add key "Health" , 100

-Add key "Attack" , 5

-Add key "Defense" , 2

and if your player is chosen in the events it'll use the stats in the corresponding dictionary.

Then when you go to save the game you can download all the dictionaries as JSON data into a file or webstorage key and load them later on.

Not sure what the best way to tell the difference between the dictionaries would be though. It might be better to NOT use containers and instead give the player and dictionary an identical variable to compare.

Neither. I'd use dictionaries in containers with the characters... Each stat can be a key and you can save them all in a single file/webstorage key. Way better than instance variables.