Il multiplexer terminale gPTY usa Godot per sfidare i limiti di tmux

gPTY ha rilasciato un multiplexer terminale funzionante realizzato con Godot e Rust, nonostante sia nato come progetto di apprendimento ispirato a tmux. Questa combinazione insolita conta perché gPTY non si limita ai riquadri del terminale. Il suo sviluppatore sta trasformando l'applicazione in uno spazio di lavoro grafico in cui persone e agenti di programmazione AI possono condividere sessioni terminali osservabili.

Il progetto è comparso su Hacker News dopo una rapida sequenza di rilasci culminata nella versione 0.5.3 il 10 settembre 2026. Ora combina sessioni pseudo-terminale indipendenti, layout affiancati, cronologia persistente, visualizzazioni dello stato degli agenti e un'interfaccia di controllo programmabile. Uno pseudo-terminale, o PTY, collega un programma interattivo a un emulatore di terminale attraverso un'interfaccia del sistema operativo.

Questa portata colloca il multiplexer terminale gPTY in una posizione scomoda ma interessante. Non può ancora eguagliare tmux come strumento maturo per le sessioni, e il suo sviluppatore descrive apertamente alcune asperità. Tuttavia, Godot offre a gPTY una superficie grafica che un multiplexer esclusivamente testuale non può riprodurre facilmente.

Il multiplexer terminale gPTY è andato oltre una demo di riquadri

Il cambiamento immediato è che gPTY ora presenta uno spazio di lavoro coerente rivolto agli agenti, non semplicemente un esperimento con Godot capace di aprire diverse shell.

Il progetto è iniziato con una domanda semplice: un motore di gioco poteva visualizzare terminali del sistema operativo all'interno di pannelli ridimensionabili? Lo sviluppatore voleva acquisire maggiore esperienza sia con Godot sia con Rust. Tmux ha fornito il riferimento pratico perché consente già agli utenti di dividere un terminale in riquadri.

Quel punto di partenza resta visibile. Gli utenti possono creare sessioni shell indipendenti, dividere l'interfaccia orizzontalmente o verticalmente, ridimensionare i riquadri e ripristinare le disposizioni salvate. Tuttavia, l'ultimo codice sorgente di gPTY espone questi riquadri anche tramite un'interfaccia a riga di comando, JSON-RPC e il Model Context Protocol.

JSON-RPC è un formato strutturato per chiamare operazioni con nome tramite messaggi JSON. MCP è un protocollo aperto attraverso il quale un sistema AI può individuare e invocare strumenti. In gPTY, entrambe le interfacce forniscono il controllo esterno di uno spazio di lavoro grafico in esecuzione.

Un agente o uno script può richiedere un nuovo riquadro, elencare quelli attivi, inserire testo, ispezionare l'output del terminale, verificare lo stato dei processi o attendere un risultato corrispondente. Lo strumento a riga di comando e il server MCP derivano i rispettivi schemi dalle stesse definizioni dei comandi. Questo design riduce la possibilità che gli strumenti per agenti documentati divergano dalla CLI effettiva.

La versione 0.5.0, rilasciata il 3 settembre, ha segnato lo spostamento del progetto verso quello che il suo sviluppatore definisce un Agent Development Environment. La versione 0.5.1 ha aggiunto scrollback persistente, ricerca full-text nella cronologia, spazi di lavoro con nome e test automatizzati dell'interfaccia dei riquadri.

La versione 0.5.2 è seguita con il rilevamento dello stato degli agenti e gli eventi del ciclo di vita indipendenti dagli adapter. La versione 0.5.3 si è quindi concentrata su sicurezza, comportamento di rendering, supporto del mouse e resistenza a output terminali rumorosi. Questo ritmo di rilascio mostra quanto rapidamente si sia espansa l'idea originaria del multiplexer.

L'architettura separa ancora la meccanica del terminale dalla presentazione. Rust gestisce i processi PTY, analizza le sequenze di escape, mantiene le griglie del terminale e si occupa della comunicazione asincrona. Godot renderizza l'interfaccia visibile e organizza diversi tipi di riquadro.

Il progetto usa portable-pty per l'accesso PTY multipiattaforma e alacritty_terminal per lo stato del terminale. Usa inoltre il parser vte di Rust per le sequenze di controllo ANSI. Godot riceve aggiornamenti strutturati della griglia invece di cercare di interpretare autonomamente l'output grezzo del terminale.

Questa divisione è centrale per la direzione del progetto. Rust fornisce il comportamento del terminale e una superficie di controllo stabile. Godot fornisce un sistema di scene in grado di disegnare interfacce che vanno oltre le celle di caratteri.

Gli agenti di programmazione AI conferiscono all'esperimento un caso d'uso più urgente

La pressione non ricade principalmente su tmux stesso. Ricade sugli spazi di lavoro grafici per agenti che nascondono il proprio stato interno dietro interfacce fisse.

Gli agenti di programmazione basati sul terminale operano sempre più spesso insieme a compilatori, esecutori di test, strumenti di controllo versione e server di sviluppo. Uno sviluppatore può mantenere un agente in una shell mentre osserva i log, esamina le modifiche o esegue la convalida altrove.

I multiplexer terminali tradizionali gestiscono già la disposizione dei riquadri. Possono mantenere visibili diverse shell e preservare processi di lunga durata dopo la disconnessione dell'utente. Il modello di sessione di tmux resta particolarmente utile per le macchine remote, perché le sessioni possono essere scollegate e poi ricollegate.

Il problema più difficile è l'osservabilità. Un agente può dedicare minuti al ragionamento, all'esecuzione di strumenti o all'attesa di input mentre il suo terminale espone soltanto un flusso di testo in continua evoluzione. Il software esterno spesso risponde estraendo quel flusso e cercando di indovinare cosa stia facendo l'agente.

gPTY adotta un approccio diverso. La sua API dei riquadri può restituire testo del terminale, stato dei processi, tempo di inattività e informazioni sullo stato degli agenti. Gli eventi del ciclo di vita autenticati possono indicare se un agente supportato sta lavorando, ha terminato, è inattivo o richiede attenzione.

L'interfaccia utilizza diversi livelli di rilevamento perché non tutti gli agenti parlano lo stesso protocollo. Un evento autenticato diretto fornisce il segnale più forte. Un'annotata sequenza di controllo del terminale ne fornisce un altro, mentre modelli di output prudenti offrono una soluzione di riserva.

Questi stati restano funzionalità di visualizzazione anziché comandi di orchestrazione. Il progetto lascia deliberatamente i cicli degli agenti e la gestione dei sotto-agenti a strumenti quali Claude Code, Gemini CLI o Oh My Pi. gPTY osserva il loro lavoro e fornisce un ambiente intorno a essi.

Questo confine distingue uno spazio di lavoro per agenti da un framework per agenti. gPTY non decide quale attività un agente debba eseguire in seguito. Espone terminali e stati affinché un essere umano o un livello di automazione separato possa prendere quella decisione.

Si consideri uno sviluppatore che esegue un'attività di programmazione autonoma. Un riquadro contiene l'agente, un altro esegue i test, un terzo mostra un file e un quarto monitora un server di sviluppo. Lo spazio di lavoro può preservare questi riquadri e consentire agli strumenti approvati di ispezionarne lo stato.

La stessa disposizione offre inoltre all'essere umano una superficie visiva condivisa. Un test fallito può rimanere visibile accanto alla risposta dell'agente che lo ha causato. Lo scrollback persistente può in seguito supportare una base di conoscenza ricercabile contenente decisioni, errori e prove di convalida.

L'opportunità va oltre la visualizzazione di più terminali. Il lavoro intensivo con agenti crea molti processi concorrenti il cui stato è importante, ma il cui output è difficile da coordinare in sicurezza. gPTY sta verificando se un'interfaccia desktop possa rendere leggibile questa attività senza sottrarre il controllo agli strumenti sottostanti.

Questo spiega anche perché il tempismo del progetto conta. Un semplice clone di multiplexer dovrebbe confrontarsi con decenni di comportamenti consolidati e abitudini degli utenti di tmux. Una superficie di controllo visiva per terminali di agenti affronta un flusso di lavoro più recente, con meno convenzioni ormai stabilite.

Godot trasforma le celle del terminale in uno spazio di lavoro grafico

Il meccanismo principale non è soltanto la performance di Rust. È la separazione tra un core terminale e un motore di gioco capace di renderizzare elementi nativi dell'interfaccia.

Il multiplexer terminale gPTY mantiene le proprie griglie del terminale in Rust e invia aggiornamenti compressi a Godot tramite GDExtension. GDExtension è l'interfaccia nativa di Godot per integrare librerie compilate senza modificare il motore stesso.

Un bridge headless possiede la griglia Rust di ciascun terminale. Un nodo Control di Godot esegue il polling delle celle modificate e le disegna nell'applicazione. Questo evita di imporre l'analisi del terminale e la gestione dello stato al livello di presentazione.

La scelta introduce un overhead che un multiplexer basato sul testo evita. Tmux non ha bisogno di un motore di rendering desktop per dividere griglie di caratteri. Funziona all'interno di un emulatore di terminale esistente e si concentra su sessioni, finestre, riquadri e continuità dei processi.

Godot modifica ciò che un riquadro può diventare. Un riquadro non deve restare un flusso rettangolare di celle terminali. Può diventare un visualizzatore di codice, un albero di file, un inspector, un pannello grafico di stato o un altro controllo nativo.

Il progetto include già concetti di terminale, visualizzatore di codice, albero di file, ragionamento e inspector. Tra le possibilità pianificate figurano riquadri per video e grafi visivi a nodi, sebbene queste idee non siano ancora state distribuite. Vanno considerate una direzione, non una funzionalità attuale.

Questa è la scommessa centrale dietro l'uso di Godot. Un motore di gioco porta con sé un grafo di scene, gestione dell'input, animazione, frequenze dei fotogrammi configurabili e rendering bidimensionale flessibile. Sono fondamenta insolite per un'applicazione terminale, ma si adattano a uno spazio di lavoro grafico misto.

Le frequenze dei fotogrammi configurabili riflettono inoltre le origini sperimentali del progetto. Lo sviluppatore voleva che gli utenti potessero abbassare il limite di rendering sui laptop a batteria o alzarlo su display desktop più veloci. Il progetto non ha pubblicato misurazioni indipendenti dei consumi, quindi il risparmio energetico resta un'ipotesi non verificata.

L'implementazione attuale ha già incontrato le conseguenze del trattare l'output del terminale come un carico di lavoro da renderizzare. La versione 0.5.3 ha aggiunto il rate limiting per i riquadri il cui lavoro sulla griglia supera il budget di frame. Ha inoltre ridotto il lavoro di disegno del testo e applicato backpressure quando un riquadro inonda l'interfaccia.

Questi cambiamenti evidenziano un compromesso reale. Una superficie grafica reattiva può offrire controlli più ricchi, ma i carichi di lavoro del terminale possono generare output molto più velocemente di quanto un utente possa leggerlo. L'applicazione deve impedire che un riquadro rumoroso consumi il thread dell'interfaccia.

Godot offre inoltre al progetto un livello applicativo multipiattaforma. I pacchetti di rilascio sono destinati a Linux, macOS e Windows, e gli utenti non necessitano di una toolchain locale Godot o Rust. L'astrazione PTY sottostante è mappata sui PTY Unix e su Windows ConPTY.

Questa architettura rende gPTY più simile a un emulatore di terminale grafico con funzionalità di multiplexer e automazione che a un sostituto diretto di tmux. La distinzione conta perché ogni categoria comporta aspettative diverse in termini di persistenza, funzionamento remoto, latenza, controllo da tastiera e uso delle risorse.

Il futuro del progetto dipende dal fatto che i riquadri nativi di Godot diventino essenziali. Se la maggior parte degli utenti desidera soltanto shell affiancate, il motore aggiunge complessità senza offrire un beneficio sufficiente. Se gli agenti necessitano di visualizzazioni e controlli più ricchi, quella stessa complessità diventa la ragione per adottarlo.

gPTY vs tmux riguarda in realtà l'estensibilità GUI rispetto alla portabilità del terminale

Il confronto decisivo è tra l'estensibilità grafica e la portabilità di un modello di sessione testuale maturo.

Tmux può essere eseguito ovunque siano disponibili un terminale adatto e un processo server. Le sue sessioni sopravvivono alle disconnessioni del client, rendendolo prezioso attraverso collegamenti SSH e reti instabili. Gli utenti possono collegarsi da un altro terminale senza ricostruire il proprio spazio di lavoro.

gPTY è attualmente incentrato su un'applicazione desktop. Può preservare cronologie dei riquadri, impostazioni, layout e spazi di lavoro con nome tra i riavvii, ma questo non è identico al distacco di tmux. Uno spazio di lavoro ripristinato e una sessione remota in esecuzione continua risolvono problemi correlati ma diversi.

Questa differenza limita i confronti semplicistici. Tmux multiplexa sessioni terminali all'interno di un terminale. gPTY fornisce sessioni terminali all'interno di un programma grafico e le espone tramite un'API rivolta agli agenti.

Tmux beneficia inoltre di un modello di comandi consolidato da tempo, di un linguaggio di configurazione, di una cultura di plugin e di un ampio corpus di conoscenze operative. Gli sviluppatori sanno già come combinarlo con shell, editor, host remoti e script. Sostituire queste abitudini richiede più di bordi accattivanti per i riquadri.

Lo sviluppatore di gPTY riconosce questo problema nel racconto delle origini del progetto. All’inizio, il progetto mirava a diventare abbastanza utile da sostituire tmux o un emulatore di terminale usato quotidianamente. La scoperta di Herdr, un multiplexer incentrato sugli agenti, ha imposto una domanda strategica più circoscritta.

Invece di cercare di superare un multiplexer per agenti più completo, gPTY si è orientato verso capacità che un’interfaccia utente da terminale non riesce a esprimere facilmente. Può persino eseguire un altro multiplexer all’interno di uno dei suoi riquadri, lasciando a quello strumento la responsabilità delle proprie sessioni.

Questa componibilità è più credibile della pretesa di una sostituzione immediata. Un utente può mantenere tmux per la persistenza remota e usare gPTY come livello visivo locale. Analogamente, uno strumento terminale specifico per agenti può operare all’interno di un riquadro di gPTY.

Anche altri terminali grafici indeboliscono qualsiasi pretesa che gPTY domini questo spazio progettuale. Le moderne applicazioni terminali offrono suddivisioni, schede, rendering accelerato, scripting e layout configurabili. Progetti basati su Rust come Zellij e Okena esplorano combinazioni adiacenti di emulazione terminale e multiplexing.

La distinzione più netta di gPTY è la combinazione di tipi di riquadro misti, osservabilità degli agenti e una superficie di controllo pubblica. Un agente esterno può operare nello spazio di lavoro tramite comandi documentati invece di simulare sequenze di tasti contro un’interfaccia opaca.

Anche questo vantaggio richiede una formulazione prudente. Tmux espone già numerosi comandi per interrogare i riquadri e inviare input. Il suo modello incentrato sul testo è scriptabile proprio perché è rimasto stabile e componibile.

La differenza sta in ciò che accade dopo il comando. Tmux presenta il risultato come contenuto del terminale. gPTY può instradare l’output acquisito verso riquadri grafici, mostrare lo stato del ciclo di vita e, in futuro, visualizzare relazioni che non si adattano comodamente a una griglia di caratteri.

Per gli sviluppatori, la decisione pratica non è quindi “nuovo contro vecchio”. È capire se il flusso di lavoro richiede sessioni terminali resilienti o una tela locale estensibile. Molti utenti di agenti avranno bisogno di entrambi.

Il progetto avrà successo se completerà gli strumenti consolidati dimostrando una ragione concreta per il proprio livello grafico. Incontrerà difficoltà se chiederà agli utenti di rinunciare a un comportamento di sessione maturo prima che le sue capacità visive diventino indispensabili.

L’audit di sicurezza mostra perché le superfici di controllo degli agenti richiedono moderazione

La versione più rivelatrice di gPTY ha rimosso una funzionalità di automazione dopo che lo sviluppatore ha concluso che il suo modello di configurazione poteva consentire l’esecuzione silenziosa di comandi.

Il motore dei concetti monitora l’output del terminale alla ricerca di espressioni regolari definite dall’utente. Un concetto corrispondente può acquisire l’output pertinente e instradarlo verso un altro riquadro, come un visualizzatore di codice o un ispettore. Può inoltre pubblicare una notifica senza rimuovere l’output originale.

I progetti precedenti consentivano a un concetto di contenere un modello di comando da iniettare in una shell di destinazione. Una riga corrispondente poteva quindi attivare un’azione in un altro riquadro. Inizialmente la funzionalità non funzionava a causa di difetti di implementazione, ma le correzioni successive stavano per renderla operativa.

Durante la revisione della versione 0.5.3, lo sviluppatore ha riconosciuto il rischio. L’output del terminale non è affidabile perché file, log, sistemi remoti e comandi possono stampare testo arbitrario. Una riga dannosa potrebbe soddisfare un pattern fidato e attivare un comando configurato.

Le etichette rendevano il pericolo maggiore perché un’azione poteva prendere di mira un riquadro sensibile. Quel riquadro poteva contenere una shell remota autenticata o una sessione locale con privilegi elevati. L’azione sarebbe arrivata come input del terminale senza un passaggio di approvazione separato.

Il progetto ha rimosso i modelli di comando e il relativo percorso di iniezione invece di aggiungere un semplice interruttore di conferma. Ora i concetti possono osservare, acquisire, instradare e annunciare le corrispondenze, ma non possono eseguire comandi shell.

Questa decisione limita il comportamento autonomo di gPTY, rafforzando al contempo il ruolo dichiarato del progetto. L’applicazione fornisce uno spazio di lavoro osservabile. Uno strumento distinto, invocato esplicitamente, resta responsabile delle azioni che modificano lo stato del terminale.

La più ampia revisione di sicurezza ha coperto IPC, creazione di PTY, ripristino dello spazio di lavoro, adattatori per agenti, parsing, rendering, MCP e infrastruttura di rilascio. Ha corretto diversi problemi concreti e ne ha documentati altri, senza presentare l’audit come una certificazione.

In precedenza, i controlli di attendibilità dello spazio di lavoro non rilevavano alcuni campi eseguibili durante il ripristino dei layout. I controlli aggiornati coprono programmi e argomenti lungo tutti i percorsi di ripristino. I client del socket di controllo non possono aggirare una finestra di approvazione richiedendo un profilo non attendibile.

La versione blocca inoltre le variabili d’ambiente che possono alterare l’avvio della shell o l’esecuzione dei comandi. I processi figlio dell’ispettore non ereditano più i segreti di controllo di gPTY. Le chiamate MCP sono limitate ai metodi che il server pubblicizza effettivamente come strumenti.

Tuttavia, il progetto continua a identificare rischi irrisolti. Tra questi vi sono code di output che possono crescere sotto carico elevato, scritture della cronologia bloccanti, letture di file senza limiti, file temporanei prevedibili, artefatti di rilascio non firmati e verifica incompleta dei peer su alcune piattaforme.

Il modello di minaccia di gPTY afferma inoltre che l’applicazione non isola in sandbox i processi del terminale. Le shell ereditano gran parte dell’ambiente dell’applicazione grafica, inclusi puntatori a credenziali e socket degli agenti. Un programma eseguito in un riquadro dispone quindi della normale autorità dell’account utente.

Anche lo scrollback archiviato è un elemento da considerare. La cronologia persistente migliora ripristino e ricerca, ma può anche conservare segreti stampati dai comandi. Gli utenti non dovrebbero trattare un database locale della cronologia del terminale come un confine di sicurezza isolato.

Esiste inoltre un rischio relativo alla qualità. Il repository afferma che ampie porzioni del suo codice Rust e Godot sono state generate con modelli linguistici. Lo sviluppatore avverte che l’implementazione potrebbe contenere bug o pattern poco idiomatici.

Questa dichiarazione non dimostra che il codice sia insicuro. Rafforza però la necessità di revisione umana, test, gestione delle dipendenze e adozione prudente. Un progetto individuale in rapida evoluzione non può basarsi sul volume dei commit come prova di affidabilità.

La versione 0.5.3 offre un precedente costruttivo. Lo sviluppatore ha rimosso una funzionalità allettante quando il suo modello di fiducia non ha retto a un esame approfondito. La credibilità futura dipenderà dal ripetere questa moderazione man mano che più agenti otterranno accesso all’input dei riquadri e all’output archiviato.

Tre segnali decideranno se gPTY diventerà più di un progetto secondario

La prossima fase deve dimostrare che l’osservabilità grafica degli agenti crea valore duraturo senza indebolire l’affidabilità del terminale o il controllo dell’utente.

Il primo segnale è la prevista separazione del motore dello spazio di lavoro Rust da Godot. L’attuale roadmap di gPTY descrive un demone Rust autonomo, mentre l’applicazione Godot diventerebbe un client di rendering.

Questo cambiamento rafforzerebbe il confronto con i multiplexer consolidati. Un motore headless potrebbe preservare i processi del terminale indipendentemente dalla finestra grafica. Potrebbe inoltre supportare client remoti o front end alternativi senza vincolare la durata della sessione a Godot.

Se questa estrazione verrà rilasciata con un comportamento di riconnessione stabile, l’approccio grafico del progetto sarà più facile da difendere. Se resterà una voce estesa della roadmap, tmux manterrà un vantaggio decisivo per le sessioni persistenti e remote.

Il secondo segnale è l’adozione dell’interfaccia pubblica dei riquadri da parte di agenti esterni alla configurazione dello sviluppatore. Il repository fornisce già comandi CLI, un server MCP, schemi e una skill per agenti inclusa. Questi elementi rendono l’integrazione tecnicamente possibile.

Un’adozione significativa includerebbe flussi di lavoro riproducibili su più strumenti per agenti. Gli sviluppatori dovrebbero poter creare riquadri, eseguire comandi, monitorarne il completamento e ispezionare le evidenze senza screen scraping personalizzato.

La qualità della gestione degli errori conta quanto il percorso ideale. Un agente deve distinguere un’attività completata da un processo bloccato, un riquadro chiuso, una sessione scaduta o un’acquisizione parziale dell’output. Identificatori stabili e risposte di stato esplicite forniscono una base, ma un utilizzo più ampio farà emergere casi limite.

Se gli strumenti esterni inizieranno a trattare gPTY come un servizio affidabile per lo spazio di lavoro, la sua strategia rivolta agli agenti guadagnerà sostegno. Se le integrazioni resteranno limitate alle dimostrazioni, il progetto sembrerà più un’interfaccia personale costruita attorno a familiari operazioni terminali.

Il terzo segnale è se i riquadri nativi di Godot offriranno qualcosa che gli sviluppatori non possono ottenere dalle suddivisioni del terminale. Un editor grafico di concetti, un ispettore più ricco o una mappa visiva delle dipendenze potrebbero giustificare l’insolita base dell’applicazione.

I riquadri nativi per video e grafi di nodi restano funzionalità prospettiche. Non dovrebbero influenzare le decisioni di adozione finché non esisteranno e non funzioneranno con attività di sviluppo reali. La conferma più solida arriverebbe da utenti che mantengono aperti tali riquadri perché migliorano il lavoro quotidiano.

Le prestazioni devono restare parte di questa verifica. Un motore desktop non dovrebbe rendere l’interazione ordinaria con la shell meno immediata. I frame rate configurabili sono interessanti, ma latenza misurata, uso della CPU, comportamento della memoria e impatto sulla batteria fornirebbero evidenze più utili.

Anche packaging e sicurezza influenzeranno la fiducia. Artefatti firmati, controlli IPC più robusti e specifici per piattaforma, consumo di risorse limitato e una gestione più sicura della cronologia archiviata avvicinerebbero gPTY all’uso ordinario.

Il progetto non deve sconfiggere tmux per avere importanza. La sua opportunità più realistica è stabilire un nuovo livello tra gli agenti nativi del terminale e gli esseri umani che li supervisionano.

Questo livello può preservare l’apertura degli strumenti da riga di comando aggiungendo stato visibile, contenuti misti e automazione strutturata. Può anche creare nuovi problemi di sicurezza se l’osservazione si trasforma silenziosamente in esecuzione incontrollata.

Il multiplexer di terminale gPTY ha già compiuto una scelta importante mantenendo l’orchestrazione degli agenti al di fuori del proprio nucleo. Ora deve dimostrare che l’interfaccia rimanente è abbastanza affidabile da diventare un’infrastruttura condivisa.

Gli sviluppatori che lo valutano dovrebbero prima provare un flusso di lavoro circoscritto. Eseguite un agente accanto a test e log, osservate come appaiono i fallimenti e verificate cosa sopravvive a un riavvio. Poi chiedetevi se il contesto grafico riduce l’incertezza rispetto alla configurazione terminale già in uso.

Quella risposta, ripetuta tra utenti indipendenti, determinerà se gPTY diventerà uno spazio di lavoro duraturo per agenti o resterà un inventivo esperimento Godot.