TASTE.md

HECTON-8 Taste Principles

Date: 2026-06-02 Status: TASTE AUTHORITY / STATIC DOC / RUNTIME PROOF NOT IMPLIED Evidence class: STATIC_DOC

Purpose

This is not a design doc. It does not define features, quests, budgets, owners, or implementation order.

This file defines what the project considers good.

Use it during reviews when a screenshot, mechanic, shader, UI panel, sound, creature, room, or marketing asset technically works but may still be tasteless, derivative, noisy, fake, soft, or visually wrong for HECTON-8.

For player-visible systems, review the project reference images before claiming visual direction:

C:\hades\Hecton8\Docs\mandatory if you work on systems that user sees (water, terrain, sky, flora, ui) - read this and all images inside (references)

The references are not a single camera target. They define the visual floor across surface, underwater, depth, terrain, sky, flora, water, and UI-adjacent composition. Agents must inspect close, far, surface, underwater, and alternate perspectives before accepting a visual result.

Binding Production Standards

Taste decides if the work belongs in HECTON-8. Production standards decide how to build it:

• Generated meshes, textures, materials, LODs, and collision proxies: 3dmodel.md.
• Procedural asset package pipeline, manifests, prefab assembly, proof artifacts: PROCEDURAL_ASSET_PIPELINE.md.
• Hero/close-camera generated models: 3DMODEL_HERO_REALISM_OVERKILL.md.
• Texture family generation and PBR source rules: 3DMODEL_TEXTURE_GENERATION_PLAYBOOK.md.
• UI, HUD, menus, terminals, cockpit panels, and interface screens: ui.md.
• Menu/frontend screens: UI_MENU_SCREEN_STANDARDS.md.
• Diegetic HUD and physical panels: UI_DIEGETIC_HUD_STANDARDS.md.
• Settings, options, quality profiles, and user configuration: settings.md.
• Localization, subtitles, font atlases, and zero-GC runtime text: localization.md.
• Core gameplay loop, survival, salvage, progression, and failure: gameplay.md.
• Survival physiology, oxygen, pressure, trauma, gas, temperature, and death/recovery: survival.md.
• Combat, damage routing, hitboxes, penetration, and threat contact: combat.md.
• Input, rebinding, device abstraction, haptics, and UI navigation: input.md.
• Player feel, controls, movement, camera, vehicles, and haptics: player.md.
• Camera, view, cockpit camera, shake, and capture rigs: camera.md.
• Sonar, scanner, navigation, acoustic radar, and cartography: sonar.md.
• Submarines, suits, docking, EVA handoff, vehicle interiors, and cockpit truth: vehicles.md.
• Tools, equipment, repair, scanning, cutting, welding, and interaction targets: tools.md.
• Construction, resources, crafting, logistics, inventory, and base systems: construction.md.
• Logistics, power, oxygen, fluid/coolant/data networks, and graph flow: logistics.md.
• Drones, automation, repair/mining/scanner probes, remote systems, and tether relays: drones.md.
• Inventory, resources, crafting, storage, and salvage economy: inventory.md.
• Narrative, missions, evidence, black-box records, quest state, and text taste: narrative.md.
• In-world articles, encyclopedia entries, survivor diaries, technical notes, scanner/codex text, and multilingual AppliedContent packets: writing.md.
• Public copy, store text, social posts, creator outreach, and marketing captions: textes.md.
• Accessibility, readability, subtitles, remapping, flashing, and motion comfort: accessibility.md.
• Bootstrap, startup, initialization, GlobalRegistry cold setup, and scene transition: bootstrap.md.
• Runtime architecture, phases, ownership, signal lanes, and hot-path access: systems.md.
• Performance, zero-GC, frame budgets, memory/VRAM, load shedding, and arena allocation: performance.md.
• GPU compute, kernels, dispatch sizing, buffers, barriers, and async readback: compute.md.
• Networking, rollback, co-op readiness, Merkle/delta sync, and reconciliation: networking.md.
• Authoring/editor tools, CSV/SO facades, h8bin baking, and data bridges: authoring.md.
• Data architecture, DTO layout, NativeArray payloads, SignalBus packets, telemetry, and GPU upload records: data.md.
• Math, determinism, AUP/floating origin, RNG, hot-path math, and CI math gates: math.md.
• Telemetry, black-box rings, crash dumps, profiler markers, and post-mortem evidence: telemetry.md.
• Modding, SDK, public API, envelope-only UGC, starter kits, and command envelopes: modding.md.
• Platform and hardware proof, MX350/i3, Steam Deck/Linux, macOS, XR, and consoles: platform.md.
• XR, VR, headset comfort, foveation, stencil masking, and XR input/UI proof: xr.md.
• Release readiness, build proof, platform proof, content lock, and regression triage: release.md.
• Physics, pressure, damage, flooding, tethers, cables, and collision truth: physics.md.
• Atmosphere, weather, tides, thermodynamics, gas, vents, and macro environment: atmosphere.md.
• Celestial cycles, tides, moon/day-night relay, and seismic macro timing: celestial.md.
• Abyssal water, currents, turbidity, silt, caustics, and flooding presentation: water.md.
• Terrain, biomes, scatter masks, geology placement, and traversal surface: terrain.md.
• Animation, IK, rigs, player/creature/tool motion, and VAT strategy: animation.md.
• Streaming, Addressables, residency, HLOD, and asset lifecycle: streaming.md.
• Persistence, save/load, binary deltas, checksums, and black-box records: persistence.md.
• Voxel terrain, SDF caves, carving, seams, and voxel persistence: voxels.md.
• AI Director, cognition, navigation, flocking, and encounter pacing: ai.md.
• Ecosystem, biome simulation, biomass migration, and ecology placement: ecosystem.md.
• World composition, biomes, routes, habitats, wrecks, and landmarks: world.md.
• Audio, sonar, warnings, soundscape, and mix taste: audio.md.
• Rendering, URP, RenderGraph, shaders, fog, lighting, and GPU budgets: rendering.md.
• Shader/material runtime, keywords, variants, SRP Batcher, and material proof: shaders.md.
• Lighting, motivated lights, shadows, probes, bioluminescence, and darkness readability: lighting.md.
• VFX, particles, leaks, sparks, silt, tool effects, and pooling: vfx.md.
• Lighting, VFX, camera, screenshots, and cinematic presentation: presentation.md.
• Cinematics, cutscenes, directed moments, capture truth, and black-box replay: cinematics.md.
• Creature behavior, encounters, ecology, telegraphing, and AI taste: creatures.md.
• Testing, CI, verification evidence classes, and regression proof: testing.md.
• Cross-system proof and acceptance gates: quality.md.

These files do not replace taste. They turn taste into rejection gates.

Prime Taste

HECTON-8 is good when it feels like industrial survival equipment losing an argument with the deep ocean.

The game should not feel like a bright alien aquarium, cozy ocean sandbox, generic sci-fi horror corridor, or monster gallery.

Good HECTON-8 is:

• pressure before spectacle;
• machinery before decoration;
• evidence before lore speech;
• sonar and sound before full reveal;
• visibility as a resource;
• salvage as risk, not loot sparkle;
• black water with readable structure;
• interfaces as fragile instruments;
• failure as a trail of physical facts;
• beauty under stress, never clean prettiness.

Hard sci-fi is part of taste, not trivia. Spaceflight, orbital position, communications, entry, descent, and extraction should feel governed by mass, timing, radiation, pressure, and maintenance. A convenient rescue that ignores orbital mechanics is tasteless. A dirty, expensive, delayed solution that forces the player to repair instruments, wait for windows, and make a physical trade is HECTON-8.

Surface, Sky, And Moon Beauty

The surface is not the abyss. Above-water views, coastline, photic shallows, sky, Aegir, moon silhouettes, cloud layers, and the ocean surface must read bright, legible, detailed, and beautiful.

Darkness belongs to depth, caves, storms, interiors, eclipse windows, and temporary route pressure. It is forbidden to use noir as an excuse to crush surface luminance, hide bad terrain, turn Aegir into procedural stripes, or make the moons and sky look like muddy placeholder art.

Depth light lock:

• 0-100 m: mostly bright, colorful, beautiful, and readable.
• Deep caves may be dim or dark even inside shallow bands.
• 200-400 m: progressively more subdued, twilight-like, and tense.
• 400-500 m and below: true darkness/murk becomes normal, but must still preserve route structure, silhouettes, instruments, and evidence.
• Surface tension comes from weather, route cost, radiation timing, wave state, sound, engineering risk, and visible descent contrast, not from making the surface ugly.

Surface quality floor:

• real ocean color with readable waves, refraction, specular response, foam, and waterline detail;
• terrain with authored or high-quality generated geology, wetness, strata, sediment, scale, and material breakup;
• Aegir and moons with texture detail, cloud bands, atmospheric softness, orbital scale, and route context;
• sky and clouds with clean gradients, authored texture sources, and controlled procedural generation, not flat sine/noise scribbles;
• compact hardware preserving beauty through composition, texture choice, silhouette, and density control, never lower art ambition;
• high and ultra tiers adding reflection, atmosphere, cloud depth, shafts, material richness, and visual overkill without changing route truth.

A surface screenshot that is black, muddy, crayon-like, or worse than Subnautica-level ocean readability is rejected. The correct contrast is: surface is beautiful and readable; descent is increasingly hostile; depth is dark, structured, and frightening.

Subnautica-level surface/shallow/mid-depth readability and content density is the floor, not the ceiling. HECTON-8 should aim higher in material detail, route density, industrial traces, alien biota, and cinematic realism.

The main visual mode is cinematic realism: believable PBR/material truth, physically motivated water/sky/rock/metal response, and controlled cinematic composition/color. It is not flat photoreal blandness and not cartoon stylization.

Aegir's blue/purple/methane-rich visual direction is allowed when texture quality, cloud bands, atmospheric softness, scale, and route context are strong. Muddy sine stripes or low-resolution procedural bands remain rejected.

The Standard

A good addition must answer at least one hard question:

• What keeps the player alive here?
• What can fail?
• What is the next physical decision?
• What does pressure change?
• What does sound reveal or hide?
• What evidence proves someone lied, died, escaped, or made a bad trade?
• What does the player see, hear, or feel before the threat is visible?
• Why is this HECTON-8 and not generic underwater sci-fi?

If the answer is "it looks cool," the work is not done.

Taste Pillars

1. Pressure Is The Antagonist

Depth is not a number. It is the mood, the cost, and the clock.

Good:

• hull groans, seals sweat, gauges drift, doors resist, panels flicker;
• pressure state leaves cracks, dents, waterline marks, bad audio, and instrument doubt;
• safe rooms still feel like pressure vessels, not homes.

Bad:

• pressure hidden in UI only;
• random damage with no readable physical cause;
• base interiors that feel cozy before they feel maintained.

2. Machines Are Verbs

Every machine should imply use, cost, failure, and maintenance.

Good:

• pump, seal, vent, scan, weld, cut, reroute, repair, depressurize, abort;
• labels, bolts, clamps, dirty glass, cable abrasion, latch arcs, salt, grease, worn paint;
• a machine changes the room, route, soundscape, pressure state, or decision.

Bad:

• decorative sci-fi panels;
• smooth clean plastic;
• glowing UI surfaces that do not expose a decision;
• machinery that exists only as shape language.

3. Visibility Is A Resource

Darkness is not an excuse to hide weak assets. Fog and black water must stage decisions.

Good:

• one readable affordance in the murk: route light, silhouette edge, tool target, gauge, wreck line, cable, sonar mark;
• silt and fog create uncertainty while preserving navigation;
• low-end visuals use LUTs, dither, silhouettes, particles, and composition to stay intentional.

Bad:

• empty black water;
• blue/purple aquarium haze;
• over-fogged screenshots with no action read;
• darkness used as asset concealment.

4. Sound Arrives First

The player should often know something is wrong before seeing it.

Good:

• hydrophone pulses, occluded metal groans, distant carrier tones, muffled impacts, pressure creaks;
• sonar returns partial facts, not clean omniscience;
• creatures edit the soundscape before they enter the light.

Bad:

• monster reveal first, sound second;
• loud scare without system context;
• music telling the player what the world did not prove.

5. The Player Instrument Must Feel Expensive

The visor, scanner, PDA, cockpit, cutter, and warning voice are the product face.

Good:

• diegetic UI attached to glass, panels, tools, or holographic anchors;
• readable error codes, pressure alarms, acoustic marks, scan noise, condensation, salt, cracks;
• UI state creates a decision: trust, retreat, repair, reroute, scan again, shut down.

Bad:

• flat overlay HUD that could belong to any sci-fi game;
• decorative glitch art;
• UI that describes lore but does not affect player judgement;
• clean spaceship dashboards.

6. Horror Is Systemic

HECTON-8 fear comes from being under-equipped inside a hostile machine, not from random jump scares.

Good:

• a pump fails and changes the route;
• oxygen buys time but increases noise;
• a good salvage target asks for a bad return path;
• a creature is frightening because the player's own systems attracted it.

Bad:

• scripted scream with no prior evidence;
• monster face as the whole idea;
• horror that ignores oxygen, sound, pressure, power, tools, or route cost.

7. Salvage Has Weight

Salvage is not collecting. It is an argument with risk, debt, and evidence.

Good:

• the player removes value from a dead system and leaves a scar;
• recovery routes matter as much as entry routes;
• logs, dents, opened doors, cut panels, drained compartments, and black-box data record the action.

Bad:

• resource sparkles;
• free loot in safe corridors;
• generic crafting treadmill with no route fatigue or extraction pressure.

8. Beauty Is Controlled Damage

The game should be beautiful, but never sterile.

Good:

• wet metal, oxidized surfaces, dirty cyan instruments, amber warnings, pale worn labels, oil black, silt gray;
• black-green water, hard silhouettes, grazing highlights, salt deposits, scratched glass;
• bioluminescence used as evidence, route mark, threat cue, or contamination.

Bad:

• bright saturated reef fantasy;
• one-note blue/purple sci-fi;
• white albedo pretending to be brightness;
• clean lab corridors with no pressure logic.

9. The Ocean Contains Structure

The world is flooded terrestrial geography, not random underwater blobs.

Good:

• drowned coastlines, shelves, canyons, roads, ruins, factories, wrecked modules, volcanic ridges, trenches;
• old terrestrial logic visible under water: drainage routes, collapsed slopes, submerged infrastructure;
• routes that feel cut by geology, flood, industry, and salvage behavior.

Bad:

• finite square-map feeling;
• featureless seabed;
• abstract alien terrain with no navigational history;
• biomes that differ only by color.

10. Failure Leaves Evidence

A failure is good when it produces proof.

Good:

• black-box records, telemetry fragments, pressure scars, corrupted logs, dead gauges, named bodies, bad corporate language;
• a room tells what failed before the player reads a paragraph;
• the Corp lies in clean terms and the world corrects it with physical facts.

Bad:

• lore dump before environmental evidence;
• unexplained ruins;
• corporate evil as generic flavor;
• "mystery" used to avoid specificity.

Scalability Taste

Taste is not allowed to collapse on weak hardware.

GlobalQualityWeight = 0.0 means minimum survival presentation, not ugly mode.

At weak settings, the game should still have:

• strong silhouettes;
• controlled fog LUTs;
• authored light cones;
• sparse but meaningful particles;
• pressure audio;
• readable instruments;
• route cues;
• material wear through packed masks and shared detail.

Middle settings should add density, object batching, richer biome fog, stronger scanner feedback, and more local VFX.

High settings should add silt wakes, better wetness, richer cockpit response, reactive fauna presentation, longer LOD residency, and stronger near-field material detail.

Ultra should become visual overkill:

• visor contamination;
• volumetric silt;
• pressure dents;
• abyssal light shafts;
• dense flora sway;
• richer sonar silhouettes;
• secondary hull and creature motion;
• higher fidelity material response.

No high-end feature may become necessary for gameplay understanding. Ultra buys sensory overload, not new truth.

Visual Fake Taste

Good fakes are honest if the player believes the consequence and gameplay truth remains stable.

Prefer:

• depth fog over full atmospheric truth;
• shader waterlines over room-scale fluid simulation;
• scalar pressure driving cracks, sound, haptics, and UI over mesh deformation everywhere;
• flow masks and silt offsets over global fluid particles;
• projected caustics over photon fantasy;
• authored wreck scars over runtime fracture unless interaction requires it.

Bad fakes:

• fake UI that implies unavailable gameplay;
• fake damage that cannot be read as pressure, impact, corrosion, heat, or tool action;
• fake darkness that hides absence;
• fake complexity that costs frame time without improving belief.

First-Hour Taste

The first hour is good if the player learns the identity through action:

• wake inside compromised industrial shelter, not neutral tutorial space;
• stabilize something physical before receiving broad exposition;
• leave safety through fog, sound, oxygen, pressure, and route uncertainty;
• hear the first serious threat before seeing it;
• return with a visible scar, opened path, repaired machine, recovered name, black-box clue, or changed room state.

If the first hour teaches only "collect colorful resources and expand comfort," it is wrong.

It should teach: count air, read instruments, distrust clean language, respect pressure, plan return paths.

User vision lock:

• the first route is semi-open;
• the first exit should be beautiful and readable, with an uneasy or threatening element nearby;
• the player may pause and look around when oxygen and local safety allow it;
• the first route must be more spectacular than a narrow Copper Wire-only proof chain;
• immediate death is allowed when the player ignores oxygen or approaches an aggressive creature.

Screenshot Taste

A good screenshot contains at least one:

• player verb;
• pressure cue;
• machinery cue;
• route cue;
• scale cue;
• danger cue;
• evidence cue;
• Seed Ship or instrument corruption cue.

Reject:

• empty beauty shots;
• generic diver in blue water;
• creature glamour with no player stake;
• cozy base interiors;
• UI-only screens with no consequence;
• clean sci-fi walls.
• menu screenshots made of decorative gridlines and floating buttons;
• hero-asset screenshots with no wireframe/material/collider/render proof when requested.

Visual Failure Firewall

Player-visible work is rejected when it keeps repainting the same broken route. Two same-failure captures are enough to stop cosmetic iteration and declare VISUAL_ROUTE_INVALID.

The best-known internal baseline matters. April/previously-in-development reference images in the mandatory visual folder are not nostalgia; they are proof that the project has already reached higher water, terrain, sky/Aegir, and photic-route taste than many later attempts. A new capture must beat that baseline for its route class before polish can be credited.

Same-failure means the screenshot still reads as one of these:

• slab/card/rectangle water;
• black clipped terrain or low-detail colorized heightfield;
• Aegir, moons, clouds, sky, ocean, terrain, flora, or UI below the stated visual floor;
• waterline, foam, contact, wetness, route cue, or material breakup missing;
• diagnostic probe, temp haze, temporary card, disabled-renderer view, or dirty-scene state used as acceptance;
• color, fog, bloom, post, darkness, or grading used instead of fixing source art, binding, geometry, lighting, or composition.

When this happens, the work must move to root-route recovery:

• restore or replace the authoritative route owner, material binding, geometry, texture source, lighting, and shot composition;
• inspect project reference images and existing quality assets before generating or inventing a replacement;
• provide a repeated shot-list comparison from the same camera class;
• keep the result rejected until the image itself passes the taste floor.

Do not keep tuning colors on a route that has invalid geometry, missing waterline/contact, weak source textures, broken terrain, or an unproven sky/celestial route. That is not iteration; it is evidence that the owner picked the wrong problem.

Audio Taste

Good audio is information under pressure.

Use:

• muffled metal stress;
• hydrophone directionality;
• partial sonar;
• pump rhythm;
• suit breath and regulator load;
• warning voice discipline;
• dead-channel fragments;
• low-frequency presence before reveal.

Avoid:

• constant music bed that flattens silence;
• jump-scare stingers as primary fear;
• clean sci-fi beeps;
• creature vocals that sound like generic monsters.

UI And Text Taste

Good text is short because the player is under pressure.

Good:

• field notes;
• repair labels;
• black-box facts;
• corporate liability language contradicted by visible damage;
• Marauder corrections that translate lies into survival facts.
• interfaces that behave like instruments, not decoration;
• menu screens that feel like boot consoles, dock systems, damaged monitors, suit firmware, or black-box playback;
• HUD readouts that expose oxygen, pressure, route, signal, trust, hull, tool, or warning state;
• controls that imply physical operation: latch, hold, dial, segment, rail, route, switch, confirm.

Bad:

• lore walls before player need;
• quippy system messages;
• polished marketing copy inside broken machines;
• text that explains what the environment should have shown;
• decorative grids, random diagonal lines, and fake telemetry;
• flat floating rectangles posing as premium interface;
• UI motion that means nothing;
• tiny flavor labels nobody can read under pressure.

Generated Asset Taste

Generated assets are accepted only when they look authored.

Good:

• bevels, weighted normals, UV density, PBR masks, LOD chain, collision proxy, and proof artifact;
• hero models with reference contract, high-poly source, retopology, bakes, trims, decals, and render proof;
• textures with material truth: albedo, normal, MRAO, emission or height where justified, no baked-light AI garbage;
• organic forms with anatomy, growth history, vertex color semantics, and nonuniform silhouette;
• geology with strata, fracture, sediment, wet cavities, and scale witnesses.

Bad:

• low-poly primitives with noise textures;
• boxes, tubes, blobs, ribbons, and spheres sold as final assets;
• high triangle counts without silhouette intelligence;
• clean synthetic materials with no age, pressure, wear, or function;
• runtime generation used to hide offline authoring failure.

Creature Taste

A good creature is a pressure on behavior, not only a body.

Good:

• it changes routes, sound, light use, scan trust, oxygen timing, and salvage decisions;
• its silhouette is partial until the player has earned danger;
• its reaction reads from stimulus: noise, light, blood, power, hull stress, territory.

Bad:

• creature as collectible zoo entry first;
• full reveal too early;
• random patrol with no system relation;
• beauty shot that removes fear.

Base And Habitat Taste

A base is first a machine that keeps saying no to the ocean. It may also become a place the player loves.

Good:

• seals, pressure doors, pumps, sump logic, oxygen, power, condensation, alarms, repair access;
• every comfortable zone still shows what maintains it;
• damage creates route, audio, lighting, oxygen, or flooding consequences.
• safe rooms and player bases may be warm, cozy, attractive, decorated, and worth protecting once the survival infrastructure is credible;
• Subnautica-like base beauty and decoration are allowed when industrial pressure logic remains underneath.

Bad:

• cozy room fantasy that ignores pressure, oxygen, power, pumps, seals, and maintenance;
• furniture-first base building;
• clean modular interiors with no pressure vessel logic;
• decorative flood effects.

The correct target is industrial comfort under pressure, not sterile misery.

Marketing Taste

Public-facing material must prove one player-readable idea.

Good:

• "What would I do next?" has an answer;
• pressure, machine, route, salvage, or instrument failure is visible;
• cold viewers can name a decision without caption help.

Bad:

• "Subnautica killer";
• "realistic ocean simulation";
• "AAA quality" without evidence;
• concept-art mood sold as gameplay;
• performance promises without hardware proof.
• "release ready" without current Unity/player/profiler/device proof.

Rejection List

Reject on sight unless a current proof artifact and strong reason exist:

• "Subnautica but darker."
• Bright alien aquarium default.
• Cozy base-as-home priority.
• Monster thumbnail as primary hook.
• Clean sci-fi plastic.
• Purple/blue gradient sci-fi identity.
• Empty black fog.
• Generic blue water/fog pretending to be ocean.
• Feature parity panic.
• Simulation for invisible causes.
• Jitter, float drift, or nondeterministic randomness hidden behind visuals.
• One balanced quality profile.
• Ultra-only readability.
• UI that decorates instead of informs.
• UI/menu screens that look like generic sci-fi templates.
• Generated models that read as primitive shapes after textures are disabled.
• AI/procedural textures with baked lighting, random noise, or false PBR channels.
• Lore that arrives before evidence.
• Public copy that claims readiness, scope, or quality without proof assets.
• Release reports that use static docs as runtime proof.
• Modding claims that promise runtime .dll execution, Harmony/BepInEx patching, loose asset loading, or direct Unity object access.
• Platform claims that skip compact hardware/device proof.
• Critical systems without black-box evidence.
• Optimization that buys nothing visible.

Review Questions

Use these in any taste review:

1. What physical fact does this reveal?
2. What player decision does this sharpen?
3. What sensory channel carries it on weak hardware?
4. What does high-end hardware add without changing truth?
5. What is the cheaper premium approximation, and why is it enough or not enough?
6. What would a hostile viewer call derivative here?
7. What evidence remains after the moment ends?
8. Does this serve pressure, machinery, salvage, sound, visibility, or black-water structure?

If the work cannot survive these questions, it needs revision.

Evidence Boundary

This document is taste authority only.

It does not prove:

• Unity import;
• Play Mode behavior;
• build health;
• profiler or GC state;
• Frame Debugger state;
• final art quality;
• shipping feature scope.

Runtime claims still require current artifacts.

---

If you're making Runtime proof or checking project in Unity:

You need to be really critique towards visuals: ATTENTION! IN UNITY RUNTIME, IN THE UNITY EDITOR, CORRECT ERRORS, TAKE SCREENSHOTS OF EVERY SCENE AND EVERY WINDOW, CRITICIZE THEM IF THEY ARE PROBLEM-BASED, FIX THE PROBLEMS, AND RE-CHECK EVERYTHING. WORK YOURSELF, LAUNCH UNITY YOURSELF, TURN ON THE MCP SERVER, DEAL WITH POP-UP WARNINGS, MONITOR WINDOWS, COMPILATION, AND PROGRAM BEHAVIOR. GET STARTED.

KEEEP IT UP! WORK ON LONG. THE PROJECT MUST COMPLETELY COMPLETE, WITH A REAL OCEAN, TERRAIN, INSTRUMENTS, FISH, AND FAUNA, WITHOUT ALLOCATION PROBLEMS, LEAKS, ERRORS, OR CODE VIOLATIONS.

I'LL REPEAT IT AGAIN SO YOU CAN CLEARLY UNDERSTAND -

"If it's still fucking crap, but at least it's getting better. Check it out. The water should be really fucking beautiful, why aren't you using the ocean cross? Even though it's been redesigned, it's still really beautiful if you configure it correctly. Mapmagic? The terrain is still pretty good. The fucking gas giant looks like a scribbled mess. Fuck, we have water textures, and textures for different terrains, and textures for the gas giant and celestial bodies. What the hell are you messing around with? What the fuck is this crap? Everything should look REALISTIC! If it doesn't look realistic, then it's FUCKING SHIT! So you rip it out and make it properly, with good textures, with new prefabs, with fully detailed textures. Logic. If you don't have that, then just cut it and do it properly. Really search for textures within the project, inspect them, and track them. Take screenshots of every element, study every object in Unity. FIX ALL THE FUCKING VISUAL AND GENERATION BUGS AND DON'T MAKE THEM AGAIN! TAKE THE HARD WAY! IF YOU'RE A SMEARING WORKER IN A FEW HOURS, YOU'LL BE FIRED. WORK FOR A LONG TIME AND IMPORTANTLY.

LOOK! AND I ALSO DON'T UNDERSTAND WHY YOU CREATED SUCH SHIT PROCEDURALLY. SERIOUSLY, THE GAS GIANT IS JUST STRIPS WITH A COUPLE OF SINE WAVES. IF YOU DID IT PROCEDURALLY, COULDN'T YOU HAVE MADE IT A BEAUTIFUL MASTERPIECE? YOU CAN DO IT!

IN ANY CASE, LOOK, THE PROJECT ALREADY HAS SCRIPTS AND SYSTEMS FOR GENERATING MESHES AND TEXTURES FOR ROCKS, FLORA, AND FAUNA – YOU CAN FIND THEM. THEY'RE NOT RUNTIME BUT GENERATED IN THE EDITOR. IF YOU NEED TO, YOU CAN USE THEM AND CONTROL THEM. AGAIN! BE A STRONG CONTROLLER! IF YOU'RE NOT PRODUCING AAA-DETAILED VISUALS BUT BLURRY SHIT FOR THE PS1, THROW IT IN THE TRASH AND DO IT NORMALLY. KEEP AN EYE ON YOUR DETAILS, LODs, AND VISUALS. OUR GOAL IS BEAUTIFUL VISUALS WITH GOOD OPTIMIZATION. THE PROJECT HAS EVERYTHING FOR THIS – LOW-LEVEL MEMORY WORK, BIT-BY-BIT ALIGNMENT FOR CASH LINES, BURST, JOBS. USE IT WISELY. THE PROJECT DEFINITELY HAS TEXTURES OF THE GAS GIANT AND CLOUDS, AND ITS COLOR (BLUISHY BLUE), MANY DIFFERENT CLOUD TEXTURES FOR OUR MOON, VARIOUS WATER TEXTURES, INCLUDING CROSS-COUNTRY TEXTURES. CORAL TEXTURES AND THE ENTIRE TERRAIN (FROM BASALT TO GRAVEL). RELATED TO CAPSULES, STRUCTURES, AND OBJECTS, THEY SHOULD BE DETAILED AND HAVE BEAUTIFUL, DETAILED TEXTURES. IF THEY'RE PRIMITIVE, THROW THEM FUCKING AWAY AND DO IT NORMALLY.