Competenza · Giochi e simulazioni
Costruiamo esperienze interattive nel browser: regole che si applicano, uno stato che cambia e un motivo per cui la persona fa ancora un passo. Cinque progetti costruiti sullo stesso stack, quattro dei quali aperti al pubblico proprio adesso.
Già costruitoCinci implementări proprii pe aceeași stivă, dintre care patru se pot deschide de oricine fără să ne întrebe pe noi: humanoid-sim.megapromoting.com, vision.megapromoting.com, www.megapromoting.com/satelit/ și relieva.vercel.app — toate 200 la verificarea din 06.09.2026. Three.js apare în 17 fișiere sursă scrise de noi, în cinci depozite. Rezerva care schimbă jumătate din pagină: Unity și Unreal NU apar nicăieri în codul nostru — nici într-un fișier, nici într-un proiect, nici măcar ca aplicație instalată. Partea aceea rămâne ofertă cu condiții și e scrisă ca atare, nu ca realizare.
Costruiamo giochi, simulazioni e esperienze interattive che si aprono da un link. Senza installazione, senza store, senza plugin: il motore è Three.js sopra WebGL, e il pubblico entra premendo un indirizzo. Questo è lo stack che possiamo mostrare — cinque progetti costruiti, quattro dei quali pubblici, tutti aperti a chiunque voglia verificarli.
Un gioco non è una bella pagina. Sono regole che si applicano, uno stato che cambia e un motivo per cui la persona fa ancora un passo. Nel nostro gioco di investigazione, il motivo è un orologio di 72 ore: una replica costa 10 minuti, uno spostamento per la città 30, e all’ora di chiusura il dossier si chiude con o senza di te. Nella simulazione di robot, il motivo è la curiosità: lo stesso robot, lo stesso salto, un’altra gravità.
La parte che prendiamo più sul serio di quanto sia abituale è la provenienza. In una simulazione, la bugia più facile è lasciare che una bella animazione passi per fisica dimostrata. Nella simulazione di robot, tutte le 15 azioni dell’interfaccia sono marcate nel codice come `cinematic`, il pannello delle prove dell’applicazione dichiara `actionValidation: "none"`, e il gate di lancio del progetto oggi risponde “Release qualification: blocked”. Preferiamo pubblicare il gate che rifiuta piuttosto che un’affermazione che non possiamo sostenere.
Di Unity e Unreal diciamo le cose chiaramente: li prendiamo su ordinazione, ma non abbiamo nessun progetto consegnato su di essi. Ciò che segue dopo questa frase — le condizioni, i rischi e come si avvia — è scritto sotto, non nascosto in una nota a piè di pagina.
Cosa comprende
Un prototipo senza alcuna texture, ma con la regola giusta, dice più di una scena bella senza posta in gioco. Nel gioco di investigazione la regola significa cinque personaggi, otto indizi di cui tre sono prova forte, quattro motivi, quattro finali e un orologio di 72 ore in cui ogni replica taglia 10 minuti, mentre uno spostamento 30. Le ore 00:00–07:00 vengono saltate automaticamente, così l’orologio non si consumi nel sonno.
La stessa libreria in cinque depositi: Three.js 0.184–0.185, a volte tramite `@react-three/fiber` e `@react-three/drei`, altre volte scritta direttamente. Due progetti usano la variante React; altri due scrivono Three.js puro, fino al livello in cui gestiamo manualmente gli attributi del buffer. Il motore proprietario più grande ha 1.824 righe e disegna tutti i satelliti come un unico oggetto `THREE.Points`, con attributi di posizione, colore, dimensione e trasparenza aggiornati sul posto, frame per frame.
Lo shader su questo sito ha tre livelli: `low` con 24 iterazioni di raymarching e rapporto pixel 0,5, `medium` con 40 e 0,65, `high` con 80, precisione `highp` e rapporto limitato a 2. La scelta è automatica: su mobile scende a `low`, e qualsiasi dispositivo con 4 core o meno lo retrocede da `high` a `medium`. Se WebGL manca, il componente si spegne in modo pulito invece di generare un errore. La stessa disciplina negli altri progetti: limite 1,6 nella scena di città e 1,75 in quella di terreno, 1,5 su mobile nel dimostratore di mondo, con il ciclo di rendering fermato quando il canvas esce dallo schermo.
Una città con 9.506 edifici non significa 9.506 oggetti. Ogni impronta di OpenStreetMap diventa una `ExtrudeGeometry` senza smusso e con `curveSegments: 1`, riceve il colore scritto direttamente nei vertici, le viene cancellato l’attributo `uv` — e poi tutto si fonde in una sola geometria tramite `mergeGeometries`. Gli anelli geometrici degenerati nei dati pubblici vengono saltati con `try`/`catch`, non lasciati a far crollare la pagina.
La verità del caso non sta nella pagina. I dossier dei cinque personaggi — biografia, segreto, la condizione in cui si rompe — stanno in un file che inizia con `import "server-only"` e non può essere importato dal client. Il personaggio segnala un indizio sbloccato tramite un tag che il giocatore non vede, e il server lo accetta solo se quel personaggio ha il diritto di dare quell’indizio. Un modello che inventa un indizio che non gli appartiene viene ignorato, non creduto.
Un personaggio risponde in modo breve e difensivo in romeno, ma in russo diventa loquace e pericolosamente sincero — la regola è scritta nel suo dossier, e la prima replica in russo ne aumenta la fiducia. Il microfono segue la stessa lingua (`ru-RU` o `ro-RO`). Dove la localizzazione è classica, andiamo oltre: la simulazione dei robot ha otto lingue, con l’arabo marcato esplicitamente come scrittura da destra a sinistra.
L’altezza del salto scala con il rapporto delle gravità, il periodo di cammino con 2π√(L/g), il numero di Froude con v²/(g·L), e la resistenza dell’aria con la densità dell’atmosfera del pianeta. L’autonomia della batteria passa attraverso una funzione di decrescita in base alla temperatura con quattro soglie: sopra 20 °C invariata, sopra 0 °C `0,85 + 0,0075·T`, sopra −20 °C `0,55 + 0,015·T`, sopra −40 °C `0,12 + 0,02·T`, e sotto questo 5 %. Il cammino è cinematica inversa con due segmenti, risolta tramite la legge del coseno, con fattore di sostegno 0,6 per ciclo.
L’atmosfera del gioco di investigazione non ha alcun file audio: la pioggia è rumore rosa filtrato passa-basso a 1.400 Hz e passa-alto a 300 Hz, in loop; il crepitio del vinile sono impulsi brevi generati ogni 180 ms; il tuono è un’esplosione di rumore con decadimento esponenziale, programmata a 18–48 secondi. La pioggia visiva è un canvas 2D separato, fino a 180 gocce inclinate. La voce va in entrambe le direzioni: dettatura tramite l’interfaccia di riconoscimento del browser e repliche sintetizzate per personaggio tramite ElevenLabs `eleven_multilingual_v2`, MP3 44,1 kHz / 128 kbps.
I robot Unitree G1 e Go2 arrivano in MJCF, formato MuJoCo, che non ha un caricatore standard per Three.js. L’abbiamo scritto: 170 righe che leggono l’XML, ricostruiscono la gerarchia dei corpi, estraggono ogni giunto con il suo asse e intervallo, e caricano la geometria tramite `STLLoader` e `OBJLoader`. In scena entrano 67 file di mesh, 62 MB — 29 giunti azionati per l’umanoide, 12 per il quadrupede, contati nel blocco `<actuator>` di ogni modello.
Come si presenta
Scriviamo cosa guadagna il giocatore, cosa perde, quanto costa un’azione e quando finisce. Consegniamo il documento delle regole e l’elenco degli stati — non un moodboard. Se la regola non regge alla lettura, non regge neppure disegnata.
Il gioco di investigazione si percorre integralmente e senza alcuna chiave API: il percorso si basa su un set di battute scriptate di 237 righe, e le voci diventano quelle del browser. In questo modo si può vedere il gioco dall’inizio alla fine prima di pagare per il primo token. La stessa logica la applichiamo a qualsiasi progetto: la modalità dimostrativa è un requisito di consegna, non un conforto.
Stabiliamo fin dall’inizio l’obiettivo: su quale dispositivo deve funzionare in modo accettabile, qual è il limite del rapporto di pixel, quanti livelli di qualità esistono e quando si ferma il ciclo. Poi il contenuto si inserisce in questo budget. È l’ordine inverso rispetto a come si fa di solito, ed è il motivo per cui le nostre scene non crollano sul telefono.
Ogni valore visualizzato riceve uno stato: misurato, dedotto da fonti o simulato. Il terreno nella simulazione dei robot porta in scena il contrassegno `visual_only`, affinché nessuno lo confonda con una superficie di collisione. Consegniamo l’etichetta insieme al valore; è lavoro in più nella costruzione ed è l’unica cosa che mantiene la pagina onesta dopo che ce ne andiamo.
Alla fine consegniamo il codice, gli asset con le rispettive licenze e l’elenco scritto di ciò che non è pronto. La simulazione dei robot è pubblicata come build statico servito da Nginx e non ha una pipeline automatica di pubblicazione — è scritto nel proprio README, non in una nota interna. Preferiamo che l’elenco delle mancanze venga da noi.
I dati
Le domande che pone chiunque abbia un responsabile della protezione dei dati — poste qui prima che le ponga lui.
Un caso
La situazione
Un team vuole mostrare nelle presentazioni come si comporta un robot sulla Luna rispetto alla Terra, senza che il pubblico tecnico in sala possa dire «è solo un’animazione».
Cosa abbiamo costruito
Il modello del robot si carica dal suo formato reale — MJCF, tramite il loader scritto da noi, con ogni giunto e il suo intervallo; nell’umanoide entrano 29 giunti attuati. L’andatura è cinematica inversa a due segmenti, con fattore di supporto 0,6. La gravità cambia i valori nelle formule, non la velocità di un’animazione: l’altezza del salto si scala con il rapporto delle gravità, il periodo del passo con 2π√(L/g), l’autonomia della batteria passa attraverso la riduzione in funzione della temperatura con quattro soglie. Il terreno è generato in modo deterministico dal seme del pianeta — 80 m di lato, ampiezza 0,18 m sulla Terra e 0,58 m sulla Luna — e porta in scena il marcatore `visual_only`, così nessuno lo prenda per una superficie di collisione. Separatamente dal browser gira una validazione numerica in MuJoCo, con passo di 1 ms, che scrive il risultato in un rapporto JSON versionato, con l’impronta del modello.
Cosa è emerso
La scena si apre da un link, in otto lingue, inclusa la scrittura da destra a sinistra. Ogni azione nell’interfaccia è etichettata onestamente — oggi, tutte come anteprima cinematica — e un pannello espandibile mostra esattamente cosa è stato verificato numericamente e cosa no. Quando qualcuno in sala chiede «è dimostrato?», la risposta è sullo schermo, non nel discorso.
Cosa non dice il caso
Presuppone un modello del robot in un formato aperto, con la sua licenza verificata; un elenco scritto dei valori che devono essere visualizzati; e l’accordo che i valori non validati restino marcati come tali, anche nelle presentazioni di vendita. Senza il terzo punto, il progetto non è questo.
Domande
Three.js sopra WebGL, nel browser. Il motivo è pratico: il deliverable è un link. Non c’è installazione, non c’è store, non c’è processo di revisione, e una correzione arriva a tutti nel momento della pubblicazione. Lo usiamo in cinque repository — le versioni 0.184 e 0.185 — a volte tramite `@react-three/fiber` e `@react-three/drei`, altre volte scritto direttamente, fino al livello in cui gestiamo manualmente gli attributi dei buffer. Quattro dei progetti sono pubblici proprio ora, quindi l’affermazione si può verificare senza chiederlo a noi.
Le prendiamo su ordinazione, ma la risposta onesta comincia altrimenti: non abbiamo nessun progetto consegnato su Unity o Unreal. Abbiamo cercato in tutto il codice sulla macchina di lavoro — nessun riferimento a `UnityEngine`, nessun file `.uproject`, nessun `.csproj`, nessuna macro di Unreal. I motori non sono nemmeno installati. Cosa cambia in pratica se ne scegli uno: il deliverable non è più un indirizzo web, ma una build per piattaforma; la distribuzione passa tramite store o installer; e i termini di licenza sono quelli pubblicati da Unity, rispettivamente Epic, alla data del progetto, e li verifichiamo allora, non li presumiamo. Come procediamo: partiamo con un prototipo a pagamento e, se il progetto richiede un’esperienza da motore che non abbiamo internamente, lo diciamo prima del contratto.
Sì, ed è una decisione presa in fase di costruzione, non una speranza. Lo shader di questo sito ha tre livelli di qualità — 24, 40 e 80 iterazioni — e si abbassa da solo: su mobile parte dal più leggero, e su qualsiasi dispositivo con 4 core o meno il livello massimo diventa quello intermedio. Il rapporto dei pixel è limitato ovunque: 0,5 sul livello basso qui, 1,5 su mobile nel dimostratore di mondo, 1,6 e 1,75 nelle due scene della mappa urbana. Quando il canvas esce dallo schermo, il loop si ferma. Quello che non posso darvi: un numero di frame al secondo su un telefono specifico — non abbiamo una tale misurazione pubblicabile, quindi non ne inventiamo una.
Tutto ciò che abbiamo costruito finora si apre nel browser. Tre dei progetti sono build statiche servite da Nginx dal nostro server; uno è su Vercel. Un gioco installabile — desktop, telefono o console — è una discussione diversa: presuppone un account da sviluppatore, un processo di revisione, classificazione per età e, molto probabilmente, un altro motore. Nessuno dei nostri progetti è distribuito tramite uno store, quindi quello sarebbe un percorso nuovo, con i suoi passi.
Il codice scritto per il tuo progetto ti appartiene, e i termini si scrivono nel contratto prima dell’inizio del lavoro. Per gli asset, la distinzione conta: quelli generati da primitive o da dati pubblici arrivano senza vincoli aggiuntivi — la macchina nel dimostratore di mondo è costruita da cubi, capsule e cilindri, la città nella scena urbana è OpenStreetMap sopra Copernicus DEM. Quelli importati mantengono la loro licenza: i robot Unitree sono BSD-3-Clause di MuJoCo Menagerie, con la notifica accanto al modello. In un progetto con grafica creata su commissione, la fonte e la proprietà di ogni asset si stabiliscono in elenco, asset per asset.
Questa è la riserva più onesta che abbiamo. Nessuno dei cinque progetti ha stato condiviso tra i giocatori: il gioco investigativo mantiene tutto in `localStorage`, la simulazione di robot tiene lo stato nella memoria della pagina. Un gioco con più persone contemporaneamente richiede un server autoritativo di stato, sincronizzazione e gestione del ritardo di rete — pezzi nuovi, non un’impostazione da spuntare. Si può costruire, ma entra nel progetto come sottosistema separato, con il suo lavoro, non come opzione.
Non Le do un numero che non posso sostenere. Le do l’ordine: la prima consegna è un prototipo giocabile con la regola corretta e la grafica minima, e deve funzionare senza alcuna chiave API — così come il nostro gioco investigativo si percorre interamente su repliche scritte. Solo dopo che la regola regge si aggiungono grafica, voce e modello. Se un fornitore Le promette il termine prima di vedere la regola, promette qualcosa che non ha misurato.
Il consumo lo controlla tramite i limiti scritti nel codice, non tramite la speranza. Nel gioco investigativo: la cronologia inviata al modello viene tagliata alle ultime 20 messaggi, il messaggio del giocatore a 600 caratteri, la risposta a 400 token, e il tempo massimo di attesa è 45 secondi. La sintesi vocale taglia il testo a 900 caratteri. Ognuna di queste soglie è una linea che possiamo spostare insieme, con effetto diretto sulla fattura. E rimane la modalità senza chiavi, in cui il gioco funziona su repliche scritte e non consuma nulla.
Non sosteniamo che un’animazione sia una dimostrazione fisica. Nella simulazione di robot, tutte le 15 azioni sono marcate nel codice come `cinematic`, il pannello delle prove dichiara `actionValidation: "none"`, e il verificatore di rilascio oggi risponde «Release qualification: blocked», perché la risposta di 5 ms dell’arresto dell’articolazione non è calibrata su hardware reale. Non consegniamo il multiplayer come opzione nascosta. Non ci presentiamo come studio Unity o Unreal. E non inseriamo un demo nell’offerta senza dire se è pubblico — il nostro gioco investigativo, per esempio, funziona solo localmente e non ha indirizzo.
24 di esse sono codice e file dei nostri repository. Non ne pubblichiamo il nome né la riga: insieme, in un'unica pagina, descriverebbero con troppa precisione come sono costruiti sistemi che non sono solo nostri. Le esaminiamo con te, nel repository, su richiesta — la verifica resta possibile, solo che avviene in una discussione.
Raccontaci il tuo processo. Insieme stabiliamo cosa vale la pena costruire, cosa possiamo collegare e come verifichiamo il risultato.