GameMaker: Gioco 2D Gratis o a 95€, 12 Passi [2026]

A fine 2023 GameMaker ha cambiato pelle: via gli abbonamenti Creator e Indie, dentro un modello più semplice fatto di una versione gratuita e di una licenza commerciale a pagamento singolo. Tre anni dopo, nell’agosto 2026, quel cambio di rotta si è consolidato e il motore (oggi chiamato semplicemente “GameMaker”, senza più il suffisso “Studio 2”) resta uno dei modi più rapidi per passare da zero a un gioco 2D giocabile. In questa guida, parte della nostra copertura dedicata al mondo gaming, costruiamo un platform 2D completo, passo dopo passo, usando la build 2024.14.x aggiornata a marzo 2026. Copriamo installazione, sprite, movimento, collisioni, nemici, HUD, audio, ottimizzazione ed export, con codice GML pronto da incollare.

Cos’è GameMaker e perché conviene nel 2026

GameMaker è un motore pensato principalmente per giochi 2D: piattaforme, sparatutto dall’alto, puzzle, RPG a scorrimento. Rispetto a un motore generalista come Unity o Unreal, riduce il numero di passaggi tra “ho un’idea” e “ho un prototipo che gira”. L’editor integra sprite editor, room editor per costruire i livelli e un linguaggio proprio, il GML (GameMaker Language), affiancato da un sistema di scripting visuale a blocchi per chi parte da zero.

Il punto di forza principale nel 2026 resta il modello commerciale: nessuna royalty, nessuna quota sui ricavi. Paghi una licenza (o non paghi nulla, se il progetto resta non commerciale) e tieni il 100% di quello che guadagni vendendo il gioco. È una differenza che pesa parecchio rispetto a motori che applicano commissioni o fee sui runtime, ed è uno dei motivi per cui GameMaker resta popolare tra sviluppatori indie e piccoli team in Italia e nel resto d’Europa.

Dal rebranding del 2023 al modello attuale

Il cambio di rotta è partito da un annuncio pubblico del team di GameMaker a fine novembre 2023, poi ripreso da TechRadar: al posto degli abbonamenti Creator e Indie, il motore sarebbe diventato gratuito per uso non commerciale su tutte le piattaforme non console, con una licenza a pagamento unico per chi vuole vendere il proprio gioco. La stessa novità è stata raccontata anche dal blog di Blips.fm, che ha descritto il cambiamento come un tentativo di rendere il motore più accessibile a sviluppatori hobbisti e piccoli team. A distanza di quasi tre anni, quel modello a tre livelli (Free, Professional, Enterprise) non è più cambiato, segno che l’azienda lo considera stabile.

Il nome stesso del prodotto si è semplificato nel frattempo: la voce Wikipedia dedicata al motore riporta la transizione da “GameMaker Studio 2” al marchio unico “GameMaker”, oggi usato anche nella pagina del prodotto su Steam.

Prerequisiti: account, versione e requisiti di sistema

Prima di aprire l’installer, serve un account gratuito sul sito di GameMaker (email più password, oppure login social) e un sistema operativo a 64 bit: l’engine non si installa più su Windows o macOS a 32 bit. Serve anche una connessione internet attiva almeno una volta al mese, perché la licenza viene verificata online periodicamente. La build di riferimento per questa guida è GameMaker 2024.14.4, rilasciata il 26 marzo 2026, ma il flusso resta identico anche con versioni leggermente più recenti della stessa serie 2024.x.

Requisito	Configurazione minima	Configurazione consigliata
Sistema operativo	Windows 10/11 o macOS Big Sur (64 bit)	Windows 10/11 o macOS Monterey (64 bit)
Processore	Dual-core	Quad-core (es. Intel i5 o equivalente)
RAM	2 GB	8 GB
Scheda video	Compatibile OpenGL 4	GPU dedicata, 2 GB di VRAM
Archiviazione	HDD, almeno 3 GB liberi	SSD, 3-5 GB liberi
Rete	Verifica licenza mensile	Connessione a banda larga sempre attiva

Per seguire questo tutorial non serve saper programmare: bastano le basi di logica (variabili, condizioni, cicli). Se hai già seguito il nostro tutorial su Unity o quello su Godot Engine, riconoscerai molti concetti: oggetti, eventi, room al posto di scene. Cambia soprattutto la sintassi del linguaggio.

Piani e prezzi: Free, Professional ed Enterprise a confronto

Il modello 2026 di GameMaker si articola su tre livelli. Il piano Free costa zero euro e dà accesso all’editor completo, con export verso desktop, mobile, web e la piattaforma GX.games, ma solo per uso non commerciale: non puoi vendere il gioco né guadagnarci sopra. Il piano Professional richiede un pagamento unico di 99,99 dollari, corrispondenti a circa 90-95 euro al cambio di fine agosto 2026, e sblocca la vendita su tutte le piattaforme non console, senza royalty successive. Il piano Enterprise, necessario solo se vuoi pubblicare su console, costa 79,99 dollari al mese oppure 799,99 dollari all’anno (circa 73-74 euro al mese al cambio corrente) e aggiunge l’export verso PlayStation, Xbox e Nintendo Switch.

Piano	Costo	Cosa include	Limite principale
Free	0€	Editor completo, export desktop/mobile/web/GX.games	Solo uso non commerciale
Professional	99,99$ una tantum (~90-95€)	Vendita su PC, mobile, web, nessuna royalty	Niente export console
Enterprise	79,99$/mese o 799,99$/anno	Tutto Professional più export su console	Costo ricorrente

Per questo tutorial resta tutto nel piano Free: costruiamo e testiamo il gioco senza spendere nulla, e solo al momento di pubblicarlo su Steam o itch.io serve valutare l’acquisto della licenza Professional.

Free o Professional: quale scegliere per iniziare

Se non sai ancora se il tuo gioco arriverà mai a uno store, parti sempre dal piano Free. Non ha limiti di tempo, non scade e permette di completare l’intero progetto di questa guida, incluso l’export di una build giocabile da condividere con amici o playtester. Il passaggio a Professional ha senso solo quando hai davanti a te un piano di pubblicazione concreto, perché a quel punto i 99,99 dollari si ripagano con la prima manciata di copie vendute, senza percentuali trattenute sulle vendite successive.

Quando serve davvero il piano Enterprise

L’abbonamento Enterprise ha senso quasi solo per chi ha già un accordo o un dev kit per pubblicare su PlayStation, Xbox o Nintendo Switch: al di fuori di quel contesto, il costo mensile non si giustifica per un progetto ancora in fase di prototipo. Molti team indie rimandano la scelta a dopo il lancio su PC, quando il gioco ha già dimostrato di vendere e i costi dell’abbonamento diventano una frazione piccola dei ricavi.

Passo 1: scaricare e installare GameMaker

Vai sulla pagina ufficiale di download, crea l’account se non ne hai già uno e scarica l’installer per il tuo sistema operativo. Su Windows lancia l’eseguibile e segui la procedura guidata, lasciando il percorso predefinito a meno di ragioni specifiche per cambiarlo. Su macOS trascina l’app nella cartella Applicazioni. Al primo avvio l’engine chiede di effettuare il login: usa le credenziali create in precedenza. Da questo momento sei nel piano Free, sufficiente per tutto il resto della guida.

In alternativa, GameMaker è disponibile anche come applicazione gratuita su Steam: la scelta è comoda se preferisci gestire gli aggiornamenti dell’editor con lo stesso client che usi già per i tuoi giochi, e il comportamento dell’IDE non cambia rispetto alla versione scaricata dal sito ufficiale.

Se l’installazione si blocca, verifica di avere i 3 GB di spazio libero richiesti e che l’antivirus non stia mettendo in quarantena l’installer: è un falso positivo comune, dovuto alla scarsa reputazione del file appena scaricato agli occhi di alcuni motori euristici.

Passo 2: creare il primo progetto 2D

Dalla schermata iniziale scegli “New Project” e seleziona il template 2D vuoto (Blank 2D). Dai un nome al progetto, ad esempio “PrimoPlatform”, e scegli la cartella di salvataggio. Si aprirà il workspace principale, diviso in tre zone: l’albero delle risorse a sinistra (dove vivono sprite, oggetti e room), l’area centrale con gli editor aperti e i pannelli di output in basso, dove compaiono errori e log durante i test.

Fai subito un salvataggio (Ctrl+S su Windows, Cmd+S su macOS) e prendi l’abitudine di ripeterlo ogni volta che completi un passaggio. GameMaker non salva in automatico durante la modifica delle room, e perdere venti minuti di lavoro per un crash imprevisto è un errore che capita a quasi tutti i principianti.

Passo 3: configurare la Room e la risoluzione

Nell’albero delle risorse trovi già una Room di default, di solito chiamata “Room1”. Aprila e imposta larghezza e altezza a 1280×720 pixel dal pannello delle proprietà: è una risoluzione comoda perché scala bene sia su desktop sia su schermi più piccoli. Rinomina la room in “rm_livello1” seguendo la convenzione con prefisso “rm_”, che rende l’albero delle risorse leggibile appena il progetto cresce oltre le prime due o tre scene.

Nella scheda “Views” della room puoi attivare una camera che segue il giocatore invece di mostrare l’intero livello in un colpo solo: utile già da adesso, dato che il livello finale sarà più largo dello schermo.

Passo 4: importare e animare gli Sprite

Crea una nuova risorsa Sprite (tasto destro sulla cartella Sprites, “Create Sprite”) e chiamala “spr_player”. Puoi disegnare i frame direttamente nello Sprite Editor integrato oppure importare un file PNG con più fotogrammi di camminata: per un primo test bastano anche due o tre frame semplici, tipo dei quadrati colorati con una freccia, giusto per vedere il movimento a schermo. Imposta l’origine dello sprite al centro-basso, così le collisioni con il terreno risulteranno più naturali.

Ripeti l’operazione per creare “spr_wall” (una piattaforma) e “spr_enemy” (un nemico). Tre sprite bastano per costruire l’intero prototipo di questa guida.

Passo 5: programmare il movimento del giocatore in GML

Crea un nuovo Object, chiamalo “obj_player” e assegnagli lo sprite “spr_player” appena creato. Aggiungi un evento Create per inizializzare la velocità e un evento Step per gestire l’input da tastiera ogni frame. Il codice qui sotto muove il personaggio a sinistra e destra e applica la gravità verticale, la base di qualsiasi platform 2D.

// Create event di obj_player
hsp = 0;          // velocità orizzontale
vsp = 0;          // velocità verticale
grav = 0.4;       // forza di gravità per frame
move_spd = 4;     // velocità di movimento
jump_force = -9;  // forza del salto (negativo = verso l'alto)

// Step event di obj_player
var key_left  = keyboard_check(vk_left);
var key_right = keyboard_check(vk_right);
hsp = (key_right - key_left) * move_spd;

if (place_meeting(x, y + 1, obj_wall)) {
    vsp = 0;
    if (keyboard_check_pressed(vk_up)) {
        vsp = jump_force;
    }
} else {
    vsp += grav;
}

x += hsp;
y += vsp;

Nota due dettagli: keyboard_check restituisce vero o falso a ogni frame finché il tasto resta premuto, mentre keyboard_check_pressed scatta una volta sola al momento della pressione, l’ideale per il salto. Senza questa distinzione il personaggio salterebbe in continuazione tenendo premuto il tasto.

GML contro lo scripting a blocchi: quale usare

GameMaker offre due modi per scrivere la logica di gioco, e non sono in alternativa netta: si possono mescolare nello stesso progetto. Lo scripting a blocchi, chiamato Drag and Drop, funziona componendo icone che rappresentano azioni (muovi, controlla collisione, riproduci suono) trascinandole nell’ordine desiderato. Non richiede di ricordare la sintassi esatta di una funzione ed è la via più rapida per chi non ha mai scritto una riga di codice.

Il GML, il codice usato in questa guida, richiede di imparare sintassi e nomi delle funzioni, ma offre più controllo e si legge più in fretta una volta superata la prima curva di apprendimento: dieci righe di GML sostituiscono spesso una ventina di blocchi visuali impilati. Il consiglio pratico è iniziare con i blocchi per capire il flusso degli eventi (Create, Step, Draw, Collision) e passare al GML non appena la logica supera tre o quattro condizioni annidate, perché a quel punto il codice testuale diventa più facile da rileggere e correggere rispetto a una catena lunga di icone.

Passo 6: collisioni, piattaforme e gravità

Crea l’oggetto “obj_wall” con sprite “spr_wall” e segnalo come “Solid” nelle proprietà: questo attributo dice al motore fisico interno che il giocatore non può attraversarlo. Il codice del Passo 5 usa già place_meeting per verificare se sotto i piedi del giocatore c’è un blocco solido, ma manca ancora la risposta alla collisione orizzontale, altrimenti il personaggio si incastra nei muri laterali.

// Aggiunta all'evento Step di obj_player, dopo il calcolo di hsp
if (place_meeting(x + hsp, y, obj_wall)) {
    while (!place_meeting(x + sign(hsp), y, obj_wall)) {
        x += sign(hsp);
    }
    hsp = 0;
}
x += hsp;

Questo ciclo avvicina il giocatore al muro un pixel alla volta prima dell’impatto, evitando il classico bug del personaggio che si “incolla” dentro la piattaforma. Posiziona ora quattro o cinque istanze di “obj_wall” nella room per formare un pavimento e un paio di gradini.

Passo 7: nemici, danni e game over

Crea “obj_enemy” con sprite “spr_enemy”. Nell’evento Create imposta una velocità orizzontale fissa e nell’evento Step inverti la direzione quando incontra un muro, ottenendo un pattugliamento semplice ma efficace. Aggiungi poi un evento di collisione tra “obj_player” e “obj_enemy” che toglie una vita al giocatore e lo riporta al punto di partenza.

// Step event di obj_enemy
if (place_meeting(x + hsp_enemy, y, obj_wall)) {
    hsp_enemy = -hsp_enemy;
}
x += hsp_enemy;

// Evento Collision con obj_enemy, dentro obj_player
lives -= 1;
if (lives <= 0) {
    room_restart();
} else {
    x = xstart;
    y = ystart;
}

Le variabili xstart e ystart vanno salvate nell'evento Create del giocatore (xstart = x; ystart = y;) per poter riportare il personaggio al punto di partenza dopo un colpo, invece di riavviare sempre l'intera room.

Passo 8: punteggio, vite e interfaccia (HUD)

Aggiungi due variabili globali nell'evento Create della prima room o in un oggetto controller dedicato: score e lives. Disegnale a schermo con l'evento Draw GUI, che a differenza del normale Draw resta ancorato allo schermo anche se la camera si muove seguendo il giocatore.

// Draw GUI event di un obj_controller
draw_set_font(fnt_hud);
draw_set_color(c_white);
draw_text(20, 20, "Punteggio: " + string(score));
draw_text(20, 50, "Vite: " + string(lives));

Per far salire il punteggio, aggiungi un oggetto "obj_coin" con un evento di collisione con il giocatore che incrementa score di 10 e distrugge la moneta raccolta. Bastano cinque o sei monete sparse nel livello per dare un obiettivo concreto al prototipo.

Passo 9: suoni, musica ed effetti

Importa un file audio breve in formato WAV per il salto e uno per la raccolta delle monete, creando due risorse Sound chiamate "snd_jump" e "snd_coin". Richiamale con audio_play_sound(snd_jump, 1, false) nel punto in cui il giocatore salta, e allo stesso modo per la moneta. Per la musica di sottofondo, un file OGG in loop caricato con audio_play_sound(mus_livello1, 1, true) nell'evento Create della room è sufficiente per un primo prototipo: l'ultimo parametro impostato su true attiva la ripetizione automatica.

Passo 10: testare e debuggare il gioco

Premi F5 (o il pulsante Run) per compilare ed eseguire il gioco in una finestra separata. La console di output in basso mostra in tempo reale eventuali errori GML, con numero di riga e nome dell'oggetto coinvolto, un dettaglio che velocizza parecchio la correzione rispetto a leggere solo un messaggio generico. Un output tipico dopo un errore di sintassi appare così:

___________________________________________
############################################################################################
FATAL ERROR in
action number 1
of Step Event
for object obj_player:

Variable obj_player.hsp_enemy(100033, -2147483648) not set before reading it
at gml_Object_obj_player_Step_0 (line 12) - x += hsp;
############################################################################################

Il messaggio indica che una variabile viene letta prima di essere assegnata: quasi sempre significa che manca l'inizializzazione nell'evento Create, oppure che il nome della variabile è stato scritto in modo diverso tra i due eventi (GML distingue maiuscole e minuscole). Usa il debugger integrato (icona a forma di insetto accanto a Run) per mettere breakpoint e ispezionare i valori delle variabili istante per istante, invece di indovinare a colpi di show_debug_message.

Passo 11: ottimizzare le prestazioni

Con poche decine di istanze un platform 2D gira senza problemi anche su hardware modesto, ma alcune abitudini evitano cali di frame quando il livello cresce. Disattiva l'evento Step sugli oggetti fuori dallo schermo, usando view_get_xview() e view_get_yview() per capire se un'istanza è visibile prima di eseguire calcoli pesanti. Riduci il numero di collisioni ad alta frequenza raggruppando i controlli invece di ripeterli su ogni singolo oggetto muro.

// Step event di obj_enemy, con controllo di visibilità
if (x < view_get_xview() - 200 || x > view_get_xview() + view_get_wview() + 200) {
    exit; // salta la logica se il nemico è lontano dalla camera
}

Il pannello "Show Stats" durante il test (tasto F6 in molte configurazioni) mostra fps correnti e numero di istanze attive: se il contatore scende sotto i 55-58 fps con un livello ancora piccolo, il problema è quasi sempre nella logica di un singolo oggetto, non nel motore stesso.

Passo 12: esportare e pubblicare su Steam o itch.io

Con il piano Free puoi esportare build di prova per Windows, macOS, Linux e HTML5, utili per far testare il gioco ad amici o alla community, ma senza poterlo vendere. Dal menu "File > Export" scegli la piattaforma di destinazione: GameMaker genera un eseguibile pronto da distribuire, o un pacchetto HTML5 caricabile direttamente su GX.games o itch.io in modalità gratuita.

Quando decidi di vendere il gioco, acquista la licenza Professional (99,99 dollari una tantum) dal tuo account GameMaker: da quel momento lo stesso progetto può essere esportato ed elencato su Steam, su itch.io a pagamento o sugli store mobile, senza dover cambiare una riga di codice. Se punti anche a PlayStation, Xbox o Nintendo Switch, serve invece l'abbonamento Enterprise, che aggiunge gli SDK e i template di export specifici per ciascuna console.

Un export completato correttamente per Windows produce un log finale simile a questo nel pannello di output:

Compiling project...
Packaging files...
Creating executable...
Build completed successfully.
Output: PrimoPlatform_Windows.zip (18.4 MB)
Elapsed time: 42.3 seconds

Se invece il pannello si ferma su "Build failed" senza generare il file, la causa quasi sempre è un asset mancante (uno sprite cancellato ma ancora referenziato da un oggetto) oppure un percorso di output non scrivibile: controlla i permessi della cartella di destinazione prima di rilanciare la compilazione.

Errori comuni da evitare

• Confondere Step e Create. Inizializzare variabili nell'evento Step invece che in Create le resetta a ogni frame, azzerando salto e punteggio senza un motivo apparente.
• Dimenticare l'origine dello sprite. Un'origine impostata in alto a sinistra invece che al centro-basso rende le collisioni imprecise e il personaggio sembra fluttuare sopra il terreno.
• Usare nomi di variabili duplicati tra oggetti diversi. GML non segnala errore se due oggetti usano lo stesso nome per scopi diversi, ma il comportamento finale diventa difficile da tracciare.
• Non salvare prima di un test con room complesse. Un crash durante il test può chiudere il progetto senza salvare le ultime modifiche alla room.
• Ignorare la differenza tra Draw e Draw GUI. Disegnare l'HUD nell'evento Draw normale lo fa scorrere insieme al livello quando la camera si muove, invece di restare fisso sullo schermo.
• Esportare per console senza Enterprise attivo. Il template di export per PlayStation o Xbox compare nel menu solo con l'abbonamento attivo, e la sua assenza confonde spesso chi si aspetta di trovarlo già nel piano Free o Professional.
• Riempire una singola room con troppi oggetti diversi. Superata la trentina di tipi di oggetto in un'unica room, l'editor diventa lento da navigare: conviene dividere il livello in più room collegate invece di continuare ad aggiungere contenuto alla stessa scena.
• Non testare mai su una build esportata prima del lancio. Il comportamento in editor e quello della build compilata possono differire leggermente, soprattutto sui tempi di caricamento degli asset: prova sempre l'eseguibile finale prima di pubblicarlo, non solo l'anteprima interna.

Risoluzione dei problemi: le domande tecniche più comuni

La maggior parte dei blocchi che si incontrano nelle prime settimane con GameMaker ricade in poche categorie ricorrenti: licenza, collisioni, audio e prestazioni. La tabella seguente raccoglie i dieci problemi più frequenti segnalati da chi segue guide simili a questa, con la causa più probabile e il modo più rapido per risolverli senza dover riscrivere il progetto da capo.

Problema	Causa probabile	Soluzione
Il gioco non si avvia dopo Run	Runtime non installato o corrotto	Reinstalla il runtime dal pannello Preferences > Platform Settings
"Variable not set" all'avvio	Variabile letta prima dell'evento Create	Sposta l'inizializzazione in Create o verifica con variable_instance_exists
Il personaggio attraversa i muri	Oggetto muro non segnato come Solid o sprite senza maschera di collisione	Controlla la proprietà Solid e la Collision Mask nello sprite editor
Il salto non funziona a volte	Uso di keyboard_check invece di keyboard_check_pressed	Passa a keyboard_check_pressed per l'input del salto
L'HUD si sposta con la camera	Disegno effettuato nell'evento Draw invece che in Draw GUI	Sposta il codice del punteggio nell'evento Draw GUI
L'installer viene bloccato dall'antivirus	Falso positivo per reputazione file bassa	Aggiungi un'eccezione temporanea o scarica dal sito ufficiale
Audio che non parte su alcune build	Formato file non supportato (es. MP3 con codec non standard)	Converti in WAV o OGG prima dell'importazione
Frame rate instabile in room grandi	Troppe istanze con Step attivo fuori dallo schermo	Disattiva la logica per le istanze lontane dalla view
La licenza non si verifica	Connessione internet assente da oltre un mese	Connettiti almeno una volta al mese per il controllo automatico
Export console non disponibile nel menu	Abbonamento Enterprise non attivo	Attiva Enterprise dal proprio account prima di esportare

GameMaker contro Unity, Unreal e Godot: quale scegliere

La scelta tra motori dipende soprattutto dal tipo di gioco e dal budget iniziale. GameMaker resta pensato in primo luogo per il 2D: sprite editor, room editor e GML riducono i tempi rispetto a un motore generalista, ma manca il supporto nativo al 3D avanzato. Il nostro tutorial su Unity mostra un motore più versatile per progetti misti 2D/3D, con una curva di apprendimento più ripida. Unreal Engine punta invece su rendering 3D di fascia alta, adatto a produzioni più ambiziose ma decisamente sovradimensionato per un platform in pixel art. Godot, coperto nel nostro tutorial dedicato, è gratuito e open source, ma richiede più lavoro manuale per l'export su mobile e console rispetto al flusso già pronto di GameMaker Enterprise.

Motore	Focus principale	Costo per commercializzare	Curva di apprendimento
GameMaker	2D	99,99$ una tantum (Professional)	Bassa
Unity	2D e 3D	Gratis fino a soglie di ricavo, poi piani a pagamento	Media
Unreal Engine	3D avanzato	Royalty sui ricavi oltre soglia	Alta
Godot	2D e 3D	Gratuito, open source	Media

Per un confronto più esteso, con dati di prezzo aggiornati su tutti e tre i concorrenti, trovi l'analisi completa nel nostro articolo Unreal Engine vs Unity vs Godot.

Quando scegliere GameMaker

Scegli GameMaker se il progetto è dichiaratamente 2D, se vuoi vedere un prototipo giocabile entro i primi giorni di lavoro e se il budget per la fase di sviluppo deve restare vicino allo zero. È la scelta più sensata anche per chi insegna programmazione di base attraverso lo sviluppo di giochi, perché lo scripting a blocchi abbassa la soglia d'ingresso senza precludere il salto al GML vero e proprio.

Quando conviene guardare altrove

Se il progetto prevede ambienti 3D, un sistema di illuminazione complesso o una pipeline di asset condivisa con un team che lavora già in Unity o Unreal, restare su GameMaker significa scontrarsi presto con i suoi limiti strutturali. In quei casi conviene valutare da subito uno dei motori generalisti, anche a costo di una curva di apprendimento più lunga nelle prime settimane.

Localizzazione e controlli: rendere il gioco accessibile

Se punti a un pubblico europeo, vale la pena separare fin da subito i testi dal codice invece di scrivere le stringhe direttamente dentro draw_text. Un approccio semplice è una struttura dati (una ds_map o un array associativo) che associa una chiave testuale, ad esempio "punteggio", alla traduzione nella lingua attiva. Cambiare lingua a runtime diventa allora questione di ricaricare la mappa giusta, senza toccare la logica di gioco né gli oggetti che disegnano l'HUD.

Sul fronte controlli, evita di legare i comandi a tasti fissi come vk_left e vk_right senza un livello di astrazione. Definisci invece variabili come input_left e input_right assegnate una sola volta in un oggetto di configurazione, e leggi quelle nel codice di movimento: permette di aggiungere in seguito il rebind dei tasti o il supporto a un gamepad senza riscrivere l'evento Step di ogni oggetto che risponde all'input. GameMaker espone anche funzioni dedicate al gamepad, come gamepad_button_check, utili se prevedi di supportare un controller fin dalle prime fasi di sviluppo.

Documentazione ufficiale e community

Il manuale ufficiale di GameMaker resta il riferimento più affidabile per ogni funzione GML citata in questa guida: ogni funzione, da place_meeting a draw_text, ha una pagina dedicata con parametri, valori di ritorno ed esempi minimi. È anche il primo posto dove controllare se una funzione è stata deprecata o sostituita in una versione più recente della serie 2024.x.

Per dubbi sulla licenza, sui limiti del piano Free o sulle differenze tra Professional ed Enterprise, la FAQ ufficiale copre la maggior parte delle domande pratiche prima ancora di dover aprire un ticket di supporto. Il forum della community e i canali Discord collegati al progetto restano inoltre il posto più rapido per confrontarsi con altri sviluppatori quando un bug non dipende dal codice ma da una configurazione specifica del proprio sistema.

Consigli avanzati per andare oltre il tutorial

Una volta solido il prototipo, tre direzioni portano il progetto a un livello successivo. La prima è lo strumento Sequences, integrato nell'editor, che permette di animare oggetti e camera senza scrivere codice, utile per cutscene brevi o transizioni tra livelli. La seconda è l'uso di shader GLSL ES personalizzati per effetti visivi come dissolvenze, illuminazione dinamica o distorsioni, applicabili a singoli sprite senza appesantire l'intero rendering. La terza è l'organizzazione del codice in script separati invece di scriverlo direttamente negli eventi: uno script scr_player_movement() richiamato dall'evento Step rende il progetto più leggibile quando gli oggetti superano la decina.

Vale anche la pena esplorare il Marketplace di asset di GameMaker per librerie di gestione dell'inventario, dialoghi o sistemi di salvataggio già pronti: accelerano lo sviluppo di un progetto più ampio senza dover reinventare meccaniche già risolte dalla community.

Gestire texture page e memoria video

Man mano che aggiungi sprite, GameMaker li impacchetta in texture page condivise per ridurre il numero di operazioni di disegno per frame. Se noti un calo di prestazioni dopo aver importato molti asset di grandi dimensioni, controlla nel pannello Texture Groups quante pagine vengono generate: troppe texture page separate aumentano il numero di cambi di contesto sulla GPU e possono costare più fps di quanto sembri guardando solo il numero di istanze a schermo. Raggruppare sprite usati nella stessa room dentro lo stesso texture group è spesso sufficiente per recuperare il frame rate perso.

Il progetto completo: struttura finale del gioco

A fine guida il progetto "PrimoPlatform" contiene: tre sprite (giocatore, muro, nemico), quattro oggetti (obj_player, obj_wall, obj_enemy, obj_coin) più un obj_controller per punteggio e vite, una room da 1280x720 pixel con piattaforme, un nemico pattugliante e alcune monete da raccogliere, due suoni (salto e moneta) e una musica di sottofondo in loop. Il flusso di gioco è completo: il giocatore si muove, salta, raccoglie punti, perde vite contro i nemici e può concludere il livello raggiungendone la fine.

Da questa base puoi aggiungere una seconda room collegata con room_goto(rm_livello2), un menu iniziale con un obj_menu dedicato e un salvataggio dei progressi tramite ini_write_real e ini_read_real, le funzioni GML per leggere e scrivere piccoli file di configurazione locali.

Per mantenere il progetto ordinato quando aggiungi altri livelli e meccaniche, conviene tenere una struttura di cartelle coerente nell'albero delle risorse fin dal primo giorno:

• Sprites/Player, Sprites/Enemies, Sprites/Environment: separano gli sprite per categoria invece di lasciarli tutti alla radice.
• Objects/Player, Objects/Enemies, Objects/Items, Objects/Controllers: rispecchiano la stessa logica per gli oggetti.
• Rooms/Livelli, Rooms/Menu: separano le room di gioco da menu e schermate di caricamento.
• Sounds/SFX, Sounds/Music: distinguono effetti sonori brevi dalla musica in loop.
• Scripts/Utility, Scripts/Gameplay: utile appena il codice condiviso tra più oggetti supera i due o tre script.

Questa organizzazione non cambia il comportamento del gioco, ma fa risparmiare tempo reale quando il progetto passa da quattro a quaranta oggetti, un salto che avviene più in fretta di quanto ci si aspetti non appena si aggiungono più livelli e nemici.

A questo punto hai un platform 2D funzionante, con movimento, salto, collisioni, un nemico pattugliante, monete da raccogliere, un HUD con punteggio e vite, audio ed export pronto per Windows, macOS, Linux o HTML5. È lo stesso schema che regge la maggior parte dei giochi 2D commerciali costruiti con questo motore: poche meccaniche solide, testate a fondo, prima di aggiungere contenuto. Da qui, la strada più naturale è espandere in orizzontale (più livelli, più nemici, più power-up) prima di introdurre sistemi complessi come un inventario o un albero di dialoghi, che richiedono una base di codice già stabile per non trasformarsi in un lavoro di refactoring continuo.

Domande frequenti

GameMaker è davvero gratuito?
Sì, per uso non commerciale: puoi scaricare l'editor completo e pubblicare build gratuite senza pagare nulla. Serve la licenza Professional da 99,99 dollari solo per vendere il gioco.

Serve saper programmare per iniziare?
No. GameMaker offre uno scripting visuale a blocchi oltre al linguaggio GML, quindi puoi partire senza esperienza di codice e passare a GML man mano che il progetto cresce.

Quanto costa pubblicare su console?
Serve il piano Enterprise, 79,99 dollari al mese o 799,99 dollari all'anno, che sblocca l'export per PlayStation, Xbox e Nintendo Switch.

GameMaker è meglio di Unity per un principiante?
Per un gioco puramente 2D, GameMaker ha in genere una curva di apprendimento più bassa. Unity resta preferibile se il progetto prevede elementi 3D o richiede un ecosistema di plugin più ampio.

Posso usare GameMaker su Linux?
L'editor ufficiale gira su Windows e macOS. L'export verso Ubuntu/Linux è però supportato come piattaforma di destinazione per il gioco finito.

Cosa succede se non mi connetto a internet per un mese?
La licenza richiede una verifica online periodica. Senza connessione per un periodo prolungato l'attivazione può scadere e serve rifare il login per sbloccare di nuovo l'editor.

Il piano Professional è un abbonamento?
No, è un pagamento singolo di 99,99 dollari. Solo il piano Enterprise, dedicato alle console, funziona con un abbonamento mensile o annuale.

Quanto tempo serve per completare un platform come quello di questa guida?
Seguendo i dodici passi con calma, tra le due e le quattro ore, a seconda dell'esperienza pregressa con la logica di programmazione e con l'editor di GameMaker.

Conviene imparare prima il GML o lo scripting a blocchi?
Per chi parte da zero, i blocchi aiutano a capire subito il flusso degli eventi senza doversi preoccupare della sintassi. Il passaggio al GML conviene non appena la logica di un oggetto richiede più di tre o quattro condizioni annidate, perché a quel punto il codice testuale resta più leggibile dei blocchi impilati.