Pokemon Java Engine
View Single Post
February 16th, 2013, 01:16 AM
Lead Dev of Pokémon Essentials
Join Date: Jan 2008
Originally Posted by
I see what you are saying, and my thought is: if my system doesn't work in the end, I can change it. I like how the mapping system is looking right now, but if it ends up not working out, I've already programmed the kind of 3 layer system that you were talking about, and I can do it again. But I disagree with you about the confusing part, in the real world bridges have to be higher than you so that you can go under them, which is basically the basis of my system. I don't think of the layers so much as layers of tiles that look nice, but as different heights of different objects in the world. What it also does is simplifies the creation of maps, instead of having to tile the entire map, then go back and do movement permissions, you can just tile the map once and you are finished. And for bridges and such you have layer changes for the player, which are simple.
True, you can always change things if you need to. I was just wondering whether your current system is overkill (which I'm still sure it is as far as infinite layers is concerned).
Perhaps 3 sets of 3 layers would be an alternative. Each set corresponds to a level the player walks on, and contains 3 tile layers
RMXP. I suppose the player would be inserted between the middle and top layers for the player's current level, which the map-maker needs to change via some kind of eventing at user-defined points for the sake of bridges, etc. Tile passabilities are considered only for tiles in the bottom and middle layers only for the player's current level and below. Oh, and a single "layer" of events, perhaps with each event's level being definable for the sake of making them appear above/below certain layers (their functionality could also depend on the player's current level if necessary, to allow effects depending on the current level), but importantly there's just one layer for events rather than one per level - it makes working with them easier.
Just a suggestion. I haven't thought about it in too much detail so I don't know about all the ramifications.
I presume in your system that a tile's passability is defined at the tileset, like what RMXP does. Priority doesn't need to be defined, though, of course - that information is now defined by the layer the tile is in.
Originally Posted by
Yes... And those both are things that are not even close to becoming features on this engine at the moment. The problem with multiple tilesets is finding a good way to store what tileset is used for each tile. I want to be able to do this at some point, but this will probably require ANOTHER overhaul of my mapping/save system. And auto-tiles are definatly gonna be in the game, but it is not really a priority at the moment.
I imagine that would just be a case of keeping a list of tilesets used in the order they're used, and showing them glued together during map-making (see ROM hacking's AdvanceMap). Then each tile simply remembers the cumulative tile ID used there, and a couple of quick calculations are done in-game to figure out which tileset and which tile in that tileset should actually be used.
For example, I choose the 6th tile in the second tileset. The first tileset has 40 tiles in it, so the tile ID saved in the map data (the "cumulative tile ID") is 46. In-game, the renderer sees that 46 is greater than the length of the first tileset, so it subtracts that length from the ID and checks the next tileset for that ID (now 6).
Or you could literally create a new tileset on the fly in-game made up of the component tilesets, and use that for map drawing instead. It means each map ends up using just one tileset graphic. I believe Minecraft does this nowadays (or will once the next version comes out).
I don't know how autotiles would work, though.
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