Combat Camera – Update #16

We have briefly discussed camera during exploration in Update #12, now it’s time to discuss camera during combat.

Because exploration is done in real-time and combat is turn-based and because during combat the player is facing different challenges that during exploration, the camera control also needs to be a bit different.

In practice there are more things happening and it is even more important to clearly convey the information to the player.

Previously the camera would just automatically focus on the character who’s current turn it is. However this proved insufficient. Among others there were problems with AI controlled characters moving faster than the camera, resulting in empty, irrelevant space being shown, also monsters entering and leaving Fog Of War proved a bit of a challenge.

After a round of polish the camera behaves much better. The focusing logic has been improved, as well as it now follows the current character during their turn. All of this behaviour can be overridden immediately by the player if they choose to move the camera somewhere else. This combination of automatic behaviour with an easy way for the player to take over seems to work well so far.

Combat – Update #15

Elemental Enigma is 2D isometric RPG with turn-based combat. After months of improvements to quests, rendering and other important systems it is finally time to have a look at combat.

Combat in Elemental Enigma is inspired by modern Shadowrun and XCOM games as well Disgea and Final Fantasy Tactics. Player controls a party of 1 to 4 characters and by using various skills and positioning tries to eliminate attacking monsters.

Skills that the player controlled characters have depend on their build, and unlike most games their build is directly tied to their personality.

Positioning is relevant, not only in regards to distance to enemies, but also certain objects offer cover while some locations might offer passive buffs. Also direction in which character is facing is important, as flanking enemies can provide significant bonuses to attack.

Combat is divided into rounds which are divided into turns. Each character gets one turn in a round, when they can perform a limited amount of actions. Order of characters in a round is randomised based on their Initiative stat. The higher a character’s Initiative, the earlier in the round they will be able to act.

Combat encounters are self contained. That means that health and magick points are restored at the end of combat, KO’ed characters are revived and most status effects are removed.

Over the course of development more details will be shared. Among others on how equipment impacts combat, what kind of skills might be available and more.

Character Animations – Update #13

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.

Camera control – Update #12

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.

Minimap and the importance of iteration – Update #11

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.