• Advertisement
Sign in to follow this  
  • entries
    2
  • comments
    3
  • views
    3974

About this blog

A journal of game studio AurumDust

Entries in this blog

All the joy and pain of game development from the horse's mouth in the second installment of our developer diaries.

[quote]

filia_house.png

During the first month of the new year we passed several important milestones in a row. We finished the first music track for the game and completed work on the rotoscope data of our first two characters -- Ramlin and the archer Ark. We also began to work intensively on the network part of the game and a new game designer joined us--focusing on balance and the game mechanics. Also, we completed work on the animatics and the storyboard for the game's intro video.

The Build and the Plot

We are slightly behind schedule creating the episodes for the game. As for art and the script, there are 4 episodes ready (8 scenes and 3 cutscenes). We are still making several cinematics and backgrounds for dialogues, but the most complex part is over. The tools in Unity are still not fully ready and this is a big restriction for us. I think that during the very first week of February we'll fix everything we need. We can assemble episodes already now, but it's not as comfortable as it should be, and as we've realized from the unsquashed bugs, not entirely safe either.

dialog_test.jpg

On the screenshot above you can see the first working version of the UI where the phrases and possible answers are shown. We are very eager to make it comfortably readable and to make it clear who said what and who replies to whom.

The crucial problem of our "sufferings" - is to associate the data model and the arrangement of the scenes in Articy with that how it should be reproduced on the episode sequencer in Unity.

Now, when we're associating the Articy story episode and the graphic scene in Unity, the game engine automatically places onto the sequencer the dialogues, the author's text, battles and special groups which are considered by the game as the place where you see the dialogue icons, the store, and other actions for the current location.

timeline_2.0.jpg

I've already mentioned that we are doing everything in parallel. Because of that, when the integration comes, we sometimes have to redo some of the earlier episodes, to make them comfortable for the import. I still suppose that this strategy is way better than to wait for the game engine to be fully ready for import.

Dmitry (the game designer) and Sergey (the author of the script) have finally found a common literary language, so the process of editing the episodes now takes much less time. I wouldn't risk to give any numbers now, but everything obviously goes easier now.

This game contains several defining and very complex episodes (from the point of view of implementation). These are parts 8, 10, 12 and 15, where the actions are taking place in one and the same city - Ursus - but with different protagonists and in different times. I write about this because it is our own version of hell, so to say. You have to track all the possibilities of each character to die. This means that we have to walk through all the episodes where these characters are featured and reset their storylines to make the story look logical when you consider every version of the episode's ending. I suspect that this is just a first circle of Hell, because we are still not taking into account the behavior of protagonist (whether he is a good person or behaves like an asshole) in the dialogues.

Music

The music for the game is being created by Adam Skorupa and his colleagues Krzysztof Wierzynkiewicz and Micha? Cielecki. We are planning to record over an hour of music before the end of summer--in general this is West European and Pagan folk music, with vocals and polyphony in a fictional language. Some tracks - the music of combat scenes, for instance - are set to fit the individual types of enemies. The "bad guys" in our game are Frisians (inhabitants of the Northern kingdoms), Gells (an equivalent of Celtic warriors) and Ensa (otherworldly intruders). We will try to record the individual tracks for each of these factions, the tracks which will reflect the nature of these foes. Some of tracks will just reflect the set of emotions or be intended for use in specific scenes.

In January we completed the first track for the game - the music for the main menu. Vocals by Magdalena Przychodzka, guitars by Aleksander Grochocki, the vielle by Katarzyna Kamer. The vielle is quite an exotic instrument. At the same time, I think that it amazingly reflects the feeling of anxiety and desperation. We are planning to record some more exotic instruments - the gadulka and, probably, some unusual drums.

img_1975.jpg

On the upper photo you can see Adam Skorupa and Katarzyna Kamer during the recording session for the music of the Ash of Gods main menu. In February we plan to finish the music for the intro and outro videos as well, and then we will begin to work on the first battle themes: four whole tracks lasting a total of 12 minutes. Maybe we will include male vocals--we are thinking about it now.

The intro video

intro_tone.jpg

To be honest, I write about this video just because I'm very excited about it. I cannot show it now (otherwise it will no longer be "terribly secret"), but I want to write a couple of words about it all the same.

The intro plays a crucial role from the point of view of the plot--in fact, during 2/3 of the game you will search for the answer of question "what and why has happened here?" We want to make a player ask many questions to himself and to us. We want to bring a fog-like feeling of uncertainty and, partly, to give an answer about the game's title. The upper picture is the tonal scheme for the first seconds of intro video.

hopper_clear_line.jpg

This is the clean line (in its quality) for one of the crucial characters of this video - Hopper Rouley. As with all the other animation in the game, this video will be hand-drawn frame by frame. It has required a lot of complex montage. For some scenes we had to do the reconstruction in 3d to set the camera and the motion of a large amount of people. It is almost two minutes long and has a very tense plot with a lot of action. We came to the final of the first part of this work - the 19th version of animatic is complete and the first scenes are ready to be drawn in a rough line. The very first of them is even ready for the insertion of the intermediate frames.

intro_landscape.jpg

These pictures show the concept of location where the action of the intro video takes place. Adam Skorupa composes the music for the first 38 seconds, while our new-found sound engineer and sound designer provides the post-scoring. I've crossed my fingers in the hope that we will not fail with this intro; because we want to impress and fascinate all of you with this.

kontur.jpg

This is the stuff that showcases how we chose the contour lighting tech. In the working version we paint the middle and the long-range distance in brown, while the frontal perspective will use the contour adapted for the color of the substrate.

Also, we have already started to work on the outro video too. In the working version of it we have 3 different endings, but, independently of them, we have also a little second ending - which will be a bridge between the first part of game and the next chapter of the story.

We draw and animate

The most huge and complex part of our work (i. e. "the biggest headache") is the creation of the combat animations for the characters. On average each unit requires 16 animation sequences of approximately 80 frames for each of them. The creation of a full sequence takes about a month of work for one animator.

ramlin_front_loop.gif

The rotoscoping technique makes the animation creation simpler, but only in part. There are some very complex animations - getting damage, the death of the character, or simply walking - you can't do it well if you lack the skills of an experienced animator. It's very difficult to properly record the damage sequence, while the walking animation suffers due to the cycle length. All the animations where the actor moves suffer due to perspective distortion. We record them on a 35mm camera (though we have to turn it on its side), because with the 50mm, where distortions are barely seen, it's impossible to find a studio where you can record something in isometric perspective. The 50mm cam should stand at a distance of not less than 9 meters from the recording subject, and has to be lifted at least 7 meters higher than the floor.

get_hit.gif

Sadly, we didn't record those auditions when I tried to actually hit the actors with a stick to get the necessary level of lifelike damage reactions. Now this point is a complex thing because it requires a huge volume of the animator's work - to make it obvious for the player that the character has really been hurt. The second problem is the gait. In the studio where we are recording videos, there's not enough space for a full walk-cycle, so if you only use the rotoscope, the characters literally look lame. We are thinking what to do with that.

From the beginning of current year we decided to stop using TVPaint in preference of Toonboom (the software for frame-by-frame animation). If you are still in doubt which of these two you should use--pick ToonBoom. It will allow you to work faster, while the tools of line control allow you to receive similar pictures even when different animators are working on the same animation or its frames - the key ones or during the insertion of intermediate frames.

crowd_in_ursus.jpg

This is the crowd from the combat scenes of Ursus city. We had a long argument among the team: whether it was good to place the static images (for example, the city inhabitants) on the battlefield. It may look strange that during the battle on the city street the citizens are standing still instead of running for their lives. But if we wouldn't use the people and animals for the scenes arrangement, the levels would seem empty and not lifelike. It's long and expensive to create full complex animations for such objects. So, we finally decided that we will draw the animations with a low frame frequency - about 10 frames per second (for 2 or 3 key frames and automatic insertion of intermediate frames in ToonBoom). It can be a drunk holding up the wall, or a woman with buckets, who drops them in the beginning of the fight and presses herself against the wall. Maybe some scared people will look out of the windows and close the shutters. Just some simple activity which would allow you to feel the life and vibrant emotions of the environment.

albus_color.jpg

Another complex moment is shown on the upper picture. We had a lot of work on the color correction in the scenes which were already created (the upper one is "before", the lower is "after"). The difference between earlier and later scenes was very significant, so Andrey Zherdev has revisited the old scenes to make them equal by tone and atmosphere to the newer ones. With some of them we significantly missed with the emotional tone (there are corpses around but you cannot feel it from the picture). I hope that the current view is the final.

What's next

We've began to code the network part of the game. I think that by the middle of March we will have the basic possibility of holding matches, and it will allow us to play a rough but real game not in the html prototype but in Unity. Now we try to use PhotonServer as the lobby and game server. It's too early to talk about anything else now. We are planning to take part in the DevGamm exhibition in March, to show off our combat system as close as possible to the final expected result.

Also, we've completely finalized our combat animation schedule (about 5 characters per month) and decided how we should correct the overall work on the game accordingly - everything that concerns recording sessions, actors, references and integration.

Since the previous issue of our devblog we drew 5 characters, animated 6 dialogue portraits of heroes and completed the rotoscope of 2 ones. Also we drew 2 combat scenes (both from the city of Ursus). One of them is the constructor that will simplify the composing of multiplayer scenes and other city battles for us. Sergey Malitsky has completed 27th chapter of the novel (there are 30 of them totally) and we already know in detail how the story will end. And, at the end of the day, I'll give you a little spoiler: as it turns out, Frisia has an undercover agent among your allies and if the player does not realize who it is, he will shout: "Le Roi est mort".

By Nikolay Bondarenko

[/quote]

Words by AurumDust's CEO Nikolay Bondarenko

I'm eager to complete the game in the space of a year. It's damn hard, even when you know exactly what to do. It was obvious from the very beginning that we'd have to do everything simultaneously: write a novel, turn it into a script, work on its technical adaptation so we could launch it in Unity, draw backgrounds and characters, and create visual effects and animation for the combat system. All in the best traditions of indie agile: fast, steady movement forward, even when you have no idea which exact route will take you to your goal. But on the other hand, after four months of intensive work on this game we still don't have a build in which everything we did can be shown off as an integral product. Right now we are moving towards this goal with giant strides.

In search of a style

Most part of August and all of September we spent on searching for the right style and techique for scene drawing. At this stage I failed a bit as a newborn "I-know-everything' guy. I hoped that concept artist Vladimir Malakhovsky, my mate and a close friend of our art director, Igor, would help with the adaptation of the scenes' style. I've worked with Vladimir before, on a game called Cradle of Magic - he did cool graphics in the old-school manner, which, as I supposed, would fit into our new project too.
I really wanted it to look like Disney's Fire and Ice and LoTR, and The Snow Queen (1957) and Twelve Months (1956) by the Soviet studio Soyuzmultfilm - thin lines, simple forms and fills, a warm palette. At the same time, it would have to be quite close to comic books in its aesthetics.
However, Vladimir's current style turned out to be closer to classic oil paintings and it wasn't the manner that we wanted to see.

vilage.jpg

The effort of bringing more realism and clarity has required too much time for drawing the scenes. And the style turned out to be too complex for other artists to work in without making the difference stand out.
We've lost almost a month with these experiments and it was exhausting and demotivating. It seemed to be a total failure given the fact that with the characters we did everything right from the first attempt. Fortunately, Igor (our art director) remembered about Andrey Zherdev - and the very first sketches he did already had the feeling we were looking for.

test_env.psd40502528Group1copy42CQuickMask_829_2016-08-1416.03.28.png

At the end of August (thanks to social networks) we found Julia Jokhova - a great artist who had experience in making illustrations according to the technique that we need. We started to search for references and also the stylistics which would manage to express the atmosphere of the story accurately. It took almost one and a half months to create the city of Albus and its vicinities and the yard of Thorn Brenin's mansion. Despite all its seeming simplicity, this elaborate techique of drawing (the brushes, coloring and light) still demanded a lot of time. We had to design the greenery separately: individual trees, groves and bushes. We had to understand how to correctly draw the building materials. So, in its first version our city of Albus looked like it had been created by genie a minute ago, out of materials freshly arrived from the factory.

Parallax (That's when different layers on the screen are moving at different velocities) is "our everything", but during the work on the first scene we just had no tools to test the stuff that the guys drew in Photoshop. We did it "quick-and-dirty", creating the animatics directly in Photoshop.
The first attempt to build animatic scenes in Unity was made at the end of September:

We had to find a solution that wouldn't only satisfy each one of us, but would also allow us to create the content quickly. I'm not sure, however, that we really managed to do it: with each new scene there appears something new and interesting that was missed in the stuff which was already created. You want to go back and redo everything - or, at least, redraw it. By the middle of December we've learned how to draw one scene one-and-a-half to two screens in width. We did it in 2-3 weeks - from idea to Unity build. This scene - "the village at Arch" near the town of Ursus - was one of our first victories.

vilage.jpg

In this scene Julia used some of the methods that were previously used by Andrey Zherdev in the third game's episode (we didn't show these scene anywhere): elements of work with color, mountains on the background, greenery, the stylistics of drawing the Menhirs (those huge stones which form the arch). Such things helped us to finish the illustration faster.

Hello, Unity
unity1.jpg

This image showcases what the basic episode direction looks like: managing the camera and the points where the dialogues begin. This is the part that we're intensively coding right now. The first urge - to pick Fungus (the only distinct solution for visual novels in Unity) - didn't work for us. The storytelling in the episodes is tightly bound to the camera work and the author's text. Fungus doesn't contain anything like this while its tools for work with story trees aren't as convenient as in Articy (I will talk about this thing some later).
We began with something else, however - we moved the main rules from the prototype into the game's code, we built our own animation controller - to play the animations on the battle field - and we wrote a little tool for importing the individual clips of battle animations:

fiskloop.jpg

We had to solve several problems simultaneously. So, the current sequence of the "Rush" hit contains 53 frames and the character in this animation moves quite a lot - he crouches, turns his body from side to side, steps back. The battle field is presented in isometric perspective and if you want the animations to flow smoothly from one into another, each of these frames needs an accurately set point of binding. In other words, this is how you center one set of frames in relation to others. Being a naive man, I thought that Unity would include this operation, which is so easy and regular for any 2D game (and I have a pretty extensive amount of experience working with stuff like that in Flash). But, as it turned out, Unity doesn't have this functionality (just as it lacks many other things which you expect from a platform intended for making 2D games). Moreover, almost everything you can find in open source or in the Unity store for 2D games is intended for platformers. So we had to code the import and alignment of the battle animations by ourselves.
Then we focused on the part that plays the animations - to make sure that our clips with walking, strikes and the master poses are done right and look good.

ingame_battle-1.jpg

When we began coding in Unity, we already had a combat system prototype that was written by me in JavaScript. Currently we are still adding and testing new classes in it, following the next rule: code fast and don't think about the consequences. I think that the main hurdle about implementation in Unity was our attempt to port our prototype proof-of-concept combat system into it without any changes, keeping all the features which were in the Web version. And this was long before the work on AI begins. Either we'll decide to incorporate the completed animations, or do something serious with this part of the game in general. It was important for me to do this as soon as possible - so we could understand how difficult it would turn out to be and on what general principles to base development as a whole.
It was also very important to let all the mathematics and mechanics be ready for quick incorporation into the final version of the game: the skills and parameters of the different battle classes, the rules of motion and all the rest.

codeimage.png

Each skill is a little text file in YAML format that describes, in declarative form, how this skill works. You can quickly change the parameters, add or remove effects, or simply change individual classes' behavior mechanics. This allows us to quickly try out the ideas we get from the people playing our prototype. For instance, the idea of the Hammerman class was suggested by Voice of Reason. This is a class that can move across the entire battlefield and has only one goal - to deprive your enemy's characters who haven't moved yet of the opportunity to move. A few minutes are all you need to create a new class and begin to watch how it plays and affects the game process.

The plot?
articy.jpg

During all this time Sergey Malitsky (the author of the script) and Dmitry Erokhin (the game designer) worked with Articy. Articy is the gizmo that allows us to write and check the script independently from the creation of the game's code. You can't play the novel in its entirety yet, but we're already able to play the first 5 episodes in Articy - to check how the decision trees and choices work.
For almost a month, since the middle of November, we've been engaged concurrently in the directing of the dialogs - how to place characters correctly in dialogs, how to do the switchover of backgrounds in 2D scenes. Such dialogs in the game have up to a maximum of seven characters. This is how we arrived at the "three scenes" model: two general and one additional. Game designers sets the place where each of characters is standing, while Articy controls who's speaking at the current moment.

dialog1.jpg
Any course in film photography will give you the essential theory - where to place the camera correctly when filming the conversation of several people, how to do the switchover of backgrounds, and which rules you shouldn't break. But when you try to emulate these rules in 2D, you encounter some difficulties: you can't turn the camera in different directions, so you have to somehow simulate motion which is natural for a 3D scene. When you're making a movie, it's enough for the director to give a command, and the cameraman will shoot the episode from another point of view. But when your making a game, we very badly wanted to avoid having to place the camera manually, because that looks a lot like suicide : even now the game already contains about 2000 of speech lines (if I calculated correctly). We've spent almost a week to understand when and how we should change the views to make everything look nice.

And yes, articy:access api is a big headache. In practice working in it turned out not to be as simple as the ads promised. This wasn't a story of "start it up and everything just works out of the box". I'm also thinking with some trepidation about the localization process - the internationalization tools which were promised in 2014 still haven't appeared in Articy. Not that it's that big a deal, but it makes us nervous anyway.

What's next
There are 37 characters, 21 scenes and 12 battlefields to be done. We've drawn seven scenes and three battlefields so far. Since the beginning of September we've drawn 22 dialogue portraits of characters and six individual miniatures of the enemies. This is a bit more than two thirds of all the characters in the game. It looks like we'll manage to draw all the characters we need in time. We've also done tons of concept art for the intro video.
By the end of December the first animation packs for the battle miniatures will be ready: Fisk, Rumlin, Krieger, Ark and Sopp. By the middle of February - another ten characters and by the beginning of summer there will be around 30 of them. Unfortunately, we are four or five calendar weeks behind schedule with the scenes, and two to three weeks late with the script plan. Right now we're still deciding what to do with all of this. Should we reduce the amount of content or speed up? I don't know.
Sometimes it's harder to finish something than to start. So, here is the brief list of things that fucked us up. Aaaargh, we don't have time! The winter is torturing us. It already gets dark by 16:30 and it seems daylight doesn't exist anymore - you wake up when it's still dark and you finish up when it's already dark. The neighbor with his electric hammer drill is making it really hard to write the storyline. And for some reason, there is such a small number of hours in a day.

Sign in to follow this  
  • Advertisement