Andryuha on Creating Game-Ready Characters for Real-Time Production

Creating a game-ready character involves far more than getting the model to look convincing in a render. It has to hold up inside a real production pipeline, from topology and rigging to animation, materials, optimization, and final implementation in a game engine.

For Andryuha1981, that technical foundation starts with strong character design. His work on RenderHub ranges from individual fantasy characters to larger character packs designed to work together as part of the same game world.

In this interview, he breaks down how he and his team develop game-ready characters, where optimization matters most, why third-party characters still require project-specific adaptation, and what game developers should understand before bringing third-party characters into production.

From Character Design to In-Game Use

What types of game-ready characters do you specialize in, and what makes your work distinctive?

I work across a fairly wide range of game-ready characters, including fantasy, dark fantasy, knights, orcs, monsters, mythological characters, magical creatures, bosses, NPCs, and other character types.

At the same time, I try not to limit myself to a single genre. I constantly monitor the market and look for directions that may become popular, as well as niches where there are very few strong assets available.

One of the main things that distinguishes my work is the design. I have been working as an Art Director for many years, and I try to maintain a consistent visual standard and a recognizable approach to character design. Judging by sales and customer feedback, this approach works very well.

For me, it is not enough for a character to be technically correct. It also needs a strong visual identity, a readable silhouette, interesting details, and a design that makes developers actually want to use it in their game.

What does "game-ready" mean to you when creating a character?

For me, game-ready means that a character should, in most cases, work almost out of the box.

Of course, it is impossible to create an asset that fits every project perfectly. Every developer has different gameplay systems, world scales, animation requirements, materials, skeletons, and performance targets.

Our job as sellers is to make the character as universal and integration-friendly as possible.

The asset should have a correct mesh, proper topology, UVs, textures, materials, skeleton, skinning, and animations, and it should work properly in the target game engines. The buyer should not have to repair the character before they can start using it.

What is your typical workflow from concept to the final game-ready character?

With the rise of neural networks, our pipeline has changed a little, especially at the concept stage.

It is not a case of simply typing, "Make me a beautiful character," and using the first result.

Everything starts with an idea. We describe the direction, define the role and mood of the character, and then begin a long process of exploring the silhouette. We add details, remove details, change proportions, clothing, armor, accessories, and test different color schemes.

Sometimes a single character can go through close to one hundred concept iterations before we finally combine the right elements into the design we want.

Neural tools can also help generate some high-poly elements or serve as supporting tools. If a detail cannot be produced at the quality we need, we model or refine it manually in ZBrush and Maya.

From that point onward, the technical work is almost entirely manual. Retopology is done by hand. At the moment, neural networks and automatic tools still do not produce production-ready topology well enough for proper rigging and animation.

Once the retopology is finished, the mesh is manually optimized, and then we create the UV layout. The technical stage is either completed manually or carefully checked by hand.

After the UVs are finished, the character is assembled in Maya. All parts are fitted together, intersections are checked, clothing thickness is adjusted, armor placement is refined, and everything is prepared for the later skinning stage.

We then bake the high-poly details onto the low-poly mesh and create the main texture maps.

After that, the work is divided within the team. A separate specialist handles the skeleton, skinning, animation, and setup inside the game engines.

My role as Art Director is focused primarily on the design, high-poly work, visual direction, and texturing. I believe the high-poly stage and the final paint and material work are among the most important parts of the entire process. They are a major reason the final characters achieve the visual quality they do.

I started doing this around eight years ago, and interestingly, the core production process has hardly changed. The tools have improved, neural networks have appeared, and some routine operations are faster now, but the fundamental process of creating a game character is still very similar to what it was many years ago.

How do you balance visual quality with real-time performance?

The main principle is not to use geometry where it provides no real visual benefit. If small surface details can be represented effectively through a normal map, there is no reason to build all of that detail directly into the geometry.

Polygon density should primarily support the silhouette, major forms, face, hands, armor, and other areas that are clearly visible during gameplay.

Optimization also depends heavily on the role of the character. A boss, hero, or unique character can usually afford more complex geometry and materials. A standard NPC or common enemy should be significantly lighter.

I do not believe there is one universal polygon count that works for every character. The important thing is to understand the role the asset will play inside the game.

How do you approach topology for rigging, animation, and deformation?

The basic principles have not really changed for many years. First, you should not overload the mesh with unnecessary density.

Special attention is always given to areas that deform during animation, including the shoulders, elbows, wrists, fingers, knees, hips, neck, head, and other major movement zones.

These areas need clean topology, correct edge flow, and enough geometry to deform properly.

If a mesh is mostly static, you can simplify it much more aggressively.

The same principle applies to weapons and other assets. With a bow, for example, you have to consider the bending of the bow itself, the movement of the string, and any other deformation.

Overall, the principle is straightforward: good edge loops and sufficient mesh density where movement happens, and efficient geometry where it does not.

How do you approach rigging and animation compatibility for your characters?

For most humanoid characters, we use a skeleton based on the Epic Skeleton structure used in Unreal Engine 5.

It is a very practical foundation because Unreal Engine and Unity remain the main engines used by many developers working with detailed real-time characters.

Using a familiar skeleton structure makes integration, retargeting, and further customization much easier. For non-standard creatures with unusual anatomy, we create a custom skeleton. In those cases, it becomes especially important to provide enough ready-made animations with the asset.

There also needs to be a reasonable balance. Technically, you could create one hundred or two hundred animations for every character, but from a business perspective, that does not always make sense. Production costs increase dramatically, while the additional value of each extra animation decreases after a certain point.

We aim to provide a strong set of animations that covers the main gameplay actions without increasing production unnecessarily.

Which software and game engines do you use to test your characters?

My main software stack has remained almost unchanged for around seven years.

ZBrush is used primarily for high-poly sculpting and detailed modeling. Maya is used for final character assembly, scene work, skeleton setup, and general production preparation. Marmoset Toolbag is used for baking, material checking, and presentation renders.

For UV work, I use the dedicated UVLayout software. 3DCoat is used for retopology and some texturing tasks. Photoshop and several other supporting tools are also part of the workflow.

The final character is tested directly in Unity and Unreal Engine because that is where you can truly determine whether the asset works correctly as a game-ready product.

How important is customization, such as modular parts, skins, or material variations?

It is extremely important. Good modularity can effectively turn one character into several different characters.

For example, if a character includes a T-shirt, shirt, sweater, and jacket, those clothing combinations alone can already create several different NPC variations.

If you then add different hairstyles, headgear, weapons, material variations, clothing colors, or small facial blend shapes, the number of possible variations increases significantly.

A skilled developer or technical artist can turn one well-designed modular character into five, six, or even ten visually different characters.

That makes modularity one of the most valuable features a marketplace character can have.

What common problems do game developers face when using third-party game-ready characters?

These may include an incompatible skeleton, incorrect scale, material problems, transparency issues, hair setup, two-sided surfaces, root motion, skinning, and similar technical problems.

Animation is another major area. Customers often expect to receive a character with perfectly tuned animations straight out of the box, but every game is different.

Character scale, movement speed, terrain, stairs, combat systems, weapons, and even camera height can change how an animation feels.

Because of that, it is practically impossible to create a character that requires no additional setup at all.

Even when the seller has prepared the asset very carefully, I would say the end user may still need to perform around 30-40% of the final adaptation specifically for their own project. That is completely normal.

Game-ready means providing a strong technical foundation, not a universal character that automatically fits every game without adjustment.

What should game developers check before purchasing a game-ready character?

The most important thing is to read the product description carefully. Surprisingly, a very large number of buyers do not do that. That often leads to questions such as:

"I bought this character, but the skeleton does not fit my project."

"Why does it not include the animation I need?"

"Why is this weapon not included?"

"Why is this part not modular?"

In many cases, all of this information was already clearly stated in the product description. A good seller should provide as much information as possible, including polygon count, textures, materials, skeleton type, animation list, engine versions, and other technical specifications.

There should also be plenty of screenshots and, ideally, a proper video showing the character, materials, and animations in action.

Today, especially with neural image generation, it is very easy to create one beautiful promotional image. Buying an asset based only on an attractive cover image is a bad idea. You need to understand exactly what you are paying for.

Creating Characters for Different Roles in a Game World 

How do you approach characters with multiple skins, equipment, and animations?

In most cases, we try to build this type of character around one core framework. There is a base skeleton and a base character structure, and different clothing, armor, weapons, and additional parts are built around that same system.

This simplifies production and makes the asset much easier for the end user to configure inside a game engine.

In general, the more components in a pack that are compatible with one another, the better.  If several clothing variants use the same skeleton, the same attachment points, and a consistent material structure, it becomes much easier for developers to mix and match everything inside their project.

How do you decide how many animations and variations a character needs?

We usually aim for a practical, medium-sized animation set that covers the character's core actions. For a typical game character, this often means around 1214 core animation types or a similar basic set.

This may include walking, running, idle, attacks, getting hit, death, sometimes jumping, strafing, and other necessary actions.

The number of variations depends on the role of the character.

A boss, for example, should ideally have several different attacks and multiple death or hit reactions. A basic NPC may not need that level of animation coverage.

The final number always depends on the role of the character, and we also consider the practical standards and recommendations used by major game marketplaces.

Do you use a technical or QA checklist before releasing a character?

Yes, absolutely.

We check the mesh, UVs, materials, textures, skeleton, skin weights, animations, scale, naming, import settings, and overall file structure.

The character is also tested directly inside the target game engines.

This is especially important because a model can look perfect in Maya or Marmoset and still develop completely different problems after being imported into Unreal Engine or Unity. That is why engine testing is a mandatory part of the production process.

How does optimization change when creating NPCs and enemies?

Optimization becomes much more important for standard NPCs and common enemies. There may be many of these characters visible on screen at the same time, so every part of the asset needs to be considered carefully.

In most cases, we try to use one or two materials and keep the topology as efficient as possible, with only the necessary number of vertices and triangles.

This is important even before automatic LOD systems are introduced. If the base model is already too heavy, LODs will not solve every performance issue.

A hero character or boss can usually afford significantly more detail because there are fewer of them on screen, and the player sees them from much closer distances.

What Matters Most in a Game-Ready Character

What is one thing you always prioritize when creating a game-ready character?

For me, the first priority is still strong visual design. The character needs to look good inside the game.

Even if it is not the main hero, but simply an NPC or standard enemy, it is still part of the game world and contributes to the overall visual quality of the project.

Of course, the technical side is essential. Without it, there is no real game-ready asset. But strong design is what makes the buyer notice the character in the first place. Judging by the sales of my characters, this approach has been working very well.

What is the biggest misconception about game-ready characters?

One of the biggest misconceptions is that every game-ready character needs to be an AAA-level hero with extreme detail, complex armor, expensive materials, and maximum technical complexity.

A game does not consist of one main character. For every hero, there may be one hundred, two hundred, or even three hundred NPCs, enemies, and background characters inside the game world. Those characters do not need the same level of detail as the main hero.

If you try to build every NPC at the same quality level as an AAA protagonist, production becomes unnecessarily expensive and time-consuming.

A good game-ready character is not necessarily the most complex character possible. It needs the right level of visual quality and optimization for the specific role it is meant to perform.

Which three characters from your RenderHub store best represent your work, and why?

I would probably highlight my Dark Knight series, Orc Knight characters, and some of my larger fantasy packs.

They represent the direction I enjoy developing most: strong visual design, dark fantasy, unusual creatures, armor, weapons, and characters that immediately help establish the atmosphere of a game world.

A large part of my catalog is designed so developers can use these assets together to build a visually cohesive, high-quality fantasy game.

There are knights, orcs, magical creatures, monsters, mythological characters, and many other types of assets.

I try not to think of them only as isolated models. Over time, I am gradually building a larger library of characters that can visually work together as part of the same world.

What advice would you give a game developer using a marketplace character for the first time?

First, read the full description carefully.

Second, look through all of the screenshots.

Third, watch the video preview if one is available.

If a product has only one image, one line of description, and no video, I would approach the purchase carefully.

The buyer should clearly understand what is included.

It is also important to understand that no marketplace asset is going to be 100% universal. In almost every case, you will need to adapt something to your own project. That may mean adjusting materials, tuning animations, retargeting the skeleton, changing parameters, or modifying some parts of the asset.

Developers should therefore have at least a basic understanding of how characters and game engines work. And if something is unclear, contacting the seller and asking questions is completely normal.

How would you describe your overall experience as a vendor on RenderHub?

Overall, my experience with RenderHub has been positive. The platform is very convenient from a seller's perspective. I like the asset upload process, the way product descriptions and images are handled, and the overall presentation workflow.

The seller conditions are also very good.

Another important advantage is that RenderHub actively works on promotion and advertising and helps assets gain additional visibility.

That is very important for a marketplace because simply giving sellers a place to upload files is not enough. A strong platform should also help connect sellers with potential buyers.

Overall, I have had a good experience with RenderHub, and I am interested in continuing to expand my catalog there.

Beyond the Individual Character

Throughout the interview, one idea keeps returning: a game-ready character has to be created with its role in the game in mind. That affects everything from visual design and topology to animation, optimization, and the amount of technical complexity the character actually needs.

The same thinking carries into Andryuha's work on RenderHub. Rather than approaching each model in isolation, he has been building a broader library of characters designed to visually work together as part of the same world.

For game developers building out a larger cast rather than searching for a single hero, that gives them more options for expanding the cast without losing visual consistency. Take a look at Andryuha's game-ready 3D characters and see which ones could belong in the world you are creating.