RPG Maker Tileset Builder (Current Release: March 25, 2015)

[taarna23]

NEW: Now supports RPG Maker XP tiles to be used in VX Ace! Animations and autotiles placed on their appropriate tileset type will be automatically modified to work as animations and autotiles on VX Ace.


Edit: Two fixes on the 25th - one to prevent a crash and one to prevent locking out of a tileset loaded for editing; it may now be overwritten when saving.


So, I realize this is fairly old... I plan to start from scratch(ish) on a new version in the coming months. At work, I'm going to be transferred out of programming for 3-6 months, as some of my other skills are needed elsewhere. I'll need to be able to work on something to keep from getting totally rusty. At this point, I plan to support MV (surprisingly easy), and we'll see how it goes from there. Upside: my existing tileset data will be usable.


Please forgive the lack of updating the documentation - it is late at night. I hope to provide updates in the next couple of days. Use of the XP tiles can be achieved by adding the parent folder (RPGXP for Steam users) to the folder manager. The program knows what to do from there.


RPG Maker Tileset Builder


Please note that this post may not be kept up-to-date. For current information, please view the page available at Catball Games.


What is it?


The RPG Maker Tileset Builder is a program made by me to help facilitate the creation of customized tilesets from existing tilesets for RPG Maker VX Ace. This is an ongoing project with each release currently adding additional functionality.


How does it work?


Load the program by double-clicking the RPGMakerTilesetBuilder.exe.

• NOTE: Under no circumstances should you delete or modify the included XML, config or SDB files - this will break the functionality of the program.
  
• NOTE: The included PNG graphics files are for the background grid - removal of these will NOT break the program, but you will have no grid, only a cyan box. Feel free to edit if you do not like the boring gray grid.
  

When the program is loaded for the first time, or if you haven't previously chosen an RPG Maker folder, you will be notified that there are no folder configured, and that the program is defaulting to the included tiles folders.

Spoiler

Spoiler

After this message is displayed, the tileset builder will be loaded using the default tiles folders. Enough images are included to have at least one of each type available. Note that due to the way these load, wide tiles will not have a preview version and may exceed the bounds of the display.

Spoiler

Spoiler

To load an RPG Maker folder or tileset folder, select the "Open Folder Manager..." option.

Spoiler

Spoiler

The folder manager will appear, allowing you to add or remove folders for use in the application.

Spoiler

Spoiler

Clicking the "Add Folder" button will open the folder browsing dialog.

Spoiler

Spoiler

Multiple folders can be added to the folder manager. The first one that contains the needed files (determined by the first and last tileset image used by VX Ace) will be used when actually loading tiles from. Folders that can not be used will be ignored. You can specify either the RPG Maker folder, or the tilesets folder itself, both pictured below. When done, you can click the X or the "Close Folder Manager" button to return to the main application.

Spoiler

Spoiler

Once you have your RPG Maker folder loaded correctly, you can select a result resource pack using the "Resource Pack" dropdown. This tells the program where to source the tileset graphics from.

Spoiler

Spoiler

After deciding where to source your graphics from, you can choose what type of tileset you want to make using the "Result Tileset" dropdown, and you can choose what tileset to display graphics from using the "Source Tileset" dropdown. Note that Source Tileset will be unavailable if you are using the Custom VX Ace option, as loading is done by way of folders of individual images, and not tilesets.

Spoiler

Spoiler

After that, simply click on your grid to place and remove tiles. Left clicking will place a tile "block" (a complete autotile, generally speaking). Right clicking will remove it. If working with an A5 for B-E tileset, right clicking will remove one square of the grid, rather than attempt to guess at what you want removed and potentially removing parts you want to keep.


Known Issues


As with most programs, especially those in development, there are issues.

• Tiles are NOT removed beneath one being placed. Watch your transparency if just going over an existing tile. This may actually prove useful for things such as creating a table tile that already has something like a map or notebook on it.
  
• Only supports RTP and custom folders.
  

Future Plans

• Support for additional tileset packs beyond the RTP.
  

Downloads


The part everyone wants! Everything needed except for your copy of VX Ace is in the zip. Remember not to alter the XML files.


Download link: RPG Maker Tileset Builder

 

[ElementalLight]

nice is there a download yet?

 

[taarna23]

nice is there a download yet?

No... That would be why it is still in development.

 

[ElementalLight]

well to be fair thins can still be in development while being released but ok thank you for answering my question.

 

[taarna23]

well to be fair thins can still be in development while being released but ok thank you for answering my question.

Okay, I'll clarify: It's been in development on weekends and during work lunch hours for maybe two weeks, by someone whose skills are rusty and is looking into entirely new aspects of programming never faced before. Once I bypass my major hurdles, it should go faster. Except for writing out all the information for supported tilesets in XML. That one will be tedious and time-consuming.

 

[EternalShadow]

Ok so basically when we find tiles that go into the E tab, but these tiles only fill half the tab, we can add a second tilesheet to that same tab via this program to create a grid-formatted tileset, for example?

 

[taarna23]

Ok so basically when we find tiles that go into the E tab, but these tiles only fill half the tab, we can add a second tilesheet to that same tab via this program to create a grid-formatted tileset, for example?

Um... I'm not really sure what you're asking? You seem to be asking if this will add additional graphics to what is already loaded into RPG Maker. If that is the case - no, that is not what this is for, The idea behind this is to allow users to pick and choose from existing resources to create a custom tileset image. This is similar to what people already do with graphics programs, it just simplifies the process.

 

[EternalShadow]

Oh, no - I meant does it basically merge images and put them into tileset format? I didn't mean adding graphics into sets already in RM.

 

[taarna23]

Oh, no - I meant does it basically merge images and put them into tileset format? I didn't mean adding graphics into sets already in RM.

Sort of, I suppose. You're creating something entirely new from compatible bits and pieces. Compatible meaning that you're not going to be able to go an put an A4 tile piece into an A1 tileset. The result, of course, wouldn't work correctly.

 

[TheoAllen]

Interesting. Gotta follow this update.

Keep up the great works

 

[cosmickitty]

this is pretty interesting, will it work with the smaller object tiles or only autotiles?

 

[taarna23]

this is pretty interesting, will it work with the smaller object tiles or only autotiles?

For the beginning, just Autotiles. I do want to support B-E tiles, but I need to figure out HOW. It's a little complex.

For a general update - I can now save the resulting image in PNG format.

 

[Andar]

For the beginning, just Autotiles. I do want to support B-E tiles, but I need to figure out HOW. It's a little complex.

???
The autotiles with their different formats are the ones that are usually considered complex.


B to E tiles are simple grids of 16x16 tiles with 32x32 pixel per tiles.


If you have any problems with such things - just ask, there are a lot of people in this community who will gladly help you to make such a tool.

 

[taarna23]

???

The autotiles with their different formats are the ones that are usually considered complex.

B to E tiles are simple grids of 16x16 tiles with 32x32 pixel per tiles.

If you have any problems with such things - just ask, there are a lot of people in this community who will gladly help you to make such a tool.

I will be honest - I found your reply to be somewhat condescending. If you are a programmer and understand what needs to be done, offer assistance. If you are not a programmer, please do not assume this to be simple.

Autotiles are simpler because they tend to have a set shape and size. Whether or not they are difficult to create is not the issue. They are rectangles, always the same size. They are predictable and as such, easily placed.

B-E graphics are not consistent. They can be any shape and size. How do you place these while minimizing waste of space? I have an idea, but I would prefer to focus on an initial release before tackling that one.

 

[Andar]

B-E graphics are not consistent. They can be any shape and size. How do you place these while minimizing waste of space? I have an idea, but I would prefer to focus on an initial release before tackling that one.

You misunderstood something here:
B to E graphics are consistant, they are always rectangles and they are always 32x32 pixel large - from the engine side.


However, a lot of artists either used only part of the 32x32 pixels, or combined several tiles to form non-regular tiles - from the viewer's side.


But no matter how the tileset creators use the existing grid, neither the editor nor the engine can leave that grid, and for them the B to E tiles are ALWAYS rectangles with a fixed size of 32x32 pixels. And if you try to leave that grid because some tileset made a 4-tile-sequence of about 50x50 pixels (but with a transparent frame of 7 pixels to each direction, because the engine forces it into a 64x64 pixel-sequence of 2x2 tiles), then you'll end up with a lot of problems, because everything in the engine enforces the 32x32 pixel grid for B to E tiles.


So what you need is not some way to store the non-consistent used part of the consistent tile-grid, but a way to remember sequences of consistant tiles that have been used by the artists in a way that hides that consistency with a large transparent frame. Because you cannot remove that transparent frame without getting in a lot of problems.

 

[taarna23]

You misunderstood something here:

B to E graphics are consistant, they are always rectangles and they are always 32x32 pixel large - from the engine side.

However, a lot of artists either used only part of the 32x32 pixels, or combined several tiles to form non-regular tiles - from the viewer's side.

But no matter how the tileset creators use the existing grid, neither the editor nor the engine can leave that grid, and for them the B to E tiles are ALWAYS rectangles with a fixed size of 32x32 pixels. And if you try to leave that grid because some tileset made a 4-tile-sequence of about 50x50 pixels (but with a transparent frame of 7 pixels to each direction, because the engine forces it into a 64x64 pixel-sequence of 2x2 tiles), then you'll end up with a lot of problems, because everything in the engine enforces the 32x32 pixel grid for B to E tiles.

So what you need is not some way to store the non-consistent used part of the consistent tile-grid, but a way to remember sequences of consistant tiles that have been used by the artists in a way that hides that consistency with a large transparent frame. Because you cannot remove that transparent frame without getting in a lot of problems.

In all fairness, I don't think anyone wants part of a table or half a mirror in their tileset - additionally, to force users to wade through up to 256 small squares that contain PART of what they are wanting to use is just plain asinine. I'm proposing that each tile block represents a single whole item, regardless of size. 2x2 squares, 1x1, 1x2... It doesn't matter. Whole items are added to a tileset.

By the autotiles being a consistent size, I mean that, in the case of animations, water is always 192x96, and waterfalls/smaller animations are always 64x96. This is consistent; always the same shape and size.

 

[Andar]

I completely agree - but that's why I said you need to store the sequences of tiles, not the content.


However, there are some assumptions that you can do, even if storing the content independently:


1) Any tile will be an rectangle.


That is because the editor can only select multiple tiles if they are a complete rectangle - even it an object looks like a T, any tileset creator I know of will still make it into a rectangle, letting the bottom edges both be transparent even if there is enough place for other tiles there.


If you were to place other tiles into that free zones, you would have to either pick each tile single, or delete the other tiles after placing on the map.


2) All tiles will be multiples of 32x32 pixels


The editor simply cannot handle other sizes, and the passage settings would also be impossible to handle.


I would still handle the larger pictures with meta-data ("Object 7 consists of tiles 32, 33, 34 forming shape 4"), but if you want to store them as pictures then still make them multiples of 32x32, because you'll never know how the original artist was placing it in the grid if you remove the transparent frames - some of those pictures need to be off-center to fit on other tiles that are used as tables or similiar situations.


And if you store those tiles as pictures with multiples of 32x32, simple grid positioning will fit it to the tilesheet - perhaps you'll need a bit storeage to indicate which tiles are already used, but that's it. You don't need to foolproof the tool against everything...

 

[Onomotopoeia]

I know mostly how to do this in Java, because I've been creating my own editor and engine; I've been following an independent tutorial series on YouTube where the objective is creating a 'platformer' -- somewhat identical, because the tutorial dealt with loading tilesets much like the B-E graphics; unlike the OP, what *I* have trouble understanding is parsing the autotiles (series A1-A5 tiles).


More specifically, I can figure out how to load the tiles; I'm just at a loss of how to do the automatic placement of the proper tile in an autotile sequence in the map editor. Do I have to look at the tiles north, south, west, and east of the placement position, to know which tile is the next one to place?

 

[taarna23]

I know mostly how to do this in Java, because I've been creating my own editor and engine; I've been following an independent tutorial series on YouTube where the objective is creating a 'platformer' -- somewhat identical, because the tutorial dealt with loading tilesets much like the B-E graphics; unlike the OP, what *I* have trouble understanding is parsing the autotiles (series A1-A5 tiles).

More specifically, I can figure out how to load the tiles; I'm just at a loss of how to do the automatic placement of the proper tile in an autotile sequence in the map editor. Do I have to look at the tiles north, south, west, and east of the placement position, to know which tile is the next one to place?

Well, while I wish I could help, I don't really do anything with the autotiles beyond set a rectangle to crop, crop it, and paste the result into the tileset in progress.

As for your issue, I think you're likely on the right track with looking at surrounding tiles. You need to see what's already there and decide what the current tile being places is going to look like as a result. Seems like it could be quite complex.

 

[Onomotopoeia]

I must correct my earlier statement; it seems A1 - A4 are the autotiles, and A5 is for regular tiles like the B - E tile sheets.


But yeah, figuring out the algorithm for "proper" autotile management is ... a unique problem that I haven't dealt with yet.