Dragon Glass or the story about the game editor Larian Studios

Hi, Habr! This is Larian Studios again. Ugh, we have had a release, and now at last there is time to continue sharing our experience and developments with you.

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

In this article I will review the main functionality, touch on some architectural solutions and tell you a little 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 tell you more about what Tools Programmer do in our studio.

“Man is an animal, owning tools. Nowhere can you find a person 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, the game editor used by Larian to create his games. His story began with the “Dragon Commander” and has been going on for the past 6 years. Consisting of a large number of components, it combines tools for game designers, level designers, scripters, and for animators and artists. Our editor is an ever-changing and growing organism, which is constantly adapting to the new technology stack and the list of requirements for each department of the studio, so its main feature is modularity and ease of connecting new plug-ins.

And what is the basis?

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

Initially, the game editor was written using WinForms , therefore the link between the toolkit and the game is the C ++ / CLI layer, which allows you to translate the data structures from the game to the editor and vice versa. Of course, you will not be full with one WinForms , therefore third-party frameworks are also used, such as ScintillaNet for the script editor.

WinForms? Oh oh..

And true, but it was before. Now the editor has successfully migrated to WPF, and, thanks to the modular architecture, the transition could be made on the fly, i.e. introduce new features and plug-ins already on WPF with the ability to access the old windows and options on WinForms. It should be noted that WPF pretty much reduced the development time of new controllers and windows, and also allowed to increase the overall quality of the editor's interface.

One ring to rule everyone

In any large project, sooner or later the participants start using the version control system. Someone copies to flash drives, someone uses git, we in Larian use perforce (p4). And if the use of p4 by programmers doesn’t cause difficulties - everything is fairly easy to integrate into development environments, 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, artists to put 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 basic idea: “the less an artist, the designer thinks about third-party factors, aka the order of 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 greatly increases the efficiency.

Following the above described idea, we try to reduce the number of third-party tools used by our employees, bringing all the functionality in the form of plug-ins to 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 the comfortable excel tables, which using VB scripts exported the data as text files in the required format for the game. This rather quick and simple solution worked until the number of people working on the game data grew to such an extent that several people needed to constantly work in one file, the excel spreadsheet is not a trivial task, and the option to impose the restriction “one person - one file” creates the effect of a bottleneck, and development slows down dramatically. What to do? This is how the Stats Editor appeared - a newly-made plugin that allows you not only to work directly with the necessary text file directly using our UI, but also to check input data, allowing you to avoid many hours of debugging due to one incorrectly set value.

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

All spark

In addition to small plugins, 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 the team of programmers was able to completely transfer its functionality to the editor, allowing artists to edit and create effects right in the game. Allowing 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 more of 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 the game editor to the players? Everything that seemed complicated 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 the widest possible 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 rewrite content without prejudice to the game and the current progress. In our case, this solution consisted in breaking 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 in the game, then small modifications allow people to experiment with the game logic faster and easier by connecting and disconnecting the add-ons that are 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 absolutely does not need to create a large project, but rather pack everything into a small independent file that the players they will be able to include and transmit to their own discretion, without fear that their conservation will break. One example of add-ons can also be a set of levels for the Game Master mode, where an addon is actually adding new content, based on which a player with the role of a game master can create his own stories.

Adventure. If the user wants to do something huge, with a story, with overlapping quests and independent of the main game, then this type of modification is just for him. Here it will be necessary 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. Editor includes:

• The “Genome” tool for creating animations, animation blending effects, etc.
• Editor for game scripts.
• Of course, the tools for creating levels, and editing them. Work with terrain, atmospheres, level decoration, etc.
• The ability to edit mesh characters and create entire sets of visual elements for each type of creature; for example, if you want the same item to look differently on creatures of different structures (we did not want the same piece of equipment to look the same on elves, humans, 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 who works with them, so launching 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 -
  This is exactly a separate article.
• Functionality that allows you to create and edit AI templates, and AI grid that helps combat designers to create interesting battles.
• Powerful material editor.
  
  
  
  
  

Did they say something about Tools Programmer?

There are a lot of unclear associations around this position, and one of them claims that "Tool Programmer does not make the game, but makes tools for the company's employees and does not have much to do with the game being developed." A sort of "programmer for the implementation of artists and designers."

It's not like that at all. Whoever makes the game is Tools Programmer. Constantly maneuvering between two architecturally different projects (game and editor), the editor developer is practically the only person in the company who always keeps abreast of every new feature in the game, be it a gameplay feature or a new design solution. The integration of new technologies, tools and third-party solutions is done exclusively by Tools Programmer, because only he knows how to add this or that functionality in an accessible way for people who do not have a technical mindset. Often, when Gameplay and Engine developers are closed in their own current tasks, it is Tools Programmer that needs to solve architectural issues that will set and adjust the development process in all parts of the studio for several years to come.

Now we have a team of 5 programmers who are 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 =)