5 marzo 2026 · Mikhail Vasiliev

Nexus Devlog: il prototipo del motore

Watch on YouTube

Un mese e mezzo fa ho pubblicato sul sito i piani dello studio - sul motore Nexus: cos'è e quali progetti ci faremo sopra, fino alle strategie e ai seguiti della serie egizia. Lì c'era anche una roadmap. Il motore è complesso, e per ridurre i rischi volevo costruirlo poco a poco. Ma i giocatori nei commenti l'hanno detto chiaro: mettere insieme una cosa del genere è impossibile. Così ho deciso di partire da un prototipo - per mostrare che un motore così si può comunque costruire. Ed è quello che vi faccio vedere.

Il menu del prototipo: il motore propone di scegliere una di quattro simulazioni - Stone Age, Slay the Spire, il generatore di sistemi stellari e Oregon Trail

Ecco come si presenta il motore adesso. A prima vista è un'applicazione da console piuttosto primitiva. Ma mostra bene la cosa più importante - che meccaniche diverse girano su un unico motore universale.

Al momento ci girano quattro simulazioni. La prima è Stone Age, il primissimo gioco dello studio, del 2013. Le altre tre sono basate su progetti altrui. Non ho intenzione di copiarle né di pubblicarle, sono qui solo per mostrare che meccaniche di gioco completamente diverse possono girare su un unico motore.

Stone Age

Stone Age è riprodotta sul motore per intero. Le stesse caratteristiche, gli anni e i turni, la popolazione, le terre. Mandi i lavoratori nel bosco, raccolgono cibo, la popolazione cresce, compaiono le tecnologie - le studi, sblocchi gli edifici e l'albero dell'evoluzione, dall'australopiteco all'Homo habilis e oltre. Gli eventi, il finale - tutto quello che c'era nell'originale è al suo posto.

La console del prototipo: Stone Age - le caratteristiche della tribù, le terre, il menu delle tecnologie e dell'evoluzione

Slay the Spire

Poi c'è Slay the Spire, un ottimo roguelike a carte, qualcuno di sicuro ci ha giocato. Sul motore c'è solo il combattimento: il giocatore ha carte, energia e salute, il nemico ha la sua intenzione. Strike (Colpo) colpisce, Defend (Difesa) mette il blocco. Spendi energia, chiudi il turno, e così a turni finché qualcuno non vince.

La stessa console con Slay the Spire - salute, energia, l'intenzione del nemico e le carte in mano

GURPS

La terza simulazione è GURPS, un sistema da tavolo, piuttosto complesso. Da lì ho preso un solo modulo, il generatore di sistemi stellari. La cosa curiosa è che questo modulo di per sé non è affatto un gioco, ma un generatore complesso. Ha messo insieme un sistema con una stella e una marea di proprietà: dieci orbite, con sopra mondi diversi. Il primo, piccolo e roccioso, somiglia a Mercurio - con la sua massa, la pressione atmosferica e tutto il resto. In tutto questa simulazione ha più di seimila fatti. È un buon stress test: si vede quanti dati il motore riesce a reggere.

Un sistema stellare generato nel modulo GURPS - la stella, le orbite e le proprietà del primo mondo

Oregon Trail

La quarta è Oregon Trail, un classico del 1971 e uno dei primissimi giochi per computer. È il viaggio dei coloni attraverso l'America sui carri: prima di partire compri le provviste - buoi, cibo, munizioni, vestiti - e poi cacci, distribuisci le razioni e gestisci gli eventi. Qui ci hanno appena attaccato. E così fino alla fine del percorso.

Oregon Trail nella stessa console: le provviste - cibo, munizioni, vestiti, soldi - e la scelta delle azioni quando si incontrano i cavalieri

Tutti e quattro i giochi girano su un unico motore, e per nessuno di loro ho dovuto scrivere codice.

Modifiche al volo

Ma il motore non si limita a far girare questi giochi - si possono cambiare al volo, senza toccare il codice. Prendiamo Slay the Spire.

Il turno iniziale di Slay the Spire sul motore: salute, energia, il nemico e cinque carte in mano - il danno di Strike (Colpo) è ancora 6

Cambio il danno della carta Strike (Colpo), lo porto a 100:

/set Strike.CalcDamage Value 100

La proprietà è cambiata subito su entrambe queste carte, perché hanno la stessa classe.

In mano ci sono due carte Strike (Colpo), e ora entrambe hanno 100 di danno - la proprietà è cambiata di colpo su tutte le carte di questa classe

E si può anche aggiungere una carta del tutto nuova, Fireball (Palla di fuoco):

/add Fireball Is DirectDamage
/set Fireball.CostEnergy Value 2
/add Fireball Has CalcDamage
/set Fireball.CalcDamage Value 20
/add Fireball Has ApplyDamage
/add Fireball.ExecutionEffects Has CostEnergy
/add Fireball.ExecutionEffects Has CalcDamage
/add Fireball.ExecutionEffects Has ApplyDamage

Non c'era, e adesso è nel gioco - sta in mano, si gioca, infligge 20 di danno e va negli scarti, come una carta qualsiasi:

Dopo le modifiche: entrambe le carte Strike (Colpo) sono ora a 100 di danno, e in mano è comparsa una nuova carta Fireball (Palla di fuoco) da 20 di danno

Si possono cambiare anche le regole stesse, con un solo comando. Tolgo la regola per cui le carte giocate finiscono negli scarti.

/remove PlayCard Has MovePlayedCard

Adesso restano in mano. Ho giocato Defend (Difesa): il blocco è salito, l'energia si è consumata, ma la carta è rimasta.

Dopo il cambio di regola: Defend (Difesa) è stato giocato - energia 0/3, blocco 5 - ma tutte le carte giocate sono rimaste in mano, contrassegnate con [X]

In un gioco normale, scritto in un linguaggio di programmazione, per farlo bisognerebbe mettere le mani nel codice e ricompilare il progetto. Qui non serve.

Allo stesso modo si aggiunge al gioco anche ciò che prima non c'era affatto. L'oro, per esempio - lo introduco e descrivo come si spende:

/set Player.Gold Value 100
/add CostGold Output Owner.Gold
/add CostGold Math.Subtract.Apply true

Compare una caratteristica che un attimo prima non c'era - l'oro, e subito un centinaio tondo.

Nella barra di stato è comparso l'oro - subito cento - una caratteristica che un attimo prima nel gioco non c'era

Con questo oro si può creare anche una nuova azione - Bribe (Corruzione). Non consuma energia, ma oro:

/add Bribe Is DirectDamage
/set Bribe.CostEnergy Value 0
/set Bribe.CostGold Value 30
/add Bribe Has CalcDamage
/set Bribe.CalcDamage Value 15
/add Bribe Has ApplyDamage
/add Bribe Has CostGold
/add Bribe.ExecutionEffects Has CostGold
/add Bribe.ExecutionEffects Has CalcDamage
/add Bribe.ExecutionEffects Has ApplyDamage
/create Bribe Player.Hand

Bribe (Corruzione) costa trenta d'oro e infligge quindici di danno - e funziona subito.

In mano è comparsa una nuova azione, Bribe (Corruzione): zero energia, trenta d'oro e quindici di danno

Può sembrare che siano trucchi e che digitare comandi del genere sia scomodo. Ma non sono trucchi. È la modifica dei fatti logici e dei dati su cui si regge tutto il gioco - i suoi oggetti, le sue proprietà e le sue meccaniche. In sostanza è il linguaggio in cui il gioco è scritto.

Imparare questo linguaggio non è obbligatorio. Si può chiedere all'IA di tradurre una frase normale nei comandi che Nexus capisce. Per esempio:

give 999 gold

In pratica vuol dire semplicemente «Aggiungi 999 d'oro».

Una richiesta all'IA con parole normali - «give 999 gold». Il motore troverà da solo il comando giusto e lo eseguirà

L'IA ragiona, trova il comando giusto e lo esegue, e ci ritroviamo con 999 d'oro.

Si può dire anche in altri modi, «oro 100» - funziona pure così. «Fammi diventare un dio» - e l'IA ti dà l'invulnerabilità. Chiudere il turno, colpire, curarsi - tutto questo si può fare a parole, il motore capisce. E niente di tutto ciò è scriptato, funziona davvero.

Piani

I comandi voglio semplificarli. Adesso, per creare quella stessa Fireball (Palla di fuoco), servono circa otto comandi, e penso di ridurli a tre o quattro. E nel prossimo video proverò a mostrare qualcosa di più visivo - un render 2D.

Maggiori dettagli sul motore e sui piani nella sezione Nexus.

Avvertenza: Stone Age è un gioco dello studio. Slay the Spire, GURPS e Oregon Trail appartengono ai rispettivi titolari e sono mostrati solo come dimostrazione del motore - queste build non vengono distribuite da nessuna parte.