- This topic has 333 replies, 11 voices, and was last updated 12 years, 2 months ago by
.
-
Posts
-
don't think i have a choice on the transparency color, sorry.
when you load a tile set in tiled, you can specify the transp color tiled will use…
since the game will be running at a higher resolution, the tiny nes tiles will be woefully inadequate… so proper hexagon tiles would be needed in the final version or in the game art (since technically the tiled art and game art can be entirely separate).
edit: it's 06:12 unfy time (morning)… and i haven't slept yet… so… i'll be heading to sleep soon.
For the sake of people with small-ish monitors and people who like to run in a window, I'll be using 48×48 hexes. If someone wants to add additional tilesets, go right ahead.
i was targeting 1024×768, windowed.
with future plans of iOS and android devices.
48×48 is a fine starting point.
actual tile set graphics will have to be worked out later (ie: plains.png will have several frames for it to animate through, thus making the game graphic differennt than tiled, etc)… but for now static images are fine.
edit: amusingly, netbook i'm doing my current devel on is 1024×600 hehehehe… but no, 1024×768 is the current goal.
Unfortunately, tiled can't seem to handle hexagonal tiles that extend outside the standard area, even though it does so fine for orthogonal and isometric.
I guess tiled mapmaking here will wait until that's been fixed.
Start an orthogonal map. 32×32 tiles when making it, 64×64 tiles when importing tiles. Things work fine, and it perfectly respects tiles that stick outside the 32×32 area.
Start a hexagonal map. 48×48 tiles when making it, 64×64 tiles when importing tiles. Oh dear, the program resizes them in a most ugly way.
So unless I'm missing something…
i'm… possibly not sure what you're doing.
http://unfy.org/misc/da/step1.png
Creating a new map, 16×16 grid spaces, 32×32 tile size
http://unfy.org/misc/da/step2.png
Nice and empty
http://unfy.org/misc/da/step3.png
Map->New Tileset
Chose the hexagon example hexagon.png tile set (which i know aren't 32×32)
http://unfy.org/misc/da/step4.png
Was having a hard time getting ctrl-printscreen to work, but anyway… it seemed to divvy up the hexagon tiles as would be expected for the wrong size. Nothing attempted to get resized ?
I tried again with Map->New Tileset, and setting hexagon but 48×48… and it still seemed to do things fine ?
Looking at hexagon.png, the tiles appear to be 100×90 using my crude guesses in with MS Paint heh.
Opening the hexagonal_maqibooy.tmx in notepad (its just an xml file), it says the tileset has tiles of size is 100×91. Further looking at it seems to say similar.
Is there a chance you didn't take into account that hexagons are wider than they are tall ? When ya said 48×48, I just took it as a generation, but you're likely to be 48×44 or 53×48 instead (or something there about). IE: draw a square. Draw a circle who's edges touch all 4 sides (circle wholly fits within square). Generate the hexagon within the circle. While the < and > points of the hexagon will touch the left and right sides of the square, the top and bottom of the hexagon won't… thus it's wider than it is tall…
I used to stream some games on twitch.tv, so I've got most / all of the software already needed to screen cast or screen capture for video tutorials…. if that ever becomes a need.
Oh, and before you get too far into this — the flare export map format requires three layers. Colission, Background, and i think Object (not a true tiled-object-layer iirc).
I was going to use 'background' as the battlescape map, then use more tiles on the object layer to denote special cases (as for prior conversations — hand placed spawn points come to mind). Actually, I think it might be better for these hand place things to be "object layer" – i think it's easier to assign properties from within tiled for the objects then (just in case we want to add customization to the placed makers for whatever reason).
So don't go about having custom tiles with X's and O's in them already.
Tiled's source is C++, and I *hate* C++ (i prefer vanilla C), but if I really felt froggy it wouldn't be difficult to write a rotk2-project map exporter that's specific.
Anyhoo, as you can see, it's basically in flux and all up in the air (after all, just decided to use tiled last night / early this morning ?). For now, stick with just basic tile layout. If ya wanna create more tiles (desert), feel free too.. but avoid the X/O tiles for placing units right now.
The battlescape offers a lot of possibilities for changes and stuff, and although discussion is fine, I'm far from getting to that point :).
Tonight, if tiled still doesn't cooperate for you, I'll prolly attempt to construct an example map to post. If it *does* cooperate, I'll go back to making the code base more of a game rather than proof of concept screens (currently they just draw the map, you can click on it to bring up a province screen that fills out proper info, click again and it displays a general list you can sort and stuff, etc…. it needs to become an actual game rather than collection of screens heh).
GUI layout will indeed be specified via ini files, this way skinning the game is easier … particularly for the desire to port it to iOS/android.
Map-of-china stuff will need to eventually be more user editable as well (as well as for setting up the links between provinces)… but I really want stuff more game-like before getting into that. The more-game-like is the current barrier to getting a lot more input from people.
Oh, and since I don't think tiled can IMPORT flare maps, keep both the tmx and txt files for the maps handy.
My problem with tiled: http://img27.imageshack.us/img27/6199/thetileproblem.png
So unless I'm missing something…
And yes, that's a placeholder graphic.
The tile: http://img27.imageshack.us/img27/4969/maptilestest1.png
I read about TMX files in wikipedia just now, but shouldn't Tiled be able to handle tiles just fine without a tmx?
I had to take apart my netbook and reseat the touchpad and keyboard flat cables. grrrr… (touchpad stopped working).
i was able to get tiles that were an exact fit (48×43) to work correctly.
hexagon rendering order makes trying to draw tiles that are larger than than the specified tile size difficult. Similar problems can occur when doing squares….
when drawing the map, do you draw top to bottom ? or bottom to top ?
anyhoo…
i then took my 48×43 perfect hexagon and made two tiles out of it side by side, allowing for 8 pixels above and below it. i dunno if this is going to work wholly correctly with tiles that follow vertically (ie: does "spacing" also do vertical spacing as well as horz ?) … but i got it to semi-render correctly in tiled.
final tileset image size = 128×59 (gives padding of 8×8 all around). for the second hexagon i drew some arrows that went above and below the 48×43 area.
in tiled, i set the map to be 16×16 hexagons with a tile size of 48×43. i then added a tilset with a margin of 8 and spacing of 16. this at least centers the 'bigger than life' hexagon for tile rendering. when stamping the tiles on to the map, it clips the upper and lower out of bounds areas, though.
http://unfy.org/misc/hexmap1.zip
So.. this continues to beg a question… if tiles are allowed to bleed outside of their designated sizes… how do you know which order to draw them in ?
if the map is drawn starting at the top left, drawing left to right… any tile that bleeds out above where it should and to the left of where it should will render correctly. all other bleedings will get overwritten.
similarly, if we start at the bottom right, and draw right to left and work our way up the screen…. all tiles that bleed under the bottom or to the right will render correctly, the rest will not.
Thus… if tiles can be bigger than the hexagon map sizes:
1) we have to pick an order to render the map and to render it that way every single time
2) you'll have to ignore render 'errors' in tiled
3) every tile will have to be this same 'bigger size' because the game renderer will have to start at the corresponding/exact-same -x/-y offset for each tile placement
Short answer:
a) don't try to go beyond map tile size with graphic tile size
b) if you want 'bigger than one tile graphics, you'll have to make multiple tiles
c) when drawing units sitting in tiles, it's gonna make things look weird anyway
d) if you really wanted it, you'll have to create new partial tiles for each type of land you want to 'cover' with the bleed over main tile, and a matching new tile type description for the tile-type ini stuff (name=castle top over water, fire chance = 0, defense = 0, movement=5, etc).
Oh, sorry… forgot TMX.
TMX is the native map format that Tiled uses. So… it's not an ancillary thing, it's just how it stores maps (which tile goes where, tile size in pixels, map size in tiles, which tile set, etc). Think of it maybe as old school quake.map files that then get rendered (export'd?) by something else into quake.bsp files. The .map is the native format for the quake editors.
TMX would be the native all powerful format for tiled, and the flare.txt files would be the exported preferred format for me to use in rotk2-project.
In a single layer, lower tiles should overlap upper tiles. Therefore, going by my xy numbering, you'll want to draw y=0 tiles last, y=1 tiles second-to-last, etc.
Left to right should not have any overlap issues, as buildings go up, not left or right. There's no Leaning Tower Of Chengdu! (at least not in the game). Case in point, http://en.wikipedia.org/wiki/File:CivIII_01.png
Also, take a look at isometric_grass_and_water.png — compared to the full water tile, the other tiles only extend upwards, never left, right, or down.
If we have to go the way of http://www.mobygames.com/game/snes/super-conflict/screenshots/gameShotId,107636/ we will, but it just feels that it should be fairly easy to get tiles to extend if they only extend upwards.
EDIT: To clarify what I mean by "extending upwards", see http://img145.imageshack.us/img145/6445/upwards.png — blue is the normal tile, yellow is what extends upwards, and red is what will be off-limits to my tiles.
EDIT 2: Drawing order fixed
- You must be logged in to reply to this topic.