Open-World 3D Third-Person Action MMORPG in Godot 4

Stylized Low-Poly High Fantasy Art & Animation Guidelines

This static page turns the original handoff into a quick-start guide plus a searchable reference. Use the sidebar to jump straight to the parts your team cares about most.

Project

Open-World 3D Third-Person Action MMORPG in Godot 4

Audience

Character artists, environment artists, technical artists, VFX artists, animators, outsourcing partners, and integrators

Purpose

A clean production handoff document for building a cohesive stylized low-poly world with strong performance characteristics, modular characters, and Godot-friendly content workflows.

Start here

The fastest way to absorb the guide: these are the production rules that show up again and again across the document.

8 key rules
1

Silhouette first

At gameplay distance, shape clarity comes before fine detail. Hero characters should read by silhouette, then palette, then detail.

2

Use stylized, cheap surfaces

Start with vertex colors, gradients, masks, trim sheets, and atlases. Do not let noisy realism or heavy transparency define the look.

3

Keep material counts low

Most props should use 1 material. Standard humanoids should usually live in 1–2 materials, with 2–3 for special heroes.

4

Build characters around shared rigs

Use one canonical skeleton and discrete body archetypes. Fit gear offline per archetype instead of leaning on freeform runtime morphing.

5

Hide clipping with coverage masks

Armor should hide covered body polygons rather than trying to solve everything with deformation and extra complexity.

6

Terrain3D is the base, not the whole world

Use Terrain3D for broad terrain. Use mesh kits for caves, overhangs, bridges, cliffs, ruins, and other high-shape areas.

7

Combat readability wins

VFX and animation must clearly communicate who acted, where danger is, and when a move starts, hits, and ends.

8

Ship clean handoffs

Final packages should come in clean glTF, with validated clips, stable names, LODs, metadata, and no hidden junk objects.

Numbers to remember

A quick snapshot of the most reused targets, budgets, and defaults from the full guide.

Production snapshot

Body / head base mesh

~4k–10k tris

Playable humanoid target before full gear.

Equipped humanoid target

~8k–18k tris

Validate in engine against actual gear complexity.

Typical material count

1–2 shared

Absolute hero max: 3–4 materials.

Shared masks / gradients

64–256 px

Use the cheapest texture strategy that gets the look.

LOD expectation

LOD0 / 1 / 2

Keep silhouette first, then collapse secondary forms.

Asset type Typical range Upper guidance Material / workflow note
Playable humanoids Base body/head ~4k–10k tris Equipped target ~8k–18k tris Ideally 1–2 shared materials; hero max 3–4
Creatures Ambient ~500–2k tris Combat ~2k–8k tris; bosses can exceed if silhouette earns it Keep counts disciplined and rig families reusable
Props Small ~50–500 tris Standard ~300–2k tris; hero props higher with LODs 1 material is the default target
Textures Masks / gradients 64–256 Standard props 256–512 Hero props / armor 512–1024 only when justified

Browse by discipline

These shortcuts jump to the most relevant areas and can also activate the matching filter for a cleaner view.

Role-based entry points
Characters

Character team

Shared skeletons, body archetypes, coverage masks, offline-fitted gear, and readable weapon silhouettes.

HumanoidsWeaponsAnimationReview
Creatures

Creature team

Rig family reuse, readable attack language, disciplined bone counts, and efficient variant paths.

CreaturesAnimationReview
Environment

Environment team

Terrain3D for broad terrain, mesh kits for shaped spaces, instancing for density, and nav-aware scene design.

EnvironmentTerrain / NavGodot
VFX

VFX team

Graphic, readable effects with shared materials, clear timing, and controlled overdraw.

VFXGodotReview
Animation

Animation team

Snappy, intentional timing; clean skeleton conventions; and export metadata that supports gameplay.

Animator handoffHumanoidsCreatures
No sections match the current search and filter. Clear the search or switch back to a broader discipline filter.
Section 1

Visual Target

Build for silhouette, palette, and readability first. The look is stylized fantasy, not noisy realism.

3 topics
ProductionCharactersCreaturesEnvironmentVFXAnimationTech / Integration
1.1 Style pillars1.2 What success looks like1.3 What to avoid
1.1

Style pillars

Stylized low-poly high fantasy • Readable at gameplay distance • Expressive silhouettes

Our target style is:

  • Stylized low-poly high fantasy
  • Readable at gameplay distance
  • Expressive silhouettes
  • Pixel-art / vertex-color / gradient-driven texturing
  • Material-efficient and draw-call-conscious
  • Strong color scripting and shape language

A useful reference point is ABYSS X ZERO, which Studio Pixel Punk describes in official materials as having “expressive low poly visuals.” The takeaway is not to copy specific assets, but to aim for the same level of readability, bold stylization, and deliberate use of simplified forms.

1.2

What success looks like

Hero characters should be readable by silhouette first , then palette, then detail. • Equipment rarity or role should be readable through shape language , not only…

Assets should read clearly from a third-person gameplay camera:

  • Hero characters should be readable by silhouette first, then palette, then detail.
  • Equipment rarity or role should be readable through shape language, not only through tiny texture noise.
  • Environments should feel rich through composition, color, and layering, not raw triangle density.
  • Materials should rely on palette control, ramps, gradients, vertex colors, and selective emissive instead of realistic microdetail.
1.3

What to avoid

High-frequency texture noise that breaks the low-poly style • Too many tiny accessories that disappear at gameplay distance • Over-reliance on transparent materials

Avoid these common failure cases:

  • High-frequency texture noise that breaks the low-poly style
  • Too many tiny accessories that disappear at gameplay distance
  • Over-reliance on transparent materials
  • Excessively realistic PBR surfacing that clashes with the stylized world
  • Uncontrolled shape keys or body morphs that distort silhouettes
  • Large numbers of unique materials on a single character or prop set
  • Hyper-dense meshes where the shape could be achieved with fewer, cleaner forms
Section 2

Global Asset Standards

Keep scale, naming, glTF exports, budgets, and LODs consistent so assets stay integration-friendly.

5 topics
ProductionCharactersCreaturesEnvironmentVFXAnimationTech / Integration
2.1 Units, orientation, and scale2.2 File formats2.3 Naming rules2.4 Performance-minded defaults2.5 LOD philosophy
2.1

Units, orientation, and scale

1 Godot unit = 1 meter • Character and environment assets must be authored in consistent real-world scale • Forward direction should be standardized across the…
  • 1 Godot unit = 1 meter
  • Character and environment assets must be authored in consistent real-world scale
  • Forward direction should be standardized across the project
  • All exported assets should have clean transforms, frozen scale, and correct pivot/origin placement
2.2

File formats

Primary interchange format: glTF 2.0 ( .glb preferred for final handoff unless source files are required)

Primary interchange format: glTF 2.0 (.glb preferred for final handoff unless source files are required)

Source-of-truth working files may remain in DCC tools, but final integration packages should export to clean glTF with:

  • correct skeleton names
  • consistent material slot names
  • clean mesh hierarchies
  • validated animation clips
  • no hidden junk objects
2.3

Naming rules

Use stable, machine-readable naming. • CHR_HUM_A_BODY_Average_A • CHR_HUM_A_HEAD_Sharp_03

Use stable, machine-readable naming.

Examples:

  • CHR_HUM_A_BODY_Average_A
  • CHR_HUM_A_HEAD_Sharp_03
  • ARM_CHEST_Knight_T2_Average
  • ENV_Rock_CliffChunk_03
  • CRE_Wolf_Base_A
  • VFX_FireSlash_T1
  • ANM_HUM_1H_Slash_A

Recommended pattern: [Category]_[Family]_[Subtype]_[Variant]

2.4

Performance-minded defaults

These are starting production targets, not absolute laws. Validate in-engine.

These are starting production targets, not absolute laws. Validate in-engine.

Playable humanoids

  • Body/head combined base mesh: ~4k–10k tris
  • Equipped full character target: ~8k–18k tris depending on gear complexity
  • Materials: ideally 1–2 shared materials, absolute max 3–4 for a hero setup

Creatures

  • Small ambient creature: ~500–2k tris
  • Combat creature: ~2k–8k tris
  • Large boss: may exceed this, but silhouette must justify every surface

Environment props

  • Small prop: ~50–500 tris
  • Standard gameplay prop: ~300–2k tris
  • Hero prop/landmark: use higher budgets carefully and provide LODs
2.5

LOD philosophy

Every asset type should be authored with gameplay distance in mind.

Every asset type should be authored with gameplay distance in mind.

  • Near = clean silhouette and material readability
  • Mid = preserve silhouette, collapse secondary forms
  • Far = retain only major massing and palette blocks

Where possible:

  • Author LOD0 / LOD1 / LOD2
  • Merge accessories or remove floating detail in lower LODs
  • Simplify materials and alpha usage at distance
  • Use grouped/HLOD proxies for dense environment clusters
Section 3

Materials, Textures, and Surface Language

Favor vertex colors, gradients, masks, atlases, and shared materials over unique, expensive surfaces.

7 topics
ProductionCharactersCreaturesEnvironmentVFXTech / Integration
3.1 Material philosophy3.2 Preferred texture strategies3.3 Color maps and palette control3.4 Combined materials and draw-call reduction3.5 Texture size guidance3.6 Normals and detail maps3.7 Transparency policy
3.1

Material philosophy

We are not chasing realism. Materials should be stylized, controlled, and cheap.

We are not chasing realism. Materials should be stylized, controlled, and cheap.

Preferred look:

  • flat or softly ramped base colors
  • hand-authored gradients
  • vertex color breakup
  • limited roughness variation
  • occasional emissive accents
  • selective highlights placed intentionally
3.2

Preferred texture strategies

Vertex color first • Shared gradient ramps / palette lookups • Small mask textures

Use the cheapest texture strategy that achieves the look:

  1. Vertex color first
  2. Shared gradient ramps / palette lookups
  3. Small mask textures
  4. Trim sheets / atlases
  5. Unique textures only where they matter
3.3

Color maps and palette control

Color maps are encouraged where they reduce authoring cost and increase consistency.

Color maps are encouraged where they reduce authoring cost and increase consistency.

Recommended uses:

  • biome tint masks
  • armor tint regions
  • faction / rarity recolors
  • creature markings
  • VFX palette swaps

Guidelines:

  • Keep masks broad and readable
  • Use a small, controlled palette family per biome/faction
  • Avoid noisy procedural breakup
  • Maintain enough contrast between major forms
3.4

Combined materials and draw-call reduction

Atlas related assets when practical • Reuse a shared body material • Reuse a shared armor material where possible

To reduce draw calls:

  • Atlas related assets when practical
  • Reuse a shared body material
  • Reuse a shared armor material where possible
  • Use trim sheets for architecture and prop kits
  • Use palette/gradient variations instead of duplicating materials
  • Minimize the number of mesh surfaces per asset

A good target is:

  • most props: 1 material
  • standard humanoid body + gear: 1–2 materials
  • special hero characters: 2–3 materials
  • avoid unnecessary transparent surfaces
3.5

Texture size guidance

Use only as much texture resolution as the camera justifies.

Use only as much texture resolution as the camera justifies.

Suggested defaults:

  • Small shared masks / gradients: 64–256
  • Standard props: 256–512
  • Important hero props or armor sets: 512–1024
  • Character face/identity features: use carefully; keep consistency across the pipeline
3.6

Normals and detail maps

Normals are optional, not mandatory. • major bevel support • stylized panel edges

Normals are optional, not mandatory.

Use them for:

  • major bevel support
  • stylized panel edges
  • selective high-value details

Avoid:

  • noisy baked normals fighting the low-poly shading
  • hyper-real surface noise
  • relying on normal maps to fix weak shapes
3.7

Transparency policy

Transparency is expensive and visually fragile. • opaque materials • alpha test / cutout where necessary

Transparency is expensive and visually fragile.

Prefer:

  • opaque materials
  • alpha test / cutout where necessary
  • geometry-based solutions when affordable

Use transparent materials sparingly for:

  • magical VFX
  • ghosting
  • special foliage cases
  • special hair cards only if needed
Section 4

Humanoid Character Guidelines

Use a shared humanoid skeleton, discrete body archetypes, coverage masks, and offline-fitted gear.

10 topics
ProductionCharactersAnimationTech / Integration
4.1 Core production approach4.2 Body system4.3 Face system4.4 Modular assembly4.5 Equipment categories4.6 Coverage masks4.7 Equipment fitting pipeline4.8 Topology guidance4.9 Character material rules4.10 Character deliverables
4.1

Core production approach

Use a shared rig + discrete body archetypes + offline-fitted equipment workflow.

Use a shared rig + discrete body archetypes + offline-fitted equipment workflow.

Do not build the pipeline around freeform runtime body morphing.

4.2

Body system

one canonical shared skeleton • one canonical base body topology • 3–5 body archetypes such as: Slim Average Broad Heavy Tall or Short variant if needed

For each humanoid ancestry/body family:

  • one canonical shared skeleton
  • one canonical base body topology
  • 3–5 body archetypes such as:
    • Slim
    • Average
    • Broad
    • Heavy
    • Tall or Short variant if needed

These archetypes should preserve:

  • identical bone names
  • compatible bone rests
  • stable seam boundaries
  • shared attachment points
4.3

Face system

separate head families or head presets • 6–12 authored face presets per ancestry where needed • limited identity shape keys only for low-risk adjustments

Use a restrained, production-safe approach:

  • separate head families or head presets
  • 6–12 authored face presets per ancestry where needed
  • limited identity shape keys only for low-risk adjustments
  • expression shapes kept separate from identity shapes

Preserve strong silhouette and stylization. Avoid subtle “realistic” facial deformations that disappear in gameplay.

4.4

Modular assembly

body mesh • head mesh • hair / facial hair / brows

A standard humanoid should be composed of:

  • body mesh
  • head mesh
  • hair / facial hair / brows
  • skinned armor pieces
  • rigid socketed items
  • optional accessory set
4.5

Equipment categories

Rigid attachments • swords • shields

Rigid attachments

  • swords
  • shields
  • staves
  • lanterns
  • pendants
  • some back items

Skinned equipment

  • helmets
  • chest armor
  • gloves
  • pants
  • boots
  • pauldrons

Problem garments

  • robes
  • skirts
  • long coats
  • wide sleeves
  • hanging cloth

These should usually be authored as dedicated variants per body archetype.

4.6

Coverage masks

To prevent clipping, armor pieces should define coverage masks that hide covered body polygons.

To prevent clipping, armor pieces should define coverage masks that hide covered body polygons.

Examples:

  • chest armor hides torso upper + upper arms
  • boots hide lower leg base mesh
  • gloves hide hand/forearm segments
  • full helms hide hair and parts of the head where necessary

Coverage masks are preferred over trying to solve everything with extra deformation.

4.7

Equipment fitting pipeline

Author armor on the canonical base body • Conform offline to each body archetype • Clean deformation issues in DCC

Recommended workflow:

  1. Author armor on the canonical base body
  2. Conform offline to each body archetype
  3. Clean deformation issues in DCC
  4. Export fitted variants
  5. Validate in animation tests
  6. Tag the asset with compatible body archetypes
4.8

Topology guidance

Keep edge flow clean around shoulders, elbows, hips, knees, and neck • Preserve strong silhouette planes • Avoid micro-bevel spam
  • Keep edge flow clean around shoulders, elbows, hips, knees, and neck
  • Preserve strong silhouette planes
  • Avoid micro-bevel spam
  • Prioritize deformation quality over decorative topology
4.9

Character material rules

1 shared body/head material • 1 shared equipment material • optional 1 accent material for special emissive/VFX-linked pieces

Recommended:

  • 1 shared body/head material
  • 1 shared equipment material
  • optional 1 accent material for special emissive/VFX-linked pieces

Use:

  • vertex colors
  • tint masks
  • gradient ramps
  • minimal texture count
4.10

Character deliverables

source file • exported .glb • skeleton mapping notes if relevant

Each final humanoid package should include:

  • source file
  • exported .glb
  • skeleton mapping notes if relevant
  • material slot list
  • LODs
  • coverage mask metadata
  • body archetype compatibility list
  • preview renders and turntable if required
Section 5

Creature Guidelines

Group creatures by rig family, keep bones/materials disciplined, and make attack language readable.

7 topics
ProductionCreaturesAnimationTech / Integration
5.1 Creature style rules5.2 Creature families5.3 Creature rig recommendations5.4 Bone count discipline5.5 Creature materials5.6 Creature variants5.7 Creature deliverables
5.1

Creature style rules

clear silhouette • exaggerated massing • readable attack language

Creatures should feel native to the same stylized world:

  • clear silhouette
  • exaggerated massing
  • readable attack language
  • simplified material treatment
  • strong color blocking
5.2

Creature families

biped humanoid • quadruped • flyer

Group creatures by movement/rig family whenever possible:

  • biped humanoid
  • quadruped
  • flyer
  • serpent / worm
  • insectoid
  • large boss
  • mount family

Rig reuse inside each family should be prioritized.

5.3

Creature rig recommendations

CRE_BIPED_BASE • CRE_QUAD_BASE • CRE_FLYER_BASE

Prefer a small number of reusable base rigs:

  • CRE_BIPED_BASE
  • CRE_QUAD_BASE
  • CRE_FLYER_BASE
  • CRE_BOSS_HEAVY_BASE

Variant creatures should reuse the nearest compatible base rig whenever practical.

5.4

Bone count discipline

Use only the bones needed for performance and readability.

Use only the bones needed for performance and readability.

Add bones only when they clearly improve:

  • silhouette
  • readable motion
  • attachment support
  • gameplay communication

Do not over-rig secondary fleshy motion if simple animation or shader motion sells it well enough.

5.5

Creature materials

broad color separation • masks for markings • limited emissive

Creature surfacing should follow the same project philosophy:

  • broad color separation
  • masks for markings
  • limited emissive
  • stylized gradients
  • minimal material count
5.6

Creature variants

horn swaps • crest swaps • tail variants

Prefer data-efficient variants:

  • horn swaps
  • crest swaps
  • tail variants
  • color/pattern swaps
  • armor add-ons
  • elite/boss overlays
5.7

Creature deliverables

base model • base rig • animation set

Each creature should ship with:

  • base model
  • base rig
  • animation set
  • hit/hurt reference points
  • attachment points if applicable
  • LODs
  • material list
  • gameplay notes for scale/readability
Section 6

Weapons, Equipment, and Accessories

Weapons should read clearly at gameplay distance; accessories should stay lightweight and uncluttered.

4 topics
ProductionCharacters
6.1 Weapon style6.2 Weapon categories6.3 Materials6.4 Accessories
6.1

Weapon style

oversized enough to read • clean silhouette • obvious weight class

Weapons should be bold and readable from a gameplay camera:

  • oversized enough to read
  • clean silhouette
  • obvious weight class
  • recognizable rarity by shape and accent color
6.2

Weapon categories

1H sword • 2H sword • axe

Weapons should be grouped into families with shared proportions and socket logic:

  • 1H sword
  • 2H sword
  • axe
  • hammer
  • spear
  • staff
  • wand
  • bow / ranged focus
  • shield
  • off-hand focus
6.3

Materials

1 shared material per weapon family where possible • palette and gradient control for rarity tiers • emissive only on important magical elements

Aim for:

  • 1 shared material per weapon family where possible
  • palette and gradient control for rarity tiers
  • emissive only on important magical elements
6.4

Accessories

clips constantly • creates unnecessary draw calls • disappears at distance

Keep accessories light and readable. Avoid accessory clutter that:

  • clips constantly
  • creates unnecessary draw calls
  • disappears at distance
  • interferes with combat readability
Section 7

Environment Art Guidelines

Use Terrain3D for broad terrain, mesh kits for hero shapes, and instancing for cheap world richness.

10 topics
ProductionEnvironmentTech / Integration
7.1 World representation philosophy7.2 Terrain3D integration rules7.3 Terrain region workflow7.4 Terrain material philosophy7.5 Terrain texturing recommendations7.6 Environment prop categories7.7 Instancing policy7.8 Architecture kit rules7.9 Collision and gameplay proxies7.10 Environment deliverables
7.1

World representation philosophy

Terrain3D for the broad traversable landscape • modular mesh kits for hero terrain and structures • instanced clutter for cheap environmental richness

The world is built from:

  • Terrain3D for the broad traversable landscape
  • modular mesh kits for hero terrain and structures
  • instanced clutter for cheap environmental richness
  • streamed scene chunks for settlements, dungeons, landmarks, and events
7.2

Terrain3D integration rules

hills • roads • fields

Use Terrain3D for:

  • hills
  • roads
  • fields
  • shoreline massing
  • broad slopes
  • traversable open terrain

Do not rely on Terrain3D alone for:

  • caves
  • overhangs
  • bridges
  • ruins with interior logic
  • fortified structures
  • highly shaped cliffs

Those should be authored as mesh kits.

7.3

Terrain region workflow

Environment teams should think in terrain regions + prop layers + landmark kits .

Environment teams should think in terrain regions + prop layers + landmark kits.

Each area should define:

  • terrain sculpt
  • paint/control setup
  • clutter layers
  • hero props
  • blockers and collision proxies
  • nav-relevant geometry
  • streaming chunk boundaries
7.4

Terrain material philosophy

Terrain should avoid noisy realism. • broad hand-authored color zoning • gradient-based slope handling

Terrain should avoid noisy realism.

Preferred terrain look:

  • broad hand-authored color zoning
  • gradient-based slope handling
  • limited blend layers
  • biome tint logic
  • stylized paths and erosion shapes
  • strong separation between ground classes
7.5

Terrain texturing recommendations

grass/dirt/stone/sand/snow variants • broad biome tinting • optional macro color breakup

Use terrain materials to support:

  • grass/dirt/stone/sand/snow variants
  • broad biome tinting
  • optional macro color breakup
  • clean slope transitions
  • stylized path painting

Avoid:

  • too many layers per biome
  • muddy blends
  • excessive small tiling detail
  • photoreal texture sources
7.6

Environment prop categories

Clutter props • grass tufts • flowers

Clutter props

  • grass tufts
  • flowers
  • mushrooms
  • pebbles
  • small branches
  • debris

Standard props

  • crates
  • carts
  • signs
  • fences
  • barrels
  • camp gear
  • shrines
  • lanterns

Hero props

  • statues
  • magical devices
  • large trees
  • gate structures
  • ruins
  • altars
  • giant crystals
7.7

Instancing policy

foliage • repeated rocks • repeated small ruins

Use instancing aggressively for cheap richness:

  • foliage
  • repeated rocks
  • repeated small ruins
  • repeated small props
  • ambient dressing

Keep instanced assets:

  • low poly
  • single material where possible
  • non-critical for gameplay collision unless separately represented
7.8

Architecture kit rules

snap-friendly dimensions • trim-sheet reuse • shared material libraries

Modular kits should be built around:

  • snap-friendly dimensions
  • trim-sheet reuse
  • shared material libraries
  • consistent silhouette language
  • clean corner/end-cap solutions

Examples:

  • village timber kit
  • elven ruins kit
  • fortress stone kit
  • magical shrine kit
7.9

Collision and gameplay proxies

Visible geometry should not automatically be the gameplay proxy.

Visible geometry should not automatically be the gameplay proxy.

Provide separate authoring when needed for:

  • collision blockers
  • climb blockers
  • projectile blockers
  • nav proxy meshes
  • occlusion proxy meshes
7.10

Environment deliverables

source files • exported scene/piece files • material list

Each environment set should include:

  • source files
  • exported scene/piece files
  • material list
  • texture list
  • collision notes
  • snap grid info
  • LODs
  • streaming chunk notes
  • biome usage notes
Section 8

Terrain, Navigation, and Server Representation Notes

Separate visual terrain from server/navigation data and keep traversal and blockers obvious to players.

4 topics
EnvironmentTech / Integration
8.1 Client terrain8.2 Server representation8.3 Navigation authoring8.4 Artist implications
8.1

Client terrain

Terrain3D for the base landscape • mesh chunks for caves/cliffs/bridges/ruins • instanced clutter for density

Client terrain should remain visually rich but efficient:

  • Terrain3D for the base landscape
  • mesh chunks for caves/cliffs/bridges/ruins
  • instanced clutter for density
  • streamed scenes for high-value content
8.2

Server representation

heightfield • hole mask • navigation mask

The server should use exported terrain data, not the visual terrain mesh:

  • heightfield
  • hole mask
  • navigation mask
  • blocker references
  • water/dead-zone masks
  • biome/material IDs if needed
8.3

Navigation authoring

Do not expect one giant world navmesh to solve everything.

Do not expect one giant world navmesh to solve everything.

Preferred strategy:

  • authored local nav regions for towns, camps, roads, dungeons
  • limited bounded rebakes only where needed
  • simpler wilderness logic outside curated spaces
8.4

Artist implications

avoid tiny decorative protrusions in walkable spaces • keep traversal surfaces obvious • clearly separate walkable ground from decorative steep surfaces

Artists should keep nav and gameplay readability in mind:

  • avoid tiny decorative protrusions in walkable spaces
  • keep traversal surfaces obvious
  • clearly separate walkable ground from decorative steep surfaces
  • call out overhangs, holes, and cave entrances explicitly
Section 9

VFX Guidelines

VFX should be graphic, shape-driven, and easy to parse in combat without muddy overdraw.

6 topics
ProductionVFXTech / Integration
9.1 VFX style pillars9.2 Preferred VFX language9.3 Common VFX categories9.4 Material and shader rules for VFX9.5 Gameplay readability9.6 VFX deliverables
9.1

VFX style pillars

graphic • readable • shape-driven

VFX should match the stylized world:

  • graphic
  • readable
  • shape-driven
  • color-driven
  • fast to parse in combat
9.2

Preferred VFX language

bold silhouettes • clean arcs • gradient ramps

Use:

  • bold silhouettes
  • clean arcs
  • gradient ramps
  • masked shapes
  • stylized particles
  • limited frame-driven texture work where it adds value

Avoid:

  • realistic smoke simulation as the default
  • overly soft noise clouds
  • muddy additive spam
  • effects that obscure combat clarity
9.3

Common VFX categories

melee slashes • impact bursts • spell charges
  • melee slashes
  • impact bursts
  • spell charges
  • projectile trails
  • lingering AOEs
  • buffs/debuffs
  • UI-linked world markers
  • environment magic
  • weather overlays
  • live-event world changes
9.4

Material and shader rules for VFX

few shared VFX materials • gradient texture reuse • channel-packed masks

Preferred:

  • few shared VFX materials
  • gradient texture reuse
  • channel-packed masks
  • vertex color control
  • emission as a palette accent

Transparency should be used intentionally. Overdraw must be monitored.

9.5

Gameplay readability

who caused this? • what area does it affect? • when does it become dangerous?

Every combat VFX asset must answer:

  • who caused this?
  • what area does it affect?
  • when does it become dangerous?
  • when is it ending?
9.6

VFX deliverables

scene/prefab • texture list • material list

Each VFX package should include:

  • scene/prefab
  • texture list
  • material list
  • color variants if applicable
  • timing notes
  • intensity tiers
  • looping/non-looping notes
Section 10

Animator Handoff

Animation should be snappy, intentional, and metadata-rich, with gameplay readability ahead of flourish.

9 topics
ProductionAnimationTech / Integration
10.1 Animation philosophy10.2 Humanoid skeleton rules10.3 Root motion policy10.4 Required animation sets for humanoids10.5 Required animation metadata10.6 Creature animation guidance10.7 Secondary motion10.8 Stylization rules10.9 Animator export checklist
10.1

Animation philosophy

gameplay readability • timing clarity • expressive anticipation

Animation should prioritize:

  • gameplay readability
  • timing clarity
  • expressive anticipation
  • clean recoveries
  • stylized impact
  • consistency across equipment and creature families
10.2

Humanoid skeleton rules

All humanoid animations should target the project’s standard humanoid skeleton profile.

All humanoid animations should target the project’s standard humanoid skeleton profile.

Requirements:

  • identical core bone naming
  • standardized rest pose
  • stable root orientation
  • consistent weapon socket behavior
  • no surprise scale tracks
10.3

Root motion policy

in-place locomotion • root motion only for selected authored moves such as: dodge lunge leap cinematic finisher monster charge where explicitly required • dodge

Default recommendation:

  • in-place locomotion
  • root motion only for selected authored moves such as:
    • dodge
    • lunge
    • leap
    • cinematic finisher
    • monster charge where explicitly required
10.4

Required animation sets for humanoids

idle • walk • jog/run

Baseline:

  • idle
  • walk
  • jog/run
  • sprint
  • strafe
  • jump start / loop / land
  • fall
  • turn in place if required
  • ready/combat idle
  • hit react variants
  • knockback / knockdown
  • death
  • interaction
  • sheath/unsheath if used

Combat sets by weapon family:

  • light chain
  • heavy attack
  • charged attack
  • block / parry
  • dodge
  • cast start / loop / release
  • interrupt / stunned
  • recovery
10.5

Required animation metadata

anticipation start • commit frame • hit frame or hit window

Every important clip should include timing notes for:

  • anticipation start
  • commit frame
  • hit frame or hit window
  • cancel window
  • recovery
  • loop behavior
  • root-motion status
  • left/right foot lead if relevant
10.6

Creature animation guidance

silhouette changes • attack tell readability • weight class

Creature sets should emphasize:

  • silhouette changes
  • attack tell readability
  • weight class
  • clear idle personality
  • readable hurt states

Each creature family should have a consistent motion language.

10.7

Secondary motion

enough to add life • not enough to create noisy silhouettes • cloth tails, ears, and capes should never hide gameplay cues

Use secondary motion carefully:

  • enough to add life
  • not enough to create noisy silhouettes
  • cloth tails, ears, and capes should never hide gameplay cues
10.8

Stylization rules

snappy • intentional • readable

Animation should feel:

  • snappy
  • intentional
  • readable
  • slightly exaggerated
  • not floppy unless the creature design calls for it
10.9

Animator export checklist

clip names clean • frame ranges trimmed • transforms frozen where appropriate

Before handoff:

  • clip names clean
  • frame ranges trimmed
  • transforms frozen where appropriate
  • no hidden helper junk exported
  • correct skeleton bound
  • root behavior documented
  • preview video included for critical combat clips if requested
Section 11

Godot Integration Notes

Imports must be stable in Godot 4, scene structure must be clean, and handoffs must survive reimport.

4 topics
ProductionTech / Integration
11.1 Import expectations11.2 Scene structure11.3 Reimport safety11.4 Shared material libraries
11.1

Import expectations

stable material assignment • stable skeleton/skin binding • no duplicate material spam

All content must import cleanly into Godot 4 with:

  • stable material assignment
  • stable skeleton/skin binding
  • no duplicate material spam
  • no broken tangent/shading surprises
  • no unexpected scale issues
11.2

Scene structure

skeleton • body/head meshes • equipment meshes

Character content should separate:

  • skeleton
  • body/head meshes
  • equipment meshes
  • rigid socket items
  • animation resources

Environment content should separate:

  • visible mesh
  • collision proxy
  • nav proxy where needed
  • occlusion proxy where needed
  • LODs or HLOD proxies where required
11.3

Reimport safety

Avoid workflows that require manual per-import fixing. Handoffs should be resilient to reimport.

Avoid workflows that require manual per-import fixing. Handoffs should be resilient to reimport.

11.4

Shared material libraries

Prefer central material libraries and shared shader inputs over per-asset one-off materials.

Prefer central material libraries and shared shader inputs over per-asset one-off materials.

Section 13

Review Checklists

Use these approval checklists to catch style, performance, and readability issues before handoff.

5 topics
ProductionCharactersCreaturesEnvironmentVFXAnimation
13.1 Character art review13.2 Environment art review13.3 Creature review13.4 VFX review13.5 Animation review
13.1

Character art review

silhouette reads from gameplay distance • material count acceptable • body/equipment compatibility documented
  • silhouette reads from gameplay distance
  • material count acceptable
  • body/equipment compatibility documented
  • clipping addressed with masks/variants
  • LODs included
  • palette matches faction/biome/style guide
13.2

Environment art review

works with Terrain3D or mesh-chunk plan • readable navigation surfaces • material reuse sensible
  • works with Terrain3D or mesh-chunk plan
  • readable navigation surfaces
  • material reuse sensible
  • clutter suitable for instancing
  • collision proxy considered
  • streaming chunk boundaries sensible
13.3

Creature review

strong silhouette • rig family identified • attack tell readability
  • strong silhouette
  • rig family identified
  • attack tell readability
  • material count low
  • variant path clear
  • LODs present if required
13.4

VFX review

readable in action combat • overdraw controlled • palette consistent
  • readable in action combat
  • overdraw controlled
  • palette consistent
  • timing aligned to gameplay
  • shared materials reused where possible
13.5

Animation review

timing clear • readable anticipation and recovery • correct skeleton profile
  • timing clear
  • readable anticipation and recovery
  • correct skeleton profile
  • root behavior documented
  • combat metadata supplied
  • no unnecessary secondary motion noise
Section 14

Summary of the Pipeline Recommendation

The recommended pipeline centers on shared rigs, discrete archetypes, palette-driven surfaces, and instancing.

1 topic
ProductionCharactersCreaturesEnvironmentVFXAnimationTech / Integration

For this project, the best content strategy is:

  • shared humanoid skeletons
  • discrete body archetypes instead of freeform runtime morphing
  • offline-fitted modular equipment
  • low-material, palette-driven texturing
  • Terrain3D for broad terrain plus mesh kits for hero terrain
  • instancing for clutter and repeated props
  • reusable creature rig families
  • shape-driven stylized VFX
  • animation built for gameplay readability first

This keeps the style cohesive, preserves the low-poly aesthetic, and supports the performance constraints of an open-world multiplayer game.

Built as a single self-contained static HTML page from stylized_low_poly_artist_animator_guidelines.md.