Pokemon Java Engine
View Single Post
February 18th, 2013, 01:06 PM
Lead Dev of Pokémon Essentials
Join Date: Jan 2008
Originally Posted by
Ahh... I see where you are mistaken about my system. The tileset is not defined IN ANY WAY in the tileset file (as of yet). The tileset is simply a png of tiles. My system bases passability on the position of tiles in the layers.
Well, it still doesn't sound very user-friendly. It's yet another thing for the mapper to pay attention to; even though you have infinite layers, it's still harder to do. One example of this system making life harder is having a raised patch of land which you can also walk around the north edge of (see picture). In your system, to ensure you couldn't walk off the top of that ledge, you'd need to do change the player's layer and use higher levels. Defining passability in the tileset, though, you wouldn't need to worry about that at all, which makes it much simpler.
I assume, though, that you will define some properties for tiles eventually. For example, water tiles which can only be surfed on, or ledges or tall grass.
Originally Posted by
I have taken this and ran with it, spent a couple of hours, and I now have a new tileset system (its like my third...). Basically, you have a bunch of little tilesets that have tiles that are similar (all the grass tiles... etc) and the map will list them and allow you to use tiles from each in the map. The editor has no handling for removeing tilesets from the list however, mostly because that totally destroys the list of tilesets and the whole tileset system.
That's a good idea, to have mini-tilesets which act as categories of tiles.
Perhaps rather than having a tile's ID be a single number which is the cumulative tile ID, you could instead make it an array of the tileset number and ID within that tileset. You'll already have an array of the tilesets used for a map, so it wouldn't be that difficult to tweak.
When removing a tileset from the "used tilesets" list, go through the map to replace any tile from that tileset with a blank tile. Then compact the tileset list and change each tile's tileset number accordingly (i.e. -1 if it is >= the number of the deleted tileset).
Alternatively, keep the system you have but use a bit more maths to decide whether a tile's ID is in the area where the deleted tileset is (if so, make it a blank tile) or is in a later tileset (in which case, subtract the length of the deleted tileset). This isn't difficult either.
You could even check for unused tilesets in a map and remove them when compiling the data, to cut down on saving unused information.
You should have a separate "completely blank" tile somewhere, separate from the tilesets and always accessible. Perhaps put it above the tileset drop-down menu (the one which says "grass" in your screenshot) to show that it's important.
An autotile behaves as a small tileset itself. If you double-click one in RMXP, you'll see an 8x6 set of tiles which the autotile represents. When drawing an autotile on the map, RMXP will look at the 4 adjacent tiles and calculate which of the tiles in that mini-tileset to use (and will also change the adjacent tiles accordingly). Because RMXP has a fixed number of autotiles (7), it finds it easy to manage tile IDs. In fact, many scripts can be seen to account for this (the blank top-left tile counts as an autotile here, so 8 lots of 8x6 is
, and there are some lines which say things like
Knowing this, perhaps you should load an autotile in the same way as a mini-tileset, but if that graphic has specific dimensions, recognise it as an autotile rather than a tileset and display/use it differently accordingly. Maybe show the autotiles above your tileset drop-down menu (and don't include them in that drop-down menu), but still consider it behind the scenes to be just another tileset of a specific length when recording the tile ID information. The autotile's tileset needs to be created on the fly from the actual autotile graphic, of course. Autotiles should always be considered to be animated too, even if they only have 1 frame. The data of which tilesets are used in a map will also need to note which ones are actually autotiles, so that it can more easily show them animated (this allows only autotiles to be redrawn rather than all tiles).
It's quite interesting to see how something like this works, and how it could be generalised (i.e. allow a custom number of autotiles). Of course, you may not want to deal with the extra coding involved at the moment. All that matters for now is knowing that it's possible to have autotiles, and more conveniently that your current system can just be tweaked to include them rather than needing a huge overhaul.
The Pokémon Essentials Wiki
All Animations Project
View Public Profile
Send a private message to Maruno
Find all posts by Maruno
Find threads started by Maruno