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.

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.