Cos'è TIC-80 ? TIC-80 appartiene a quel filone di software che puntano a ricreare il look & feel delle console anni '80 e '90 (in alcuni casi anche '70), filone che ha il suo maggiore esponente nel PICO-8 . Questi software vengono comunemente definiti fantasy console o fantasy computer, hanno un set di istruzioni (API) ben definito ed emulano persino la RAM in maniera virtuale permettendo grande flessibilità su quello che viene portato a schermo. Le community che le riguardano sono molto vive: vi invito a fare un giro sul Discord ufficiale di questo mondo in rapida crescita. Tornando a TIC-80 , arrivato alla versione 0.60.3, è evidente il look & feel retro: se questo è vero per i fruitori finali, i videogiocatori, è soprattutto vero per chi ci sviluppa. Alcune delle caratteristiche essenziali di questa fantasy console sono: Risoluzione fissa a 240x136 Palette a 16 colori 256 sprite di dimensione 8x8 Sonoro a 4 canali Supporto ai gamepad Questa fantasy console è gratuita, con una versione PRO acquistabile su itch.io alla modica cifra di 5$ con alcune feature interessanti (alcune già presenti, altre in via di sviluppo). Il suo creatore è molto presente e disponibile per nuove richieste e bugfix. Oltretutto, è stata resa open source dal suo creatore, nonostante solo pochi contribuiscano attivamente a nuove feature. Una volta avviato il software (che gira anche all'interno del browser) ci ritroveremo davanti ad una linea di comando. Alcuni dei comandi classici come "mkdir", "cd" e "dir" hanno il medesimo funzionamento della loro controparte Windows. Per la lista completa rimando alla wiki . Premendo ESC si entra in modalità editor e si viene portati alla schermata del code editor . Con i tasti funzione F1 F2 F3 F4 F5 o cliccando sulle tab corrispettive si accede agli altri editor (sprite, map, sound e music): è subito possibile andare a scrivere, disegnare o comporre i vari aspetti del nostro gioco. Si può impostare un linguaggio di programmazione a scelta tra Lua (default), MoonScript e JavaScript attraverso un commento nei metadati del file di codice. In futuro potrebbero essere aggiunti nuovi linguaggi come Wren. Di default, utilizzando Lua, saranno disponibili tutte le funzionalità di questo linguaggio (libreria standard, math, ecc.) con alcune ovvie limitazioni per l'I/O. Una volta scritto il nostro codice e realizzati sprite e suoni, si può eseguire il gioco semplicemente premendo CTRL+R o premendo ESC e scrivendo in console "run". Se in un primo momento ottenete un errore di "Missing cart name" non preoccupatevi: prima di eseguire il gioco, è necessario salvare la "cart" (ovvero la cartuccia, un file in formato .tic che contiene tutto il gioco) con il comando "save" seguito dal nome che vogliamo dare al nostro gioco. Una volta eseguito questo primo passo si può eseguire il gioco. Estremamente essenziale, il codice di default mette a schermo uno sprite animato (2 frame) che può essere mosso tramite le frecce direzionali: non un vero gioco ma le prime basi per capire la struttura del codice di una cartuccia. La funzione TIC() viene chiamata a ogni frame. Al suo interno è possibile gestire la logica e disegnare sprite/mappe. Per tutte le API che è possibile utilizzare rimando alla wiki . Quelle che vi saranno più utili e compariranno più spesso nel vostro codice saranno senza dubbio spr e btn , rispettivamente per disegnare a schermo uno sprite con vari parametri e per rilevare la pressione di un tasto. Nel codice di default vediamo infatti che a seconda del tasto premuto rilevato con btn (0 = freccia su, 1 = freccia giù, 2 = freccia sinistra, 3 = freccia destra) vengono alterate due variabili globali x e y. Successivamente al rilevamento dell'input, viene eseguito il disegno tramite la funzione spr , passando l'indice dello sprite e le nostre due coordinate x e y, fresche di modifica se un tasto è stato premuto. Questo primo frammento di codice, interpretabile anche dai principianti più assoluti, contiene altre istruzioni come cls ("clear screen", con un parametro che indica l'indice del colore di riempimento) o print (che stampa un testo alle coordinate specificate). Partendo da queste poche istruzioni arrivare a buoni risultati è molto rapido e intuitivo rendendo TIC-80 un buon strumento anche per la realizzazione di prototipi. Spingendosi oltre le limitate possibilità tecniche della macchina, lo sviluppatore può andare ad agire direttamente sulla RAM con le funzioni peek e poke , realizzando effetti particolari (palette swap, screen shake) e rendendo via via tecnicamente più avanzato il gioco stesso.

Wow gran bel post @Stavros ! Bello questo TIC-80! Un paio di domande: Su quali piattaforme è possibile esportare il gioco? Tu da quant'è che lo usi?

davcri ehi grazie! Io lo uso da quasi un annetto 😉 Per quanto riguarda l'esportazione: è possibile esportare un'applicazione nativa Windows, quindi il classico .exe, oppure in HTML5, ottenendo un file .html che contiene l'intero gioco compreso di interprete. Nel futuro sarà possibile esportare nativamente per Android, ma è una feature che non è ancora stata messa in roadmap. Non ho specificato una cosa: TIC-80 gira anche su piattaforma Android, quindi se si riesce potenzialmente si può sviluppare su qualsiasi telefono 😎

La versione normale di TIC-80 permette di esportare i giochi su tutte le piattaforme ma... ad esempio su Pc premendo ESC si ritorna alla console dell'interprete che permette di leggere, modificare l'intero gioco. In pratica TIC-80 "pacchettizza" interprete + cartuccia (gioco) che viene avviata automaticamente. Per evitare modifiche al proprio gioco dovete compilare il sorgente su github creando la versione PRO, che permette di non accedere ai contenuti del vostro gioco (nel caso vogliate pubblicare il vostro lavoro finalizzato alla vendita). @Stavros Si, puoi sviluppare anche su dispositivi mobile (anche se bisogna avere fegato per scrivere con la tastiera virtuale), TIC-80 è davvero molto bello (anche più di Pico-8 secondo me), manca soltanto la ciliegina sulla torta... Documentazione completa, più tutorial finalizzati alla realizzazione di giochi semplici come: platform, shoot'em up e rpg stile Zelda. Utilizzo TIC-80 e mi piacerebbe molto vederlo crescere. Ho suggerito a Nesbox di implementare una variante del BASIC (QBASIC come stile sintattico), magari partendo da LUA come base iniziale 🙂 ovviamente sono spuntati personaggi strani che hanno gridato allo scandalo ___ poi hanno implementato Wren, Javascript che usano la OOP. Il bello di Lua è la proprio la sua estendibilità, lo puoi modellare come vuoi, implementarlo facilmente in progetti C, C++, ma stranamente nessuno ha mai realizzato un tool realmente facile e alla portata di tutti per realizzare semplici giochi. Ad esempio io adoro Love2D ma ha il grande difetto di essere poco documentato, oltretutto male, e con materiale vecchio di secoli. Oltre a questo ti ritroverai dopo poco a scrivere il tuo gioco con una forma abbastanza (low level) che a mio avviso è poco indicata ai principianti e quindi agli hobbysti. TIC-80 si pone come uno strumento per nostalgici capace di emulare una console/computer anni 80 in grado di sviluppare videogiochi dell'epoca. Al suo interno hai tutto! Editor di codice, Editor per disegnare sprites, Editor audio per creare suoni e musiche in stile 8-bit. Ha un grande potenziale, è rivolto ad appassionati e hobbysti. Renderlo più accessibile e facile per tutti non è un'impresa! basta creare una bella API interna che permette di scrivere meno codice e semplificare gli eventi del proprio gioco. Allo stato attuale TIC-80 è indicato soltanto ad utenti esperti che da anni studiano vari linguaggi di programmazione e hanno una pazienza infinita (tipo il sottoscritto). Non avete idea di quanti ragazzi mi hanno scritto chiedendomi consigli su come utilizzare TIC-80, ma la mia risposta era sempre la stessa (Lua è un linguaggio privo di documentazione, molto minimale che non posside neppure una libreria standard al suo interno, nato principalmente come linguaggio script integrato in progetti C, C++. Il mio consiglio è quello di studiare Python che è molto simile, molto facile e possiede una grande community e tanta documentazione. Imparare Python richiede un'arco di apprendimento molto veloce, una volta apprese le basi di questo linguaggio passare ad altri linguaggi come Lua sarà una passeggiata). P.S. Ho scritto una guida per LUA sapete? vorrei condividerla da tempo ma non trovo mai il tempo di completarla (ho tutte le bozze complete revisionabili e revisionate parzialmente), se qualcuno è interessato alla cosa sarei felice di pubblicare il progetto su Github per collaborare alla sua stesura completa. Il manuale è scritto interamente in LaTeX (utilizzo TexStudio ovviamente), sarebbe molto utile per tutti coloro che vogliono smanettare con TIC-80, Love2D, Corona SDK (che io evito come la peste), Amulet (framework per Lua sperimentale molto valido), e altro ancora. @Stavros Tu hai tirato su qualche progettino con questo tool? io non amo particolarmente Lua 😉 ho sempre avuto un rifiuto psicologico verso il sistema di tabelle. In pratica è un linguaggio minimale che utilizza una forma OOP ibrida. Moonscript (linguaggio fork di Lua) ha molto più senso secondo me e rende la sintassi più facile per tutti quelli che hanno costruito le proprie basi da linguaggi come C, C++, Java, Python, Ruby. Un saluto a tutti.

XenonLab Hei grazie per il tuo commento! Analizzerò i vari punti che riporti, almeno quelli su cui ho qualcosa da dire 😉 Le esportazioni al momento supportate sono native per Windows e Html, ma non esporta nativamente Android (che è in programma ma non ha una deadline specifica). La questione di esportare il prodotto senza editors è attualmente ancora in via di sviluppo, anche per la versione PRO (parlo di versione 0.60.3). Per quanto riguarda i tutorial, ce ne sono parecchi (ad esempio sul github ufficiale ), almeno per gli aspetti basilari dei generi più classici (platform e shootemup) ma di fatto le cose da "imparare" sono davvero poche, data la natura spartana della piattaforma. Inoltre la fonte di conoscenza più utile è il Discord ufficiale . Certo una guida passo passo per arrivare allo Zelda di turno non esiste ma credo che l'utilizzo di questo software per la realizzazione di giochi commerciabili non fosse tra le idee che componevano la filosofia di Nesbox, almeno all'inizio, visto che ora è in programma. Per quanto riguarda OOP o no: sinceramente, avere un linguaggio OOP non mi fa schifo, permette di ragionare in modo molto più moderno e simile a quanto faccio già per lavoro. Ovviamente per motivi didattici/storici più linguaggi ci sono meglio è 😉 Quindi non disdegno nessuna aggiunta diciamo! Non sono convinto che allo stato attuale sia utilizzabile con profitto solo da esperti o gente con pazienza infinita, secondo me la curva di apprendimento è molto bassa. Certo, per andare a creare cose più complesse ci vuole tempo, ma uno Space Invaders lo tiri su in mezz'ora (grafica e suoni compresi). Sì ho creato qualcosina, di fatto mi ci perdo via abbastanza ( JousTIC e PrehistorTIC ).

Purtroppo chi come me ha iniziato con linguaggi come Pascal, Basic, la OOP non è il massimo. Oltretutto la OOP nasce per rendere più semplice l'organizzazione di progetti molto grandi con decine di migliaia di linee di codice. TIC-80 emula una piattaforma anni 80, negli anni 80 si utilizzava la programmazione funzionale (se ti andava bene), quindi per come la vedo io un linguaggio funzionale con la dichiarazione dei tipi (simile a Python e GDScript per intenderci) la trovo molto più coerente come scelta, e risulta molto più facile per gli appassionati che vogliono "giocare" con questo tool. Come tu stesso hai fatto notare lo scopo di TIC-80 non è quello di realizzare un tool professionale volto all'industria oppure finalizzato alla distribuzione commerciale di titoli indie. Quindi approcciare un sistema complesso che richiede molto studio, pazienza, ed esperienza alle spalle non ha molto senso. Anche per me TIC-80 tutto sommato non è difficile, ma io e te non siamo utenti della domenica 🙂 Sarebbe bello rendere TIC-80 uno strumento giocattoloso per bambini, per dare modo a loro di imparare senza dover combattere con aspetti logici troppo complessi che nel 70% dei casi porterebbero i suddetti ad abbandonare i loro "piccoli" sogni di gloria. Condivido pienamente quello che hai scritto, ma TIC-80 non è SFML, non è Irrlicht, non è Pygame, e neppure Cocos 2D... A volte i sviluppatori realizzano prodotti fantastici, con un grande potenziale alle spalle ma dimenticano l'aspetto più importante di tutti... la semplicità! l'utilizzatore finale non è necessariamente un programmatore e non è neppure un'esperto di informatica in generale. Quindi diamo a Cesare quello che è di Cesare 😉 Spero di non essere frainteso, ma vorrei tanto un mondo colorato, dove ognuno ha la possibilità (in base alle proprie conoscenze) di tirare fuori un coniglio dal cappello senza necessariamente essere uno stregone con esperienza ventennale XD Ho notato che hanno cancellato alcune cose riguardo al procedimento di compilazione?!? qualche mese fa inviavano commit quasi giorno per giorno mentre adesso sembra tutto piuttosto fermo?!? spero che riprenda il ritmo di allora, il progetto è molto interessante e si trova ad un buon livello di sviluppo. Se migliorano 3/4 cose diventa un bel giocattolo per nostalgici. I tuoi giochi sono molto carini, la difficoltà di PrehistorTIC lo eleva a Rage Game XD

XenonLab guarda, mi trovi in disaccordo su quasi tutto 😆 Soprattutto con l'eccessiva difficoltà di OOP: anche io ho cominciato con Pascal e (Visual) Basic... Ora per lavoro utilizzo ogni giorno linguaggi OOP e non ho avuto problemi nella transizione. Un'opportunità in più non è mai qualcosa di negativo, anzi da scelta. Inizialmente non era lo scopo, ma perchè non rendere TIC-80 una piattaforma capace di soddisfare anche richieste più "professionali"? Già ora è giocattoloso, perchè davvero mettere due robe a schermo è un attimo, letteralmente un attimo, manca quel piccolo scalino per ottenere delle produzioni commerciabili. Vedi pico-8, che permette di realizzare prodotti effettivamente vendibili e che hanno appeal 😉 E tutto si ricollega al discorso linguaggi: più linguaggi vuol dire più sviluppatori che producono grazie alla loro esperienza pregressa in questo o quel linguaggio, permettendo più numeri e quindi, di riflesso, più professionalità. Si Nesbox è impegnato su un altro progetto, la 0.70.0 dovrebbe essere rilasciata prima di fine anno comunque! 😉

Ok, il tuo discorso non fa una piega, ma allora che senso avrebbe un linguaggio come Wren e lo stesso Lua? tanto valeva tenere Javascript che oltretutto è quello maggiormente diffuso e utile allo scopo potendo contare su un numero impressionante di librerie e documentazione varia. Wren chi lo usa? è un linguaggio nuovo, non ho mai capito che senso ha in TIC-80... se mettono Python allora le cose prendono una piega decisamente migliore (parlare di prestazioni per giochi in stile 8-bit su macchine attuali mi sembra un discorso inutile). Avere più linguaggi in un tool molto spesso porta confusione e problemi di vario genere (tutorial e documentazione). Per come la vedo io tanto valeva implementare una variante di Lua con sistassi del C senza puntatori, faceva molto più anni 80, e permetteva anche di imparare da un linguaggio che ancora oggi è un riferimento assoluto. Oppure (meglio ancora) Python che io stesso ho suggerito ma subito scartato perchè "poco performante" come se con TIC-80 ci puoi fare il nuovo Fallout XD Manca che implementano il C#, tanto lo hanno già messo in Godot (e solo dio sa il motivo). Poi ovvio che è una mia opinione personale. Ma la programmazione OOP non è per nulla facile da assimilare, soprattutto se la utilizzi con linguaggi anomali come Lua e Wren non trovi? io ho imparato le basi con Java e C++ che alla fine utilizzano la forma standardizzata della OOP, con Pythn ci ho messo un pochino ad assimilare la cosa, perchè Python tende a voler semplificare alcuni aspetti come classi, istanze ed ereditarietà e ci riesce bene! TIC-80 è sviluppato principalmente da Nesbox che fa un gran bel lavoro, ma stranamente la community fatica a crescere. Ripeto è un mio parere personale, ma a conti fatti ho parlato con molta gente che ha comprato Pico-8 e scaricato TIC-80 e poi li ha accantonati in favore di roba come Pygame e Love2D. Il tuo gioco (PrehistorTIC) in Pygame lo fai con un numero equivalente di linee di codice (più o meno in base alle librerie che utilizzi). Con BeepBox mi creo i suoni e le musiche in stile 8-bit, oppure le trovo su opengameart, i sprite li disegno con Aseprite e piskel, e distribuisco il mio giochino usando pyinstaller su tutte le piattaforme desktop. Alla fine il mio concetto è semplice: creare una propria dimensione dove l'utente sceglie un determinato strumento che si distingue da tutti gli altri. Ultimamente nascono Game Engine come funghi, ne trovo tantissimi tipo Banshee, un paio cinesi che non ricordo il nome, e altri ancora che seguono la scia di unity e soci, ma... sono destinati a rimanere nell'anonimato ancor prima di essere rilasciati come prodotti stabili. Pico-8? si ha lanciato la moda e devo ammettere che è una delle trovate più cool degli ultimi tempi. TIC-80 è molto meglio! ha più memoria, meno limitazioni e un potenziale maggiore (Pico-8 ormai vende e come tutti i software che vendono si trastulla beato). Il bello di stare qui? scrivere le proprie opinioni, critiche, consigli e tutto ciò che può essere utile alla community. Tutto ciò può solo giovare alla distribuzione e alla curiosità dell'utente interessato che vuol capire cos'è TIC-80 e soprattutto perchè è la scelta giusta per lui. Per quanto mi riguarda è cross-platform e lo porti su dispositivi mobile quindi non è poco.

XenonLab Ma siamo d'accordo che esistono strumenti migliori anche per prototipare, ma sinceramente è più immediato utilizzare TIC-80 che Pygame o Love2D, in quanto la configurazione (scaricare cose, installarne altre, controllarne altre ancora) è inesistente, lanci l'eseguibile e hai tutto (TUTTO) lì. Detto ciò chi si sogna di fare prodotti commerciabili con una fantasy console mi sa che sta puntando il fucile senza guardare. Se poi si mette a usare Pygame o Love2D per sopperire alle mancanze delle fantasy console spara proprio alla cieca, allo stato attuale delle cose. Certo esistono giochi e giochi, ma da li a dire che avere più scelta è una "perdita" ne passa. Ovvero vuoi usare Love2D farti gli sprite in Piskel e usare BFXR per i suoni? Buon per te, ma non dirmi che democratizzare la cosa con uno strumento come TIC-80 è negativo. Per quanto riguarda OOP: mi spiace che la tua esperienza sia stata così negativa, ma penso sia abbastanza soggettivo 😉 E poi dai Lua non è neanche OOP 😆

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.

XenonLab Si ma editare ogni giorno il messaggio aggiungendo cose non è una good practice, FYI. Passando al commento non risponderò oltre, la mia opinione riguardo TIC-80 penso sia molto chiara, rileggendo quello che ho scritto. Quello che non è chiaro è il tuo parere e anzi sembri avere le idee un po' confuse, passando da "TIC-80 uber alles" a "TIC-80 meh" senza motivare praticamente queste critiche e nel giro di poche ore... Registriamo i tuoi dubbi: se vuoi passare su discord a parlarne sei il benvenuto 😉

TIC-80 (fantasy-console)

davcri

Ho joinato sul server Discord delle fantasy console! Nel weekend se ho un po' di tempo lo provo questo TIC-80 🙂

« Previous Page