Pokemon Java Engine

[Maruno]

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 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.

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.

 

[danice123]

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.

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.

PIX:

 

[Maruno]

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.

Oh.

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.

"image removed"

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.

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 384, and there are some lines which say things like if @tile_id>=384).

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.

 

[danice123]

Yeah I was already thinking through the code necessary to remove a tileset, basically what you posted, and I decided that I don't really wana deal with that at the moment. I'll have to add it in sometime, but I can leave it out for now. I think I will have to add some sort of tagging/flags onto the image files at some point also, for things like surfing and autotiles, but I haven't found a real good way of attaching that data to the file. A separate file is a possibility, but that is a pain. Maybe if I can find a way to hide a few bytes inside a image file...

 

[Ayutac]

By the way, defining more than two ways on a tile (a multi-bridge) is kinda unnecessary and that's way I wouldn't bother with so many tiles/permissions but just mark some specific tiles as bride tiles which have a flag if the player is standing on or under them. NPCs generally just on bridges and finding items dependent on where the player is.

Did I mentioned interfaces? ... Oh yeah, I did.

If you have interest, I can give you the code for my mapper, even if it's just an unfinished rebuilt of the RPG-Maker.

 

[kudoms]

You should make it so that the window is re-sizable.

 

[danice123]

Year 2 update, see first page.

 

[PKMNxJoThRa]

Any updates?