And, ... back to the development talk. It has come to the point of needing graphics to start testing some of what I got. If you happen to know me, you would know that I'm no artist; even Colonel Klink could draw better doodles than I, lol. But, I do need some graphic assets for testing my project.
Since what I'm creating is directly inspired by the works of Enterbrain, namely, that "RPG Maker" program, I will be using sample tilesheets to test out my program's features. In the initial state of development, I will be coding to parse those RM tile sheets into their individual tiles, so that I can both begin working on the Mapper part of the editor, and have the engine capable of reading the same tiles for display to the screen.
In the VX Ace program, I have been examining the properties of the tilesets. Each tileset has a name (for in-editor use only), a mode, a number of tilesheets, and a note field. In turn, each tilesheet contains the selectable tiles that are used to make the maps. Finally, each tile may have assigned a number of bit-based properties.
For each tile, RPG Maker apparently uses twelve bits; that's right, one and a half bytes (unless they have undocumented tile properties). Five bits are for boolean-state properties (is passable, is ladder, is bush, is counter, is damage); four bits are for passage in the four cardinal directions (north, south, west, east); and three bits are for the field tag (0-7) assignment. If we wanted passage also in the diagonal directions, that would add four more bits; and if we wanted to extend the maximum field tag value, we could add additional bits to that, if necessary.
In my editor and engine implementation, I would be using something akin to Steganography, the science of putting information in plain sight, as it were, inside the images as additional rows of pixels. The editor would parse these pixels' RGBA color byte values as booleans and other bit-based information. (From reading RPG Maker's help files, the A1 through A5 "auto-tiles" may have additional properties; for example: a tile may be classified as a forest-type autotile if the pixel four inward from the bottom and right sides (coordinates <27,27> from the tile upper-left) is transparent. For auto-tiles, this might be better as a bit-based value, instead of blocking that pixel location.)
- The bottom-most row of pixels might be for general tilesheet-relevant metadata: default tile width/height, expected tiles wide, expected tiles high, a simple name, ext cetera. Perhaps we might have space for encoding the tilesheet update URL, so that the users of the editor and engine both might be able to update their graphic assets at program launch.
- The second-from-bottom row of pixels would be for the tiles' metadata, the twelve bits per tile mentioned above.
- Everything else in the image should be parsable as tiles.
Note that RM's tilesheets B through E are 512x512 sized PNG sheets, with 256 tiles per sheet. If these are images with RGBA values (recommended), that's up to 32 bits per pixel; so if each of the 256 tiles used one sequential pixel on the second-from-bottom row, we would still have room for about twenty more bit-based values for all tiles. But, for what it's worth, I cannot think of other expansion properties to use them, at this time; but I'll take reasonable suggestions.
It also comes to mind that, while discussing the tiles themselves, and their uses in mapping, that each and every tilesheet could, and perhaps should, have a miniaturized version as well, for a "mini-map" feature (like the saying, "killing two birds with one stone") that is lacking from Enterbrain's products. If normal tiles are 32x32, then the minimap tiles would be 2x2 or 4x4, whichever looked better for a map overlay.
Also, that depends upon the minimap size; the 4x4 tiles are a one-eighth reduction in size, so to show more of the map beyond what's on screen, the mini-map size must be larger than one-eighth of the screen width and height. A 2x2 minimap tilesheet is a one-sixteenth reduction, and may be adequate for generic games, though minimap definition would be low. A single pixel from the 4x4 tile represents 8 pixels wide by 8 pixels high, whereas in the 2x2 tiles, each pixel equates to a single quadrant of the parent tile that it represents. See the difference?
In summary, I've got basic classes for Tilesets, Tileset, Tilesheet, and Tile objects, all used to define the hierarchy of mapping tiles; these will be tested and tried, in the coming weeks.
