Level Loaded and Navigable

It's been a while since I've posted any visuals, and I'm happy to show the level that I had been making maps for actually running in my game engine. The path to this point had some interesting steps:

Hexographer parsing

Hexographer writes all of its data out in a pretty easy to interpret text file format. I opened it up in emacs, and saw the size of the level, terrain declarations, terrain instances - all pretty straightforward.

I started writing a Python script to take things apart, and was immediately surprised to find garbage in the strings that I wasn't expecting. Turns out, the text isn't ASCII, it's UTF-16. Whoops. So, I poked around on the internet and figured out how to use Python's "chardet" library, which got things squared away there.

I started writing a tool to take my interpreted structure of the level and dumping that to custom JavaScript, which I'd write to a file, but I quickly got annoyed by the fact that lists in JavaScript can't have a terminating comma: "[1,2,3]" is valid, but "[1,2,3,]" is not. I imagine I could have got around, but I decided, instead to use Python's json library to create the JavaScript for me.

I still think the idea is a good one, but if I had made a custom exporter, code that currently looks like this: 

  "terrain": {

    "Corner 1": {

      "blocks_mvt": true,

      "blocks_vis": true,

      "filename": "c1_0_x.png"

    },

would probably look more like this:

  "terrain": {

    "Corner 1": {

      blocks_mvt: true,

      blocks_vis: true,

      filename: "c1_0_x.png"

    },

Not a big change, but then the calling code would refer to terr.filename, instead of terr['filename'].

Coordinate Conversion

I actually expected this to be trickier than it was - switching coordinate systems can be tricky, and hex grids are weirder than most. Hexographer uses an "offset horizontal layout" in Amit's terminology, and I'm using "cube coordinates". It turns out, the conversion wasn't so bad, and inside a tool, I don't mind the math. I did it in my head, and it worked on the first try.

Transparent Tile Background

I copied my Island of the Rat King code over to my new working directory,, and brought things up, tinkered here and there to change the procedural level generation of last month to an asynchronous asset loading pattern (even with compiled in level data, the tile art is loaded at runtime). All I was seeing was green grid lines on a black background  - which was promising, but not quite right. I tinkered around, and discovered that my tiles were mostly transparent, with opaque black lines for the features, and green lines for the edges of hexes. I went back to my drawing script, and tagged most of my hexes to draw a white background, reexported the tiles, and things are showing up pretty much as I expected

Things not quite working right

Visibility

I'm not sure if I'm entirely satisfied with my visibility. For solid hexes, it's doing great, but for partial hexes, maybe it needs to be reconsidered. Or maybe I adjust some of the data. For example, walls that appear to be straight occupy jagged hexagonal regions. The entire hexagon gets tagged as blocking visibility or not, and that means that the corners, even if the pen strokes suggest otherwise, might block visibility. In a lot of cases, I could flip half-walls and corners to not block visibility, but that might have other issues.

Pathfinding

This isn't anything new - I just haven't ever got around to implementing a simple A* tool, instead, using a breadth-first search. With cubic hexagonal coordinates, I've got a good distance heuristic, which was what kept me from implementing A* back in The Cave of the Rat King.  So, if you're patient, you'll be able to click around corners. But it shouldn't take that long.

Schedule

Here it is, halfway through November, and my goal was to have a party-based tactical RPG done by the end of the month. I've got one level loading, with no enemies, with one character. I may find myself scaling back a lot. I could turn it into "explore this spooky house", which really only makes it a small improvement on The Maze of the Rat King. I think I might do a single-character turn-based tactical RPG, with really simple enemy AI, and really simple inventory (possibly none).

Hexographer "Features"

With the scare quotes in the title, I almost expect this post to be about bugs I've found in Hexographer. I've found one, and filed a bug report, but that's not important right now.

What I have done in the above map is tidy up some bits that were annoying me, bits of walls that hook up with actual terrain pieces. It occurred to me that I can add these in as an extra graphical layer that make the map look correct, without having any change to the underlying behavior.

It turns out, Hexographer has this same notion; there's a "terrain" type that a hex can have, and then hexes can have zero, one, (or many?) features. The little connecty bits adjacent to the doors, above, are features. You may not be able to read it, but there are hexes tagged as "Retreat" and hexes tagged as "Spawn".

I started off using Hexographer as a convenient place to screw around with my hex tiles, and as I've moved along, it seems like it's going to be a workable level editor for the November game.

Towards that end, I've started looking at the .hxm file that I've been saving out, and it's plaintext and easily parseable. There's a section of the file that describes all the hex types available, and then there's a list of hexes, with what kind of terrain and features.

I'm not sure if the level I've been working with, above, is actually going to make it in to the game, or if it's just a test, but it's got most of what I need. I think the next thing to do is to work on taking the .hxm file and turn it into a format that I can use at runtime, and begin making a game in this level.