Stavros Sento di volerti bene dopo il tuo "dai Lua non è neanche OOP" ecco il punto 🙂 Lua utilizza le tabelle creando una pseudo OOP anomala (anomala se provieni da Java e soci ovvio) Un linguaggio OOP ti impone di ragionare in modo completamente diverso da un linguaggio procedurale. Per me Nesbox deve solo migliorare le API interne, con pochi ritocchi si può migliorare parecchio.
Per quanto riguarda il lato commerciale approvo tutto ciò che hai scritto. Proprio per questo TIC-80 dovrebbe andare in direzione degli hobbysti e per scrivere un gioco con TIC-80 se non hai esperienze pregresse di programmazione col cavolo che fai un giochino 🙂
Avere più linguaggi e quindi più scelte è una bella cosa (sulla carta) ma controllando il repository github del progetto ho scoperto che js, wren e moonscript hanno parecchi bug. Questo accade perchè Lua è il linguaggio integrato principale al progetto, gli altri sono wrappati e per mantenere tutte le features su tutti i linguaggi devi necessariamente lavorare su tutti e se ho capito bene Nesbox non lavora su Wren, e js (almeno mi sembra di aver capito questo). L'implementazione di altri linguaggi in genere viene gestita da collaboratori esterni. Io consiglio sempre e comunque Lua, perchè a conti fatti lo usi meglio, ha una sintassi più facile e funziona meglio degli altri.
Hanno aggiornato la wiki dall'ultima volta che ci andavo, hanno aggiunto molti tutorial e sono felice di questo, ma non sono leggermente complessi per chi è alle prime esperienze? cioè generazione procedurale dei livelli, pathfinding e algoritmi come se piovessero XD e sono tutti in Lua fortunatamente!
Sai una cosa? TIC-80 potrebbe essere sfruttato per realizzare una piccola retro-console basata su Rasperry PI, perchè la funzione "SURF" permette di usare il menu navigabile con anteprima delle cover di tutti i giochi e tutto questo è decisamente bello. Può essere utilizzato per molte cose, in molteplici piattaforme, ma gli mancano solo pochi ritocchi per essere perfetto:
[1] Manca l'autocompletamento del codice e delle word presenti nel codice.
[2] Migliorare le API e rendere la scrittura di un gioco meno incentrata sulla matematica brutale? cioè ho visto gente fare un platform basilare gestendo il gioco pixel per pixel, è un suicidio di massa.
[3] Un sistema di conversione per i progetti Pico-8, dato che sono tanti e Pico-8 è più limitato di Tic-80 sarebbe una bella features. Non ho idea se legalmente sia possibile fare ciò, ma sarebbe davvero bello.
[4] Un sistema di documentazione interna delle API richiamabile dall'editor e dal terminale. Questo garantisce un'ambiente completo al 100%: editor di codice, editor sprites, editor suoni e musiche, editor mappe, e doc completa. In pratica lo porti su un tablet e sviluppi tutto su piattaforma mobile, non è fantastico?
[5] Tutorial graduali e più coerenti, perchè per fare un giochino 8-bit non c'è bisogno di sbattersi tanto. Poi chi vuole andarci giù pesante nessuno lo ferma ovvio. I tutorial per creare un fps raycasting stile doom è qualcosa di epico, ma fuori dalla portata del comune essere umano hobbysta.
[6] Utilizzare una struttura sintattica (Lua) identica a Pico-8, e Liko-12 (open source e molto promettente). Nello specifico mi riferisco a questo:
function _init()
end
function _update()
end
function _draw()
end
Che poi sono funzioni speciali (interne dell'API) che vengono utilizzate da altri frameworks/tool per creare giochi tipo: Godot Game Engine, Phaser, Pygame, Pico-8, Liko-12, e tanti altri! praticamente è una forma sintattica standardizzata e molto più facile da leggere e assimilare dato che molti utenti che approcciano Tic-80 per la prima volta avranno sicuramente utilizzato uno dei game engine/frameworks che ho elencato sopra.
[7] In 2 giorni mi sono messo di impegno per realizzare dei piccoli test utilizzando Pico-8, Liko-12, e Tic-80. Mi spiace dirlo ma con Tic-80 è tutto più macchinoso e tende a complicare le cose senza un motivo apparente. Tic-80 è il migliore per quanto riguarda gui, funzionalità e portabilità, oltre che per le prestazioni e l'ottimizzazione in generale. Per come la vedo io gli manca soltanto il tocco finale! un linguaggio derivato da Lua che semplifica le cose, seguendo la scia di Pico-8 con un pizzico di GDScript.
Con Pico-8 ho seguito dei tutorial su YT di un ragazzo (americano credo) che ha realizzato ben 75 tutorial! tutto ciò è stato molto utile anche per Liko-12 che è praticamente identico a Pico-8 (sintassi e gui), purtroppo con Tic-80 ho fatto più fatica ma alla fine ho convertito tutto e ho fatto il giro più lungo 🙂
Non voglio aggiungere altro, anche perchè la tua idea di aprire uno spazio dedicato a TIC-80 ti rende molto simpatico ai miei occhi XD sono felice di trovare una piccola community italiana che si interessa a questo bel progetto.
