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.