In our studio, we often use Articy Draft as our main game asset management tool, and we would like to share this experience so that you know what to expect behind the marketing shell. Expect only an honest review here.
In one of our previous articles, we discussed the hard life of a game designer and handy tools that sweeten it. In our studio, we often use Articy Draft as our main game asset management tool, and we would like to share this experience, so that you know what to expect behind the marketing shell. Expect only an honest (to the extent of our knowledge) review here. We’ll skip the information you can easily find in the official tutorials and reviews. Straight to business this time… and, yes, prepare for a long-read.
So, what is Articy Draft exactly? While diving into game development, you have to deal with lots of unknown words and sometimes it’s not enough to just look them up on Wikipedia or even promo site. Simply put, Articy Draft (AD further down the road) is a tool for visual representation of game entities with vast automation capabilities. Its other use case is the entities database. AD can really help a game development studio keep entities organized. Let’s find out how this software helps us make a really remarkable product.
Most games require various data storage and use files of different formats, including custom ones — i.e., inventory items for RPG and Adventure games, in-game units and characters with all their properties. Typically, when a game is developed and balanced, these configs are edited a countless number of times, which is time-consuming and never convenient. If you use custom file formats, most likely you have developed and are supporting custom tools. While those definitely are needed for any serious game, Articy Draft can help you keep that game data organized.
What it allows you to do is to define game entities and necessary properties. For example, you can put the entire set of magic spells, available in your game, inside AD.
You can define such properties as:
Spell Name — a name of the spell shown to the player in the game
Spell Description — a spell description shown to the player in the game
Spell Element — an integer or list value of an element, to which spell belongs (i.e. Wind, Fire, Water, etc.)
Spell FX variable — a text variable that could be used as a reference to a visual object in the game.
Spell Damage — an integer field that defines how much damage the spell does.
The same process can be used for other game entities, like inventory, game library data, characters, achievements, quest objectives, etc. Basically, you can replace all your numerous game config files with just one tool, and manage them in one place. This is what no other wiki-like system allows you to do.
However, AD allows you to export these entities in data-friendly formats and even provides ready-to-use frameworks for the most popular engines: Unity3D and Unreal. Even if you use other engines, an export to a JSON format is available. So you can quickly develop a parser —in any case, it will be faster than the development of custom game data manager software. Thus, you can treat AD as a ready-made editor for your entire game database.
Let’s briefly look at the process of configuring and managing of entities.
AD has a tree-like structure, where each entity can have an assigned template, each template is a set of features, and these features can have property fields of several basic types, like string, integer, boolean, etc.
Let’s look at our mission feature, that contains the following fields:
Mission title
Mission description
Primary objectives list — a reference to the object, which contains information about the mission’s primary objectives
Secondary objectives list — same as above
Achievements objects list — a reference to achievements that can be earned in the mission
References to cutscene, briefing, debriefing, level and story tips objects, that are also entities containing their own fields.
The good thing is that all these objects we define in the visual tool are available as C# objects in Unity after project export, so you can easily access values and data.
After you’ve defined your features, you create a template out of them, like on the screenshot below:
As you might’ve noticed, our actual mission templates contain two features: mission and event timing, which adds additional information required for the gameplay process.
After the template is developed, you then create an entity and assign a template to it. The screenshot below indicates another entity — Unit configured in AD.
AD is much like an Object-Relational Mapping (ORM) in a world of databases. One could ask, why properties can’t be assigned to templates directly? Well, we assume this extra step is added for more flexibility. For example, the properties like title and description exist in many game entities (i.e. spells have title and description just as well as game collectibles do), so they can be reused to keep your structure more organized without duplication.
AD’s assumption is that flows are the sets of objects that can be traversed (or navigated) sequentially as it is defined in the editor and based on conditions. It is like a slideshow where you turn the pages in the code to see a new page. One of the possible application of this feature is the dialogues flow. That’s where AD really shines in my opinion, making complex, non-linear dialogues creation a breeze.
Conditions and Global variables can track the state of previous player choices, so player answers “No”, when given choice, AD records it and allows accessing it in sequent dialogues to guide the flow, based on player’s actions. Let’s see in more details how the flow system works.
In order to construct a dialogue or a flow you have certain tools at your disposal:
Flow fragment — this is another entity, which can have an assigned template (with custom features and properties)
Dialogue fragment — specific flow fragment designed to be used in dialogues.
Global variables — user-defined list of variables, which are used by Articy to store choices and conditions.
Conditions, hubs and other connectors that help you define your flow logic. Basically, these are visual representations of IF...THEN…ELSE statements. You just write simple conditions that take global variables into account and connect with the proper path in the flow.
In the screenshot above, we provide a user with different information, depending if he uses Mouse or Gamepad.
Here is the dialogue from one of the missions in Rise Of Colonies — a game we’re currently working on:
And a whole picture with branching and multiple choices:
While dialogue flows offer a convenient way to present information to the user, they are not exactly convenient for other parts of the game.
Initially, we hoped to have all game flows, such as a campaign flow, a mission flow, defined in Articy, so we would have something similar:
Available chapters — OK, we’ll get that from Articy’s Flow.
Available and completed missions within chapters — OK, we’ll get that from Articy’s Flow.
In-Mission progress — OK, we’ll get… well, you’ve got it.
It was quite tempting to put it all in AD, but, after some tests, we dropped this idea, because of the limiting issues:
When using the flow functionality, you are, actually, limited to only 2 methods in your code: OnFlowPlayerPaused and OnBranchesUpdated.
For example, when you are on the chapter screen, you need to get the list of branches, sort them (because there’s no default sorting), identify valid branches (the valid ones are available entities). To get that info you need to set starting flow traversal point — the entity from which you start to flip pages. Then, you launch flow playback and wait for the callback. After that, to go deeper, for example, to get the chapter’s missions, you repeat the process, however, this time the entities are different, because they are now missions’ ones, not chapters’, so, obviously, they need to be processed differently. However, you still have only the above 2 methods available. To add to the point, you have objectives, dialogues, etc — all that should be processed in the above-mentioned callback methods, making them like the main methods of your game.
When you access your flow from multiple places in your code, you’ll have to implement some methods to skip playback forward and backward, which means extending above-mentioned methods even more.
Restoring game progress (i.e. loading a save file) becomes a very difficult task, because if you have anything more complex than “Hello World Spinning Cube Type Game”, you’ll be riding flow back and forth, setting correct starting points for all of your game entities (provided, of course, that your game supports in-mission states and allows saving ).
While AD provides some basic logic variables and scripting ones capabilities, those aren’t nearly enough for the games, where Articy database usage is considered. It means that you will be actively combining Articy Logic and gameplay logic in your code. And you’ll have to put your logic into AD’s 2 infamous callback methods. So, why bother dealing with 2 progress storages? Just have one in your code.
However, AD flows can be used like entities, where access logic is controlled from the game code.
The screenshot above displays the mission’s flow contents. Keep in mind, that there aren’t any connections between entities — they are managed from game code:
Mission ÑÂÂutscene — optional flow fragment that contains dialogue and necessary technical data to load necessary cutscene in the game. If this component presents in the mission, a special cutscene player scene is loaded in Unity before the level.
Mission briefing — another mandatory flow, which is used by briefing play scene.
Mission level flow component — flow fragment, which defines mission level data, which are:
Mission dialogues — the dialogues that are triggered by the Mission’s script code
Mission objectives — flow fragments that contain references to primary and secondary missions objectives
This is how it looks in AD:
Note: Just one important note to keep in mind. Articy Draft Database is read-only, it means that all runtime changes made to it will be lost after reload, so you need to develop additional facilities to save and restore DB state, like player’s choices in dialogues, for example.
AD has some additional features that can be useful in some cases:
Localization Tool. Articy Draft can be used as a localization handling tool not only for Articy content but also for your own entities in the game. Once you add them to Articy-generated excel spreadsheet and, then, import Articy data in your game engine, you can access those entities using special methods to get localization data. This is really handy, though, insufficient for complex games, where you ’d better check for more specialized solutions, as more things usually have to be localized in the game than just text and audio. Also, textures, models and, sometimes, animations. Again, to avoid using multiple solutions, you’ll probably have to skip this functionality in AD.
Voice-over tools. There’s a free first-party Articy plugin that helps you manage voice- overs — a very convenient tool provided your game has voice overs. Once you setup this plugin, it will generate either empty or Text-To-Speech audio files using OS capabilities on export. Surely, TTS files are only for prototyping, but they are great to reduce the number of iterations between development and voice-over teams. And they can be easily accessed as Dialogue’s Entity properties.
Articy Draft has some quite unpleasant surprises that you need to consider prior to facing them under extreme development conditions and tight deadlines.
This software doesn’t allow moving data between projects. Yes, this one sounds like complete nonsense. Let’s say, you had a dialogue scene in your game project that was removed at some production point. However, after a while you decided to put it back or let’s say that you had a bund of inventory items that you would like to get back in the game. What would your normal and obvious actions be? Right, you copy an old project version from the repository to the new one and save it. Sounds simple? Sure, but you just can’t do this with Articy Draft! It’s just impossible to copy entities from one project into another, so if you ever delete something from Articy project, the only way to get it back is to recreate that data from scratch.
This tool is often advertised as something that helps to build a complete adventure game using internal flow management tools. While technically you truly could do this (on paper), the reality is harsh. There is no (and probably will never be) visual tool that allows you to create a game without coding and programming skills. And Articy Draft also isn’t such a tool. So, take your best judgment to define data structure for your project or seek help from an outsourcing company.
Importing system is limited, so don’t rely on it. I.e., Articy can’t even import back its own exported xls files. So while it would be nice to get some of the assets created in different tools, your only viable option is copy-pasting.
From a pricing standpoint, Articy Draft isn’t an expensive software solution (given its value), but it’s not cheap either. Generally, Articy comes in 3 licenses: Perpetual Single and Multi-user licenses and a subscription-based one with a monthly fee.
A single User license is the most affordable option, which comes under $100. You should understand that it allows no collaboration at all. However, if your studio has a single employee that creates Articy content, you can get away with it.
Multi-user license is where the real game starts. Each user in multi-user license will cost around $1200 with an additional $120 view-only version. Floating licenses are twice as expensive.
While these prices can be really affordable for game studios with AAA budgets, they can be a burden for indie studios, considering the fact that Articy Draft is not the only software you will have to buy for your game. Overall, in our opinion, this software has all chances to become a perfect tool for a game designer letting developers work out some of the currently existing flaws and introduce more flexible plans for small indie teams.
Read more about:
BlogsYou May Also Like
