Front matter

I've updated the splash screen (which you'd only have seen if you had been playing the Android builds up until now). I've also added a main menu, a title screen, a credits screen, and going in and out of the game. Nothing exciting, but the sort of thing that makes a game feel like a package.

I struggled with getting the buttons working right on all three of the platforms at the same time: desktop web, mobile web, and mobile app, but I think they're working now.

I think there's some bug in the way I'm loading my splashscreen - the first time I load the game, it fails, but eventually it gets loaded and is cached. If you try to play the game, and just get a blank screen, hit F5 a few times. Sorry.

Maybe I'll get to fixing this today or tomorrow. If not, it's hitting the features I wanted to get done for the month.

http://bigdicegames.com/RatMaze/maze.html

Things that don't make for good screenshots

I spent some time tinkering with the game camera, and got two pieces pretty much working: dragging and pinch/zoom.

The dragging is accomplished by taking long clicks (longer than half a second) and applying the offset from the mouse(touch) down event to the current mouse(touch) position. That's pretty good, but then I have some special case code to get rid of that offset through interpolation, and it's pretty similar to the camera movement code I have in the other branch, which focuses on a hex. Similar, but completely separate. Code redundancy is nice, if I expect one path of the code to be eaten by gamma rays, not so good if I want to maintain it.

The pinch/zoom code is relatively simple: when I detect two simultaneous touches, I capture the distance between them. As the touches update, I compare the new distance to the old distance, and scale appropriately. There's a bunch more fiddliness, and it turns out that I end up snapping the camera position back to where the character is standing, which is probably not the best solution, but it's a solution.

Maybe tomorrow, I'll put in the main menu screen. Cause I can't have a credits screen if I don't have a menu screen.

Maybe I'll update the character movement so he hops instead of blinks.

Mobile progress

I only have a little more time to go on this one, and I haven't been putting in a bunch of time lately. However, I have sorted out some issues with handling touch events that had been keeping the game from working on mobile.

I also learned a bit about remote debugging: https://developers.google.com/chrome-developer-tools/docs/remote-debugging which proved valuable - breakpoints and data inspection are handy.

I also figured out that by passing "script" to the Closure "calcdeps.py" script, instead of "compiled", you get one big uncompiled file, suitable for debugging. I also saw that there's some hints of a source map, but I haven't dug in to that yet.

As the above screenshot evidences, you can use a single touch and move around, as if you were using a mouse to click. I really want dragging for both desktop and mobile to work, and pinch-zooming on mobile. Maybe that'll be easy, given the things I've built, the things I've learned.

There ought to be sound, there ought to be a title screen. Other than that, this is just about done.

On Better Hiding Keys

When I first wrote the code to place the items (exit, key, gate), I used this process:

1. pick a random location
2. find the farthest place away from it - put the player there
3. find the farthest place away from the player - put the exit there
4. find a spot about 70% of the way from the player to the exit, put the gate there
5. find a spot about 50% of the way from the player to the gate, put the key there

And this works, in the sense that the key and the exit are guaranteed to be on the correct sides of the gate. It also does a good job of forcing the player to travel the furthest, guarding against degenerate mazes.

I recognized one thing that it didn't do was to allow the player to reach the gate without first having reached the key. And, if you're guaranteed to pick up the key before you reach the gate, one or both of them isn't really fulfilling its purpose.

So, I've put a new build up here: http://bigdicegames.com/RatMaze/maze.html The big difference here is that the key is now placed differently. I've got a modified version of the "farthest place away" code that generates a table of locations indexed by distance from the start location and another table of locations indexed by distance from the gate. I then walk through one of these lists and cross reference with the other list, and I can find out the distances for each location to the start location and to the gate location. I find a hex that has the maximum sum of these two values, and that's going to be a place far away from both, and probably off in some dead end; a good place to hide a key.

One thing I'm pleased about, even though the code is a little gross, that whole thing is running in O(n) in the number of walkable spaces inside the gate. A somewhat simpler algorithm would have been O(n2)

So, the game is pretty much doing what it needs to - you get a maze, you have to find the key, the gate, and the exit, and visit them in that order.

Some things that aren't working correctly:

• pinch to zoom on mobile - the mobile experience isn't really something I've looked at recently.
• mobile viewers of the webpage can't click - I haven't really been optimizing for this case, but it's totally broken. May stay totally broken, depending on how excited I am about fixing it.
• dialogs when finding an item - this may be pretty simple, and the text is going to be trivial to write, something like "You have found a key! Now find a gate to unlock!"
• sound effects - footsteps, picking up a key, opening a gate
• main menu, about, credits screens - I'll probably reuse much of earlier projects, that's what I'm here for. 
• HUD? - maybe I should provide an indicator that you've picked up a key and are looking for a gate. Almost like a mini quest log thing. Or a simple inventory. Or maybe I don't need it for this game.
• smoother movement - blinking from hex to hex isn't what I wanted. I like the Lair of the Rat King implementation where the guy would move by using a spline, hopping from location to location, like a piece on a board.

Fog of War

There's no war. And not really much fog. But that's what I'm calling this functionality - stuff you can see is bright, stuff you've previously seen is darker, stuff you've never seen is black.

This took a fair amount of work, even though it's a very small difference from the last screenshot, because I did a bunch of refactoring under the hood - now there's a "location container" class that holds "locations".

The various bits (player character, key, gate, exit) ought to be held inside locations, but that's not in yet.

Things I hope to get in this weekend:
- picking up the key
- opening the gate
- landing on the exit
- dialog boxes demonstrating all of this

Visibility, pathfinding, new build up

http://bigdicegames.com/RatMaze/maze.html

It's starting to feel like the game I have in mind. Big bits that aren't there:

Smooth movement - in The Cave of the Rat King, character movement had a feel like physical counters on a boardgame, with "hopping" from location to location. That movement is smooth between points, rather than now, where the character blinks from tile to tile. It's not going to be very animated, but it's something.

Fog of war - the greyed out bits of the map right now are unexplored. I want to have the explored, but not currently visible, bits to be greyed out, and the unexplored bits be black. I'm in the process of rewriting the Tile class, which should make this sort of thing easy.

Picking up the key - when the player lands on the key, stuff should happen

Landing on the gate - there should be logic with the gate, keeping the player from going through without the key. Huh, I just realized, the way I generate the key position right now, there's no way to get to the gate without having the key.

Landing on the exit - trumpets, confetti.

Pathfinding with awareness of player knowledge - the pathfinder doesn't take into account if the player hasn't explored a location, so you can click on the exit even if it's greyed out.

Mobile support - I haven't made an Android build in a while. When I do, I'll want to support pinch to zoom.


It's kind of weird, shifting from making minimal implementations to building big pieces of a system that are only lightly used by the current game. The tile system I'm working on and the visibility system are examples of things that I know I'll need down the road, even if the work doesn't seem necessary this month.

Visibility Calculations

280 lines of hexagon math, 148 lines of test harness to verify the code as I was going, and now I have a visibility routine. The thing with this month's mazes is that visibility is always going to be very constrained; I could have accomplished the same effects in a lot less time, in a lot less code by doing a simple raycast in 6 directions.

I'm halfway through refactoring the tile code - my intention is to keep track of what the player has seen in the tiles, and use that to create a "fog of war" effect; stuff you currently see is bright, stuff you saw previously is darker. Stuff you've never seen is, let's say... black.

I've been wrestling with what colors to use for the various tiles. Anything that's at all colorful has been, to my mind, debugging assets. The stuff I was thinking I'd use was the greyscale (anything between black and white, inclusive) hexes. But the difficulty there was that a currently visible wall is going to be some color of grey, and a previously visible path tile will be some other color of grey, and a previously visible wall, that's yet another color of grey, and it's all too much. So, new assets for the tiles, I guess.

Sometimes, the successes, they look like a long list of numbers.

I'm going to tag this with the "screenshot" tag, which is an abuse, since the above isn't an actual screen from the game, or running the main loop of the game. What it is is a debug harness running some of my new code. If you look carefully at it, you can get some hints where I'm going with this.

Hint: the contents two lines at the bottom of the top pane are important, and perhaps more important are the contents of the line that isn't there.

Ok, that's elliptical.

Key, Gate, Exit

Well, I've got something working. I don't like the behavior, and I don't like the implementation. But it's "working". Including sometimes when it isn't exactly working the way I want, even then it's pretty much working.

My process here is to first pick a random spot on the map, I call that the seed. Then I find a spot as far as I can (pathfinding-wise) from the seed. That's the exit from the maze. Then I find a spot as far as I can from the exit, that's the start. I'm not entirely sure that that's the right feel for a maze - but it does give the player the maximum distance to travel in the best case.

After that, I find the path from the start to the finish, and drop the gate 70% of the way along it. This divides the maze into two sub-mazes. I want to pick a spot in the player's sub-maze, far away from the start position and far away from the gate. Instead, I just pick a spot halfway from the start to the gate. This puts all the interesting bits of the maze on a single path, and if you're extremely lucky, you won't have to backtrack at all.

I'm finding that I want to build some nicer tools for handling tile positions - right now, I'm iterating over lists more than I want, and it's gross.

Also, sometimes, the player ends up at a location that's not the furthest from the exit, so something's not right.

If/when I rewrite the tile position code, maybe that bug will get sorted out.

I'm calling this stuff good for now, with the intent to come back and rewrite it to make it pretty.

TODO:
clicks make player move
player animates from location to location
player picks up key
player can't pass through gate without key
landing on exit is a victory

That's not much, really, and I have over 3 weeks to do it. That means I'm likely to actually get around to the cleanup, I hope.

Refactoring can be painful

Since we last met, I added in some (placeholder?) icons for various things in this game - a key, a gate, and the exit. Also, I'm reusing a player character icon from my last hex game, The Lair of the Rat King. The icons are just dropped anywhere on the white tiles, so there's no guarantee that the player can reach the key in order to open the gate and then get to the exit. In fact, in the screenshot above, the player can get to the exit without mucking about with keys or gates.

I've got a plan for positioning the exit, then positioning the player, then positioning the gate to be between them, then positioning the key to be between the player and the gate. "Between" is a path-finding thing, in this case. Should be easy.

One thing you can't see here is that there's a "camera" that pans around the level to focus on the player character once all the tiles have been placed. This was working acceptably well, and so I started pulling the camera into its own class, and in so doing, got things mostly broken for most of the past 12 hours.

But things are back to functional again, and it's kind of fun just watching the mazes be generated.

I'm beginning to wonder if there's a bug in my maze generation code - I've seen some mazes that have surprisingly long, straight passages. I've seen more than once a level that's just a single straight corridor, with no turns. That seems really unlikely to happen once, much less twice.

Now with click detection and screen -> tile math

In which we learn that math is hard, and going to sleep is good.

Hex grids are cool, and they give me a frisson of strategy-geeky joy when I look at them. I was just chatting with my sister about hex grids, and she reminded me that an early influence on me (before the wilderness rules of Expert Dungeons and Dragons) was the game "Outdoor Survival" by Avalon Hill.

I remember playing a variety of starship battle games on the living room table with large hex maps and 1/2" cardboard counters. A buddy of mine at the time, Nathan, complained that a flat map didn't capture the full three-dimensionality of true space combat. "Oh, come on", I said, "you can stack the counters, surely that's three dimensional enough".

Those old hex maps used a numbering system where each hex had a 4 digit number printed on the map, going from 0000 to 2245, maybe. The first two digits were the column, and then the second two digits were the hex within that column. That's all fine for pencil-and-paper reference, but it becomes cumbersome for algorithmic computation of adjacent hexes. Quick! What hexes are near 1327? Well, 1326 and 1328, sure. And then 1227 and 1427. Um, 1226 and 1428? or 1228 and 1426? Could be either, depending on how the map was laid out. Bah!

Last summer, I made a hex-based RPG using this "offset coordinate" system, and I managed to make it work with a little modular arithmetic and a fair amount of special-case code. I never managed to get a distance calculation working, just adjacency. More recently, I stumbled across the Q-Bert coordinate system also known as the Cubic coordinate system, in which you put x and y 60 degrees apart, which makes the numbering really simple, but then you introduce a z coordinate such that x + y + z = 0. This doesn't seem like it adds anything, but once you have well behaved x,y,z coordinates, calculating distances on that surface is simple. Click either of the links above to see the math.

Ok, so I've got distances now. The next tricky bit is converting a position in screen space back to a tile. In my offset coordinate game last year, that was some involved math, with three different regions, a rectangle, some triangles, bleh. With the new cubic coordinates, I just reverse the code that I use to figure out the tile-to-screen positions, which wasn't all that hard, and then I use the rounding technique to clamp to a set of integer tile coordinates.

Along the way (and not terribly late last night, just later than I intended to be up), I added some debug code to my hex maze display to highlight my x, y, and z axes. I did this by checking to see if the x-coordinate was 0, and if so, color the hex red. If the y-coordinate was 0, color it blue, and if the z-coordinate was 0, yellow. It took me maybe a half hour to figure out that the y-axis was the collection of points where x was 0, and the x-axis was the collection of points where y was 0, which was why the blue hexes were a horizontal line, instead of the red hexes, like I had been expecting. Part of me knew this already, but my sleepy brain wasn't listening.

I think I've worked out the difficult bits of the math now, and I can click on tiles, and my current debug code lets you turn path tiles green by clicking on them. Hey, that's almost like gameplay. Solve a maze by drawing a path from one side of the screen to the other. Ok, it's self-directed gameplay - the computer doesn't give you any goals, or enforce any rules.

Still, if you like clicking on hexagons, it's got that.

http://bigdicegames.com/RatMaze/maze.html

A maze of twisty passages, all alike.

Not a game yet, just an experiment - I intend September (and October?) to be small-game months. We'll see how that works out.

I would like my small September game to run natively and enjoyably on Android. I would also like to see it feel native and enjoyable on the web. Again, we'll see.