---
title: "Cum facem un joc în Godot"
description: "Construim SOLOMONAR, un joc folk-horror la persoana întâi, într-un sat din Maramureș, pe parcursul a șapte zile. Agenții scriu cea mai mare parte, iar un om decide. Metoda se sprijină pe trei decizii luate din prima zi, pe o lume care se poate verifica fără ecran și pe o singură regulă: nicio verificare automată nu primește încredere până nu am văzut-o picând pe o lume stricată intenționat."
date: 2026-10-11
lang: ro
canonical: https://goingstellar.ro/ro/metode/cum-facem-un-joc-in-godot/
author: Going Stellar
publisher: GOING STELLAR S.R.L.
topic: Jocuri / Godot
license: CC BY 4.0
alternate_en: https://goingstellar.ro/methods/how-we-make-a-game-in-godot/
---

# Cum facem un joc în Godot

*Construim SOLOMONAR, un joc folk-horror la persoana întâi, într-un sat din Maramureș, pe parcursul a șapte zile. Agenții scriu cea mai mare parte, iar un om decide. Metoda se sprijină pe trei decizii luate din prima zi, pe o lume care se poate verifica fără ecran și pe o singură regulă: nicio verificare automată nu primește încredere până nu am văzut-o picând pe o lume stricată intenționat.*

> Jocuri · Godot · 2026-10-11 · https://goingstellar.ro/ro/metode/cum-facem-un-joc-in-godot/

## Pe scurt

- Într-un joc construit cu agenți AI, nicio verificare automată nu primește încredere până nu a fost văzută picând pe o lume stricată intenționat.
- O simulare Godot scrisă ca modul de date simplu, fără noduri, cameră și input, se poate testa automat; una încâlcită în noduri, nu.
- Fixarea unei axe din spațiul de stări al jocului, de exemplu o singură vreme pe zi, micșorează matricea de testat, pe când reîmpachetarea acelorași combinații nu o micșorează.
- Capturile de pe un server fără placă grafică prind regresii de randare, dar nu aprobă nimic; verdictul vizual final îl dă un om, pe randatorul jucătorului.
- Agenții nu comprimă partea omului care conduce jocul: reglajul, cititul cu voce tare al replicilor și judecata culturală asupra asseturilor se pun în plan de la început.

## La ce folosește

SOLOMONAR e un joc folk-horror la persoana întâi, făcut în Godot 4. Ajungi într-un sat din Maramureș, ai șapte zile, o fată a fost găsită moartă la hotarul dintre două parcele, iar satul are deja un cuvânt pentru ce s-a întâmplat. Atât spune din poveste pagina noastră publică, și atât spunem și aici.

Articolul e despre cum se produce jocul. Un om conduce, joacă și judecă; agenții scriu cea mai mare parte din cod, din unelte și din teste. Estimarea noastră pentru tot jocul e de aproximativ **2.750 de ore**, de la o primă estimare de circa **6.000**, după mai multe runde de verificare adversarială. N-am tăiat nicio funcție ca să ajungem acolo. S-a schimbat metoda, nu ce face jocul.

Cam **un sfert** din ore aparțin omului care conduce și nu se pot muta la o mașină sau la altcineva: reglajul, cititul cu voce tare al fiecărei replici, judecata culturală asupra asseturilor. Agenții nu comprimă partea asta, așa că o punem în plan de la început, în loc să sperăm că se micșorează.

## Trei decizii din prima zi

**1. Simularea rulează fără randare.** Injecția de taste în Godot headless e defectă din februarie 2023, iar problema e încă deschisă, deci un joc fără ecran nu poate fi condus prin input. De aceea simularea satului e un modul de date simplu, condus printr-un API cu nume (`tick(dt)`), fără noduri, fără arbore de scenă, fără cameră și fără input. Dacă simularea e încâlcită în noduri, nu se poate testa nimic automat, iar agenții nu mai câștigă niciun timp la testare.

**2. Înghețăm versiunea motorului.** Facem un proiect gol cu toate addon-urile, îl deschidem o dată pe mașina de dezvoltare și o dată pe un server, și abia apoi începem. Folosim Godot **4.6.3**, pentru că 4.6.2 are o regresie (issue 118110) în care `TIME` folosit într-un shader de cer strică lumina.

**3. Strângem spațiul de stări, nu îl reîmpachetăm.** Fiecare dintre cele șapte zile are o singură vreme, fixă. Cu mai multe vremi posibile pe zi, combinațiile de zi, vreme și stare socială pot fi doar eșantionate de un testator; cu o vreme pe zi, tot spațiul se parcurge complet într-o singură rulare de noapte. Am crezut la început că „o zi înmulțită cu N stări” iese mai ieftin decât N zile. Nu iese: un joc cu exact arhitectura asta, în 2D, a durat șapte ani. Matricea rămâne aceeași oricum ai împacheta-o. O micșorezi doar fixând o axă.

## De la documentul de design la versiunea jucabilă

Fiecare subiect are documentul lui: arhitectura, folclorul atestat din spatele fiecărei mecanici, licența vocilor, lista asseturilor interzise.

O parte din design se execută. La pornire, proiectul își verifică singur bugetele și promisiunile: **10–12** scene în tot satul și **7–8** interioare; fiecare probă are două uși, una în care ți se spune și una în care vezi singur; nicio concluzie nu atârnă de o singură sursă; iar un rezolvitor dovedește că ancheta se poate duce la capăt în cele șapte zile, pe ambele drumuri.

Conținutul stă în tabele, nu în scene. Un sătean e un rând și se adaugă în **15–40 de secunde**, fără să atingi vreo scenă. O regulă trimite la un predicat înregistrat după nume, niciodată la o expresie scrisă într-un șir. Granița dincolo de care designul pe date devine greșeală e momentul în care începi să scrii un limbaj: condițiile din șiruri n-au tipuri, n-au urmă de stivă și nu se pot testa.

Ordinea de lucru: deciziile de formă, în scris; descărcarea asseturilor cu licență liberă, fiecare cu fișierul de licență lângă el; o sondă scurtă de hardware; o buclă vizuală în care agentul apasă Play și citește eroarea; simularea pură, cu rulări lungi fără ecran; și un teleportor care încarcă direct o stare a jocului, după nume. Azi, rezultatul e un sat prin care poți umbla pe mașina noastră de dezvoltare, bate la uși și striga la porți. Strigatul e public: vecinii aud pe cine cauți.

## Capcane de motor care nu dau nicio eroare

**`scaled()` mută originea.** În Godot 4, `Transform3D.scaled()` lucrează în cadrul părintelui și înmulțește și originea, nu doar baza; `scaled_local()` atinge doar baza. Un script de așezat copaci chema `scaled()` după ce pusese poziția, iar copacii au ajuns, măsurat, până la **56 m** în aer, alții pe jumătate îngropați. Același apel e inofensiv când originea e zero, de aceea „l-am mai folosit și a mers” nu dovedea nimic.

**Două WorldEnvironment, unul folosit.** Addon-ul Sky3D extinde `WorldEnvironment`. Scena noastră avea deja unul, deci erau două noduri valide, iar Godot randa cu al nostru: fundal de culoare plată, fără cer. Cerul, soarele, luna și norii erau ignorate, iar treimea de sus a fiecărui cadru era un dreptunghi plat. Nicio eroare, niciun avertisment. Un agent a găsit cauza comparând ID-ul resursei de mediu active cu cel al fiecărui nod. Reparația: ambele folosesc aceeași resursă `Environment`. Din aceeași familie: o funcție care preda cerul și ieșea cu `return` înainte să aplice ceața și ocluzia ambientală, deci setările acelea nu ajungeau niciodată pe ecran.

**Fără LOD pe `.obj`.** Godot generează automat niveluri de detaliu la import, dar nu pentru fișierele `.obj`; documentația o spune. Terenul nostru era `.obj` și n-avea niciun nivel de detaliu. Acum exportăm totul în glTF.

**Cele mai mici.** Ceața de înălțime din Godot nu are termen de distanță, așa că setările noastre puneau între **28%** și **53%** ceață pe pământ la zero metri. `Expression` cu `const_calls_only` nu blochează funcțiile utilitare, deci o condiție poate chema `randf()` și strică pe tăcute determinismul unei rulări lungi; noi permitem doar funcțiile dintr-o listă, verificată la parsare. Godot cade pe Vulkan software (issue 82435), deci capturile de pe un server fără placă grafică folosesc alt randator și sunt alte imagini.

## Cum testăm un joc 3D cu agenți

Sondele și capturile rulează într-o copie a motorului pe care sistemul de operare n-o aduce niciodată în față, cu driver audio fals, randând într-un viewport din afara ecranului. Nu iau focusul și nici mausul omului care lucrează.

Un verificator al lumii compară scara fiecărui animal cu înălțimi reale, găsește tot ce intră în pereți, plutește sau e îngropat și verifică lățimea porților. L-am testat repunând intenționat bug-urile reparate: a raportat **8** probleme, iar cu reparațiile a spus că lumea e curată. Asta e regula noastră fixă: nicio poartă nu intră în lucru până n-a fost văzută roșie pe o lume stricată intenționat. Din **nouă** porți, așa cum erau scrise prima dată, **trei** ar fi intrat în producție mințind.

Verificăm și verificatorul. Într-o noapte de optimizat umbre, sonda noastră desena o configurație pe care jocul nu o desenează: **80,8%** din umbra pe care o măsuram nu exista în joc. Acum, înainte de orice verdict de randare, dovedim că sonda și jocul numără același lucru.

Capturile de pe server prind regresii, dar nu aprobă nimic. Verdictul vizual final îl dă un om, pe mașina cu placă grafică. Ca omul acela să nu devină o coadă de așteptare, agenții nu vin cu o întrebare, ci cu o comparație: trei variante de ceață pe același cadru, zece versiuni ale aceleiași replici.

## Unde am greșit

Am presupus că agenții vor grăbi tot proiectul de **1,8** ori. Verificat pe tipurile de muncă din joc, factorul e de circa **1,5**: mare la cod și text, **1,0** la judecata artistică și poate sub 1 la reglaj, pentru că mai mult cod pe oră înseamnă și mai mult de reglat pe oră.

Am optimizat umbre o noapte întreagă pe cifre false și am dat de două ori un verdict greșit. Costul real al unui cadru era în altă parte: pământul **55%**, ocluzia ambientală **31%**, vegetația **1,9%**, umbrele **0,3%**. Am căutat vina pozelor spălate în tonemap și în saturație înainte să calculăm formula ceții.

## Unde suntem, spus direct

Construit: un sat prin care se poate umbla, cu viață zilnică, săteni care vorbesc și verificări automate, pe mașina noastră de dezvoltare. Neconstruit: o lansare. SOLOMONAR nu are jucători și nici recenzii, iar nimic de aici nu afirmă altceva. Lista de reparat de la ultima parcurgere mai avea puncte deschise, printre ele o roată de moară care trece prin clădire, geometria turlei bisericii, copacii și cele mai multe texturi. Primul livrabil planificat e o singură noapte completă, nu toată săptămâna.

Mai spunem un lucru: un studiu separat al pieței pentru jocuri de felul ăsta a concluzionat împotriva unui joc construit ca afacere. SOLOMONAR e o metodă de producție pusă la încercare și așa trebuie citit.

## Listă de verificare

**1.** Poate rula simularea fără noduri, cameră și input? **2.** E versiunea motorului fixată și verificată față de regresiile cunoscute? **3.** Ce axă a spațiului de stări ai fixat? **4.** A fost văzută fiecare poartă automată picând pe o lume stricată? **5.** Desenează sonda și jocul același lucru? **6.** Dă un om verdictul vizual final, pe randatorul jucătorului? **7.** Folosești `scaled_local()` după ce ai pus originea, o singură resursă `Environment` și glTF în loc de `.obj`?

## Întrebări și răspunsuri

### Cum testezi automat un joc 3D făcut în Godot?

Testarea automată a unui joc 3D în Godot începe cu o simulare care rulează fără randare, condusă printr-un API cu nume, nu prin input, fiindcă injecția de taste în Godot headless e defectă. Sondele și capturile rulează în afara ecranului și nu iau focusul. Un verificator al lumii compară scara obiectelor cu înălțimi reale, găsește ce intră în pereți, plutește sau e îngropat. Fiecare astfel de poartă trebuie văzută întâi roșie pe o lume stricată intenționat.

### De ce mută Transform3D.scaled() obiectele în Godot 4?

În Godot 4, Transform3D.scaled() lucrează în cadrul părintelui și înmulțește și originea, nu doar baza, așa că un apel făcut după ce ai pus poziția mută obiectul. Într-un script de așezat copaci, unii copaci au ajuns în aer, alții pe jumătate îngropați. Transform3D.scaled_local() atinge doar baza. Același apel scaled() e inofensiv când originea e zero, de aceea faptul că a mers înainte nu dovedește nimic.

### De ce nu apare cerul în Godot, deși nu primesc nicio eroare?

Cerul din Godot poate dispărea fără eroare când scena are două noduri WorldEnvironment, de exemplu când un addon de cer extinde WorldEnvironment, iar scena avea deja unul. Godot randează doar cu unul dintre ele, așa că cerul, soarele, luna și norii pot fi ignorate fără niciun avertisment. Cauza se găsește comparând ID-ul resursei de mediu active cu fiecare nod, iar reparația e o singură resursă Environment comună.

### E mai bine .obj sau glTF pentru modele în Godot?

Pentru modele în Godot e mai bine glTF decât .obj. Godot generează automat niveluri de detaliu la import, dar nu pentru fișierele .obj, iar documentația o spune explicit. Un teren importat ca .obj rămâne deci fără niciun nivel de detaliu, fără vreun avertisment. Exportul întregului conținut în glTF evită această pierdere tăcută de performanță.

### Cât de mult grăbesc agenții AI dezvoltarea unui joc?

Agenții AI grăbesc dezvoltarea unui joc inegal: factorul presupus de 1,8 a ieșit de circa 1,5 după verificarea pe tipurile reale de muncă. Câștigul e mare la cod și text, de 1,0 la judecata artistică și poate sub 1 la reglaj, pentru că mai mult cod pe oră înseamnă și mai mult de reglat pe oră. Partea omului care conduce jocul nu se poate muta deloc la agenți.

## Cum se citează

**Citare:** Going Stellar (2026). *Cum facem un joc în Godot*. GOING STELLAR S.R.L.. https://goingstellar.ro/ro/metode/cum-facem-un-joc-in-godot/

```bibtex
@misc{goingstellar2026how,
  title  = {Cum facem un joc în Godot},
  author = {{Going Stellar}},
  year   = {2026},
  url    = {https://goingstellar.ro/ro/metode/cum-facem-un-joc-in-godot/},
  note   = {2026-10-11}
}
```

Licență. Se poate cita liber, cu atribuire.

## Mai există și

- Pagina în HTML: https://goingstellar.ro/ro/metode/cum-facem-un-joc-in-godot/
- Același articol în engleză: https://goingstellar.ro/methods/how-we-make-a-game-in-godot/