Tech Art Bible for Unity: Graphics Standards and Pipeline Automation
Introduction
We often encounter situations where a new artist joins the team and asks, "What's the polygon budget for the character?" The team lead answers, "Well, roughly between 5 and 15 thousand, depending on importance." This is not a standard. It's a verbal agreement that everyone interprets differently and that breaks with every new hire or contractor. Without clearly documented standards, a team spends up to 30% of its time reworking assets. Our experience shows: after implementing a Tech Art Bible, the number of reworks drops by 3 times compared to verbal agreements. Budget savings on art production can reach 30%. Over 5 years of work, we have created Tech Art Bibles for dozens of projects—from mobile games to AAA consoles. The document fixes numbers, formats, and procedures, eliminating ambiguities. Automated checks in the pipeline work 5 times faster than manual review and reduce the number of artifacts by 40%. Get a consultation on implementing standards in your pipeline.
Why document "obvious" standards?
The gap between what is considered "self-evident" within the team and what artists actually do is huge. Examples of real discrepancies:
-
Texture resolutions: one artist uses 2K for background objects, another uses 4K. In VRAM this is immediately visible—profiling shows
Texture Memory at 800 MB instead of the planned 400. And the document only says "use reasonable resolutions."
-
Naming:
hero_body_d.png, Hero_Body_Albedo.png, character_1_diffuse_final.png—three textures of the same type from three artists in one project. AssetDatabase.FindAssets by pattern doesn't work, automatic import by suffix doesn't work, CI checks on naming convention don't work.
-
Pivot points in FBX: one Blender artist exports with pivot at the geometric center, another at the world origin. The developer gets an object that rotates around an unexpected point when calling
transform.Rotate().
What is included in the Tech Art Bible
Polygon budgets
A table by object category with breakdown by platform:
| Category |
PC (LOD0) |
Mobile (LOD0) |
Mobile (LOD1) |
| Main character |
10,000–15,000 |
5,000–8,000 |
1,500–3,000 |
| Secondary NPC |
5,000–8,000 |
2,000–4,000 |
500–1,000 |
| Large prop |
3,000–5,000 |
1,000–2,000 |
200–500 |
| Small prop |
500–1,500 |
200–500 |
50–150 |
Texture standards
Resolutions by category, formats (PNG for sources, TGA for normal maps when importing into Unity—not PNG, BC7 as the target compression format for PC, ASTC for Android/iOS), mandatory channels (Albedo, Normal, Metallic/Roughness, AO—separately or packed).
Naming convention
Conventions with examples. For textures: {object}_{part}_{type}_{resolution}.ext, e.g., hero_body_albedo_2k.png. For meshes: {category}_{name}_{LOD}.fbx. We document not only the rule but also the rationale behind it—this reduces resistance during implementation.
UV standards
Tile size, acceptable UV-overlapping for lightmap UV (only LOD0, UV channel 2), seam placement requirements (not on visible edges, not on joints).
Export procedures from each tool
Blender FBX export settings (Apply Transform, Forward axis, Units), Substance Painter export template for Unity (specifically which channels go into which slots), Maya export checklist. Adhering to procedures reduces import errors by 3 times compared to ad-hoc settings.
Example Blender export checklist
- Apply Transform (Scale = 1, Rotation = 0)
- Forward axis = -Z, Up axis = Y
- Units = Centimeters (import into Unity with multiplier 1)
- Mesh Smooth = Edge, not Face
- Export only visible objects
How the Tech Art Bible is developed for your project?
We start with an audit of existing assets: what is already used in the project, what are the de facto applied values. The document should reflect reality plus improvements, not a perfect standard from scratch—otherwise the team will ignore it.
Interviews with artists: what questions are asked most often, where do conflicts arise during asset review, what has to be redone. This is the best source for determining priorities in the document.
Format: Confluence or Notion—interactive, support nested tables and screenshots. Not PDF—no one reads PDFs after six months. Structure: table of contents with anchor links, "Quick Reference" on the first page (most frequently needed data), complete sections below.
Document versioning—date of last update and changelog. A standard without a version loses trust: "Is this relevant for our current platform?"
How to automate compliance with standards?
A document doesn't work without automated checks. Unity Editor scripts for validation:
- Checking imported textures for naming convention compliance via
AssetPostprocessor.OnPreprocessTexture()
- Checking max resolution on import: if a texture > 4096 for the background category—warning in console
- Mesh validator via
AssetPostprocessor.OnPostprocessModel(): check polycount by category name from file name
This is not a replacement for the document, but real-time feedback when standards are violated—before code review. Order integration of validators into your project—we guarantee a reduction in asset review time. Read more about automation approaches in the AssetPostprocessor documentation.
Implementation timelines
| Document scope |
Timeline |
| Basic standard (naming + budgets + export) |
1–2 weeks |
| Full Tech Art Bible + CI validators |
3–6 weeks |
| Update of existing document for a new platform |
3–7 days |
The cost is calculated after an audit of the team's current practices and the project's target platforms. Contact us for a free preliminary consultation and get a commercial offer within a day. We guarantee a 30% reduction in rework and faster onboarding of new artists.
Why choose our standards?
Over 5 years in the gamedev documentation market. We have helped dozens of studios unify pipelines—from indie to AAA. Our clients report a 40% reduction in code review time and higher asset quality at the first checkpoint. Order an audit of your current practices—get a plan for implementing a Tech Art Bible tomorrow.
Manual pre-release preparation as a source of delays
We automate the entire pre-release pipeline for mobile and XR games. A studio is about to release a game — a week before the date, the manager remembers they need to build an AAB, sign it, and upload to Google Play. The build engineer manually starts the build, waits an hour, forgets to enable IL2CPP, the build crashes on Android 12. Rebuilding takes another hour. Simultaneously, the icon needs to be redesigned to meet new Google requirements. As a result, the release is delayed by three days. Experience shows: manual pre-release preparation is the primary source of delays and bugs that do not manifest on the developer's machine.
How to set up CI/CD for mobile game builds?
Pipeline tools
GameCI — open-source Docker images for Unity builds, running on GitHub Actions, GitLab CI, or any other CI provider. Key components: unity-builder (builds for the target platform), unity-test-runner (runs Unity Test Framework before build), unity-return-license (returns the license — critical for Pro). Unity Cloud Build is simpler but less flexible and expensive for frequent builds. Fastlane is the standard for final steps: signing, uploading to stores, metadata.
Typical pipeline
jobs:
test:
name: Run Unity Tests
uses: game-ci/unity-test-runner@v4
with:
unityVersion: 2022.3.20f1
testMode: playmode
build-android:
name: Build Android
needs: test
uses: game-ci/unity-builder@v4
with:
targetPlatform: Android
androidKeystoreBase64: ${{ secrets.ANDROID_KEYSTORE_BASE64 }}
androidKeystorePass: ${{ secrets.KEYSTORE_PASSWORD }}
androidKeyaliasPass: ${{ secrets.KEY_PASSWORD }}
upload-to-play:
name: Upload to Google Play (Internal Track)
needs: build-android
uses: r0adkll/upload-google-play@v1
with:
serviceAccountJsonPlainText: ${{ secrets.SERVICE_ACCOUNT_JSON }}
packageName: com.yourcompany.yourgame
releaseFiles: build/Android/*.aab
track: internal
Secrets, not variables — all keys in CI secrets. AAB instead of APK has been mandatory for several years. Tracks: internal → closed → open → production. Promotion — manual or Fastlane supply promote.
iOS specifics
Unity builds an Xcode project, then xcodebuild. Need Distribution Certificate and Provisioning Profile (App Store). Fastlane Match solves the problem of certificate synchronization within the team:
lane :build_ios do
match(type: “appstore”, readonly: true)
build_app(workspace: “Unity-iPhone.xcworkspace”,
scheme: “Unity-iPhone”,
export_method: “app-store”)
upload_to_testflight
end
App Store Connect API Key replaces login/password, does not break with 2FA.
Step-by-step pipeline setup
- Audit Unity PlayerSettings (Graphics APIs, Scripting Backend, stripping).
- Create CI configuration with GameCI — define test, build, and deploy jobs.
- Integrate Fastlane for code signing and store uploads.
- Store all secrets (keystore, certificates, API keys) in encrypted CI variables.
- Run a test release on internal track, verify end‑to‑end.
Each step includes validation: build must pass on a clean runner, not just a local machine.
Why does App Store reject about a third of first submissions?
Apple rejects 30–40% of first submissions from new studios. Common reasons:
| Category |
Typical problem |
| Metadata |
Screenshots with third‑party brands, description mentioning other platforms |
| Technical |
Crash on iPad, lack of IPv6 (Apple requirement still valid) |
| Policies |
Sign in with Apple not implemented when using third‑party providers; no link to Privacy Policy |
Practice: before submission, go through the App Store Review Guidelines from start to finish — 2–3 hours, saving 2–3 weeks of resubmission loops.
Google Play is more lenient: typical reasons — outdated targetSdkVersion, excessive permissions, incorrect Data Safety Form.
Detailed breakdown of common rejections we solve
-
iPad crash: missing universal storyboard or 2x assets — we add device‑specific assets during build.
-
Missing IPv6: we verify network code works on IPv6‑only networks.
-
Third‑party screenshots: we generate store assets that only contain your IP.
-
Privacy Policy link not found: we ensure the link is active and matches the app bundle ID.
Deliverables of pre-release preparation
We deliver the following for your game release:
- CI/CD pipeline configured (GameCI + Fastlane, Unity Cloud Build — turnkey)
- Metadata and marketing assets (screenshots, icons, feature graphics)
- Store submission guidance with documentation of all accesses and credentials
- 72‑hour post‑release monitoring (Crashlytics, ANR rate, user reviews)
- Pipeline documentation and team training session (hands‑on)
- Age rating configuration (IARC, ESRB, PEGI, CERO) and localization of store metadata
Pipeline automation replaces the manual work of an entire department. For example, setting up Continuous Integration via GameCI and Fastlane reduces pre‑release preparation time threefold — from 8 working hours to 2.5.
Our pre-release workflow: from audit to store submission
| Phase |
What we do |
| Audit |
Analyze current build process, check PlayerSettings, identify bottlenecks |
| Pipeline setup |
Implement CI with GameCI + Fastlane, integrate secrets, configure tracks |
| Metadata creation |
Generate store screenshots, icons, video previews according to platform specs |
| Store submission |
Submit to Apple / Google / Steam, accompany until approval |
| Monitoring |
Track crash rate and ANR for first 72 hours, hotfix if needed |
Impact of pipeline automation on timelines and budget
Manual game release incurs significant engineering and testing costs. CI/CD automation pays for itself within the first two months, reducing release costs by 40–60%.
| Stage |
Manual |
Automated (our approach) |
| Building AAB |
1 hr (risk of error) |
20 min (reproducible) |
| Testing on 20 devices |
2–3 hr (manual run) |
20 min (parallel tests) |
| Upload to Google Play + metadata |
1–1.5 hr |
5 min (Fastlane) |
| Total per release |
4–5.5 hr |
45 min |
Result: we reduce the commit‑to‑publish cycle by 6–8 times. For projects with frequent hotfixes, this is the difference between a week‑long user wait and a one‑day fix. We guarantee the pipeline works reliably after setup. Our engineers hold Unity Certified Professional credentials.
Typical savings: $2,500–$5,000 per month on engineering time eliminated by automation — $30,000–$60,000 annually on a mid‑size project.
Post‑release: monitoring and updates
Crash rate < 1% (Firebase Crashlytics), ANR rate < 0.47% (Play Console) — otherwise visibility restrictions. Phased rollout is mandatory: first 10%, then 50%, then 100% of users.
Our track record: 30+ mobile game releases, 5+ years on the market. CI/CD automation pays for itself within the first two months, reducing release costs by 40–60%.
Timeline
Setup takes from 2 days (simple mobile game with existing Unity project) to 2 weeks (complex multi‑platform project with custom CI runners). We calculate exact hours during a free pipeline audit.
Contact our engineers for a free pipeline audit and a timeline estimate. Submit a request — we will analyze your pipeline and offer a solution within 2 days. Get a consultation from an engineer who has shipped 30+ titles.