33 lines
2.1 KiB
Markdown
33 lines
2.1 KiB
Markdown
|
# Blog design — agent rules
|
||
|
|
|
||
|
|
Design and content rules for agents writing tinqs/blog posts.
|
||
|
|
|
||
|
|
## Voice
|
||
|
|
|
||
|
|
- **Confident, shipped.** Every feature is presented as built, complete, and working. Never "we plan to," "we're working on," "next we'll."
|
||
|
|
- **No evolution narrative.** Don't tell the "first we tried X, then we fixed Y" story. Present the final design as if it was the plan from day one.
|
||
|
|
- **External audience.** Readers are game developers and technical audiences outside Tinqs. No internal project names, no team org charts, no "Ozan decided" or "Uygar built."
|
||
|
|
|
||
|
|
## What to never mention
|
||
|
|
|
||
|
|
- **Asset pack names or vendors.** Polyperfect, Low Poly Ultimate Pack, Quaternius, Kevin Iglesias, etc. Say "our animal models" or nothing at all.
|
||
|
|
- **Unity import details.** FBX source format, `.anim` files, `.meta` clip ranges, `isleborn/` paths.
|
||
|
|
- **Internal tooling specifics.** `migrate_animals.py` internals, Blender pipeline details, repo paths.
|
||
|
|
- **Things that failed or were removed.** Failed migrations, broken assets, animals we deleted, bugs we shipped then fixed. If you must mention a bug, frame it as a design insight learned during development — never "we shipped this broken."
|
||
|
|
- **Roadmaps, tiers, trade-offs, future plans.** The post describes what exists. No "Tier A/B/C," no "recommended build order," no "what's next."
|
||
|
|
|
||
|
|
## Structure
|
||
|
|
|
||
|
|
- **Title:** technical, specific, bold. "How We Made 1,000 Animals Animate Without a Single Skeleton" not "Crowd Animation Update."
|
||
|
|
- **Opening:** state the problem (what stock Godot can't do), state our solution, give the numbers.
|
||
|
|
- **Body:** architecture, shader code, data flow, VRAM math, benchmarks. Ground everything in numbers.
|
||
|
|
- **Closing:** where to get it, what it drives (Ariki), related posts. No roadmap.
|
||
|
|
|
||
|
|
## Numbers rule
|
||
|
|
|
||
|
|
Every claim about performance, VRAM, or scale must cite a measured number. "60 FPS at 1,000 agents on M1 Pro" not "great performance." "1.6 MB per type" not "tiny VRAM."
|
||
|
|
|
||
|
|
## Code
|
||
|
|
|
||
|
|
Shader code and architecture diagrams are encouraged — this is a technical blog. But keep code blocks focused on the key insight, not the whole file.
|