Pathfinding, redux

This evening I got pathfinding working around a larger, scrolling map. I thought this would be best demonstrated in motion, so here’s a little YouTube video of it in action:

I had to turn the sprites down to 32×32 from 64×64, as the view seemed too claustrophobic that zoomed in. This has some unfortunate knock-on effects for the mobile client — I think at 32×32 the tiles will be too small to accurately tap on — but I’ll tackle that another day.

Point of view

Last night was the inaugural meeting of my new after school study club, and it was a very cosy, pleasant experience. We went around the table and talked about our various works-in-progress, discussed the merits of various database/model frameworks, and eventually settled down to work on our individual projects.

I spent the time getting field-of-view and fog-of-war working in Bones of the Idle. I already had some code from an earlier JS roguelike project to hand, so with a bit of refactoring I was able to slot that into place:

There is nothing insignificant in the world. It all depends on the point of view” — Goethe

The darker areas around the edges represent tiles the player has seen before, but currently cannot see (fog of war), with brighter tiles they can currently see surrounding them. As you can see, their field of view isn’t a perfect circle, as it’s being obscured by the nearby trees.

Now that the player can be placed on the map (which in turn can be larger than the view port, a new feature over the previous code base), the next obvious step is to re-implement pathfinding and get them moving around and scrolling. I still want that to be verified server-side, so again I’m hoping to take the existing code I already have, give it a polish, and drop it in place.

Aesthetics

I spent a bit of time last night working on the new look for Bones of the Idle. I’ve been on a bit of a lo-fi vaporwave kick at the moment, and seeing how much of the game is supposed to evoke a kind of wistful nostalgia for late 80s/early 90s BBS door games like Legend of the Red Dragon (1989) and classic ASCII roguelikes (Rogue, 1980), as well as early pixel art gems from the 8-bit eras of the Spectrum and Commodore 64, vaporwave seemed like a good fit.

Some vaporwave discussion on YouTube

Prototyping

I prototyped some UI elements like simple buttons, basic form elements, overlays and popup boxes, and ended up implementing them on the main home screen, which I think looks pretty good now:

It’s aggressively neon, the green glows in a totally tacky way, and I’m mixing green and pink in a way that shouldn’t exist in nature. In short, I’m pretty pleased with it.

I’ll be sticking mainly with this colour palette (top row), which I think most would consider to be canonically vaporwave, but I’ll also be experimenting with the colours on the bottom row, which are the 180° hue-rotated compliments. In theory they should compliment each other well (if used sparingly), but I’m no designer or colour theorist. I’m pretty confident in my skills for the more technical aspects of getting this game built, but the look and feel of it is something I’m really going to have to work at and pay close attention to.

What happened to June?

Here we are in the middle of July, and there’s a conspicuous lack of changelog notes for June. So what happened?

Most of June was spent in an existential funk as the project floundered a bit and I found it hard to keep working on it. Some of code was getting a bit smelly, particularly on the client-side, and I found as I was working on new content (skill-driven combat, specifically) a lot of the structural assumptions I had made early on were proving to be incorrect.

So it’s time for drastic measures to get things moving again. Co-incidentally, the folks at Debian released buster, the new version of their distribution recently. I took this as a bit of an omen and upgraded my server. It went pretty smoothly, and it gives me access to the latest version of PHP, and so the latest version of Laravel, too.

I created a new project, and I’ve been slowly porting over the decent code and rewriting the bad, paying particular attention to the client, where I’ve completely re-written the network handling, and made some pretty massive changes to the display canvas.

The upshot of all this is that the game is looking… different. Better, I think, but certainly different. The colour palette is a lot more high-contrast (and dare I say it? vaporwave aesthetic) and the visible map area is much larger. I realised that what I really want to be implementing is a more roguelike experience, with larger, scrolling maps to explore. So that’s where I’m heading.

Changelog, 2019-05

May was a huge month for Bones of the Idle. For one thing, it got named and stopped being “that browser game project”. But it also got pixel art sprites, maps you can wander around (with A* pathfinding), crafting, and skill-based combat. It really went from being a proof-of-concept to being an actual game.

Environment

  • The player is now visible on the map and will move to a location when the map is clicked. Pathfinding is calculated entirely server-side and starting an action is now co-ordinate based and validated by the server.
  • The forests are now (potentially) infinite, with new maps generated by the server on demand. A small town consisting of pre-generated maps has been started.

Combat, monsters and NPCs

  • Monsters (and players) have a selection of stats that influence combat. Both now also have combat skills that have individual effects, strengths and weaknesses.
  • New monster: giant forest rat
  • Initial work on NPCs you can converse with.

Items and crafting

  • Crafting is now implemented with two skills: woodworking and cooking. Interacting with a crafting workbench opens up a new UI that shows all the recipes available to you, and allows you to specify how many products you want to start crafting.
  • New recipe: process oak wood
  • New recipe: wooden skewers
  • New recipe: rat on a stick

User interface

  • Player health and energy are displayed as a pair of progress bars above the map. Players now slowly recover health while performing any action other than combat, and can quickly recover both health and energy by eating food, or resting at specific locations.
  • New popup overlay windows for player stats, inventory and item details.
  • Clicking an item now pops up a small window describing it, and allows you to use certain items. Items with a use effect show a small yellow star next to their name.
  • Many, many visual updates and tweaks, including full mobile browser support.

All my to-do notes and outstanding bugs are tracked on this public trello board.

Pathfinding for robots

Bones of the Idle is the result of multiple separate coding projects coming together over the course of six months or so. I made each of them with the intention of learning something new, then in typical fashion abandonded them once I was happy with the fundamentals. What’s been gratifying to see is how each of those projects has fed directly into the game. All that time wasn’t wasted after all!

The largest piece of the puzzle was an event-driven mini game, envisioned as a clone of the World of Warcraft mission table. I used it as an excuse to learn Laravel and play around with Bootstrap, and it still forms the basis of much of the back-end today. It was styled like a typical Bootstrap admin panel, heavy on text and progress bars, and when you complete some herb gathering or tree logging in the game today, that’s a much-sped up version of finishing a mission that originally would have taken hours or even days to complete. Although it had locations with different objectives in each, there was no sense of the player existing anywhere beyond a room-like “container”.

The next project to get folded in was a roguelike engine I made in Javascript, to experiment with the excellent ROT.js library and the Command design pattern. That resulted in the maps we have today, with the player visible and moving around, interacting with the map elements to complete actions. Unfortunately, the disconnect between the old location code and the new maps lead to a few inconsistencies that needed tidying up.

For one, the player’s position and movement wasn’t often validated server-side; with a little bit of JavaScript know-how it was possible to teleport yourself around the current map. In fact, alpha-tester extraordinaire Simon did just that.

It wasn’t hideously game-breaking, considering the server didn’t (yet) care if you could reach a given tile before allowing you to interact with it; but annoying nonetheless. What was a little more disturbing was an auto-farming function he managed to come up with, that sought out rats, trees and flowers to farm, and automatically clicks on them. The game wasn’t even in proper alpha state, and already I had my first scripted bot to contend with.

The solution was to make movement a lot more robust and to handle pathfinding server-side. I used the BlackScorp/Astar PHP package to handle generating paths, and changed the client side to request a path to follow, rather than having it make up one of it’s own. Now the server only saves genuinely accessible positions for the player, making movement much more controlled. In addition, the server also validates that players are adjacent to the action nodes they’re attempting to interact with. Some botting via Javascript injection is still possible (and likely always will be; that’s just a cost of having a JS client), but at least now you can’t do things that are impossible by playing manually.

Long-term, I’m not too worried about JS injection and botting. I’m going to make sure everything is validated server-side, so bots can’t outperform human players, and aim to make enough actions that require human interaction that botting becomes perhaps an interesting diversion, rather than the best way to experience the game. I might not support it per se, but I was genuinely excited to see the stuff Simon had come up with, and it certainly gave me plenty to do.

Screenshot: take that, you rat!

I’ve begun work on the combat engine, and rats now leave a satisfying puddle of bloody goo when they’re killed. It’s a little rough when you first start out, so the numbers probably need a little tweaking.

Welcome

You are standing in an open field west of a white house, with a boarded front door.

There is a small mailbox here.


ZORK I: The Great Underground Empire

Recently I’ve been doing a lot of fun, exploratory programming, making little games and engines and example systems with an eye towards creating a persistent browser based game. I’ve experimented with using ROT.js to make a JavaScript roguelike engine using the command design pattern; written the barest of bones of a MUD and learned about websockets along the way; and most recently started on a Laravel project that I’m hoping is going to be the surviving incarnation of this browser game idea.

I’ve been thinking about starting a little research and development blog to go along with my programming efforts, so I posted a few questions to the always-helpful r/roguelike community, and Kyzrati (of Cogmind fame) posted this characteristically generous and informative reply; consider this brand-new WordPress install my response.

I’m going to be posting a mix of development notes, changelog discussions, thoughts on theorycrafting and design, procedural development, idle/incremental games, computer and tabletop RPGs, plus any links and asides that catch my eye. You can find me on twitter at @rumorsmatrix.