Chi Siamo

è un piccolo studio di gioco indipendente con una memoria lunga. La pagina “Chi siamo” che stai leggendo è quella originale: un’istantanea dei primi anni 2000, quando lo studio era composto da due persone, un home office condiviso e la convinzione ostinata che si potessero creare veri giochi senza un editore che ti alitasse sul collo.

L’abbiamo mantenuta in gran parte intatta perché è onesta su da dove veniamo e perché le persone citate sono ancora le persone che creano i giochi. Quello che segue è la stessa pagina, espansa: chi siamo, cosa facciamo effettivamente, come lavoriamo e perché uno studio che ha iniziato con C++ e DirectX su PlayStation 2 ha finito per distribuire giochi HTML5 e adattamenti di giochi da tavolo.

Concetti chiave

• Massively Fun è uno studio indipendente di due persone fondato e gestito da Stephen e Angela Wilkinson, attivo dalla metà degli anni ‘90.
• Il background di Stephen è l’ingegneria professionale per console e PC: C++, DirectX e titoli pubblicati su hardware dell’era PS/2, Xbox e GameCube.
• Il background di Angela spazia tra Java, C++, ASP e Delphi, oltre al lavoro molto più difficile di gestire la casa che mantiene in vita lo studio.
• L’output dello studio si è evoluto con l’industria: dal lavoro nativo su console ai giochi HTML5/JavaScript basati su browser e agli adattamenti digitali di giochi da tavolo fisici.
• Costruiamo in piccoli incrementi rilasciabili e consideriamo il “fatto e rilasciato” più prezioso dell‘“ambizioso e incompiuto”.
• Tutto ciò che trovi qui — recensioni, download, note di sviluppo — proviene da persone che realizzano effettivamente giochi, non da una content farm.

Chi Siamo

Stephen Wilkinson — Sr. Software Engineer. Stephen ha trascorso anni come game engineer professionista, in particolare presso Paradigm Entertainment, una società di Infogrames, lavorando su titoli per console durante la generazione PS2/Xbox/GameCube. Era l’era in cui “pubblicare un gioco” significava rientrare in un budget di memoria fisso, ottimizzare a mano un renderer ed eseguire il debug su devkit che costavano più di un’auto. Si è diplomato nel 1987 alla Duncan High School di Duncan, in Oklahoma — il che ti dice che scrive software da moltissimo tempo e che è arrivato ai giochi attraverso lo stesso percorso di molti di noi: curiosità, un computer di casa e troppe nottate in bianco.

Le sue competenze dichiarate sono quelle che contano per questo studio: scrittura di giochi per computer, C++, DirectX e sviluppo per console su PS/2, Xbox e un po’ di GameCube. In pratica, ciò significa che è a suo agio in tutto lo stack: dalla gestione della memoria e dal rendering ai sistemi di gameplay e agli strumenti di sviluppo.

Angela Wilkinson — La mamma di Arthur e programmatrice in standby. Il titolo ufficiale di Angela la sottovaluta. Il suo toolkit comprende Java, C++, ASP e Delphi, oltre a ciò che la pagina originale chiama “Mom 1.0” — il sistema operativo che in realtà mantiene in funzione uno studio di due persone. Chiunque abbia provato a creare giochi avendo una famiglia sa che il secondo lavoro è quello più difficile, e che uno studio senza qualcuno che gestisca la logistica, i programmi e il morale non pubblica nulla.

La sua lista dei preferiti è breve e significativa: Arthur (e Stephen). Ecco l’intero studio in una riga.

Correlato: Unity Asset Store — Grafica, strumenti e modelli già pronti che vengono inseriti direttamente nel tuo progetto Unity.

Cosa costruiamo in realtà

Il catalogo di Massively Fun spazia tra alcuni tipi di lavoro distinti, ed è opportuno essere espliciti al riguardo perché “studio indie” può significare quasi ogni cosa.

• Giochi originali HTML5/JavaScript. Titoli browser-first creati per funzionare senza plugin, senza installazione e senza l’intermediazione di uno store. Questo è il nucleo moderno di ciò che facciamo.
• Adattamenti digitali di giochi da tavolo. Il nostro lavoro più noto in questo ambito è Catan World, una versione digitale di Catan di Klaus Teuber — un gioco le cui regole sono semplici da enunciare ma davvero difficili da implementare correttamente, perché l’intera esperienza dipende dall’ordine dei turni, dallo scambio di risorse e dalla negoziazione sociale tra i giocatori.
• Piccoli e incisivi giochi in stile arcade. Fast Iron e Word² rientrano in questa categoria: loop serrati, sessioni rapide e meccaniche che puoi spiegare in una frase ma che richiedono settimane di affinamento.
• Recensioni e commenti. Giochiamo molto e ne scriviamo. Le recensioni su questo sito provengono da sviluppatori attivi, il che cambia ciò che notiamo: tendiamo a dare importanza ai sistemi, al feeling e all’esecuzione tecnica tanto quanto alla presentazione.

Questo mix non è casuale. Riflette una strategia deliberata: mantenere la portata di ogni singolo progetto abbastanza piccola da consentire a due persone di completarlo, e tenere in piedi diversi tipi di progetto affinché lo studio non dipenda dal successo di un unico titolo.

Come siamo arrivati qui: da DirectX al browser

La pagina originale “Chi siamo” è una capsula del tempo di un momento specifico nello sviluppo dei giochi. Alla fine degli anni ‘90 e all’inizio degli anni 2000, se volevi creare un gioco, lo scrivevi in C o C++ utilizzando l’SDK di una piattaforma — DirectX su Windows, o le librerie proprietarie di una console — e lo distribuivi su supporti fisici tramite un editore. Paradigm Entertainment era esattamente quel tipo di studio, e lavorarci significava imparare la disciplina dello sviluppo per console: hardware fisso, scadenze rigide, requisiti di certificazione e l’impossibilità di rilasciare patch dopo il lancio.

La nostra scelta: Udemy Game Development Courses — Corsi su richiesta riguardanti Unity, Unreal, C++, C# e programmazione shader.

Il web ha cambiato l’economia di tutto questo. Quando i browser hanno ottenuto una vera tela 2D e, successivamente, WebGL, è diventato possibile distribuire un gioco a chiunque avesse un URL.

Nessun editore, nessun disco, nessuna coda di certificazione. I compromessi sono reali: rinunci all’accesso diretto all’hardware, combatti le stranezze del browser e non puoi dare per scontato un frame rate costante, ma il lato positivo è che un team di due persone può raggiungere giocatori in tutto il mondo fin dal primo giorno.

Questo cambiamento è il motivo per cui il centro di gravità di Massively Fun si è spostato su HTML5 e JavaScript. Le abitudini ingegneristiche legate al lavoro su console non sono scomparse; sono state semplicemente applicate a un target diverso. La disciplina della memoria, i cicli di aggiornamento deterministici e un’attenta profilazione contano tanto in un browser quanto in un devkit.

Come lavoriamo

Gli studi di due persone vivono o muoiono in base al processo, e il nostro è costruito attorno ad alcuni principi che sono sopravvissuti al contatto con la realtà.

Pubblica in piccolo, pubblica spesso. Un gioco che esiste ed è giocabile batte un gioco che teoricamente è migliore ma è incompleto. Definiamo l’ambito in base a ciò che due persone possono completare, poi tagliamo finché non entra nel budget.

Prototipa prima la parte rischiosa. Se una meccanica potrebbe non essere divertente, ne creiamo la versione più brutta possibile prima di realizzare qualsiasi grafica o interfaccia utente. La maggior parte delle idee muore qui, ed è proprio questo il punto.

Correlato: Amazon: Game Dev Books & Gear — Libri di programmazione di giochi, tastiere meccaniche, monitor e hardware per sviluppatori.

Mantieni la toolchain noiosa. Per il lavoro HTML5 ciò significa generalmente una base di codice JavaScript/TypeScript, un approccio di rendering leggero (Canvas grezzo o WebGL, o una piccola libreria anziché un motore pesante) e Node.js per gli script di build, le pipeline delle risorse e i server di sviluppo locali. Strumenti noiosi significano meno sorprese e meno tempo dedicato al debug del tooling invece che del gioco.

Testa sul peggior dispositivo che riesci a trovare. I giochi browser girano su tutto, da un desktop di fascia alta a un telefono di cinque anni fa. Se regge sul target più lento, regge ovunque.

Metti tutto per iscritto. Le note di sviluppo e le recensioni non sono marketing: sono il nostro modo di pensare. Spiegare una decisione progettuale a parole è uno dei modi più rapidi per scoprire che si tratta di una decisione sbagliata.

Se stai facendo acquisti: Construct 3 — Motore HTML5 senza codice basato su browser che esporta su Web, dispositivi mobili e desktop.

Scegliere uno stack tecnologico: come decidiamo

Una delle domande più comuni che riceviamo dagli sviluppatori hobbisti è “con cosa dovrei costruire?”. Non esiste una risposta universale, ma esiste un processo decisionale. Ecco più o meno come la pensiamo.

Considerazione	Propendi per Canvas/WebGL grezzo + JS/TS	Propendi per un motore completo (es. Godot, Unity o un motore JS)
Dimensione del team	1–2 persone a cui piace il controllo	Team più grandi o artisti che necessitano di editor
Tipo di gioco	2D, arcade, puzzle, porting di giochi da tavolo	3D, ricchi di fisica, scene graph complessi
Target	Browser-first, caricamento veloce, download ridotto	Multipiattaforma incluse console/desktop
I tuoi punti di forza	Ti piacciono i sistemi e il controllo di basso livello	Preferiresti dedicare tempo ai contenuti e al design
Budget temporale	Puoi permetterti di costruire alcuni strumenti	Hai bisogno di un editor e di una pipeline di risorse subito

Un avvertimento onesto: i motori ti fanno risparmiare un tempo enorme sul rendering, sulla fisica e sulla gestione delle risorse, ma impongono anche la propria architettura e i propri bug. Creare il proprio sistema ti dà il controllo totale e la responsabilità totale.

Per uno studio di due persone che distribuisce giochi per browser, una via di mezzo — una piccola libreria di rendering più la propria logica di gioco — è stata solitamente la scelta giusta. Per il primo progetto di un hobbista, un motore è quasi sempre la strada più veloce verso qualcosa di giocabile.

Se desideri approfondire gli standard e le piattaforme coinvolte, i Documenti Web MDN sull’API Canvas sono il riferimento canonico per il rendering 2D nel browser, e la specifica WebGL mantenuta dal Khronos Group copre il percorso accelerato via GPU. Per la parte di giochi da tavolo del nostro lavoro, il sito ufficiale di Catan è la fonte autorevole sul gioco che abbiamo adattato.

Controllo del movimento e altri esperimenti

Parte della storia dello studio riguarda le piattaforme di controllo del movimento: l’ondata di input basati su telecamere e sensori arrivata con l’era Wii e Kinect. Il controllo del movimento è un problema di progettazione davvero interessante perché rimuove lo strato di astrazione di un pulsante. I giocatori si aspettano che il gioco comprenda il loro corpo, e di solito non succede, almeno non in modo preciso.

Le lezioni pratiche di quel lavoro si ripercuotono su tutto il resto che facciamo:

• La latenza è il nemico. Qualsiasi schema di input con un ritardo percettibile sembra rotto, non importa quanto sia intelligente la meccanica.
• Progetta per il sensore che hai, non per quello che vorresti. Se la telecamera può rilevare in modo affidabile solo movimenti grossolani, crea un gioco basato su movimenti grossolani.
• Fornisci sempre un’alternativa. Sia l’accessibilità che l’affidabilità richiedono che un gioco sia giocabile anche senza il dispositivo di input esotico.

Questi principi si applicano altrettanto bene ai controlli touch su un telefono, che rappresentano il problema del controllo del movimento dell’era HTML5.

Le persone dietro i giochi

Vale la pena ribadirlo chiaramente, perché è ciò che distingue uno studio come questo da un sito di contenuti: i nomi su questa pagina sono le persone che scrivono il codice, mettono a punto le meccaniche e giocano ai giochi che recensiamo. La lista dei preferiti di Stephen — Final Fantasy Tactics Advance, Il Signore degli Anelli: Le Due Torri su PS2, Fire Emblem, Call of Duty e un cast a rotazione di altri — è la lista di uno sviluppatore attivo. È ricca di giochi basati su sistemi con una progressione profonda, che è esattamente il tipo di design che premia la mentalità ingegneristica.

L’elenco di Angela è lungo una riga e dice tutto: Arthur e Stephen. Uno studio è una famiglia prima di essere un’azienda, e questo è sempre stato entrambe le cose.

Domande frequenti

Chi gestisce Massively Fun?

Massively Fun è gestito da Stephen e Angela Wilkinson, un team di due persone. Stephen si occupa della maggior parte dell’ingegneria, attingendo a un background professionale nello sviluppo per console e PC, mentre Angela contribuisce alla programmazione in Java, C++, ASP e Delphi, oltre a gestire la casa che rende possibile lo studio.

Quali giochi ha realizzato Massively Fun?

Il catalogo dello studio include titoli originali in HTML5/JavaScript come Word² e Fast Iron, oltre a Catan World, un adattamento digitale del gioco da tavolo Catan. Lo studio pubblica inoltre recensioni e commenti sui giochi a cui gioca.

Quali tecnologie utilizza lo studio?

Storicamente, C++ e DirectX per il lavoro su console e PC, incluso lo sviluppo dell’era PS/2, Xbox e GameCube. Oggi l’attenzione è rivolta a HTML5 e JavaScript per i giochi browser, con Node.js per il tooling e le pipeline di build, mentre Java, C++, ASP e Delphi fanno parte dell’esperienza più ampia del team.

Posso assumere Massively Fun o collaborare?

Il sito è sempre stato una pagina personale dello studio piuttosto che la vetrina di un’agenzia, quindi non esiste un elenco formale di servizi. La via migliore per collaborazioni o domande è contattarci tramite l’indirizzo di contatto pubblicato sul sito.

La pagina originale “Chi siamo” è ancora accurata?

Sì — le biografie, le competenze e i preferiti originali sono conservati qui perché sono ancora attuali. Le persone, il loro background e i loro gusti non sono cambiati; ciò che è cambiato è la piattaforma per cui lo studio sviluppa e la dimensione del catalogo.

Che consigli avete per gli sviluppatori di giochi hobbisti?

Iniziate in modo più piccolo di quanto pensiate sia necessario, prototipate la meccanica più rischiosa prima di costruire qualsiasi altra cosa e scegliete uno stack tecnologico in base alle dimensioni del vostro team e al tipo di gioco, piuttosto che in base a ciò che è di tendenza. Pubblicare un singolo piccolo gioco finito insegna più che iniziarne cinque ambiziosi.