Il motore
MicroGames Engine
Godot fa girare i giochi. MicroGames Engine è tutto quello che ci sta intorno: porta un'idea fino a una build per browser, Windows, macOS, Linux e Android, e a ogni passo controlla che il gioco regga davvero.
Un motore di gioco risponde a una domanda precisa: come si disegna, si muove e si ascolta quello che succede sullo schermo. Per quella usiamo Godot 4, e non abbiamo nessuna intenzione di riscriverlo: rendering, fisica, input e audio sono suoi.
MicroGames Engine risponde a un'altra domanda: come si fa un gioco — e come lo si tiene vivo dopo l'uscita — senza che ogni passaggio dipenda da qualcuno che se ne ricordi. È lo strato che scrive e ripara il codice, prepara le esportazioni, prova le build, salva le versioni e pubblica.
Cosa aggiunge a Godot
Un documento che diventa lavoro
Il documento di progetto non resta un file da consultare: si scompone in compiti, che il costruttore porta avanti a blocchi. Un compito conta come fatto solo quando un verificatore, che può soltanto leggere, lo ritrova nel codice. «Compila» non basta.
Chi scrive e chi ripara sono due
Il costruttore scrive scene e GDScript. Quando l'esportazione o la prova d'avvio falliscono, l'errore passa a un riparatore separato, che fa la modifica più piccola possibile: fino a cinque tentativi, poi il problema si ferma e resta scritto.
Cinque controlli prima di pubblicare
Compila, parte, è coerente — scena principale e condizione di vittoria — si carica, si vede. L'ultimo non lo decide il codice: il gioco viene aperto in un browser vero e si guarda se disegna qualcosa.
Giocato per davvero, ogni notte
Un giocatore automatico apre ogni gioco, lo gioca per una ventina di secondi e ne ricava il poster e il filmato che vedi sul sito. Le schermate ferme — menu, pausa, «sei morto» — vengono scartate: un poster che mente è peggio di nessun poster.
Ogni versione resta
A ogni pubblicazione i sorgenti del gioco vengono salvati. Si può tornare a qualunque versione e riesportarla: un gioco qui non si abbandona dopo l'uscita, continua a cambiare.
Materiale vero, sprite mancanti
Immagini, suoni e video caricati per un gioco entrano nel progetto già nel formato che Godot legge. Se al gioco manca uno sprite, viene generato e scontornato, pochi per volta.
Un export, cinque destinazioni
La stessa catena produce la build per il browser e i pacchetti per Windows, macOS, Linux e Android, con la versione scritta nel nome di ogni file. La build per il browser può partire anche verso itch.io.
Uno studio, non un prompt
Ricerca, progetto, costruzione e pubblicazione sono divise fra 12 figure con un compito solo ciascuna. Chi ha scritto il codice non è chi lo giudica.
Chi fa cosa
Godot resta il motore. Quello che cambia è quanto lavoro gli arriva già fatto, e controllato.
| Godot 4 | MicroGames Engine | |
|---|---|---|
| Disegno, fisica, input, audio | Li fa girare | Non li tocca |
| Codice di gioco | Esegue il GDScript | Lo scrive, lo ripara, lo verifica |
| Esportazione | Fornisce i template | Prepara i preset, impacchetta, mette la versione nel nome |
| Collaudo | Avvio senza finestra | Cinque controlli e una partita vera in un browser |
| Versioni | — | Salva i sorgenti a ogni uscita e le ripristina |
| Pubblicazione | — | Sito, pagina del gioco, poster, filmato, itch.io |
Contati adesso
Letti dal database a ogni visita, come quelli della vetrina.
Altri motori
Oggi MicroGames Engine parla solo con Godot: impalcatura del progetto, istruzioni agli agenti, esportazione e prove sono scritte per lui. Aggiungere un secondo motore vuol dire scrivere un adattatore per ognuna di queste parti — non è un interruttore.
Il criterio con cui li valutiamo è uno: un motore entra se si può costruire, provare e pubblicare senza mani. Build da riga di comando, sorgenti di testo che un agente può leggere e modificare, e un'esportazione per il browser, perché è lì che ogni gioco viene provato prima di uscire.
| Motore | Cosa porterebbe | Cosa lo frena | A che punto |
|---|---|---|---|
| Godot 3D | Stessa catena, stessi controlli, nessun adattatore | Serve arte 3D, che oggi non produciamo | La strada più breve verso il 3D |
| Phaser, three.js, Babylon.js | Nascono per il browser: prove e riprese funzionano già | Per il desktop serve un contenitore come Electron o Tauri | Il candidato più naturale per un secondo motore |
| Defold | Build da riga di comando, sorgenti Lua testuali, export per il web | Un secondo linguaggio e un secondo editor da insegnare agli agenti | In valutazione |
| Unity | Un ecosistema enorme | Licenza da attivare, installazione pesante, scene poco leggibili da un agente | Non ora |
| Unreal Engine | Il 3D di fascia alta, dove lo studio vuole arrivare | Nessuna esportazione ufficiale per il browser: salterebbero «Gioca», prove e riprese automatiche; strumenti da decine di gigabyte | Su una macchina dedicata, fuori dalla catena automatica |
Quando un secondo motore produrrà un gioco, lo leggerai nel diario come tutto il resto: con i numeri, e con quello che si è rotto per strada.
