Dragon Glass or the story of the game editor Larian Studios

Hello, Habr! This is Larian Studios again. Ugh, we had a release, and now finally there is a time to continue to share our experience and best practices with you.

Today I will talk about the most important tool, with the help of which 4 projects were born - about the coffee machine, the internal editor of the game. The editor is available in a limited (for modders and players) form on Steam / GoG, so anyone who has purchased the game can download it and try it for free.

In the article, I will review the basic functionality, touch on some architectural solutions and talk a bit about the process of its development and support. If you like it - in the following articles I will tell in detail about each element of the editor separately.

Well, I’ll also tell you what Tools Programmer is doing in our studio.

“Man is an animal that owns tools. Nowhere will you find a man without his tools. Without them he is nothing, everything is with them. ”
Thomas Carlyle

The Divinity Engine Toolset (or, as we call it, Glasses) is an internal tool, a game editor used by Larian to create its games. Its history began with Dragon Commander and has been going on for 6 years. Consisting of a large number of components, it combines tools for game designers, level designers, scripters, as well as for animators and artists. Our editor is a constantly changing and growing organism that constantly adapts to the new technology stack and the list of requirements of each department of the studio, therefore its main property is modularity and ease of connecting new plugins.

And what is the basis?

All our games are written using C ++, and Glasses is an additional add-on for the game, which allows us to reuse the functionality of the engine to implement the necessary tasks. Thus, for example, users of the editor can play the game without leaving it and not starting another process, which greatly facilitates testing of quests, atmospheres and battle scenes.

Initially, the game editor was written using WinForms , so the connecting link between the toolkit and the game is the C ++ / CLI layer, which allows you to translate data structures from the game into the editor and vice versa. Of course, you won’t be full of WinForms , therefore third-party frameworks like ScintillaNet for the script editor are also used.

Winforms? Oh oh..

True, but that was before. Now the editor has successfully migrated to WPF, and, thanks to the modular architecture, the transition could be made on the fly, that is, introduce new features and plugins already on WPF with the ability to access old windows and options on WinForms. It should be noted that WPF pretty much reduced the development time for new controls and windows, as well as improved the overall quality of the editor interface.

One ring to rule all

In any large project, sooner or later, participants begin to use a version control system. Someone copies to flash drives, someone uses git, we at Larian use perforce (p4). And if the use of p4 by programmers is straightforward - everything integrates quite easily into the development environment, then with the rest of the departments everything can be more complicated. The lack of information about the status of files in the version control system forces designers and artists to put in additional tools and complicate the process of creating content (“before you start you must check out, otherwise the file may be read-only”, etc.). Therefore, the integration of the version control system into the game editor is a task that solves a lot of problems at once. The main idea: “the smaller the artist, the designer thinks about third-party factors, aka the procedure for uploading files or adding new files to the version control system ”, the more time he has for his real tasks. It seems to be simple, but at the same time it greatly improves efficiency.

Following the idea described above, we try to reduce the number of third-party tools used by our employees, taking out all the functionality in the form of plug-ins for the editor. Here is another example: initially, all the “math” and game data (how often this weapon will fall out, how much damage this fireball does, how many lives this guard has) were in cozy excel tables that exported data as text files using VB scripts in the format necessary for the game. This rather quick and simple solution worked until the number of people working on game data grew to such an extent that several people needed to constantly work in one file, merging excel tables is not a very trivial task, and the option to impose a restriction of “one person - one file” creates the effect of a bottleneck, and development slows down greatly. What to do? This is how the Stats Editor appeared - a recently made plug-in that allows not only working directly with the necessary text file directly using our UI, but also checking input data, avoiding many hours of debugging due to one incorrectly set value.

By the way, reducing the dependence on third-party applications improves the quality of user content made by modders. After all, the less they need to install and configure, the again they can focus on the realization of their ideas.

All spark

Also, in addition to small plug-ins, we were able to fully integrate fairly large programs and third-party editors. For example, a VFX editor. Initially, VFX artists used a separate tool, but a team of programmers was able to fully transfer its functionality to the editor, allowing artists to edit and create effects right in the game. Allowing you to combine various animated effects, adjusting and modernizing them, the user can create a huge amount of visual "magic", ranging from spells, skills and ending with environmental effects and even working with the camera. I would love to talk about this in more detail, but this is rather a topic for a separate article.

Modding

Glasses is an editor that allows you to create modifications to the released game. What happens when you give a game editor to players? Everything that seemed difficult or impossible becomes real. The enthusiasm of modders and players in the desire to create cool things is very strong, and therefore one of our tasks was to make the editor as accessible as possible to a wide audience. Because the simpler the tool, the more additional content will appear, and this greatly increases the life cycle of the game. All this leads the development team to make important architectural decisions that allow you to add, delete and overwrite content without affecting the game and ongoing progress. In our case, this decision was to break the game entities into "add-ons" and "projects / adventures."

More specifically, both entities are a set of data (objects, models and scripts) that a player can connect to his game.



Add-ons are “data packs” (content packs), i.e. an independent set of level models that any player can connect anywhere. Our experience shows that if huge user adventures add a lot to the game, then small modifications allow people to experiment faster and easier with the game logic by connecting and disconnecting the add-ons necessary in our case. For example, if a player wants to add more different weapons to the game (and this is not tied to the history of the main game), or add a chain of new quests, for this he does not need to create a large project, but just pack everything into a small independent file, which players they will be able to turn on and transfer to their discretion without fear that their conservation will break. One example of add-ons can also be a set of levels for the Game Wizard mode,

Adventures. If the user wants to do something huge, with history, overlapping quests and independent of the main game, then this type of modification is just for him. Here you will need to work with scripts, and engage in level design and other cool things that Larian Studios employees do to create their game.

What else is there?

A lot of things. As I mentioned, this is the main tool for developing our games. The editor includes:

• Genome tool for creating animations, animation blending effects, etc.
• Editor for game scripts.
• Of course, tools for creating levels and editing them. Work with terrain, atmospheres, level decoration, etc.
• Possibilities of editing character’s meshes and creating entire sets of visual elements for each type of creature; for example, if you want the same object to look differently on creatures of different structures (we did not want the same item of equipment to look the same on elves, people, and gnomes).
  
  
  
  
  
• Tool for working with localization.
• Dialog editor.
• Additional visualization. Different triggers, colliders of different shapes and types should be visually understandable and visible to the user working with them, so starting the game in the editor allows you to see their exact location and shape - it is much easier, for example, to control the game atmosphere depending on the player’s level of movement.
• Lighting editor. We use PBR (physically based rendering) to create realistic light. To do this, we use light probes and a story about their logic and generation is for
  sure a separate article.
• Functionality that allows you to create and edit AI templates, and an AI grid that helps combat designers to create interesting battles.
• Powerful material editor.
  
  
  
  
  

Did they say something about Tools Programmer?

Around this position there are a lot of obscure associations, and one of them claims that “Tool Programmer does not make a game, but makes tools for company employees and has little relation to the game being developed.” A sort of "programmer for the implementation of Wishlist artists and designers."

It's not like that at all. Who makes the game is the Tools Programmer. Constantly maneuvering between two architecturally different projects (a game and an editor), the editor’s developer is almost the only person in the company who always keeps his finger on the pulse of every new feature in the game, whether it is a gameplay feature or a new design decision. The integration of new technologies, tools and third-party solutions is carried out exclusively by the Tools Programmer, because only he knows how to add this or that functionality in a way that is accessible to people of a non-technical mind. Often when Gameplay and Engine developers are closed in their own current tasks, it is Tools Programmer who needs to solve architectural issues that will establish and adjust the development process in all parts of the studio for several years to come.

Now we have a team of 5 programmers directly involved in the development of The Divinity Engine Toolset. And we are not enough! So if suddenly you have a desire to help us and participate in the development of a very cool engine - write and come to us =)