Hello Sarnautians!
A peek behind the scenes at how a game is made is an exciting experience! We showcased the Developer Diary videos earlier this year, explaining the reasons behind the Xadaganian girl revamp, how they draft new zones and so on! Today, we are sharing with you the diary of Arkady, the Game Designer, explaining how raids are created!
Settle back with a nice cup of tea or coffee and learn more about the creation of this exciting activity!
My name is Arkady, and I happen to be a Game Designer. A better, but not complete description of what I do, is the development of game mechanics design. However, we are not going to discuss my field of action today. We’re going to talk about raids, in the development of which (among other things), I am a part of.
Raids, also known as group adventures, are PvE activities for groups of up to 24 players (for the moment). But you might already know this. In this article I am going to tell you about things you do not yet know about. Curious? Shall we start then?
How does the creation of a raid begin? First you have to pick a whiskey brand, at least, some say so. I wouldn’t know about that, but what I know for sure is that it’s actually a Scriptwriter who’s at ground zero of it all.
The Scriptwriter’s task is to make sure there’s a common sense to everything we do and bring it all into sync with the Allods Online universe. This is where a raid springs from. The Scriptwriter develops the plot and sets the mood. It normally goes like this: “Friends and colleagues! In our new Raid we should elaborate on the subject of Tep. He is a very important character, we ought to favor him with our attention”.
To cut a long story short, we develop the plot a couple of updates ahead, and we pick a villain to be subdued. Today we are going to discuss a raid where we bring low Tep and his minions.
The Scriptwriter provides us with one simple fact: “We battle Tep,” – and with a few extras. For instance, there’s a list of Tep’s minions that includes their backgrounds, basic qualities, likes and dislikes and so on. Also, there’s Key Keeper, who’s malign, but faithful to Tep, fond of engineering and knows well how to disassemble and reassemble a golem.
Here’s where the Creature and World Object Design Leads step in. Together we decide how much we are able to do. This is one of the most important things – how much we’re allowed to create. We are limited by our deadlines and other stuff we have to work on. For instance, we had to create new mounts and costumes simultaneously with the Raid mobs. Having all this on our plate, we must set priorities – what needs to be done in the first place, and what can be prioritized. High priority things push the raid down the queue.
Thus, the discussions held together with the Creature and WO Designers is vitally important. It sets our immediate and potential goals for the near future and helps develop the schedule for any new things that need to be created and some old things that could be redesigned.
That’s correct, we create the new, but we also modify the old. Skin modification is the process of “dressing up” an old model with new textures, visual effects and animations. The most obvious case is the mount with its kaleidoscope of color patterns. The first raid boss called Bouncer is a direct offspring of good old Squealer.
This discussion results in a list of raid bosses and the estimated size of the raid. Concept creators enter the field now. They create the concept sketches of the future models and animations. This is one of the most complicated points because of the sheer volume of what must be done. We need to elaborate how a boss should behave, what actions it should perform: Will it freeze to the ground or move about? Will it use physical or magical attacks, et cetera. All this has a significant impact even upon the rough draft sketches, not to mention further modeling and animations.
At the same time we start building up the location and the visuals and develop the scenario of the raid. The location’ size is highly important, for it depends on whether the raid group will have to run about much or not, kite or split the additional mobs, or if any pools will be splashed… all this needs careful thought before designing the gameplay.
The environment is constructed very carefully and may undergo numerous transformations. For instance, when Tep’s Pyramid was being developed, its interior was reworked five or six times. The reasons vary: the scenario was rethought, the Mood of the Raid changed, the boss’ list of abilities extended…
The most frequently modified parameter is the Atmospherics, that is: the light options, the air clarity, the general mood. The first version of atmospherics in Tep’s pyramid looked like this:
As soon as the processing of all the necessary components has started, I lay down the Raid Design itself. In our particular case it contains the general plot, the subject, the list of bosses, gameplay drafts (they go like “Nihil casts AoE; route, devices; Bouncer – tanks”). Before it is submitted, a few concepts and details are subject to modification.
Now, here’s my favorite part: Boss Fight Design. The first rough draft may take up to a month to complete!
The draft basically covers two points: what the players do and how they do it. The first is the basic description of Players’ Actions. Sihal, for instance, has four stages, each of which requires certain gameplay. Stage One: Players meet the boss. Stage Two: They focus on additional mobs, switch tanks, deal damage. Stage Three: Active healing and Sparks transmission. Stage Four: Damage, damage, enrage. To get to the point, my task is to make players play this particular instance.
The WAY they do it, the second point, goes down to achieving the goal described above. I describe the principles that direct the players to play exactly the way it was meant to be played. There are two ways to acheive this: encourage the correct gameplay and punish the incorrect. The carrots work better than the whips; however, it is perceived a bit differently in the game.
To tell you the truth, I’m absolutely sure that carrots and whips need to be finely balanced when designing the boss fight. I’ll explain. Figure a random boss who splashes in pools that increase damage dealt to him. The players need to lure him right into the pools, while each step deals damage to them. Thus, we have carrots – increased damage to the boss while he’s in the splashed pool, and whips – it costs players hit points to use the feature. However, if the whips are too painful – that is, too much damage is received – the players are not going to use it.
The same boss casts an aura that stacks poison on players within a 10-plus yard radius. Extra damage equals whips. To make the poison debuff fade, players have to slip out of the area. They run out and away from the boss, who, in his turn, ends up out of his extra-damage pool. Voila, carrots make players ignore the whips.
All this makes up the Boss Design. At the same time, we need to decide whether we should let the players fight the boss strictly in the pre-designed way, or we should allow them to develop their own strategy. On the one hand, forcing players is not nice at all. On the other hand, the single way is easier to balance and pre-calculate. Besides, if there are multiple strategies, one of them is bound to be more efficient. One design covers all raid bosses. Despite a diversity of features they all should work in one style and accord.
Another important thing to be carefully considered is Class Abilities. It’s not a good idea to fix up a boss with a powerful area of effect spell that reduces players’ hit points by 146% – not all classes are able to reduce incoming damage of this magnitude.
By the time the designing routine is over, the creature concepts must have already been finished. In a perfect world, even the models should be created. Now there’s this epic moment to proceed to a most difficult and complicated stage – The Effects. That is, visual effects of spellcasting, spells, abilities, buffs et cetera.
Sometimes a visual effect can be implemented using an existing engine, this is a welcome but rare case. If a solution does not turn out to be this simple, it’s time for workarounds — a non-standard means of solving non-standard problems.
(1) Energy flows appear from the thin air, concentrate (2), move down with the rays (3) that eminate from the sphere (4). Sparks dance around the sphere.
It took me over two weeks to create an Out-of-the-Box solution for the Spark in the third phase of Sihal. It had to appear from a broken generator and into the first illusion to destroy it, on to the second illusion and so on. It’s not as simple as it looks: a creature can cast a spell on another one, but it’s tricky to send a visual effect roaming from point A to point B, especially if they are not interconnected.
Sometimes the Resources of the engine and the in-game mechanics are not up to the design, and it has to be reconstructed to ensure game client does not slow down or lag.
Effects are the last (but not least) thing that is created by other teams and does not depend on me to develop. Actually, there are also sound and music, but they’re recorded after the fact. When the effects are ready, it’s my turn to enter the stage and put down in detail the Game Mechanics.
What are Game Mechanics, exactly? They are a list of commands supported by the server and the game client. These commands define the movements of mobs, describe their spells and abilities, everything. Nothing is going to work if the mechanics are not thoroughly described. This is the important, crucial part of the job. Mechanics are the core of the game.
Raid Mechanics take a pretty long time to develop. The more complicated the raids become, the more complex the Raid Mechanics get. Each new raid involves something brand new, original, never-done-before, so we create, invent, build up, drink blood, eat brains and succeed.
Let us study a simple case – A Mage’s Fireball. This is a ranged spell (its distance is, say, 40 yards), it has a certain visual, aimed at a single target, and it deals Fire damage. It is described as follows in the editor:
Pretty neat, huh? Now figure a spell that casts selectively upon targets whose hit points are above a certain level, and then applies Buff A if the target’s hit points are lower than 50%, or Buff B, if their hit points are over 50%. Buff A stuns the target and may be healed, but it damages everyone in the area when cleared. Buff B deals damage over time, and upon fade casts a pool around the target. This pool applies Buff C to everyone who steps in it, and when Buff C fades, it increases the damage dealt by the boss to the target. This all is described as one single spell. Not so simple now.
To make the work more structured, for every single boss we create a Workspace, where we store all of their abilities, spells, additional mobs, all the phases and stages, and the rest of the things connected with that particular boss.
The Game Mechanics Designer’s primary task is to create a concise description that would not potentially cause bugs. A 10 step description that includes checks and sub-checks is more dangerous in terms of errors than a simple 2-step-1-check listing.
A bug-hazardous code is a code which won’t allow full apprehension of the mechanics – the Fireball is least bug-hazardous, while the complicated spell might cause a few. Each of the classes has its own peculiarities, such as spell protection, physical protection, different types of bubbles and immortalities, resistances and a lot of Rubies. To make sure a spell is 100% bug-free, one has to test it through and through in all the possible combinations.
There was once a Boss whose mechanics were bound to work alright, but for an unknown reason, it kept failing. The reason was finally found. It was one of the Paladin’s abilities that forcefully applied an effect to targets, and its high priority overlapped with Boss’ actions. The funny thing is that this ability had never triggered any such things before.
Of course, there are special scripts, bots, testing programs and servers that test such things, but sometimes this is just not enough. For a good designer it is vitally important to know how it all works, and to be able to test it manually.
Raid mechanics development includes A Few Steps: gameplay rough draft, test version, polishing. First, we place a few identical mobs with no objects or skins on a plain surface, attach Bosses’ mechanics to them, gather a group of the designers and a couple of assistants and playtest the raid to see if our ideas are working out. This way we develop about 99% of the mechanics, then we add the models, most of the effects, and get to the Adjustments. We define the damage, hit points, schedule time to summon additional mobs. After this the time comes to gather a proper group of six players (Tank and Healer included) to hold another play test which may result in more changes and alterations in the mechanics.
Nihil has suffered many changes; the way it is now is the sixth revision of the mechanics. In the very beginning she had no phases, her spells cast instantly, and players had to be under shield and jump away from black holes. There was a special device to aim Nihil’s cannons at herself. We took a couple of play tests, and saw how complicated it was all at once, so we decided to divide the fight into phases.
The last step is The Polishing. We replace draft figures with final ones: the damage, hit points, time counters. See that the effects and the sounds are finalised and well linked. Figures are the most difficult part. It looks simple: the boss deals 200000 damage. However, The Basic Damage is to be modified by a lot of stats, both boss’ and players’: boss’ level, type (boss, raid boss, common mob etc), its difficulty, stat modifiers; players’ level, resistances, Rubies, stats. We enter “damage 19” in our editor, and after all multiplications, calculations, reductions and scaling, it results in 200000.
Thorough tests are needed to check the whole volume of work done. We invite a few players to our office to hold Real Time Play Tests, which show exactly what’s come out really well, and what hasn’t. The result of this test changes a lot. For instance, we once playtested Sihal, and I hated the looks of his attack, so we swapped his tentacles for claws:
After the polishing is done, we pass the raid to the QA department for a few weeks for testing. They look for minor bugs and discrepancies.
Before we distribute the new content, we bind one last Spy function to each boss. It records boss fight history, so we can always look up what players do to our creatures and how they do it. We also monitor raid groups, wipe frequency, damage done by different classes, spells used. This helps estimate the effectiveness of classes and boss design quality.
Raid creation is a long and complicated process that involves a lot of difficulties and risks. About a hundred people work on it, from artists to QA, for you to enjoy the game and have fun.
I hope you have liked my story! See you!
