Dopo la mia disamina arrangiata di qualche mese fa su librerie varie per sviluppamenti videoludici, ora devo ritornare sulla cosa, perché in quel momento ho considerato solo roba 2D... e, principalmente, per quello vale ciò che ho già detto; però, tra ieri e oggi, stavo guardando meglio altre due opzioni, che sarebbero invece ideali per il 3D, visto che avrei in mente qualche progetto segreto di porting umma umma che al momento non voglio dire. 🤫️
In questo caso, avere un #framework completo di tanta roba specifica fa comodo, visto anche che il funzionamento interno del #3D non è qualcosa che programmi da zero dalla sera alla mattina. Però, gli altri requisiti restano uguali... poter programmare in qualunque situazione, con qualunque hardware (cosa che squalifica immediatamente Unity ed Unreal), usando un linguaggio non marcio (che gestisca la memoria per me, che non crashi in modo misterioso dicendo solo "segmentation fault", la cui API non si rompa da una versione all'altra rendendo tutto incompilabile, e con una sintassi che non mi faccia piangere mentre dormo... mamma mia quanti linguaggi odio io), e che supporti principalmente Android, ma in secondo luogo anche PC desktop e web. Quindi... 🤓️
- Come prima scelta... ho installato l'editor dei progetti di Godot sul tablet, per provarlo un po' meglio; infatti ora in ogni caso me lo tengo, e se mi viene in mente di giochicchiarci lo ho già lì. So già che come #engine funziona bene, rispetta i requisiti, la comunità è sufficientemente grossa, e il porting mobile dell'editor ufficiale completo funziona fin troppo bene. 🤖️
Penso che con questo, se ci si prende la mano, si può realisticamente passare da "Godot" a "Godo", ed usarlo seriamente. Anche se, non so quanto radioso sia il futuro di Godot, considerato il disastro che la social media manager pazza ha combinato la settimana passata; questioni che a me, come developer che guarda il prodotto di per sé, fregano meno di zero, ma intanto sia utilizzatori che backer hanno iniziato a scappare... non buono, perché significa meno supporto, sviluppo più lento, e tutto quanto.
- Poi però... mi torna in mente anche libGDX che, seppur meno popolare, in realtà è interessante parecchio. È #Java, e io Java non lo apprezzo particolarmente... ma supporta tranquillamente Kotlin, e quello invece mi piace. Dalla sua ha che, pur essendo un framework molto ricco, non è costruito attorno ad un editor (anche se qualcuno terzo esiste, ganzo), quindi sarebbe forse più accessibile per me, che devo così abituarmi a meno cose... devo solo imparare la API praticamente (cosa che vale per qualunque libreria). ☕️
A quanto pare, #libGDX supporta ufficialmente la compilazione verso web, nello specifico con TeaVM nel caso si abbia codice #Kotlin... ma ho dovuto testare personalmente, perché non si sa mai, visto che quando avevo provato a compilare del codice esempio di TeaVM mesi fa per altri motivi non funzionava. Sorprendentemente, quel mostro di Gradle non ha dato problemi, e quindi ora so che, con questa libreria, la compilazione verso tutti i target che mi interessano funziona sulla mia macchina. 🤯️
In ogni caso, enfasi sul dover imparare, comunque... perché OK, bello l'IDE che, in classico stile Java, ha non solo l'autocompletamento delle cose, ma pure tutta la documentazione integrata bellina... però la roba è comunque tanta, e la wiki ufficiale non mi pare fatta benissimo, per libGDX; anzi, proprio per il 3D rimanda principalmente a una guida esterna, per giunta vecchia, che non usa API apparentemente più nuove che ho trovato invece in un'altra guida. 😶🌫️️
ScreenUtils.clear()... ripeto, non sembra male. Infatti quasi la scelta principale è libGDX, non #Godot... 👻️