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.

Putting it all together – Update #10

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.

Optimisation – Update #9

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.

Cutscenes! – Update #8

Cutscenes have been a part of video games ever since they started having stories incorporated into them. Over the years their quality, fidelity and complexity has increased dramatically. Probably achieving it’s height during the golden age of FMV games in the 90s, when often gameplay was just a means to get you from a cutscene to a cutscene.

Although games are a fundamentally interactive medium and should follow the “play to don’t show” rule, cutscenes, even now, have a lot of utility. They are a great way to build up set pieces, or show the player consequences of their actions, or emphasise a payoff to player’s efforts.

They are also an interesting technical challenge. After all, one is trying to create a system in which the game does what usually would be done by the player, or do things that normally would not be possible in the game in the first place. That’s one of the reasons why so much has been written about Matinee in Unreal Engine and one of the first community questions regarding the Aurora Toolset (powering Neverwinter Nights) was: “How do we create cutscenes?”.

In essence: they are important in modern games.

They also will be important in Elemental Enigma. And although it’s a game that emphasises player choice first and foremost, certain non-interactive elements will be necessary to move the plot along, add some punch to narrative points and make the game world feel a bit more alive.

For this update it mostly means that the system for creating and running cutscenes has been polished up and tested, and a number of short ones are being created for the upcoming demo.

The way this system works is fairly unorthodox, as unlike most, cutscenes are not represented as a timeline, but a graph. That might make it more difficult to time-align events, but on the other hand it makes it easier to chain events that don’t have a certain duration (like ordering a character to walk to a location, when moving obstacles are involved).

So far the results are quite good, even quite complicated scenes are easy to create and test. More work is needed to determine what is the best way to integrate them into the actual game, but that is also being done.

Quests – Update #7

Quests tie all parts of an RPG together. They provide the motivation to keep playing as well as track the player’s progress through the game. Because they are so central, they can get quite complex.

This week more work has been done on the main quest for the demo. That means both creating the actual content, as well as making improvements to the system that manages it.

Quests in Elemental Enigma from the very beginning were represented as hierarchical graphs, a fairly natural way for branching narratives. The idea is to make as easy as possible to create a free form way for the player to progress, while still maintaining some structure.

Each quest is made up of multiple phases, which are moments in the game where the player needs to perform something. They can be very simple, as in – go get that item, or extremely complex having their own internal set of conditions and steps.

Complex quest phases can be made clearer by having sub-quests – smaller quests, that are to help the player go through an individual phase. The can be tracked in the game separately. And, at least in theory, sub-quests can have their own sub-quests, if needed. Making it a multilayered hierarchy.

As mentioned in the previous quest update, there are multiple ways to create Narrative Systems and processes with which to create Quests. It’s usually best to tailor the system to a kind of game one is trying to make. Linear jRPGs will have different needs to Open-World Immersive RPGs.

Elemental Enigma is using the briefly described here hierarchical graph approach, which was designed to facilitate building of a narrative filled with player choices. So far, while working on the current demo, the results are promising.