Scribes Devlog 2 – To Render a Map
For February 2024
Hello all, and welcome back!
Over the past month, I’ve been working on the implementation of in-game region loading. What I’m aiming for is a system for pulling the map data from the external files, and loading and rendering them in-game with as little frame loss as possible. To that end, I’ve been prototyping a handful of rendering methods and testing them on my laptop (which is quite a bit weaker than my PC).
Alongside the rendering, I’ve also been working on the game’s wall culling system, the spell list, and a companion tool to use throughout development. With all that, let’s get into the devlog!
How does the map loading work?
In essence, the in-game map loading works similar to how the map builder loads maps. The big difference between the two is that the file pulling done in-game is split up between more frames to reduce strain. The current system I have works well enough that I likely won’t have to make many changes to it down the road.
The main thing that causes frame loss is the actual rendering of the loaded map data. So the bulk of my efforts over the month have gone towards optimizing that system.
So how does the rendering work?
Scribes renders the map data by drawing all of the tiles one row at a time (from top to bottom) onto a surface, and then draws that surface to the game screen. By doing it from top to bottom, the natural overlapping of the tiles layers them, with no need for additional logic.
By drawing the tiles onto a surface, the game creates a temporary image of the ground and walls. Using these images makes it so that the game doesn’t have to redraw the individual tiles. Instead, it can make a single call to draw the compiled images.
Then how are tiles culled?
Since the wall tiles are compiled into a single image, I can’t just tell the game to *not* draw the tiles that need to be culled. Instead, I have to use a bit of trickery with surfaces and shaders to get the desired affect.
It works by drawing the culled tiles in white on a separate surface, and then redrawing any tiles which are hidden behind the culled tiles. The redrawn tiles are only done over the parts of the surface that gets culled to prevent issues with the redrawn tiles overlapping the compiled wall image.
The two surfaces are them combined and drawn to the screen using a shader which erases white pixels, and cleans up the edge pixels on the sides of the culled tiles. This creates the completed look of culled walls:
The game uses a sequence of checks and logic to determine which wall tiles need to be culled. This logic allows the game to cull tiles which may be above the player, in order to ensure the player can see everything that’s relevant. The culled walls are updated 6 times per second in order to minimize frame loss.
So what else?
Outside of the rendering system, I’ve been working on a companion tool to use in development. This tool is an app for converting a tilesheet into a usable tile sprite. The idea behind it is to cut out most of the logic checks made while rendering to further reduce frame loss.
While this may seem like a good idea up-front, it does have the drawback of increasing the file-size of the game by a potentially significant amount. Since the compiled tile sprites are quite a bit larger than the original sprite sheets they come from, they will inevitably add some bloat. However, if the amount of added size is within a reasonable margin, then the positives will definitely outweigh the negatives.
On the game design side of things, I’ve finished designing all but a couple of the 80 base spells which can be cast in-game. Though some are subject to change as the project progresses, the vast majority of them are all but set in stone.
For Scribes, I wanted to design a magic system that’s more than just a means for combat. So, of the 80 spells in the game, only 14 of them deal damage. All of the others are mobility, utility, and status spells. The magic system is built to facilitate exploration, puzzle solving, and expression in playstyle.
While I’d like to take some time to talk more about my magic system, I think it’d be better to just wait until I can actually show it in action. So, despite how short this devlog was, this’ll be it for now.
I’ll see y’all in a month or so with the next devlog!