One of the biggest benefits of making a 2d game is that in regards to technical aspects there is one parameter that has to be monitored and kept in budget – video memory, as opposed to 3d games where polygon count, level of detail, draw distance, animation complexity, lighting complexity as well as video memory all have to be balanced.
One of the biggest problems with making a 2d game is that its video memory consumption can easily explode. All animations, objects, characters – everything that is visible on screen ultimately ends up in a texture atlas, with few ways to optimise them.
However regardless of difficulties, optimise we must.
One of the ways to do such optimisations is to look at animations of all characters and monsters and make sure they take as few frames as possible. However this has to be balanced with making sure they still look smooth.
After latest set of such optimisations a typical character animation atlas was reduced from over 7000 frames of animation to about 5000. During that process all animations were improved to look less jerky and have a unified look.
There will be more work needed, but at this point only smaller improvements and polish will be necessary.
All games utilise some sort of a camera to show the game to the player. Even though it is one of the most common aspect of games, it can still be a tricky problem to solve. Of course for some games it can be trickier than others. 3rd person 3D action games are probably the most notorious in this department, as the camera can get easily stuck in all types of geometry. 2D isometric games have less complicated problems to solve, but it doesn’t mean they are trivial.
Ultimately one has to remember that camera control (just like walking) is not a game mechanic. It’s something that just has to be there, for the player to be able to play. It has to be unobtrusive, easy to use and ideally not require player input at all. The challenge here lies in making it smart enough, so that the player doesn’t have to constantly be distracted by where the camera should be pointing, but without taking agency away from the player.
After recent round of polish, the camera in Elemental Enigma during exploration tries to anticipate where it should look, based on player input, but without taking away all control. Also additional ways to focus on party members have been added, so it’s easy to see the relevant character if they happen to be off-screen.
While playing through the game at it’s current state it was becoming clear that for big game areas, such as the forest that will be featured in the demo, it was easy to get lost. Although it is to be fairly dense with content, relevant quest locations were far enough from each other that at times it wasn’t clear where to go. Even if one has already visited the relevant location.
Because the game will not feature objective markers of any kind, a different solution had to be found. The best one seemed to be to provide the player with an auto-map. A feature that from it’s introduction into the cRPG genre in the 80s/90s, has been seen in almost all isometric RPGs.
But adding such a feature is not that simple of a task. What should the map look like? What information should it show? How information should be represented? How should the player access it? How should it be interacted with? These and more questions needed to be answered for this feature to be ready.
This is where prototyping, fudging and iteration come in. The best way forward was to try things, experiment with different methods of the map being displayed, as well as the process for the data for the map to be created.
Early in development of the game there was a mini-map in the HUD of the game. This was deemed not very practical, as it didn’t solve any of the issues that were faced and cluttered the screen. It was good to try out, but ultimately that implementation was scrapped. Unfortunately no screenshots of that remain anymore.
Over the course of last week various implementations of displaying of the map in the game’s Map Menu were tested. That seemed to solve a lot of issues related to navigation, without detracting from the gameplay itself. However there was still a lot of details to work out.
Initially the map was an image showing the whole game area, but scaled down, with some detailed icons showing player party member locations, NPC locations and various points of interest. A solution similar to the one that has been used in many Infinity Engine games and Torment: Tides on Numenera.
This although provided relevant information to the player, had certain readability issues. The image used a lot of colours, making it difficult to show clearly additional information on it. Another thing was that the image was huge, so opening of the Map Menu took noticeably longer than other menus. Also the way it looked stood out from all other menus.
To deal with the shortcomings of the scaled-down-image representation was to use a much more symbolic map. One that would just show relevant areas as outlines and simplified icons for locations of relevant characters and points of interest. This turned out to work much better. It was clean, consistent with other menus and because it was generated from existing data, no new images needed to be created and loaded.
Ultimately the minimalist map was chosen as the solution. With some tweaks to generation logic and used colours, it was possible to make it load quickly and be easy to read and easy to use. This implementation seems to be solving all problems with navigation through, and orientation in the game world.
Most likely there will be more tweaks to the auto-map, but what is currently in the game works quite well, and for the time being, the implementation can be considered done.
A couple of days ago was an important milestone for the project. It was a moment when the all individual parts of the main quest for the demo became a single whole. All the conversations and other interactions, placement of objects on the map, puzzles, cutscenes as well as the quest structure, became a single experience.
For the first time the quest could have been played through start to finish, and in turn the demo could have been played from beginning to completion, although still in its skeletal state.
There is still a lot of work ahead. Combat encounters need to added to the demo and balanced, sounds need to be attached to many elements, tutorials for relevant game mechanics, plus a lot of smaller details and fixes.
This whole process is taking a bit longer than expected, which is nothing new for game development, but the work is constantly moving forward.
Every now and then one needs to pause cramming content into a game, take a step back and have a look how the game runs. There is a certain art to picking the right moment for doing that during the development process, as doing it too early might result in looking at the areas which have little real impact, and doing it too late might result having to fix or refactor a lot of existing content or technology, while struggling to work efficiently when the game runs in an unsatisfactory way.
This week this moment came for Elemental Enigma. The plan, from the very beginning, was for the game to be able to run at locked 60 FPS on fairly low-end devices, like laptops with Intel i3/AMD Ryzen 3 CPUs and integrated GPUs. The frame rate is to be locked, because there is little benefit to having an unlocked frame rate in 2D games without any vector graphics.
So far this method of taking a step back every couple of months has been very successful. There have been very few moments during the whole development process where the frame rate would consistently drop below 60. However with time as more things were being added (more foliage, more complicated particle effects, more objects in general, bigger maps, etc.) the frame rate started becoming less and less stable. So although the average frame rate was still 60 FPS, there were common, although short, drops. Which might not be a deal breaker during development, but would be absolutely unacceptable in the finished product.
Thankfully there are many tools, both 3rd party and created in-house, to address these kind of issues, to see which part of the game takes too many of computer resources.
After fiddling with these this week, addressing issues with how objects are queued for rendering, how Fog Of War is rendered and multiple others, most frame drops have been dealt with. It is satisfyingly solid, at least for the time being.
Elemental Enigma is not yet finished, this will still take considerable amount of time. And while new, more complicated content is being added, the game’s performance will be constantly monitored, so that even people wanting to play the game on older laptops, will be able to do that without any problems.
