Ale-Gap
-
Numero contenuti
73 -
Iscritto
-
Ultima visita
-
Days Won
5
Risposte pubblicati da Ale-Gap
-
-
Hmmmmmm
Okay, diciamo che avete un po' dissipato le mie perplessità, però cavolo è stato un parto riuscire a capirci eh! Vi devo sgridare più spesso, così ci capiamo subito
@Miha imperatrice del forum? XD
No a parte gli scherzi, penso come Just che la struttura a nodi sia la migliore, ma capisco le perplessità di Miha e Ghost...
Nelle mani sbagliate un event editor a blocchi può dare luogo a grovigli inleggibili... Nel dettaglio sto pensando che si potrebbe trovare una soluzione per aiutare gli utenti più inesperti ad approcciarsi a tale editor... Per esempio una modalità di "piazzamento blocchi guidato"? Dove il nuovo blocco viene piazzato subito dopo il precedente...
Una soluzione per agevolare la creazione di un evento a quegli utenti più inesperti si potrebbe trovare...
Ghost Rider reacted to this -
Miha, anch'io all'inizio avevo qualche perplessità sugli eventi, ma fidati se ti dico che in realtà è veramente facile e intuitivo
-
Si, posso confermare: mentre tileset e charset sono quelli di XP, in realtà il tool è tutto un altro mondo!
Se vogliamo, per come sta nascendo a mio parere può essere un "le cose migliori dei vari rpg maker, con qualche chicca in più (chicche notevoli, per altro)"
Thejuster e Ghost Rider reacted to this -
Ok adesso mi tocca ripescare le vecchie dispense, a patto che abbia ancora qualcosa della terza superiore
Dannati dubbi XD
Hahaha No dai, ti basta una piccola ricerca su Google, tanto a livello pratico è sufficiente sapere "che cosa" puoi mettere nella variabile non tanto come questa è costituita
-
@@kaine Esatto: Float è un'abbreiviazione che sta per "floating point", quindi sì: sono i valori a virgola mobile. Che poi si usi la virgola o il punto varia un po' tra i vari linguaggi, di norma il punto (come nella notazione USA)...
Non conosco il LUA, ma a occhio (senza scendere troppo in tecnicismi inutili) è un linguaggio molto semplice: è imperativo il che vuol dire che il modo con cui si costruisce uno script è piuttosto lineare, inoltre possiede elementi della programmazione a oggetti, che vuol dire che certe funzionalità sono semplificate attraverso particolari costruzioni del linguaggio (es: per stampare a video è sufficiente usare "io.write(...)", senza richiedere che il programmatore includa manualmente librarie necessarie come accadeva in C) e fu pensato sin dalla sua creazione per creare vidogame, quindi sono sicuro che abbia già implementate delle funzioni adatte all'utilizzo che ne faremo noi
Spero che le potenzialità e soprattutto la semplicità del linguaggio possano far sì che molti non programmatori possano interessarsi e magari sperimentare qualcosa in questo senso!
Ottima scelta Just!
-
Benvenuto!
Spero che questa comunity possa piacerti e venirti in aiuto ogni volta che vorrai!
Quoto Ghost: Non tutti sono bravi disegnatori, per fortuna online si trovano molte risorse per i tool vari della saga di rpg maker, quindi ci si arrangia!
-
Non è una vera e propria notizia, ma volevo comunque comunicarlo a chi fosse interessato, Some Fairy Tales potrebbe riaprire a (relativamente) breve periodo.
Dopo la sua chiusura SFT è diventato una campagna Pathfinder openworld-sandbox che sto giocando con un gruppo di amici. Seguendo tale adattamento la trama e i protagonisti sono cambiati, ma non il suo stile e la "poetica" legata al gameplay.
In realtà è ancora presto per parlare di una possibile riapertura: il nuovo tool di sviluppo sarà il MIRE, quindi SFT non riprenderà definitivamente finché tale non sarà rilasciato, e dall'altro lato preferirei essere cauto prima di parlare di una riapertura concreta dei progetti, poichè come universitario non godo di molto tempo libero
Modifiche importanti legate alla trama e al gameplay che posso anticiparvi con sicurezza sono:
Nuovo cast di protagonisti (derivante dal mio gruppo di gioco) quali:
- Shaboom il monaco libertino;
- Mordred il mezzorco inquisitore;
- Blixtra lo gnomo evocatore;
- Richter il mago subdolo.
Rielaborazione della trama:
- Ora le tre trame sono state unificate in un unica fabula divisa in episodi, maggiori dettagli sono ancora da definire.
Rielaborazione del gamelay:
- Il sistema non sarà più basato sul d20 system il quale a mio parere non è adatto a un videogame.
Vi sono due possibilità, la più concreta: Gameplay jrpg classico battle system a turni con visuale laterale.
Quello che vorrei io: battle system ibrido con elementi di gameplay derivanti da Warcraft III, The Legend of Zelda, Pokemon e Fire Emblem, in cui le meccaniche di giochi più prettamente tattici si arricchiscono ad elementi rpg, puzzle e action (ancora in dubbio se a turni o real-time)
Non sono in grado di fornirvi altre notizie, soprattutto per questioni di ancora "inconsistenza" del progetto...
Prendete ciò che ho detto come "rumors" di terze parti, poichè è ancora presto per essere concreti, ma la speranza è tanta e pure la buona volontà
MrSte reacted to this -
Mannaggia regaz!
Voi non dovete farli 'sti scherzi che io puntualmente ci casco in pieno!
Che dire: aspetto una build solida per rimettere le mani su Some Fairy Tales (Ok: adesso l'ho confessato
)Ghost Rider e Thejuster reacted to this -
NO! Just!
Hai tra le mani un ottimo tool e chiudere ora sarebbe veramente un peccato!
E' vero: concordo ampiamente su tutta la linea riguardo le tue considerazioni: il mondo degli mmo è andato in caduta da ormai un po' di tempo, ma allo stesso modo è anche vero che hai creato un tool di ottime potenzialità: io per primo (e come me credo molti altri) sono stato attirato non tanto dalle possibilità multiplayer, quanto dai risultati ottenuti dal tuo progetto anche sul fronte single player! Parlo del map editor, dell'illuminazione sulle mappe, gestione degli eventi e di tanto altro ancora!
Nella tua posizione io valuterei piuttosto l'opzione di deviare il progetto su un fronte più puramente single player con eventualmente un modulo online per il multiplayer.
E' vero che di tool per la creazione giochi ce ne sono molti, ma è anche vero che di molto semplici da usare ce ne sono pochi (credo solamente rpgmaker) e che spesso non soddisfano tutti i requisiti desiderati dai maker che non masticano troppo i linguaggi di programmazione o che vorrebbero qualcosa di migliore (o semplicemente diverso) rispetto i tool proposti dalla Enterbrain.
Se fossi in te prenderei in considerazione queste opzioni e proverei a portare a termine il progetto, anche solo per dare una risposta open source al mondo del making con quello che prometteva di essere un ottimo tool!
Thejuster e Ghost Rider reacted to this -
E' un'epoca che non scrivo e questa mi sembra un'occasione buona. Il tool mi sembra davvero ottimo!
La scelta del Lua (per quanto sia un linguaggio che non conosco) mi sembra molto azzeccata dato che già a una prima occhiata risulta molto semplice e intuitivo e credo sia così anche per qualcuno nuovo nell'ambito dello scripting, senza contare che se ricordo bene dai post vecchi (prendetelo con beneficio d'inventario) è un linguaggio compilato, il che lo rende più performante.
L'editor di mappe mi piace moltissimo! E se non è già presente ti consiglio di aggiungere opzioni per modificare la dimensione della griglia, così che ciascuno possa usare tiles del formato preferito senza dover modificare i propri per adattarli al tuo standard.
Se fossi in te inoltre porrei anche l'attenzione ai character oltre che ai tileset, ma voglio spiegarmi: non dico di includere un character generator, non è quella l'idea, ma dare la libertà a un utente di usare il formato di character che preferisce. Per esempio, capita spesso a un maker di non avere risorse e voler utilizzarne alcune da un gioco famoso che però sul web sono reperibili solo in un formato che non coincide con quello che ci serve (non formato di file, intendo come sono disposti i vari frame nell'immagine, quali frame usa, che dimensione hanno... esempio principe: la differenza tra i charset di rpgmk xp e quelli di vx).
Ora sarebbe interessante usare il nostro formato preferito senza dover affrontare un lavoro esagerato per convertire un formato all'altro.
Sarebbe improponibile avere un codice che riconosce il formato e si adatta in automatico, meno impossibile sarebbe invece avere un editor, molto simile a un map editor che usa il vecchio formato come tileset e ti permette di collocare le varie immagini in un formato compatibile con quello usato dal tuo tool.
So che l'operazione che ho descritto potrebbe essere banalmente eseguita con un qualunque programma di grafica, sia paint che gimp che photoshop, ma avere un editor incorporato del genere è comunque un valore aggiunto che velocizza il lavoro, inoltre sono sicuro che a tale editor si possano aggiungere un considerevole numero di funzioni (a esempio e questo supportasse più layer si potrebbe ottenere un ottimo character generator).
Comunque capisco benissimo che la cosa possa non interessarti causa mole di lavoro e tempistiche, semplicemente butto un'idea che spero possa interessare.
Per il resto che dire? Continua su questa strada! Sono molto interessato al progetto, attendo una versione stabile e a conti fatti se devo rimettermi al lavoro su un gioco utilizzando un nuovo tool sceglierei più volentieri questo che MV per molti motivi! Ti aiuterei molto volentieri Just soprattutto come beta tester o scripter, ma come evidente (vista la mia prolungata assenza dal forum) non ho molto tempo libero per makerare e scriptare per conto mio, spero almeno di fare un salto sul forum più spesso.
Ghost Rider e Thejuster reacted to this -
Le notizie che ho letto non fanno che rendermi ancora più interessato!
Ho provato la demo, ma non mi ha entusiasmato molto... più che altro perchè non adoro le ambientazioni sci-fi negli rpg (non me ne vogliate) e devo poi aggiungere che la grafica che hanno usato è quel che è...
Mi lascia perplesso il prezzo: 80 euro li trovo abbastanza eccessivi per il tipo di prodotto il che è proibitivo per molti (a mio parere)...
-
E' un'idea che non avevo preso in considerazione! Grazie!
-
Ciao ragazzi, domanda veloce veloce:
Conoscete dei tileset per la world map che siano sullo stile (o comunque non stonino) del materiale di Celianna?
Ho provato a usare quelli delle RTP e qualche altro, ma la gamma cromatica è così diversa che mi risulta come un pugno in un occhio...
Continuerò a cercare, ma se conoscete qualcosa ve ne sarei grato!
PS:
Anche materiale per l'Overlay mapping è ben accetto
PPS:
Mi accorgo ora del sub forum dedicato alle richieste... -.-" Sbadato come sempre...
-
Beh caro Mike, non c'è una risposta univoca alla tu domanda...
Posso raccontarti come ho iniziato io, come secondo me dovresti iniziare, ma non c'è una ricetta pronta e testata!
Supponendo che tu non abbia esperienze pregresse di alcun genere eccoti alcuni consigli che mi sento di dare sotto vari aspetti:
1) La trama:
Soprattutto nel caso in cui si tratti di un rpg la trama è centrale! Si parla role play, quindi di immedesimazione... almeno un pochino! Se hai una storia tua tanto meglio, altrimenti puoi utilizzare trame altrui, per iniziare non è un problema e se decidi di fare un gioco partendo da un film che ti è piaciuto nessuno ti dirà niente se anticipi che la trama sia altrui e non ne vanti l'originalità! (Questo a meno che tu non voglia vendere il tuo gioco, lì è un altro discorso... XP)
2) Il genere e il Tool:
Non è detto che tu debba creare proprio un rpg! Ci sono molti generi nel campo videoludico. Ricorda sempre però che ogni engine viene costruito pensando a un genere specifico, nel caso di RpgMaker è il jrpg! Esistono anche tool pensati per essere il più generico possibile con i quali puoi creare qualunque genere di videogame, parlo di titoli come Unity 5, Unreal Engine o anche banalmente il più abbordabile GameMaker, questi programmi ti permettono molti più sbocchi, ma sono anche molto più difficili da usare.
Dall'altro lato Rpg Maker invece ti permette di raggiungere ottimi risultati con molta meno fatica, quindi tienilo in buona considerazione perché come già detto è più potente di quanto appaia.
3) Fai piccoli passi:
Non fare l'errore di molti (me compreso) cercando di creare giochi fuori alla tua portata! Per creare World of Worcraft o (il santissimo) The Witcher 3 ci sono fior fior di programmatori, designer e ingegneri che spendono mesi della loro vita per ottenere risultati del genere! Non pensare in grande, non da subito almeno, parti con giochi molto semplici, brevi e facili da realizzare, avrai più soddisfazioni e nel frattempo imparerai sempre nuove cose!
3) Prova!
Sì, perché l'unica vera soluzione ai tuoi problemi è provare. Prendi il tuo be programmino e inizia a testare le varie funzioni! Cerca tutorial su youtube che in fondo non sono così inutili come può apparire e così vedi se ti piace e ci prendi la mano
Se poi vuoi sapere come ho iniziato io la storia è molto semplice! Sono un master di giochi di ruolo (D&D per l'esattezza), ero senza un gruppo, ma avevo molte storie da raccontare, così ho cercato in quel grande e confuso pentolone che è internet e ho scoperto Rpg Maker, col tempo poi h scoperto il forum e così ho iniziato a creare i miei primi progetti...
Spero di esserti stato di aiuto
-
Devo dire che vedere un nuovo tool Enterbrain mi mette buonumore, anche se confesso era un po' che attendevo la notizia speranzoso!
Spero che con l'uscita riesca anche a trovare il tempo per testarlo, perché sono davvero molto curioso di vedere cosa salta fuori!
Ovvio che non sarà mai ai livelli di Unity, la politica dell'Enterbrain è ben diversa puntando molto al creare un engine accessibile a tutti più che un engine potente, ma vedere che hanno abbandonato quell'insulso RGSS3 in favore di Javascript mi sembra quasi un peso levato dalla coscienza: finalmente si potrà scriptare tranquillamente senza dover imparare un linguaggio inutile (si ok, non un linguaggio difficile, ma comunque inutile).
Anche per l'assenza di classi nascoste la vedo alla stessa maniera, finalmente non serviranno 18mila script per risolvere problemi minori!
Il formato dei tile 48x48px è un valore che sinceramente a priori mi ha lasciato un istante perplesso: non è un formato facilmente riconducibile al 32x32px a cui eravamo abituati! Ma sinceramente lo vedo più come un dato di fatto che come un vantaggio o uno svantaggio... sì, bisognerà darsi un gran da fare per avere nuove risorse...
Lo stile quadrettoso delle loro risorse anche quello è da prendersi come dato di fatto, è così e rimarrà così! Il motivo della scelta credo possa essere molto banale:
1) Si tratta di un tool giapponese pensato fondamentalmente per poter creare jrpg, ovvio che vogliano restare fedeli ai classici 2D di genere;
2) Il mapping a quadretti è in assoluto il più semplice da realizzare, la scelta è in linea con la politica di creare tool di facile accesso che chiunque possa maneggiare!
Non mi sembra il caso di pretendere da Rpg Maker la potenza di engine più complessi, è vero che così ne si limitano le potenzialità (Per ora non ho mai visto un rpg maker in 3D e ancor di più mai giochi indie sviluppati con RpgMk di grande successo), ma è anche vero che non tutti hanno le conoscenze, le risorse e soprattutto il tempo per sviluppare usando tool più potenti. Nella mia modesta opinione RpgMk nel suo settore e nel suo piccolo resta un ottimo prodotto
Devo dire che MV mi incuriosisce davvero parecchio! Le novità già annunciate le ho molto gradite e spero vivamente ne inseriscano delle altre!
Spero anche che inseriscano molte risorse di default che non costringano l'utente a peregrinare per il Web alla ricerca di qualcosa di utile perché quelle quattro paginette in croce di Tiles del VxAce a mio avviso tutte uguali non le ho mai radite, nonostante facessero sempre comodo... (Questo sia nell'aspetto di Tiles, che dei characters)
Ho molta fiducia nel tool e nella promessa di personalizzazione del gioco da parte dell'utente! Spero che questa possa essere l'occasione buona perché riprenda a makerare seriamente!
Non come qualche tempo fa dove ho iniziato 500 progetti e conclusi zero -.-"
Spero di tornare sul forum il prima possibile
MrSte, Ally e Ghost Rider reacted to this -
Sono due tipi di approccio molto differenti... Personalmente non ho preferenze. Un testo a scorrimento controllato dal giocatore permette di regolare la velocità dei dialoghi, uno dialogo automatico dà un forte taglio cinematografico (che poi puoi coordinare con bgm, come già detto). Io sono cresciuto coi classici Nintendo dove il dialogo che procede a pressione di tasto è d'obbligo, aiuta a dare un ritmo molto pacato e ordinato all'esperienza di gioco. Un dialogo automatico invece se gestito bene rende il gioco molto più dinamico e ti permette di costruire anche cutscene più elaborate definendone meglio i dettagli.
Puoi anche mescolare le due cose (approccio che personalmente non amo, ma se fatto bene, efficace)
-
Il Lua? Un linguaggio di scripting imperativo? La cosa si potrebbe anche fare
Ok dai! Ci sto! Però tieni conto che faccio quel che posso: studio già Java e C++, il tempo libero è praticamente inesistente e quel poco volevo dedicarlo ai miei Pseudo-Tutorial... Però quando posso vedo di mettermici e guardarmelo per bene
-
Purtroppo ho già il mio bel da fare, quindi posso dare un aiuto limitato...
In che linguaggio sono gli script? Se è un linguaggio che già avevo intenzione di imparare posso offrirmi volentieri come "tributo" XD Altrimenti credo che dovrò passare la palla a qualcun'altro...
-
No pesante no. Ma penso che l'utente si ritroverebbe una lista immane di eventi.
Non necessariamente Just... Un'idea potrebbe essere quella di organizzare il tutto in maniera simile alla programmazione a oggetti... Del tipo che hai un oggetto, lo istanzi quante volte ti pare e poi per ogni istanza vai a definire i dettagli...
Se hai mai visto un tutorial di base su Game Maker potresti aver già capito a cosa mi riferisco...
Oppure un'idea alternativa sarebbe quella di etichettare ogni evento con una stanza e rendere visibili solo quelli "locali".
Per esempio tu a bordo finestra hai un 'mini menu' in cui puoi creare eventi che dal punto di vista dell'utente sono "locali" ed esistono solo in quella stanza, mentre in realtà sono globali ed etichettati in quella stanza!
Dopodiché tu anziché creare 2/3/4 eventi uguali tra loro potresti addirittura istanziare l'evento (ovvero creare delle copie autonome dell'evento che anche se eliminate non eliminano definitivamente l'evento originario -per chi non s'intendesse di programmazione-).
Ancora meglio sarebbe far si che lo stesso evento possa essere "copiato" in più stanze, dove in realtà la "copia" corrisponderebbe in realtà all'aggiunta di una nuova etichetta-stanza all'evento e tale evento fosse visibile anche nella nuova stanza (alias "mappa", il nome è abbastanza convenzionale)...
Con questo metodo avresti a livello di programma si: un'infinita lista di eventi globali, ma dal punto di vista dell'utente questi vedrebbe per ogni stanza solamente gli eventi che secondo lui ha creato in quella stanza. Inoltre potrebbe "copiare" tali eventi tra due stanze diverse (che con un sistema di etichette risulterebbe anche molto più leggero ed efficace di un reale copia-incolla) e potrebbe creare infinite copie dello stesso evento nella stessa mappa! (che in certi casi risulta veramente molto utile! Vedi la creazione di menu/BS a eventi)
EDIT: Mi accorgo solo ora che in buona parte era l'idea che avevi avuto già!
Effetti dello stomaco vuoto XD -
@@Freank Grazie molte, lo sapevo già in quanto la mail è arrivata anche a me
Sta di fatto che non credo proseguirò molto nell'utilizzo di game maker: sono più interessato a prendere confidenza con lo sviluppo in generale che con il linguaggio specifico, soprattutto in quanto conosco molto bene i suoi limiti...Per quanto riguarda Game Maker Italia sono già un utente, ma oltre a spulciarne gli archivi per trovare articoli che mi interessano non sono molto attivo... Proprio perché non sono molto un tipo da forum, già la mia presenza su makerando è molto limitata e continuo a postare soprattutto perché mi sono sempre trovato molto bene e perché è una piccola realtà in cui considero molti come amici
@@Ghost Rider Grazie mille!
Thejuster reacted to this -
@@Freank Grazie!
Per quello che riguarda Game Maker la risposta è no.Ho iniziato a lavorare con Game Maker solo da agosto, principalmente lo utilizzai quasi esclusivamente per lavorare a un mio vecchio progetto che attualmente è in stand-by. Infatti ci sono ancora molte funzioni del linguaggio che non conosco...
Proprio per questo la serie si chiama Pseudo-tutorial: io stesso sto cercando di studiare il GML come "trampolino di lancio" per iniziare a lavorare con altri linguaggi (In realtà sto già studiando altri linguaggi, ma sviluppare videogame è un'altro paio di maniche) e voglio condividere i miei risultati con chi potesse essere interessato!
Purtroppo so che questo magari non è il forum migliore per discutere di Game Maker, molti lavorano con altri tool e va benissimo così! Nonostante ciò vorrei incuriosire chi è attratto dalla programmazione, ma non sa da dove potrebbe partire e possibilmente coinvolgerli in una discussione su quale potrebbe essere la soluzione migliore al problema presentato.
@Ghostino Eeeeh hai troppa fiducia in me
Scherzi a parte, nonostante non possa garantire una periodicità in questo mio tipo di lavoro (causa studi), ho seria intenzione di continuare e sarebbe un grande onore avere una sezione tutta mia! -
Grazie del supporto JeanBis!
-
Consiglio a chi non l'avesse ancora fatto di guardare l'introduzione nel post precedente, per capire l'approccio da me utilizzato in questa serie di tutorial
Il problema dello sprite animato:
Ciao a tutti, questo è Link;
"Ciao, Link!" No, evitiamo, di cadere nella cazzata XP
(Chi sapesse già realizzare sprite in Game Maker salti lo spoiler)
Sta di fatto che come molti di voi sapranno in Rpg Maker per creare uno sprite animato in tutte e 4 le direzioni ci è sufficiente inserire per quello sprite un charaset che comprende tutti e 3 i frame da visualizzare e in tutte e 4 le direzioni per poter completare l'animazione nelle 4 direzioni.
In Game Maker la cosa è leggermente differente: si, possiamo creare sprite animati, ma la cosa risulta un po' più complessa nel nostro caso specifico. La funzione principale da utilizzare in questo caso è la "new sprite" quella con l'icona che sembra pacman
Non approfondirò nello specifico il funzionamento, ma la cosa evidente è il vantaggio che questa ci porta: Nessun vincolo di dimensione o formato, il che per un utente di Rpg Maker che aveva il formato obbligatorio può essere una grande liberazione! Possiamo utilizzare lo sprite che preferiamo senza che il tool ci dia problemi, basta impostarlo adeguatamente per le nostre esigenze!
E giungiamo così al nostro primo problema: abbiamo da realizzare un personaggio animato che ha 4 differenti direzioni, supponiamo di avere un personaggio con 4 disegni diversi per animazione (Lo standard per i characters di rpg maker): Come realizziamo il tutto? Esistono due soluzioni principali: Mettere tutti i frame (consentitemi il termine "sottoimmagini") in un unico sprite animato, oppure fare 4 sprite (uno per direzione) ognuno con la sua animazione
IO ho optato per la seconda scelta. Non che la prima sia peggiore, ma perchè per risolvere la prima e ottenere un risultato accettabile a tempo d'esecuzione bisognava passare attraverso un algoritmo matematico, non subito immediato per essere compreso e soprattutto molto scomodo da riutilizare nel corso del resto del codice.
A lavoro terminato dovreste avere un risultato del genere:
Per ora è più che sufficiente avere un frame per direzione, per l'animazione vedremo in seguito.
Il movimento del personaggio:
Ok passiamo all'argomento veramente interessante di oggi: la realizzazione di un movimento in 4 direzioni nei giochi Top-Down (insomma giochi con una visuale come quella di rpg maker).
Nel GML esistono 2 variabili fondamentali per il movimento:
speed
Esprime la velocità con cui si muove lo sprite in pixel/room_step.
Per vedere quanti Step ha la vostra Room basta andare a controllare nelle impostazioni (setting) della room stessa, come in figura:
La durata di un singolo step è di 1/(room_speed) secondi, poichè la Speed della stanza indica proprio il numero di Step che il programma deve eseguire in un secondo (quindi davvero un istante microscopico D:).Tenete bene a mente il concetto di Step perchè lo utilizzaremo varie volte.directionEsprime la direzione che lo sprite deve assumere mentre si muove in gradi (non ne sono sicuro, ma credo accetti solo valori interi, quindi sarebbe meglio evitare misure del tipo 58.6, anche se -ripeto- non ne sono sicuro).Per capire effettivamente a cosa coincidono le direzioni vi basti sapere che convenzionalmente lo 0 viene posto orizzontalmente verso destra, quindi:direction = 0; //indica verso destra direction = 90; //indica verso l'alto direction = 180; //indica verso sinistra direction = 270; //indica verso il basso
(Nota: il simbolo "//" denota un commento, utile al programmatore, ma ininfluente ai fini del codice)
Quindi l'idea sarebbe quella di far capire al programma che quando noi premiamo un tasto lo sprite deve andare in alto, quando ne premiamo un altro deve andare in basso ecc ecc.
Personalmente piuttosto che utilizzare le frecce direzionali preferisco utilizzare le lettere W, A, S, D. Ma come farlo capire al programma?
Innanzi tutto dobbiamo creare un oggetto che chiameremo Link per semplicità, gli diamo il uso bello sprite (uno a caso, per ora non ci preoccupiamo dell'animazione) e aggiungiamo un altrettanto bello Step Event, che quindi verrà effettuato ad ogni Step (ovvero 30 volte in 1secondo di default), in cui piazziamo il nostro codice:
if(keyboard_check(ord('W')) { direction = 90; speed = 2; } if(keyboard_check(ord('A')) { direction = 180; speed = 2; } // eccetera eccetera per ogni direzioneinput da tastiera
L'istruzione "keyboard_check(...)" controlla che venga premuto il tasto indicato restituendo un VERO o FALSO
In GML non esiste il tipo boolean, true e false sono equivalenti rispettivamente a 1 e 0, come in C sarebbe il codice:
typedef enum {false, true} boolean;Mentre l'istruzione "ord(...)" serve a indicare alle funzioni legate alla tastiera che è stata premuta una lettera (indicata in maiuscola da apici come 'A', 'B', 'C', ...) nell'Help di Game Maker Studio c'è la tabella completa dei comandi da tastiera).
Ottimo! A questo punto possiamo far partire il nostro programma e vedere il nostro personaggio cambiare direzione quando premiamo un tasto e vedere che si muove, ma... Come mai non si ferma più???
Beh, chiaramente il programma capisce quando noi gli diamo una direzione, ma non capisce quando ci dobbiamo fermare!
Come risolvere ciò?
Beh noi abbiamo i nostri Step, ce n'è uno ogni trentesimo di secondo, perchè non sfruttarli anche per far capire al programma non solo quando premiamo un tasto, ma anche quando non lo premiamo?
Abbiamo due opzioni: o sfruttare un algoritmo che capisca non solo quando il pulsante è premuto, ma anche quando non lo è (attraverso il costrutto IF-ELSE magari) oppure far sì che il programma resetti il movimento ad ogni Step ed effettui il movimento in seguito.
Effettivamente l'evento Step è un evento il cui contenuto viene ripetuto ad ogni singolo step...
potremmo quindi migliorare il nostro codice come segue:
//movimento var move_up, move_left, move_down, move_right, movement; move_up = false; move_left = false; move_down = false; move_right = false; vk_action = false; movement = false; move_up = keyboard_check(ord('W')); move_left = keyboard_check(ord('A')); move_down = keyboard_check(ord('S')); move_right = keyboard_check(ord('D')); movement = (move_up) or (move_left) or (move_down) or (move_right); speed = 0; if (movement) { speed = 1.5; if (move_up) {direction = 90;} if (move_down) {direction = 270;} if (move_right) {direction = 0;} if (move_left) {direction = 180;} }Dove la variabile movement è vera quando W,A,S oppure D è premuto.
In questo modo ad ogni Step vengono azzerati gli input da tastiera e la velocità di base del nostro sprite viene azzerata, poi Se uno dei 4 tasti direzionali è premuto allora 1) impostiamo la speed come se lo sprite si muovesse (in questo caso ho scelto che si muova di 1.5 pixel ad ogni step) 2) scegliamo la direzione del movimento in base al tasto premuto! Nulla di più nulla di meno!
L'animazione del nostro sprite:
Ok l'abbiamo mosso, ma come animarlo? Basta cliccare in una casella di spunta? Ahimè no...
Vediamo di fare un passo alla volta!
Il primo problema sta nell'associare lo sprite corretto alla direzione corretta (poichè abbiamo scelto di utilizzare la scelta con 4 sprite differenti).
L'idea sarebbe quella di far capire all'oggetto qual'è lo sprite iniziale che viene utilizzato e cambiarlo in base alla direzione scelta, a questo scopo sfruttiamo la variabile sprite_index.
La variabile sprite_index indica qual'è lo sprite utilizzato dal nostro oggetto. Cambiare la variabile comporta cambiare lo sprite utilizzato.
Potremmo dunque modificarla facendogli assumere il valore dello sprite che vogliamo ottenere quindi:
//animazione if (direction == 90) {sprite_index = 1;} if (direction == 270) {sprite_index = 2;} if (direction == 0) {sprite_index = 3;} if (direction = 180) {sprite_index = 4;}Ma come fare a sapere qual'è lo sprite 1, 2, 3, 4?
Per risolvere ciò ho implementato il codice come segue:
//animation sprite = sprite_index; if (direction == 90) {sprite_index = sprite+1;} if (direction == 270) {sprite_index = sprite+3;} if (direction == 0) {sprite_index = sprite;} if (direction = 180) {sprite_index = sprite+2;}Cosicché non è necessari conoscere il numero dello sprite, ma questo verrà calcolato da solo!
ATTENZIONE: in questo modo diventa cruciale l'ordine con cui avete memorizzato gli sprite!
Nel mio caso per semplificare le cose ho direttamente salvato gli sprite nell'ordine associato alle direzioni: right, up, left, down (poichè vi ricordo direction è 0 quando si fa riferimento alla destra).Ottimo! possiamo fare una prova allora! vediamo cosa succede!Provato? Sicuramente non abbiamo ottenuto ciò che speravamo...Perchè? Perchè il valore di sprite in questo modo cambia ad ogni passaggio, come cambia il valore di sprite index a ogni passaggio! Dobbiamo fare in modo che il valore di sprite sia costante dall'inizio alla fine e per fare ciò sfruttiamo l'evento Create che viene eseguito una sola volta alla creazione dell'oggetto. Come per Step, creiamo un evento Create e spostiamo nel codice di create la riga:sprite = sprite_index;
Problema risolto!
Non provate nemmeno a risolvere il problema cancellando semplicemente la riga di qui sopra! Pena....
Provate da soli!
Provato? Perchè fa così?
Beh perchè sta utilizzando un valore (sprite) che per lui non esiste! e quindi va tutto a farsi friggere!
Ora passiamo all'animazione vera e propria!
Riapriamo i nostri sprite e inseriamoci tutti i frame di cui abbiamo bisogno! Avviamo il programma e...
No, non proprio quello sperato...
E' il momento di introdurre un'altra variabile di sistema: image_speed che banalmente indica la velocità a cui si muovono i frame
Ciò è parzialmente inesatto... A differenza della variabile speed che indica i pixel/step, image_speed non indica i frame/step, ma il numero di cicli completi effettuati ad ogni secondo!
A questo punto la inizializziamo a 0 nell'evento Create per dargli un valore di default e guardiamo come modificarla in seguito.
Ok a questo punto bisogna dire al programma che SE il personaggio si muove, deve animarsi, se resta fermo deve restare al frame iniziale!
Ed eccoci qui:
//movement animation if (speed != 0) {image_speed = 0.9;} else {image_speed = 0; image_index = 0; }Come codice ha poco da commentare, 0.9 è la velocità dei frame quando non è fermo, quando è fermo ferma il ciclo dei frame e lo resetta a quello iniziale.
Un po' più interessante è la condizione dell'IF (speed != 0), avremmo potuto utilizzare la variabile movement e il risultato sarebbe stato altrettanto efficace! La scelta è puramente estetica, ve ne accorgerete poi quando avremo affrontato l'argomento delle collisioni. A programma completo vi consiglio di provare entrambe e valutare la differenza, lascio a voi capire perchè in una link si ferma contro il muro, nell'altra no...
Il dannato mostro delle colliioni:
Premessa: Quando mi ritrovai a questo punto ebbi molto da faticare! Fu per me uno scoglio moto duro realizzare un sistema di collisioni efficace! La soluzione non la trovai da solo, cercai un po' in giro e trovai qualcosa di soddisfacente solamente nel modulo della YoYo Games per gli Rpg, quindi l'idea dell'algoritmo è loro, io poi la rielaborai in base ai miei scopi.
Questo è il signor muro:
E vi dico sin da subito che lo odierete!
Ok: ovvio che quando il nostro amico Link incontrerà un muro non potrà proseguire bellamente a mo' di fantasma!
Dovrà invece fermarsi contro di esso e starsene lì, finchè noi pigri giocatori non ci accorgeremo che è ora di cambiare direzione!
L'idea sarebbe quella di mettere un controllo: SE Link è in contatto col muro, si deve fermare, altrimenti può proseguire, ci conviene quindi creare uno script da sostituire al semplice movimento per ottenere un controllo anche su eventuali collisioni.
Ovvero sostiuire il codice, da così:
speed = 0; if (movement) { speed = 1.5; if (move_up) {direction = 90;} if (move_down) {direction = 270;} if (move_right) {direction = 0;} if (move_left) {direction = 180;} }a così
//collision and movement var obj_speed; obj_speed = 0; if (movement) { obj_speed = 1.5; if (move_up) {direction = 90;} if (move_down) {direction = 270;} if (move_right) {direction = 0;} if (move_left) {direction = 180;} } move( obj_speed, direction, ...);Dove "move(...)" è il nostro script.
Ma che forma deve assumere questo script?
Dovrà sicuramente prendere in paramentro la direzione e la velocità che dovrebbe avere Link in questo momento!
Vediamo di elaborare l'idea un po' alla volta:
Prima dovrebbe controllare se ci sono collisioni nel punto in cui ha intenzione di muoversi, poi si dovrebbe muovere in quel punto!
Quindi il codice dovrebbe avere questa forma:
var move_speed, self_direction, obstacle; move_speed = argument0; self_direction = argument1; obstacle = argument2; switch self_direction { case 0: if !(place_meeting(x+move_speed, y, obstacle)) { speed = move_speed; } else { speed = 0; } break; case 90: if !(place_meeting(x, y-move_speed, obstacle)) { speed = move_speed; } else { speed = 0; } break; case 180: if !(place_meeting(x-move_speed, y, obstacle)) { speed = move_speed; } else { speed = 0; } break; case 270: if !(place_meeting(x, y+move_speed, obstacle)) { speed = move_speed; } else { speed = 0; } break; }Più facile di quanto via aspettavate? Già è stato così anche per me! Si tratta di un algoritmo molto semplice che sfrutta la funzione place_meeting per risolvere il problema della collisione e se poi non c'è collisione gli dà il permesso di muoversi, altrimenti costringe l'oggetto a stare fermo!
Peccato che senza un aiutino dall'alto arrivare a questo codice partendo da 0 e senza aiuti può essere davvero rognoso...
Il place_meeting sfrutta tre parametri, in ordine: x, y, obj_ dove x, y sono le coordinate del punto da controllare, mentre obj_ è l'oggetto con cui effettuare la collisione. la funzione restituisce 1 se nel punto specificato si presenta una collisione con l'oggetto obj_, 0 altrimenti.
Ottimo! ma ora dobbiamo risolvere un secondo problema, chi è quel "obstacle" con cui dobbiamo verificare collisioni? Ora chi di voi conosce i principi della programmazione a oggetti probabilmente avrà già capito dove voglio andare a parare...
Il tutto è basato sul meccanismo dell'ereditarietà.
Nell'insieme degli oggetti creato nel nostro progetto è possibile impostare una gerarchia: oggetti più importanti e altri oggetti che vengono considerati "figli" di quest'ultimi, i figli ereditano dai padri tutte le loro caratteristiche (Nota: un oggetto può avere UN solo genitore, ma tutti i figli che vuole), ma possono aggiungerne o sostituirne delle altre!
In questo modo posso indicare con "par_obstacle" un oggetto senza caratteristiche che verrà inserito come argomento della funzione "move" e impostare come suoi figli tutti gli oggetti (muri, alberi, case,...) contro i quali Link non potrà oltrepassare!
Ad esempio qui ho creato gli oggetti par_obstacle e wall_sample:
e ho impostato il secondo come figlio del primo:
cosicchè posso piazzare tutti i miei blocchi nella stanza e creare un muro attraverso il quale Link non passa!
Qualche ritocco finale:
Concludiamo con qualche dettaglio che può rendere il nostro primo progetto un po' più pulito
1) Sistemiamo il Creation Event
//setup var image_speed = 0; depth = -y; sprite = sprite_index;
Questo è il creation event completo.
Potete vedere che ho inizializzato tutte le le variabili cosicchè si evitino errori.
Ho anche aggiunto la variabile depth, che esprime la profondità dell'oggetto, a -y. E' un trucchetto figlio dei giochi a visuale isometrica, dove impostare depth a -y restituisce un'illusione di profondità nonostante si tratti di 2D.
Nello schermo o in questo caso stanza, per trovare le coordinate di un punto si utilizza un sistema cartesiano, nella fattispecie se l'apice sinistro dello schermo è l'origine si utilizza il 4° quadrante dello schermo e ogni pixel è un punto. Ne segue che più si va in basso dello schermo, più Y diminuisce. Utilizzando -Y si ha che depth aumenta andando verso il basso dello schermo, cosicchè più l'oggetto è in basso, più appare "in primo piano" nello schermo.
2) Anche lo Step Event ha subito un po' di pulizia:
//Controls & Movement //animation if (direction == 90) {sprite_index = sprite+1;} if (direction == 270) {sprite_index = sprite+3;} if (direction == 0) {sprite_index = sprite;} if (direction = 180) {sprite_index = sprite+2;} //movement var move_up, move_left, move_down, move_right, movement; move_up = false; move_left = false; move_down = false; move_right = false; movement = false; move_up = keyboard_check(ord('W')); move_left = keyboard_check(ord('A')); move_down = keyboard_check(ord('S')); move_right = keyboard_check(ord('D')); movement = (move_up) or (move_left) or (move_down) or (move_right); //collision and movement var obj_speed; obj_speed = 0; if (movement) { obj_speed = 1.5; if (move_up) {direction = 90;} if (move_down) {direction = 270;} if (move_right) {direction = 0;} if (move_left) {direction = 180;} } move( obj_speed, direction, par_obstacle); //movement animation if (speed != 0) {image_speed = 0.9;} else {image_speed = 0; image_index = 0; } //depth depth = -y;Anche qui depth è stato inserito, poichè chiaramente al muoversi del personaggio, cambia la sua "profondità".
Notare che l'ordine dei vari blocchi ha un'importanza, lascio a voi analizzare le conseguenze di un possibile spostamento di un blocco da un punto a un altro.
3) Infine questo è il nostro sample_wall:
Creation Event
//depth depth = -y;
Step Event:
//depth depth = -y;
Eh già, come i personaggi, anche gli oggetti devono rispettare la regola della profondità
E in 8 direzioni?:
E in 8 direzioni come cambia il tutto?
Vi posso dire che non è molto differente la situazione, ma perché non mi proponete idee voi?
Perché non provate ad azzardare qualche modifica al codice di qui sopra e provare a trovarvi delle soluzioni?
Ringrazio tutti voi per aver seguito questo topic, spero di esservi stato utile e vorrei esortarvi a trovare soluzioni differenti ai problemi che abbiamo affrontato e postarle qui sotto e spero anche di non essere stato incomprensibile a chi non abbia mai lavorato con un linguaggio di programmazione!
Fatemi sapere i vostri pareri e ci sentiamo al prossimo Pseudo-Tutorial!
Ale-Gap
-
Che cos'è GameMaker PseudoTutorial:
Vediamo innanzi tutto di fare una piccola divagazione sullo sviluppo videogame, vedrò di fare una panoramica generale e di non soffermarmici troppo (non uccidetemi per le baggianate che dirò XP).
Nello sviluppo videogame esistono fondamentalmente 3 "metodologie" per lo sviluppo:
- Motori Grafici ad alto livello: software che permettono di suddividere il lavoro a riguardo la progettazione e creazione di videogame, cosicché aspetti come grafica, animazione, programmazione, ecc. possano essere affrontati singolarmente (Es: Unreal Engine).
- Motori Grafici di basso livello (alias Tool di sviluppo rapido): software fondamentalmente simili ai cugini di alto livello, ma che semplificano nettamente il processo di sviluppo, portando l'utente a non doversi preoccupare di processi quali animazioni, input, ecc. perché questi ottenga comunque un discreto risultato senza avere conoscenze specifiche e velocizzando il lavoro. (Es: Rpg Maker, Game Maker)
- Linguaggi di programmazione: esistono linguaggi che per loro stessa natura hanno un "impianto" fortemente grafico e attraverso un corretto utilizzo si possono creare videogame senza l'utilizzo di software aggiuntivi (L'esempio principe è chiaramente Minecraft, il quale è stato interamente creato in Java).
E' evidente che tra Motori Grafici ad alto e basso livello vi è una grande differenza, che spesso e volentieri sta nella difficoltà con cui approcciarsi ai primi e nella semplicità di utilizzo dei secondi (ovviamente nei primi sono richieste anche competenze tecniche maggiori), ma è altrettanto comprensibile che la divisione tra engine di alto e basso livello non è così evidente e marcata: esistono numerosi engine che sono "vie di mezzo", ad esempio se Rpg Maker è utilizzabile anche senza conoscere minimamente la programmazione, Game Maker, seppur restando un Tool per lo sviluppo rapido, è già più "tecnico" e richiede un minimo di programmazione. Allo stesso modo Unity 3D è considerabile come un motore grafico di alto livello (Non uccidetemi per questo, so bene che ciò che dico è pieno di inesattezze XP), ma non è che una briciola difronte al Unreal Engine!
Come dicono al sud, però "nessuno nasce imparato"! E qui entriamo in gioco noi!
Partiamo da un presupposto: non esistono tutorial efficaci! Nessun tutorial vi insegnerà a risolvere certi problemi! L'unica arma di cui potete dotarvi contro mostri sacri come alcuni linguaggi di programmazione o alcuni software per lo sviluppo è l'esperienza diretta! Metteteci le mani dentro! Impastate il tutto e vedete cosa riuscite a fare! Mettetevi in gioco! Fate i vostri errori e sbatteteci la testa!
Io non sono un insegnante, non voglio essere ritenuto tale e non posso nemmeno vantare il titolo di programmatore! Sono un ragazzo come tanti voi che è interessato nell'argomento e voglio sporcarmi un po' le mani per capire e imparare!
Arriviamo quindi alla domanda cruciale: che cos'è GameMaker Pseudo-Tutorial? La quale è una domanda più che lecita: non è un tutorial, non è un corso di programmazione, non è un corso su Game Maker, che è???
Principalente a me piace vederlo come un PERCORSO. Un percorso che sto affrontando e che vorrei condividere con voi!
In questo percorso cercheremo di creare un piccolo Remake 2D di Zelda - Ocarina of Time che comprenderà esclusivamente la foresta Kokiri e il primo dungeon (per chi conoscesse il gioco).
In ogni post cercherò di affrontare un problema che si incontra nello sviluppo di tale gioco, lo esaminerò e vi proporrò la soluzione che ho trovato. Da notare bene che io vi proporrò la MIA soluzione, che NON è l'unica, né la migliore! Anzi! Vi invito fortemente a proporre ALTRE soluzioni al problema che potrebbero essere altrettanto valide rispetto la mia o addirittura migliori!
Perché fare ciò? per alcuni motivi: 1) cercare di fare assieme un percorso che affronta alcune delle tematiche che potreste incontrare nel corso dello sviluppo di giochi analoghi a questo; 2) Sfatare una convinzione comune secondo la quale con Game Maker non è possibile creare rpg, ma è pensato per i platform. FALSO! E' possibilissimo! Semplicemente è molto più difficile creare un rpg rispetto un platform! 3) Magari potrei incuriosire qualcuno di voi ad approfondire un discorso sui linguaggi di programmazione e magari farvi capire che la programmazione non è inapprocciabile come molti credono
E se non conoscessi Game Maker!?!?!?:
E' molto probabile che molti di voi non conoscano Game Maker e (ancora più probabile) che non conoscano il Game Maker Language o che non abbiano mai programmato.
Per coloro che hanno già programmato nella propria vita almeno una volta, vi basti sapere che il GML (Game Maker Language) utilizzato in Game Maker è molto molto simile al C o al Javascript (quest'ultimo personalmente non conosco, ma così mi dice la regia XP), quindi non preoccupatevi più di tanto
Per coloro che non hanno mai preso in mano Game Maker o che non hanno mai programmato, vi dico semplicemente NON SPAVENTATEVI!
L'approccio "ommioddio che cos'è O.o " è semplicemente controproducente e fidatevi se vi dico che non è così agghiacciante come può sembrare In informatica il linguaggio di programmazione in realtà è solo l'ultimo passo per la soluzione di un problema!
E' l'idea che c'è dietro la cosa veramente importante, come in Rpg Maker molti problemi li risolverete utilizzando la testa, idem sarà per Game Maker (in realtà per tutta la programmazione
)Un linguaggio di programmazione è solamente lo strumento fisico per la realizzazione della vostra idea!
Spesso la soluzione NON sta nel linguaggio, ma nella vostra mente!
Quindi incoraggio tutti voi a cercare di capire prima di tutto qual'è l'idea dietro la soluzione del problema e poi eventualmente andare a confrontarla con il codice scritto in GML.
Infine se qualcuno di voi è interessato concretamente ad apprendere il GML nelle sue basi vi consiglio fortemente (prima di tutto) di andare a dare un occhiata ai tutorial sul GML della YoYo Games per Game Maker che (nonostante ciò da me detto fin'ora) possono risultare estremamente chiari
Non c'è bisogno che andiate a guardare anche i tutorial più avanzati sulla possibilità di creare un gioco per Facebook o sull'utilizzo di Surface, come nemmeno dovete sapere cos'è un buffer e come utilizzarlo! A noi basta semplicemente che abbiate un minimo di dimistichezza con il concetto di Evento e Azione (Non confondete questi concetti con la controparte in Rpg Maker, perchè nonostante siano intrinsecamente simili, hanno un utilizzo diverso in Game Maker) e con le basi più becere del GML (parlo di sapere che cos'è una variabile e conoscere un minimo le istruzioni di base come la condizione IF o i cicli WHILE e FOR)
Inoltre per tutti coloro che non conoscono il GML vedrò sempre di spendere 2 parole sulle istruzioni da me utilizzate
So che come post è estremamente breve e di carattere introduttivo, ma era mia intenzione spendere due parole in più per farvi capire come ho intenzione di lavorare e per rassicurare tutti coloro che non hanno dimistichezza con Game Maker o la programmazione più in generale.
A presto con il primo vero Pseudo- Tutorial,
Il vostro Ale-Gap
PS:
Potete recuperare Game Maker: Studio direttamente dal sito della YoYo Games
(Anche se sinceramente non ricordo se sia disponibile nella versione di prova o nella standard, sicuramente anche la versione di prova è più che sufficientemente per i nostri obiettivi)
MIRE Engine
in Altri Tool
Inviato · Report reply
Purtroppo siamo a Maggio e mi sto avviando verso la sessione estiva di esami, quindi non sono (per niente) molto attivo sui forum...
Volevo farvi sapere, però che continuo a seguire la conversazione e sono entusiasta delle nuove funzioni (e dei bug risolti), soprattutto dei progressi nel sistema dei nodi che trovo fantastico!
Continua così Justino che appena posso torno a fare da cavia umana (alias beta tester) e magari do anche un supporto più consistente!!