Forum Replies Created
-
Posts
-
i'm not saying that prettier battlescape design shouldn't be on the menu, and can be debated & decided upon later (i agree it needs to be done) … but there's something to be said for kicking it out of the 'constant design' phase and into play testing :)
not gonna stomp my feet on this just yet for 'flat tile biatch'… gonna give it 24hr while thinking it over hehe.
btw, i'd like to see how a staggered isometric square map feels… i do know that standard isometric stuff has been overdone IMHO and always makes me feel like i'm leaning to one side heh.
hm
immediate decision would be:
constrained hexagon (my preference)
isometric / staggered isometic (a good possibility, requires more work).
i'm leaning towards the flat constrained hexagons because it means that something interactive and playable can be achieved without too much fuck-around-ery and in short order.
changing the graphics and rendering of the battlescape shouldn't really change game logic any… mostly just the maps themselves would need to be re-tiled and re-mapped. Tedious, but by far not the end of the world.
i dunno, looking at wesnoth and images of its tiles it really does look like it's got multiple renderings. ie: the things bigger than a hexagon have completely transparent 'ground'.
a 'deep background', that would hold most of it… then an overlay/objects layer that would have stuff that is possibly bigger than a tile but the mapper would take care to not place these on top of each other….
as far as border tiles such as your coastal stuff.. those look to be object as well ?
wesnoth appears to have only a few tiles that extend beyond the reach of the hexagon… the rest is just lots of different tiles.
if those things that are on top of the tiles are 'background objects' or not i dunno.
isometric will make unit drawing a bit weird.
re: different 'upwards png'
i suppose if you draw every other X tile you should be fine…
ie: drawing B, then C, then the barely visible 'D' (heh)…. then on next pass drawing A…
cause if you rendered B, A, C…. C would overwrite A.
well, i do know that getting proper rendering out of tiled would prolly be a PITA :)
16 hours ago, was talking with the lead dev of Tiled, and he was saying he had staggered ortho isometric put into the next version already. that possibly solves these problems ?
i'd have to relook at it, but afaik Wesnoth limits tiles to be within their own boundaries ?
top to bottom in the case of wanting tiles allowed to be taller than they should be… whatever.
but the proper bleed ability would be the stuff marked in yellow:
super conflict: lol
that's the same as classic rotk2 with staggered ortho, with X axis spacing between the 'squares' ('rectangles'? hehe) heh.
i have no qualms with making all tiles render at a different x/y offset as their map position would indicate… and i don't particular mind doing a mindset of 'render bottom to top, left to right'… just so long as some considerations are paid:
if units get drawn on top of tiles after the fact, they will be standing on top of, say, castle tiles that are taller than the tile height below them.
if tiles can instead be drawn on top of units, unit information can be obscured by tiles then (units will be 'behind it').
lots of games that do this kind of thing would conceal things under the taller-than-should-be-tile, or would mark the tile it bled into as impassible, etc.
with drawing bottom to top, any part of the tile that sticks over the top will need to be within the border of the top horizontal line (otherwise, < or > edges of the tiles left/right of it will over write it.
tile map effects that go against-the-grain of the tile render order will have to be faked anyway (ie: if you want vines hanging down from another tile into partially the tile below).
if it matters any, i learned years ago that just a lot of manual blended-tiles ended up being better/easier than attempting to force effects via render order heh.
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.
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).
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.
