You are here

Karst Kaverns Tileset Discussion: July 2018

This is my brain on 4 shots, a coke, and a new job.

I'm working on another project for the state of Michigan (Using ArcMap/ArcScene) for a few days to a few weeks, with down-time in between. In the meantime, I'm trying to decide how I feel about that bridge crosser for the great chasm room terrain in the Karst Caverns set I'm building.

This is all about walkmeshes and how much I really hate them.

A few things come up that concern me:

  1. Is the crosser wide enough? I tested some appearances and found that a dire bear and a balor could both walk on the bridges without problem. Summoned minions could not pass their masters on the bridge to be effective, so I'm a bit worried two player units could not stand side-by-side on the bridge. My goal was to have a comfortable region for two PC's to stand and to be able to fight something... like a Balrog...like on a bridge. Because ... you know.
     
  2. Should I go wider, and if so, how wide? Examining other games, a unit-to-tile ratio is often different than NWN, with the full-width of a tile being used as any tile-to-tile opening. Looking back at the spider-caves-like tunnel set I was working on with Karst Caverns Type A, the percent of tile used as crosser opening was 50% (5m) and that used for room floor was 47% minimum (and standard on all tiles) with the ability to turn another tile portion on (as it is currently reserved for decor) and use 75% (7.5m). I think I prefer the wider tile floor space. Which brings up a few sub issues:
    • Opening the minimum walkspace between any two corners requires some minor changes to most tiles in Type B, and the complete rethinking of about 1/10 of the set's tiles. Most of the pit-edge tiles planned for diversity expansions would need to be modified.
       
    • I can make those changes to non-crossers via scripts, and most crossers can also be affected. Those in that 10% cannot be redone with script without making their geometry worse (at my current coding level). Unfinished diversity kits are not a problem, but some tiles will be scrapped. Again, this is because the walkmesh becomes a pain.
       
    • Within the 10% mentioned, most tiles are diagonals. There is a good chance that opening the crossing space over a diagonal, especailly to the wider space that I like, will require the tile be dropped, or that a 2x2 group be made to replace the diagonals. In any case, this keeps units from becoming trapped in or from the tile. All of this fixes walkmesh problems.
       
  3. I want to merge the Types A and B sets at some point, and the sooner the better, I think. If I open the walkspace of type B to match that of Type B, and then just keep the Type A shape, I can have two rooms that can automatically connect without any additional special tiles. Doing that also automatically gives me the Type A crosser tunnels to use immediately. I generally like the Type A tunnel walkmeshes. They're not flat, but they're fairly spacious.
     
  4. I don't like the Type B tunnels and will likely scrap them, but the Type A tunnels are also not ideal for what I'm trying to build, at least in a visual sense. What I'm looking for in a second tunnel type is a wide-squat tunnel. Multiple mesh tests suggest I should go with a terrain-based tunnel...but...that negates the possibility of easy doors within the tunnel. Making doors that span multiple tiles is not impossible, but poses additional problems. That leaves one more option: tunnel type 2 is not a terrain, or crosser, but a series of tile group options. I might do that.
     
  5. Type B room-to-room meshing almost works as a tunnel rather than a room terrain. So changing it to merge Type A removes that feel. Catch 22.
     
  6. Water....is just a problem right now in EE. Nothing I do gives me transparent water for walking in, but I want that. I assume they're going to fix it, and not too long from now, but it's currently killing me.
     
  7. More water. I have three water types and was going to add another by merging in the shallows from the test kit I made a few years ago, modeled off those Dwarven Forge cave pools. I peeked into Drakensang Online and saw something I might do instead. Keep the walkable water, and put the test kit features in that. Drop the test kit. But...add some base terrain decals of some new EE specular puddles. The ones in Drakensang are just decals of inch deep water, and I think they'll do well for EE.
     
  8. Damn water. I want to diversify by adding multi-level raise/lower. The problem with that is the water, lava, and pits. I wanted a range of just three elevation differences from 0 (so four), and I don't think that's too much considering automation, and the fact that the kit SEN put together was really fleshed out with my Granitelands Tileset. I can re-use part of that code for these caves. But... water. Damn water. A few points:
    • Older games (like 1990-2010) with multiple-raise tilesets had this thing where any raise over +2 (or visually complex tile +1) was done around "solid" or "pit" terrain, which greatly reduced the number of tiles needed. Greatly! This also meant that solid and pit terrain could include a bunch of faked non-tiles of elevation change, without having to make an actual mesh. I do this in the tileset by supplying the text NULL in place of the MDL file. I kinda want to do this with Karst 2.
       
    • Drakensang Online mimicks DS 1 and 2 in some ways of tile-making in that it has a large tileset of barely different tiles, all made to do the multi-level effect, but, in other ways they make use of 8-bit gaming tileset architecture. The width of a door opening is often greater than one tile. The center tile is the opening, but the door frame is on the adjacent tiles. That would make doors three-tile groups. Going back to the tunnel talk above, that works out in my favor. Check out the architecture of something like the Final Fantasy IV original tileset for "Mist Cave". Complex sets in these games made heavy use of the switching of elevations around pits and other unwalkable regions. Drakensang mimicked that aspect as often as posible to reduce tiles.
       
    • Fast forward to the Final Fantasy IV DS remake, and you'll see the designers didn't like the portrayal of the tileset. It was modified to work more like Dungeon Siege. Half-sized tiles (relative to the units). Terrain height changes +/- 3 levels were remodeled with some spaces in the 8-bit game being removed. Anywhere they used two tiles to do something instead of three had to be reinvented or omitted. They lost diversity, but the mesh objects made that OK. Tunnel areas that were 4-5 tiles wide were reduced to two tiles with the tunnel being represented by room-space, and tunnel ends being a 2x2 group. I like this too, and it would be easy to just use those tighter room types as the second tunnel type. However, as I mentioned, that's not the shape of the tunnel I've been tying to make, and I don't really want three tunnel types yet. But the water. The FFIVDS remake kept the pits and water the same.
       
  9. Damn dirty water. Stupid water. And those pits. OK, how about this: Why have water tiles and pits? Why not just have the empty pit, and then fill it with placeable water and water features? I'm seriously thinking this. It reduces mixing tiles by a little bit. I wasn't going to mix pits and water anyway, so that's not a problem or a bonus.
     
  10. And we're back to the great chasm (pit type 2). What am I doing? I wanted a super deep pit with little to no visible ceiling or floor. I wanted players to cross it via bridges of precariously tied-together cave formations, but instead I built this angular solid rock floor with 75% tile coverage as a room. And the bridgework has a similar character.
     
  11. And it has too many polygons in the bridge mesh which causes a slow load (and slower tile load in the toolset). What I want isn't what I made. I think I'm going to put those aside and redo them. What I need is a lower polygon floor, with the ability to bring up the visual polycount using all the placeables I've made over the last two years.

So here's what I am thinking that might fix a lot of issues I'm having, but keep in mind this takes a mechanical change in mindset...

Make all rooms using a base terrain, of which there are only four, including: solid rock, unwalkable floor, great chasm, and general (empty) pit. None of this is walkable. To make it walkable, all rooms can use a single crosser called simply: "path" or something like that. This path makes tunnel corridors through solid rock. It makes walkable rooms but automatically leaves unwalkable space (as found in the original underdark set). It makes bridges over pits, and that special bridge over the great chasm. All with a single crosser name. Just "path".

The one troubling side effect is that every path-crossing creates a support pillar. So to remedy this, you need one more terrain type, which acts not as a room type, or a crosser, but is just simply there to remove the pillar. That's all it does, so that's what it's called: "remove support". This turns the crosser-built room into a normal tileset room.

All the basic room tiles are the same, and this lets me use the same Type A rooms and stash the Type B rooms as future backup diversity. It prevents having to switch tools to continue drawing a path cross bridgework because the "road" just continues forward across the pit or chasm. Instead of using crossers and special terrain to build all the "extra" space, you are using just one crosser to make the "normal" play region, and one special terrain type to open it up to make it wider.

If I do this, everything I require to script-build elevation changes becomes suddenly easier to write, and the output of those tiles to the set file becomes a little easier too.

And then I came up with one more addition I'm working on. Tilegroups with auto-picking center tiles, but the tile is picked from a subset specific to that group. The donut hole of a 3x3 group is given a new terrain type that matches the room description. Tiles that fit the hole, and only that hole, get their four corners set to that terrain type. And then, certain donut-shaped rooms can also have corner terrain types that also auto-pick so that corner terrain only for that room will do the same.

But why do all this? The biggest reason is because I'm trying to avoid that much more difficult work of messing with complex walkmeshes because, in my experience, that is the biggest ass-kicking task of tileset making. This is really all about that walkmesh.

Those things give me nightmares.

But now, I am out of caffeine overbuzz.

What are your thoughts? Any return-rant?

First Release: 
  • up
    50%
  • down
    50%
Tarot Redhand

Your concern over the width depends on whether you want a choke point or not. Two examples spring to mind. The battle of Stamford Bridge which occurred just three weeks before the Battle of Hastings in 1066. According to the Anglo Saxon Chronicles a single berserker held up the English army in time for the invading Vikings to regroup when they were surprised by them. Wikipedia page if you are unfamiliar with this battle. The other example has to be Gandalf versus the Balrog. Something I am sure virtually everyone is familiar with.

TR

  • up
    100%
  • down
    0%