Since the last devlog there were 13 commits between 2019/02/16 and 2019/02/22, totaling 34 commits. I have worked 35 hours during this period, bringing the total to 83 hours. This one is entirely about messing with AI, iterating and refactoring the approach. Initial Approach It started with basic xml Behavior Tree from the last devlog. First thing I did though, was updating Haxe to version 4 Release Candidate, in preparation to using inlined markup.
Since the last devlog there were 10 commits between 2019/01/27 and 2019/02/15, totaling 21 commits. I have worked 28 hours during this period, bringing the total to 48 hours. I started out by adding new type of objects to my Tiled map. A bit more messing around and I can now have basic message interaction in the game. That included adding overlay UI system, some refactoring, support for nineslice scaled ui elements.
Few days ago I have decided to start an RPG project, as that’s what I’ve always wanted to make. I will be fairly limited with graphic assets and time, but at least the coding part will be fun. I will make do with what I have available. Right now I have depth sorting implemented: I’m using Time Fantasy art assets. Tiled for level editor. Haxe as programming language. Phaser 3 as framework.
In the third log we made the server authoritative and implemented client-side prediction. Now is the time to add other players and properly implement entity interpolation. Entity Interpolation In General The principle is pretty simple. Server sends updates containing positions of all entities (other players). Client waits a few updates before moving the entity while interpolating between the individual updates. As an example, if server sends updates every 100 ms, client can wait until it receives 3rd update (i.
Motivation I am developing this game on Windows 10, but eventually the game server will be running on Linux (for obvious reasons). Testing builds and functionality locally is good enough, but testing things like client-side prediction, we won’t be able to properly check the behavior without some simulated latency and packet drops. We could probably use something like clumsy on Windows for that, but personally I would still like to test on the target OS.
In the first developer log we talked about cheating and how the best way to prevent it, is making the server authoritative about the state of everything. That is what this log is about. Taking the custom simple physics engine we talked about in the second log, we are ready to start. Server Loop So how do we go about moving everything to server? Client has basic game loop where it moves character around based on input.
This second log was supposed to be about making the server authoritative so we would prevent cheating. Authoritative server has to simulate physics while client does client-side prediction. The first step took a bit longer than expected and deserves its own log. The previous naive implementation of our multiplayer platformer used Phaser’s Arcade Physics. Given new requirements, which will be further explained in the next log, we can’t use Arcade Physics and need to create our custom solution.
Motivation After finishing the project for my parents I was talking about last time, I finally had some time to get back to game development. After spending something over a month playing with unity engine, I decided to switch my focus back to something that got me to programming in the first place. Multiplayer online games. Back in high school, I implemented very naive multiplayer bomberman game as my school-leaving project.