Models presentation, development and animation techniques.
If you missed the first part of the story of The Uncertain, all about the concept and origins, you can catch up by reading here. At this point, we move on to 2015, where we arrive at the best part of the story (to me at least). Not only does it contains insight about our development process, but happens to have some pretty screenshots!
Before The Uncertain, my projects were purely enthusiastic and not very ambitious. This was the first serious game in my life. I discovered a lot of new skills, got a chance to work in a big team, and gained valuable experience in managing and developing a project.
We also made a lot of mistakes on the way. Looking back, I wonder how foolish and naive I was, but then I cheer up thinking that it's only those who do nothing that make no mistakes. There were frustrating times when we had to replace a whole model or an entire location, but nevertheless we kept moving forward. My worst mistake was setting unachievable deadlines - there is so much that can slow you down or go wrong: weekends and holidays, days off and developers’ illnesses, even preparations for conferences and events. Now I know that it takes at least twice as much time to develop a project like this!
Managing a serious development project involves monotony and routine, so prepare yourself for a lot of boring work. Look at these dreadful data sheets I had to draw up in order to estimate the amount of work that needed to be done and the necessary number of team members.
Project managers are going to do lots of these. Much more than you could imagine at first, even if the project looks like a piece of cake. It's important to remember, that each element of the game is a result of teamwork, and a project manager is responsible for the coordination and efficiency of the entire group. Meaning, that the main task of a project manager is to orchestrate the performance of the team. In our case, 6 people worked on each character: an artist, 2 modelers and an animator. Then a programmer and a game-designer developed a controller in the engine for each character, as well as taught him to walk and talk.
The first big achievement of our team was the model of the main character:
As you can see, it looks quite different from the original art. Everybody in the team liked this exterior, so we decided to stick with it and called him RT (RT-217NP).
While considering the character, I tried to avoid clichés. For instance, RT won't be a superhero or have a greater mission. He won't be The Chosen One, just a normal robot, like thousands of others, who suddenly lands himself in trouble. The twist design element chosen to build some empathy from the player is a screen face. You can see not only the robot's eyes, but also various symbols, which indicate his attitude to different matters. Other robots have just luminous oculars.
We created each character in 6 steps. We’ll break it down using model of nurse robot, Abigale (pictured on the concept art below on the right) as an example.
Step 1: Concept art. We discuss the character with the artist thoroughly, and he makes a few sketches. Then we choose one from them and refine it. Experience has shown that there is no need to draw in the details carefully, for the modeler requires medium detalization. But it's crucial to make a front and a back view so there are clear guidelines for modeling. It's easy to correct a drawing but changing a high polygonal model might take a lot of time.
Step 2: High-poly model. At this stage, the CG artist can smooth the model, creating as many polygons as he'd like. In fact, he has the freedom to deny himself nothing. There is a little complication though: you should consider the natural motion. Fortunately, one of our modelers was an experienced engineer, and he designed robot's joints correctly, so they couldn't bend where they naturally shouldn't. It can also be challenging to make a model based on an art rather than a layout. I was lucky to find the guys who were experienced enough to do it.
Step 3: Low-poly model. It includes retopology — a process, when you copy the shape of a high-poly model, but with minimal values of polycount. Then you make a UV mapping of the model, followed by texture maps baking: normal, ambient occlusion, color ID and others.
Step 4: Texture mapping. We make textures for Unity PBS, based on baked maps. There is a lot of software that simplifies the process and provides great effect and high detail. By the end of this stage, the model with textures is being imported into the game engine and customized.
Step 5: Rig. A model needs bones to be able to move. This stage is very sophisticated and requires a lot of knowledge and experience. There is software that creates a rig automatically and attaches animation to it, but the outcome is often much worse than after manual work. It's also more suitable for organic characters: a robot may have some metal joints bent and distorted, which looks awful.
Step 6: Animation. This stage breathes life into the character. There are two ways of animating a robot in our game: basic and cinematic. Basic animation like walking, running, grabbing items, gestures during the dialogs are used as part of the gameplay. Cinematics are special animations used one or couple of times during the entire game. They are meant for special moments when a player cannot interfere, or for Quick Time Events. For example, walk animation becomes active, when the player uses 'move'. Turn over the radio animation is used only when we can take it in hand in order to repair. Tear off the pipe animation is used when a character must apply force during QTE.
This is how we created some other models as well. When we didn't need high detail models, we created low-poly models from the start and textured them. We also bought a few models from the Asset Store and modified them to adjust to our world.
Thank you for reading, next time I will tell you about how we created the rest of the visuals – locations and lightning!