Enemies shoot back, Selection cursor

The guy with the sword in the screenshot above is about to take an arrow, shot by the rat archer in the far left.

There's quite a lot still to do for this version. The One Game A Month Website allows a few days of slack at the beginning of the next month to finish up a project, and I'm probably going to make use of that this time around, getting some more big features into this game.

Still on the TODO list:

• doors that open and close - would be nice, probably won't happen for this month
• NPCs retreating from the map - low priority, but it'd be nice to see them flee from you.
• NPCs pathfinding to get good ranged attacks - right now, an NPC with a ranged attack will use it if there are targets within 5 hexes (or, maybe 4 hexes, depending on how my visibility code is working). If it can't find any good targets to shoot at, it'll find a path to a valid target, and follow that path. But what it should be doing is finding a path to a good shooting position, which might be behind something that blocks movement, but not visibility. Hm, the right way to do that would be to calculate visibility from the potential target, and pathfind into the target's visibility range.
• enemies being created by a data-driven factory - all games need rat factories. Right now, I create all the NPCs with the same constructor, then for the archers, I set a flag afterwards, indicating that they have a ranged attack. Better would be to have a description saying what kind of attacks the new NPC will have, and how many hit points.
• NPC memory - NPCs will pathfind into darkness, which is good, but when they get into darkness, they forget that they were on a path to the PCs, so they just stop.
• Combat Log - The old Bard's Tale scrolling log thing, this would indicate that a player took damage, or dealt damage, or maybe communicate messages about the level ("you hear scratching noises ahead").
• Effects - when an attack lands, I could have a splash of red superimposed on the target, briefly. When a character heals, I could have some other effect.
• Fireball - the guy carrying the staff needs a separate attack
• Proper PC attack, limited by class - the fighter should only get melee attacks, the archer should only get ranged attacks, the mage should only get magic attacks. Except that the mage should probably be able to do a melee attack, in a pinch. Maybe also the archer. But the fighter doesn't have a bow, and shouldn't be firing arrows.
• context-sensitive cursor cues - I want to help the player know what actions are possible on each hex. I may not get that done in this version.
• Game Over - if one side is defeated, I should show this.
• Balance - right now, the party is way overmatched. The cautious player will make use of visibility to snipe from distance and rest up before re-engaging, which is good, but doesn't feel like really engaging the enemies.
• More levels - the plan was to have 10 levels for this month. I'll be happy to have a single level working well.

NPCs attacking, projectiles in flight

I've been at work, though the screenshot above doesn't display much difference. Things that are more or less working now:

• resting - for PCs, this heals one point of damage
• attack (melee) - PCs and NPCs can attack neighboring hexes. Does one point of damage (for now)
• attack (ranged) - PCs can attack distant hexes. The to hit calculation is rolling less than (or equal to?) 5-range. This will be revisited, sometime.
• character defeat - when a character reaches 0 hp, that character is removed from the board, no longer contributing to visibility, no longer accepting movement orders.
• character movement animating - instead of blinking from hex to hex, characters now slide from location to location.
• arrows animating - when PCs shoot at enemies, a projectile sprite moves across the board. This wasn't terribly difficult, but it's new functionality that wasn't in The Cave of the Rat King, the game I made back in June of 2012, which I'm gradually rebuilding and extending. It's nice to have functionality beyond the original game.

TODO:

• NPC ranged attacks - For NPCs that have ranged attacks, I need to calculate line of sight to potential PC targets. That should be easy; I've got visibility calculations already. 
• character hopping movement - back in The Cave of the Rat King, characters had a "hopping" movement that I like. It reminds me of moving playing pieces on a boardgame. 
• zooming interrupting camera movement - if you fiddle with the scroll wheel during a camera animation, things get messed up. Maybe I disallow that. Or maybe I let it go - it's unsightly, but it goes away.
• PC weapons - right now, all PCs have melee weapons, all PCs have the ability to shoot arrows. This should be changed so that the fighter character has a sword to use in melee, the archer has a bow to shoot arrows at range, and the mage has a staff to cast fireballs.
• context-sensitive cursors - it would help the player if I told them what the default action is when clicking on a hex. I'm intending to do this by placing a cursor under the mouse, or centered in the hex that the mouse is over, or something.
• movement queue - having a dotted line indicating where the character is queued to go would help understand what's going on.
• highlighting current character - I keep having trouble knowing what character is waiting for orders. Placing a circle underneath, to indicate the current character is easy (I've done it before).
• combat log - I imagine having a pane on the right side of the screen reporting messages about combat and whatnot. Probably inspired most directly by Bard's Tale, this would give me a little more opportunity to tell the player what's going on.
• retreat (flee) - there are "retreat" hexes marked on the map; PCs and NPCs ought to be able to retreat from combat. 
• level win/loss - defeating all the NPCs ought to trigger a win condition. Retreating all your PCs or having them all defeated ought to trigger a lose condition. Currently, the game spins, getting "rest" orders from NPCs if all the PCs are gone.
• NPCs pursuing PCs around corners - right now, NPCs forget all about any PCs that they lose line of sight with. That turns out not to be very good, especially if an NPC needs to pathfind around an obstacle that blocks line of sight.
• more levels - creating more levels ought to be straightforward, but I probably won't have time enough to make the 10 levels I had in mind.

Player Character Movement Queues Interleaved

Not much to point to in the screenshot, but the party is all lined up, prepared to assault the ratmen lying in wait for them.

The game (work in progress at http://bigdicegames.com/RatTower/tower.html ) now keeps track of what character's turn it is, and on their turn, the character can issue one of many orders:

• rest - does nothing right now, just passes the turn. Later on, PCs might recover HP when resting.
• move (adjacent) - move into an adjacent hex. Updates visibility.
• move (distant) - really, the same thing as above, but it uses A* to find a path to the target hex and queues the path as a series of move orders. The interesting(?) bit is that you can have all of your characters with movement queues, and they each do one move at a time. Taking turns, like mom used to tell you.

There are additional orders that I intend to hook up, someday:

• attack(melee) - characters that have melee attacks (all characters?) will be able to engage an adjacent enemy.
• attack(ranged) - characters with ranged attacks (the archer PC, the archer ratmen, maybe the pike ratmen) can attack from a distance
• retreat off the board - there are special "Retreat" hexes on the board. A character that reaches these may leave the combat. Shame!
• cast magic spell - the guy on the right in the screenshot above is supposed to be a spellcaster. He was supposed to be a spellcaster a year and a half ago, but I never got that into The Cave of the Rat King. What sorts of spells? I don't know - healing, magic missile. There are options.
• manipulate level object - open a door, pull a lever
• use inventory item - I don't have any of these now, but one might imagine having potions or scrolls

My TODO list keeps getting longer - I'm using it largely as a brainstorming dumping ground, without any attempts to deduplicate tasks. Some of the next few things:

• enemy movement - could be just random movement, to begin with. Pick an empty space, move in to it.
• enemy attacking (melee) - if an NPC has an adjacent PC, attack - roll to hit, if hit, roll damage.
• combat log - I kind of want to split the window up into at least two panes, one for combat results and other ongoing text information, one for the main map view. Maybe also buttons for the different orders.
• character death - this goes along with combat - after a few successful hits on a character, that character is removed from the board. 
• better prompting of player orders - put a cursor underneath the current character, hold on the current character to see the actions.
• last man standing - if all of the PCs are dead or removed, the player loses. If all of the NPCs are gone, the player wins.

And then there's longer term ideas, including having 10 different levels, different weapons and armor - all of the stuff an RPG really needs.

Enemies placed

I've just created special game objects for PCs and NPCs, which each derive from a base character class. There's currently no functionality, no behavior attached to these new objects, but that's coming in time.

I rearranged the code that finds spawn locations, and now I'm able to select a subset of potential spawn locations and put the PCs and NPCs in those locations.

I also adjusted the pathfinding code in the above situation; the map allows the player to go South, and then West, and then North, to get to the pikemen and archers in the Northwest of the map, but the player hasn't explored the connecting passageway, so the pathfinder shouldn't allow the player to just click into that room.

On the TODO list:

• enemies that see player characters should approach, if they have a melee weapon, or hang back, if they have clear lines of sight and ranged weapons.
• enemies that have a clear attack should attack on their turn
• initiative ordering
• display initiative
• highlight the PC whose move it is
• allow multiple characters to move (currently there's only just the fighter PC)
• allow ranged attacks for PCs
• resolve combat
• display combat results onscreen (dialog?)
• revoke player orders when discovering a new enemy
• doors that open and close

Part of me thinks that's not a lot, part of me thinks it's huge.

We'll see how much gets done by the end of November.

A* (pronounced "ay-star")

... like the lovechild of Fonzie and Ringo.

I finally got around to replacing my really bad BFS pathfinding with A*, which had only slightly more code. I did have to do some debugging to get it working, but that's still me being clumsy with JavaScript.

If you go to http://bigdicegames.com/RatTower/tower.html you can try it out for yourself. A few caveats:

• I've already talked about some of the surprising effects of the visibility calculation. Visibility seems to be working as I designed it, with entire hexes blocking visibility or not, which doesn't look right if you're looking along walls, for instance. I have some ideas to fix it, but many of them are pretty sweeping, so I don't plan to change this right away.
• The pathfinder doesn't know what you've explored, so if you can see a hex, the pathfinder will route you there, even if you haven't explored a path to it yourself. That's something I do intend to fix.
• This all will probably change as the enemies (and multiple player characters?) get in to the game.

Still, you can walk from one end of the level to the other with no noticeable time spent on pathfinding. So, that's working.

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).

Fedora 19 NVidia Multiple Monitor Achievement Unlocked

I've been running Linux at home for... 18 years now? Quite a lot. I know that early on, I used Red Hat, maybe there were a few other distributions I used in the early days as I was poking around. Slackware? There was a brief period where I was happy to run Red Hat Linux on a pair of SparcStation IPX machines, just because I could.


And then, there was Fedora Core, and then just Fedora, and most of the machines in this house now run some version of Fedora, though most of them aren't up to date.


I was on vacation a few weeks ago, and I had a netbook with me, running, of course, a version of Fedora. And, of course, I hadn't updated it in a while. Around 4am the day I was scheduled to leave, I decided it was a good time to start an update.


And the update was still going when I packed all my stuff into my rollerbag and my carryon messenger bag. (My favorite plane joke is about the flight attendant that kicked the vulture off the plane for having too many pieces of carrion.) But, in my last bits of sightseeing, I noticed that the upgrade had completed, and I had got to a login prompt, so I powered off, and returned home.


Delighted that the upgrade to F19 went smoothly, once I got home, I triggered an update on my development desktop and my fileserver/webserver machine. Neither of these went smoothly, and I decided it was time to migrate the important files off the fileserver, including the web content. I migrated all that content up to Amazon S3, and pointed the DNS records over to Amazon, and now I've got higher reliability and higher bandwidth. That's good. Getting files up to Amazon is a little bit of a different pipe than before, but in some ways it's easier.


For the desktop machine, I just installed a new hard drive and created a fresh installation of F19. That seems to have worked for the most part. I still have several directories that I need to recover from the old system, and then it'd be nice to be able to boot back into Windows now and then, which I've lost in the shuffle.


The most recent chapter of this particular saga was when I decided that I wanted to reinstall the NVidia display drivers. I've got two NVidia cards in this machine, both GeForce GTX 560 Ti, hooked to three monitors. I could conceivably do four, but I'm limited by desktop space and view angle.


I used Google to find instructions for "Fedora 19 NVidia drivers", and got some instructions that sort of helped, and the instructions had a final step that told me how to undo what I did, which I think is the best part. Also, a necessary part, because I needed to back it all out. The dead end I got to was to have the two monitors on the first card come up, sometimes as one big display, with the login prompt in the crack between the two of them, and the system "tray" stretched across both. Yeah, that's no good. Sometimes I was able to get it back where the login prompt was only on the primary (center) monitor, and the tray was only on the primary monitor, which is better, and sometimes I was able to drag windows over onto the right monitor (sometimes not, as I kept poking at /etc/X11/xorg.conf). One thing that I was having a real hard time doing was getting the left monitor, which was on the second card, to be part of the desktop. I'm sure there are technical terms here that I never have bothered to fix in my brain - I know that there are devices and screens and sessions, and these all have useful, specific, definitions within X. But X terminology has always been a little too specific for a casual user ("It's an X server, because it's serving X requests, like drawing things on the local screen. The client is the software running possibly remotely. Yes, you can run an X client on a remote server machine, talking to an X server running locally." and "It's not 'X Windows', it's a windowing system called 'X').


I went around the loop of booting, logging in as a normal user, launching the nvidia-settings panel, poking at stuff, issuing a telinit 3 and then telinit 5 command, and things not getting better. Now and then, I'd get a screen saying that something's gone wrong, that I should log out and try again. Frustratingly, I had not even logged in at this point. Also frustratingly, the mouse wasn't working, so the OK button seemed like a cruel taunt. I tried tabbing to the OK button, which also didn't have any noticeable effect, and then I realized I could just hit Enter, which made the screen blank, and froze the system.


I poked around inside /var/log, looking for a description of what had gone wrong, but I saw nothing.


Along the way, I went to NVidia's site, and downloaded their driver tools, which weren't exactly the same as the tools at the first website I stumbled across, above (hint: NVidia distributes nvidia-installer, which felt more comfortable to me), but still, at best I was getting two out of the three monitors working.


Whoops, sometimes I'd fall back to a single monitor, displaying at 1280x1024, which is stretchy and gross.


I considered that maybe hardware accelerated graphics weren't that important to me, and maybe I could uninstall and get back to the triple monitor setup I had before. Nope, that bridge seemed completely burned at this point.


I poked around inside /etc/X11/xorg.conf, trying to enable the connection between the device and the monitor at the configuration file level, but that way led to non-booting and backtracking.


I tried enabling Xinerama, but again, "something's gone wrong. Log out and reboot."


I looked up Xinerama on the web, and I was pretty sure I didn't want that, anyway.


I kept poking at stuff, finding web pages for people mirroring displays, and setting up multiple seats on a single system (woo, timesharing!), and finding an article about using four monitors and "Base Mosaic" - which had worked in previous driver versions, but was crippled in Linux to maintain parity with Windows drivers. I know that I had seen the "Base Mosaic" checkbox on the nvidia-settings control panel, but the popup help wasn't especially helpful:







"The Enable Base Mosaic checkbox enables Base Mosaic."


I'm sure it does. I'll bet there's some intern that had 4 hours left to get things checked in, and he had forgotten to make a tooltip for this item, and he couldn't come up with anything better. I would suggest, NVidia, that it's probably better to describe what "Base Mosaic" is, rather than the fact that a checkbox can be checked.


Also, it might be useful to have a name that conveys what your feature does. I'm familiar with how mosaics work; I've made mosaics, they're cool. I've used the Mosaic browser. I know that all my base are belong to someone who set us up the bomb, and I've made my time.


But, I've clicked on everything else at this point, and I've more or less been able to recover from the dead ends, so I set


Option "BaseMosaic" "on"


in the xorg.conf file for all the screens, expecting to get some sort of mirroring or something, but when I restarted, I actually had three monitors light up, and the login prompt was centered on the primary monitor.


Oh, but the left screen was on the right side of the desktop. Ok, that's probably not too bad, I'll just go into nvidia-settings and drag the screen over where it belongs. Done. Restart. Same thing.


Hm, maybe I didn't save. Again. Drag. Save. Restart. Same thing. Huh.


Based on one of the tips from an NVidia employee on one of the forum threads that I saw along the way, I tried using the Gnome-desktop settings / "Displays" control panel, and that had three displays available to position. I dragged those around, hit apply, and I'm done.




So, lessons learned:

1. Install the official NVidia distribution - or maybe the other one, if it makes you happier. The other instructions involved akmods, which is arguably the smoother path.
2. Enable "Base Mosaic", which doesn't seem to be documented, and may or may not show up in the nvidia-settings control panel. Good luck.
3. Use the GNOME desktop settings "Display" control panel to arrange your displays, even though the nvidia-settings control panel also gives you a control that you think would do this.

I like NVidia, I do, and I get that supporting Linux isn't something they need to do. Also, I like Fedora, and I get that making upgrades between versions is hard. But this whole experience seems like it could have been a lot smoother every step of the way.

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.

Doors on the map

There are going to be some number of player-interactable objects on the map, from doors to dead bodies to chests. One could imagine even more, like pools and traps, but that's probably beyond what I'll do for November.

The fundamental thing about a door is that it has two states, open and closed. When open, it blocks sight and movement. When open, it allows both. The way that my visibility and movement code works is that an entire hex is movable/immovable, transparent/opaque. Given that, it makes sense for doors to be centered in a hex.

I've added two doors in the above map, and in each case, the joining of the door to the surrounding walls is problematic. For the horizontal door (permitting movement North/South), I could create special corner pieces that meet up with the door, which wouldn't be too bad. For the vertical door (permitting movement East/West), the connecting pieces seem trickier to get right.

I've also added the vertical lines making the N/S walls seem a little smoother. That requires more adjusting, especially once I get wobbly lines in.

The text there won't be visible in-game, it's just notes for me as I sketch out this encounter.

I'm currently planning on 10 encounters of roughly this size for my November game - I may rearrange this one pretty substantially, since the fiction is that these are portions of the Tower of the Rat King, and the above layout feels like it's been carved out of solid rock, like a dungeon. Perhaps this part of the tower is set against the hillside.

More hatch testing

Several pieces went into the above map:

• rewrote the "inHex" math - each of the penstrokes that you see there is actually composed out of a sequence of positions along a line, which then gets a "brush" image applied to the tile, more like a rubber stamp than an actual brush. The image is something like 20% or 30% alpha, but since the images overlap so much, eventually, you get a pretty dark section in the center of the stroke, fading out to the edges. This achieves the felt-tipped pen effect, even though that's not exactly what I had in mind. Rather than figuring out where the strokes should begin and end, I just filter out the bits that aren't in the hexagon, or not in the section I want to hatch (a corner has only one quadrant that I want hatched, for example). I had taken the JavaScript code that I was using inside my previous games for turning screen clicks into hex indices, rewrote it in Python, and using that to know if the pixel was inside the hex. I got something wrong, and things seemed rotated 90 degrees, which I couldn't understand, but it turned out I was just truncating when I should have been rounding.
• generating twelve versions of each feature - since I'm generating these tiles in Python, it's easy to create a bunch of variations. In this case, I slope the hatches at three angles up, three angles down, and then I rotate them 90 degrees, for a total of 12 different hatch directions. I don't want anything too close to horizontal or vertical, and even 45 degrees off feels wrong, so maybe I'll regenerate things again.
• Hexographer, from Inkwell Ideas - I don't mind plugging Hexographer - it's a Java-based map editor that does hex tiles. Not a lot of tools out there run on Linux, or do hex tiles, and this one does. I haven't used it much, but so far, it's suiting my needs. I wrote a small script to create a list of my custom tiles, imported that into Hexographer, and was able to assemble the above map in a few minutes.

Looking at that, I imagine the party coming in through the passageway in the Northeast, fighting some guards in the first room, one guard fleeing to the South, and the heavy combat forces ambushing the party from the Northwest. That sort of combat progression might be more than I'll deliver this month, but it'd be a cool place to go.

A few things I want to add:

• wobbly pen strokes - look at how ruler-straight those lines are. If there was some variation in the line, perpendicular to the overall direction of the line, it'd look more hand drawn.
• finished edges on some full hexes - the East/West walls all have that horizontal, smooth, line marking the surface of the wall, but the North/South walls only have an edge when it cuts the hex in half. Adding hexes that are solid, but have an edge would be easy enough. I might have to do something tricky to get the edge to sit inside the full hex. Shouldn't be hard
• ball point pen style - the felt tipped pen style is OK, but I think I want sharper, less fuzzy strokes. Like a Uni-Ball Vision Needle pen. I can draw some lines with one of those, scan them, and experiment to reproduce the actual physical marks.
• doors - the heroes need to knock down doors.
• columns - block movement and visibility
• other terrain features - some things would block movement, but not visibility (a portcullis, perhaps?)

... and the imagination runs much further than that, thinking about how lighting is going to be done, how the AI will handle retreating and engagement, if I wanted to have secret doors, how that would fit in to the above tools, and so much more.

Hex Tile Wall Test

For the next game, I'm going to tackle interior spaces, which present some obvious problems with hex grids. I've considered abandoning the hex grids and moving either to square grids (boring!) or to "natural" grids based on Voronoi regions. I think that latter has some interesting possibilities, but there are so many unanswered questions there that I'm going to defer experimenting with it until the new year.

The above tiles capture some of the hand-drawn hatching of, e.g. Dyson Logos. There's more work to be done, but when I look at the effect there, I see a felt-tipped pen stroke, which isn't quite what I'm going for, but it's not bad.

I wrote a little Python script to output 14 different hex tiles, and I assembled them (duplicating a few here and there) into a little room by hand in GIMP. The slant in the hatching makes the entire map seem rotated, but that's just an optical illusion. Will I fix that? Maybe. Perhaps I'll take a page from Dyson's maps and mix up the hatching, all different directions. That could be fun.

The Island of the Rat King, now playable online (finally)

http://bigdicegames.com/RatIsland/island.html

I had managed to get the game to a playable state by the end of the month, but I hadn't got around to recovering my ability to serve web content. So, I went through the Amazon S3 Tutorial, which made sense up until getting to the Route 53 bit, which you apparently have to sign up for separately? For whatever reason, it took several days to get access to the DNS functionality, and then I tediously updated all of my various domains. I'm not certain that they all work, but the link above seems to.

On to November's game: The Tower of the Rat King.