I have one month to make an MMO: Day 12
Today was a big day in code land. I’d gotten pretty much all of the core movement of the NPCs done, which was a major item in this sprint.
I’m feeling happier that my work hours are more sane. But I feel like I’m getting less done per day.
More Entity Nodes
The entity nodes are now working! They work in a similar way to the player nodes, but instead of allowing a player to control them, they have all of the NPC behaviour code inside.
In order for the NPCs to be able to move around the world, they make use of the same chunk loading system that the players do. As the NPCs navigate the game world, their own nodes will make requests to load map data for the chunks that they’re in or near; and will also subscribe to the same movement updates that players do, in order to receive location information about other entities and players in the area.
Early on in the day, to test that the nodes were working, I put in some random jittering for motion to check whether they were transmitting their data correctly:
Server-side Collisions
NPCs need to move around the map without clipping into things or going into areas they’re not supposed to be able to go into. This data is available on the Movement layer of the chunk data, which as you may remember is just another tile layer, looking something like this:
This demonstrates the key reason I decided early on to use Tiled, an external map editor, to build the maps — the data that it produces can be consumed by both the player client written in GML, and the entity nodes written in Python.
The Entity Node loads and caches chunk data, and before allowing the NPC to move, will check for collisions against the tiles in this movement layer data. The Entity node also checks for collisions against other entities and players, stopping any movement if there’s a collision.
To test this all out, I put in a hard-coded movement, so that all NPCs will try to move towards the south-east, where they will hit a collision block. I also moved my player character into their path to see if they stopped or not.
The great thing is I can re-use this collision checking code with the player node as well, to prevent players from hacking their way through everything. The player node will keep track of player movement, and will disallow movements it thinks aren’t possible, and refuse to update the player position.
NPC movement
The final piece of the puzzle is to implement the ability for the NPCs to respond to the player position. Since the entity nodes already receive position updates from other entities in the chunks around them, it can use this to decide on motion too.
To test this idea, I’ve added four obj_mobs to the map. This is done simply by dragging more obj_mobs from the template onto the map; then running the parser and bootstrap scripts to get that update into Redis
I then temporarily added some player-following code into the entity nodes to test out entities’ abilities to respond to nearby players.
This proves the concept, but of course look robotic and unrealistic. Some more advanced stuff movement models can be added later.
Day 12 Task Summary
It’s been quite a productive day, with a lot of the pieces coming together at once. Nevertheless, I’m still a day behind schedule, having not completed the NPC dialog system, which was dependant on the entity nodes existing.
Tomorrow, I’ll decide whether I feel like extending the sprint by a day, or try to slot the work into the next sprint.
