Thread: [Engine] Pokemon Java Engine
View Single Post
Old February 18th, 2013 (11:01 AM).
danice123's Avatar
danice123 danice123 is offline
    Join Date: Sep 2007
    Age: 23
    Gender: Male
    Posts: 14
    Originally Posted by Maruno View Post
    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 a la 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.
    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.

    Originally Posted by Maruno View Post
    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.
    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.

    Reply With Quote