GameMaker Pseudo-Tutorial - parte 1 - Movimento top-down

[Ale-Gap 48]

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.

direction

Esprime 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 direzione

input 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

Modificato March 15, 2015 da Ale-Gap (Visualizza storico modifiche)

[Freank 98]

Complimenti !! Davvero un gran bel tutorial ! Usi Game Maker da molto ?

[Ghost Rider 1885]

Se continui la serie di tutorial ti posso fare la sezione dedicata

[Ale-Gap 48]

@@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! 

[Freank 98]

Non so se lo hai saputo ma Game Maker ora viene acquistato dalla PlayTech, una società che opera nell'industria dei videogiochi da anni. 
 
Gli stessi autori del tool (sandy, mike e russel) affermano che già in passato la Playtech investì su di loro e confidano molto in questa società.
Concludono infatti la loro email, inviata all'amministratore del forum ufficiale, dicendo che sicuro presto verrà sviluppata una migliore versione del programma (Game Maker : Studio 2.0).
 
Sotto spoiler il messaggio in inglese degli autori.

 

 

Dear All,

We are excited to announce that YoYo Games has been acquired by Playtech, and we wanted to write to you personally and tell you more.

YoYo was founded by myself and a group of games industry friends and has never had any external investors aside from our own funds. This means we’ve relied heavily on generating revenue, mainly from GameMaker sales. While everything has gone well and we’ve grown to 30 people it means that we have had to sell more products before we could invest in new features, yet it’s the new features that generate more sales.

Most companies in this position seek external investment to break the cycle and create new products to sell. We tried to raise funds several times in order to further develop GameMaker, but the offers we were given meant giving up on a lot of what we wanted to keep doing, i.e. developing a tool that would continue to be accessible to both beginners and professionals. Our vision has always been to maintain GameMaker: Studio as affordable and great value. This is why we made the Standard Edition free last year as well as package the technology together as Master Collection.

We looked for the right company with sufficient funds, knowledge and supporting technology that matches our developer’s needs.

The reason we accepted the offer from Playtech was they were the first investor who didn’t want to alter our vision. They haven’t just bought the company, they’re committed to investing in YoYo Games in a way that we have never been able to previously. With their help we can now push ahead and hire more people and make GameMaker: Studio an even better platform for casual games developers everywhere. If there are any changes they will be additions to our plans. In fact, we’re already working on a number of these and some of you will get a very pleasant surprise this summer.

They’ve also made us commit to launching GameMaker: Studio 2.0 later this year. In our efforts to generate sales we’ve not been getting our resources packed into Studio 2.0 as we would have liked. But now it’s all hands on deck and we’re really excited that Playtech’s investment will help us get this done at twice the speed.

Playtech’s purchase of YoYo Games means that GameMaker: Studio will get even better and we’re now even more committed to making GameMaker: Studio the best platform to learn how to make games, as well as a leading technology for professional developers.

The proof will come in the next few months and we can’t wait to get going and show you what’s in store.

Sandy, Mike, Russell and the rest of the team.

 

 

p.s. se stai cercando un forum italiano di Game Maker eccolo qui 

[Ghost Rider 1885]

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! 

 

ecco fatto, ora hai la sezione dedicata ai tutorial di game maker e sei moderatore di questa sezione; nello specifico puoi aprire e chiudere discussioni, modificare post, nasconderli (ma non cancellarli del tutto) e ripristinarli. Ovviamente ogni abuso di questi poteri sarà punito con la decapitazione, impalazione della testa ed esposizione di quest'ultima sul serbatoio della mia moto, ma non penso avremo di questi problemi XDDDDDDDD

[Ale-Gap 48]

@@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!

[kaine 1855]

Ecco per l'appunto ci sarebbe da portare fuori la spazzatura e fare i piatti!

Comunque ottimo lavoro Ale ^^

 

Ps: sembra che scherzi ma ghost fa sul serio quando parla di decapitazioni e robe simili