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 240×136
- Palette a 16 colori
- 256 sprite di dimensione 8×8
- 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 😉
Salve. Ho aggiornato il messaggio perchè volevo dare quante più informazioni possibile a tutti gli utenti che passano da qui interessati all’utilizzo di TIC-80. Ho solo testato tutte queste fantasy console, e ritengo TIC-80 la più complicata tra tutte. Non sviluppo giochi per lavoro ma per semplice passione, e TIC-80 secondo il mio parere non è adatto all’uso hobbistico, almeno non allo stato attuale.
Passerò su Discord, cosi avrò occasione di parlare direttamente con voi, e magari mi tolgo qualche dubbio.
Un saluto 😉
Il mio giochino procede felice… ma ho un quesito, anzi due:
[1] Come faccio a dare la trasparenza ai sprites? come potete notare alcuni tendono a riempire lo sfondo di nero.
[2] vorrei ordinare i layer, cioè il player sempre in primo piano, NPC un livello sotto il player, infine elementi del livello tipo layer 0.
Si può fare? perchè non trovo nulla sulla wiki, oppure sono io che sto invecchiando male 🙂
XenonLab ehilà! Ma allora vedi che esprimevi dei pareri senza conoscere a fondo il tool? 😛 A parte gli scherzi ora ti do qualche suggerimento su quanto chiedi.
Come faccio a dare la trasparenza ai sprites? come potete notare alcuni tendono a riempire lo sfondo di nero.
Semplicemente indicando nella funzione spr il parametro colorkey (il 4 parametro). Questo parametro accetta un intero che va da 0 a 15 (ovvero i possibili indici dei colori nella palette). Se lo sfondo della tua sprite è di colore nero (ovvero l’indice 0 nella palette di default) basterà specificare 0 come colorkey e il colore nero non verrà disegnato. Attenzione: qualsiasi pixel di colore uguale alla colorkey non verrà disegnato. Nella wiki è specificato tutto.
vorrei ordinare i layer, cioè il player sempre in primo piano, NPC un livello sotto il player, infine elementi del livello tipo layer 0.
L’esecuzione del codice all’interno della funzione TIC() rispecchia l’ordine in cui le istruzioni sono scritte, perciò per “ordinare” il disegno dei vari componenti basterà ordinare le istruzioni di disegno (da eseguire solitamente dopo l’elaborazione di fisica, comportamenti e altro). Quindi se vuoi il player sopra a tutto, basterà disegnarlo per ultimo 😉
Grazie @Stavros e scusa se posso sembrare noob, ma sarai daccordo con me che è facile farsi sfuggire queste perle 🙂 avevo quasi intuito queste cose ma usavo una logica diversa, cioè la chiamata ad una funzione specifica oppure un metodo delle API interne. In parole povere legge le chiamate degli sprites in ordine decrescente?
Per la logica dei colori ok, questo l’ho capito al volo, ma non avevo intuito il sistema per applicare il canale alpha alle immagini. Prendo appunti perchè molto spesso mi perdo in cose banali e ragiono in modo troppo complicato.
Grazie mille.
XenonLab si tratta di semplice “ordine” di esecuzione.
Immagina di avere 3 sprite (con indice 100, 101, 102). Vuoi disegnare queste sprite con questo sistema di “layer”: 101, sopra la 102, sopra a tutti la 100. Ecco allora che banalmente avrai queste chiamate.
spr(101, x1, y1)
spr(102, x2, y2)
spr(100, x3, y3)Non mi sembra per niente complicato 😉
Ci vuole tempo per padroneggiare un minimo il tool, sono d’accordissimo. Quello che trovo strano è che tu esprima determinati pareri senza conoscere bene (non al 100%) il tool.
Ti invito a seguire il tutorial che ho preparato: ecco il link e se alla fine hai ancora qualche dubbio ne parliamo 😉
Ho capito perchè diavolo non mi funzionava 🙂 in pratica lo sprites editor di tic-80 ha 2 schermate per raggruppare gli sprites FG e BG. Io ho disegnato tutto in FG, a parte il cuore per rappresentare le vite del giocatore e altre 2 cose. Non mi applicava la trasparenza dato che inserivo gli sprites tramite map editor utilizzando gli oggetti raggruppati in FG. Ho fatto copia e incolla su BG e adesso funziona!
Non sono del tutto noob, andavo con la logica di pico-8 e rimanevo fregato 🙂 tic-80 è fantastico ma confermo che si può semplificare non poco! ho scoperto questa cosa per caso, osservando lo srite del cuore ho notato che applicava correttamente la trasparenza e mi sono fatto 2 domande 🙂
Grazie per l’aiuto 🙂 io invio un bel feedback a nesbox, magari gli gira bene e mi ascolta 😉
XenonLab ti ricordo che anche la funzione map ha il parametro colorkey per definire un colore da rendere trasparente!
Ho risolto tutto, grazie. Confermo che tic-80 è bello ma 3 cose in croce le migliorerei nel codice. Ho trovato uno strano bug, in pratica se converto il valore di due variabili:
x,y=y,x
A volte mi crasha. è successo anche ad un’altro utente quindi immagino che sarà risolto nella prossima release (la milestone è attualmente all’85%).
Scrivo un piccolo tutorial basato sul mio giochino, può essere molto utile alla community dato che i tutorial attuali sono fuffa spicciola 🙂
Un saluto 😉
XenonLab wow! Postalo anche qui una volta che l’avrai completato 😉
