Work this week covered a few different topics that are very important from a programming perspective, but no so exciting in terms of gameplay or the end product that a player would see. I hope you enjoy technical talk.
The first challenge that I've been facing down for some time now is a matter of load times and game stability. Currently the game runs at a consistent 60 FPS which is more than okay. However, due to how Verdant Village is constructed the FPS could be jeopardized at some point. Once you get past the title screen/load screen the entirety of Verdant Village is loaded up. This means all the characters, objects, code, zones, buildings, everything in the playable game is loaded. As you might guess that's a lot of stuff to load.
Modern computers are pretty powerful, even the mid-range ones can handle quite a bit. There are currently about 6000 objects in the game world once it is loaded up. The concern is that as more and more is added to the game it will reach a point where the FPS starts to take a hit. Thankfully, Construct 2 is programmed to only render on screen objects so even if 6000+ objects exist in the game the engine is only actively rendering about 100 or less at any given time. This is great, but there is the possibility that even if they aren’t rendered there could be too many objects for the engine to handle.
There are several tricks being done to hopefully keep these problems under control, things that have been done since very dawn of video games. The simplest to explain being the reuse of sprites. When an object is loaded in the game it's sprite, the image associated with the object, is loaded into memory. If you reuse the same sprite the computer doesn't have to reload that image again, thus saving space and processing power. For example, the game has many trees. If I have 100 pine trees all using the same sprite the game only has to load that sprite once. That alone is 99 fewer sprites the game has to load. When I mentioned the dawn of video games earlier, I believe it is one of the early Mario games, like 1, 2, or 3, where the bushes and the clouds in the game are actually the same sprite. In order to save space, they just recolored at runtime with code instead of making two sprites.
With any luck programming tactics similar to this will keep the game running smoothly. The other more daunting issue is load times, or specifically load time. There is only one substantial loading screen for the game, when you transfer from the title screen to the game itself, i.e. when you load your save file. Currently this is sitting at about 20 - 25 seconds of load time. In my opinion that is tolerable but also not great and I'd like to improve it.
I've spent a chunk of the week looking into solutions for the problem and come across a few things that can hopefully help. The problem mostly arises because of number of sprites the engine has to load into memory when the game is loaded. As I mentioned before when an object is created its associated sprite needs to be loaded into memory so the engine can render it. Due to circumstances in the game the entire game takes place on a single massive layout as opposed to many smaller ones. The sheer number of different objects causes the load time to hang for a while.
Currently, I'm looking into precaching sprites and staggering the objects that are loaded into memory. This basically involves spacing out the sprite loading so that instead of loading everything when you enter the game, things will gradually be added to memory without the player realizing it is happening. From the player perspective you will be playing while the game loads. With any luck these issues can be ironed out soon and I can focus more wholly on finishing the database of items that can be created and found by the player which is swiftly turning into a web of different materials and items. Below is a zoomed out screencap of web, I don't really want to reveal all the items but I like to think it gives a more visual scope of what the player can obtain in the game. This image encompasses a relatively small portion of the items in the game. It isn't a sprite but it does have bright colors at least.