This entry marks the beginning of the new dev (b)log category, where I’ll write short articles on a biweekly basis to discuss the progress I make and the challenges I meet on the projects I’m working on. These logs will typically focus on high-level overviews and gameplay examples, and usually won’t include code snippets, but I will gladly provide them if there is any demand.
The new project I’ve begun working on is (for now) named Westward. Westward is envisioned to be a massively multiplayer game, where the players need to collaborate and organize themselves to settle a wild, foreign land, and gradually build a nation of their own. This project will combine familiar MMORPG mechanics with strategical and tactical aspects. More information will be revealed in these dev logs as the development progresses.
A massively multiplayer endeavor is ambitious and risky, but also incredibly interesting from a technical and game design point of view. I hope these dev logs will be interesting to you and might help you for your own projects, even if they are quite different in nature. I’m also very eager to discuss remarks and feedbacks, whether in the comments or on the Slack channel.
By nature, Westward will require a very, very vast open game world to explore, as the colonization of this world should ideally be a very long-lasting campaign. Obviously, such a very big map should not be loaded all at once when a player connects. A common strategy is to organize the world with natural bottlenecks and passageways that naturally create separate areas that can be loaded separately. However, I find it too restrictive and prefer one single world map. In that setting, the smart approach is to only load the “chunks” of the entire map that are relevant for the player.
The idea is very similar to the Areas of Interest (AOI) system I talked about in another article, but this time applied to the rendering of the map (both go very well hand-in-hand since they can correspond to the same geographical areas, allowing for more efficient map management and networking). The chunks are areas of predefined size, which are loaded on and off of memory as the player moves. At any given time, only the chunk where the player is located and the immediately adjacent chunks are loaded.
At the time of writing this, I must admit that I didn’t find a satisfying way to implement this with Tilemaps in Phaser. I expect Phaser 3 to make it much more feasible, based on what I’ve read in Rich’s own dev log. In the meantime, in order to have more flexibility, I decided to bypass Phaser and to directly use Pixi.js. In the future, I may use my Pixi-based chunk maps implementation side-by-side with Phaser, or not at all depending on how things evolve.
The implementation went smoothly, in part due to the ability to re-use the AOI code from Phaserquest, since the same logic can be used to identify which AOI/chunks gain or lose relevance based on the movements of the player. To test the results, I created a demo map in Tiled, which I then split in multiple files corresponding to each chunk. These files are then loaded on the fly when needed. You can see a demonstration in the following gif:
The black area is the whole game canvas. As the player moves by clicking on the screen (without tweens or animations at the moment), you can see how different parts of the map appear and disappear. For the demonstration, I use very small chunks, so that the effect is visible. In practice, each chunk should be at least the size of the game canvas, so that these (dis)appearances are totally invisible to the player.
This was an important first step, to guarantee that the experience I have in mind of exploring a big world was feasible. With that approach, there is virtually no limit to the size of the game world. This, however, can become a curse, because the bigger the world, the more challenging it is to populate it with interesting content. In future dev logs, I’ll discuss the use of procedural approaches to help populate big maps.
Please post your thoughts on this in the comments. It would also be great if you could share this around : it is crucial when embarking in a new project not to do so in isolation, but rather to engage into as many discussions as possible to gather food for thought. And don’t forget to come back for the next logs!