Calcolatore tick Minecraft

In Minecraft a volte pensi al tempo in secondi, mentre il gioco, dietro le quinte, conta i tick. Una porta in redstone si chiude due passaggi troppo presto, una linea di hopper si svuota più lentamente del previsto, scrivi un numero nel comando /time set ma il sole non si ferma dove vorresti. Il problema, nella maggior parte dei casi, non è che il gioco sia rotto; è che stai considerando tempo reale, game tick e redstone tick come se fossero la stessa cosa. Questa confusione è molto comune, soprattutto tra chi si avvicina alla redstone per la prima volta.

Il tempo del gioco non scorre come i secondi

Il ritmo di base di Minecraft funziona tramite i game tick. Nel gioco vanilla, la velocità target è di 20 game tick al secondo. Quindi:

$$
1 \text{ secondo} = 20 \text{ game tick}
$$

Un game tick corrisponde anche a 0,05 secondi.

$$
1 \text{ game tick} = 0{,}05 \text{ secondo}
$$

Sulla carta è tutto molto lineare.

Se scrivi 60 secondi, ottieni 1200 game tick. Anche 1 minuto equivale a 1200 game tick. 10 minuti, invece, sono 12000 game tick. Anche il fatto che il ciclo completo di un giorno in Minecraft duri 24000 tick torna da qui: in un mondo che gira a 20 TPS, 24000 tick corrispondono a 20 minuti nella vita reale.

Quando i TPS scendono, le cose cambiano. 1200 game tick durano 60 secondi a 20 TPS. Se il server scende a 10 TPS, quegli stessi 1200 tick questa volta si distribuiscono su 120 secondi reali. Quello che in gioco guardi chiedendoti “perché è in ritardo?” a volte non dipende dal circuito, ma dal server sotto carico.

La formula principale per il calcolo del tempo è questa:

$$
\text{Game Tick} = \text{secondo} \times \text{TPS}
$$

L’inversa si scrive così:

$$
\text{secondo} = \frac{\text{Game Tick}}{\text{TPS}}
$$

Per vanilla, in genere si considera TPS pari a 20. Se il server ha lag e stai cercando di capire il tempo reale di attesa, devi inserire il valore TPS effettivo; altrimenti il calcolo resta teorico.

Questa distinzione diventa fastidiosa soprattutto nelle farm automatiche e nei circuiti di redstone. Un sistema che funziona bene in singleplayer può comportarsi in modo più lento su un server affollato. Perché il gioco richiede ancora lo stesso numero di tick, solo che li elabora più lentamente.

Il redstone tick parla un’altra lingua

In Minecraft, la parola “tick” da sola è un po’ ingannevole. Quando qualcuno dice “metti 10 tick di delay”, bisogna prima capire se sta parlando di game tick o di redstone tick. Nel lato redstone, 1 redstone tick è considerato pari a 2 game tick. A velocità vanilla, questo corrisponde a 0,1 secondi.

$$
1 \text{ redstone tick} = 2 \text{ game tick}
$$

$$
1 \text{ redstone tick} = 0{,}1 \text{ secondo}
$$

10 redstone tick equivalgono a 20 game tick. Ma 10 game tick sono solo 5 redstone tick.

$$
\text{Game Tick} = \text{Redstone Tick} \times 2
$$

$$
\text{Redstone Tick} = \frac{\text{Game Tick}}{2}
$$

Se li confondi, il tempo del circuito sbaglia di un fattore due. Nelle porte a pistoni, nei blocchi degli item sorter e nelle catene di observer, questa differenza si nota subito. La porta si inceppa proprio dove dovrebbe chiudersi, un pistone non riesce ad agganciare un blocco, il sorter lascia passare troppi item. Poi si finisce per dare la colpa ai cavi. A volte i cavi sono innocenti.

Per questo il ritardo dei repeater va considerato separatamente. Un repeater può dare un ritardo di 1, 2, 3 o 4 redstone tick. Se vuoi un ritardo più lungo, metti più repeater in serie.

Immaginiamo di volere un ritardo di 46 game tick. Prima lo convertiamo in redstone tick:

$$
46 \text{ game tick} \div 2 = 23 \text{ redstone tick}
$$

Per costruire 23 redstone tick con i repeater servono 5 repeater completi da 4 tick, con un resto di 3 redstone tick.

$$
23 = 5 \times 4 + 3
$$

Quindi la configurazione si legge così:

5 x 4-tick + 1 x 3-tick.

Qui entra in gioco anche la logica dell’arrotondamento verso l’alto. Se il calcolo non cade esattamente su un redstone tick, è più sicuro completare al valore superiore invece di dare meno ritardo. Dopotutto, non esiste un’impostazione da mezzo repeater. O sono 2 tick, o sono 3 tick. Non c’è una via di mezzo.

L’espressione pratica usata per i repeater è questa:

$$
\text{Repeater Redstone Tick} = \left\lceil \frac{\text{Game Tick}}{2} \right\rceil
$$

Poi si trova il numero di repeater da 4 tick:

$$
\text{Numero di ripetitori a 4 tick} = \left\lfloor \frac{\text{Redstone Tick}}{4} \right\rfloor
$$

Il ritardo rimanente si ottiene con il calcolo del modulo:

$$
\text{Rimanente} = \text{Redstone Tick} \bmod 4
$$

In redstone, queste piccole differenze a volte diventano molto grandi. Soprattutto nei sistemi rapidi a pistoni, un segnale che vuoi far arrivare “un tick più tardi” può determinare se l’intera struttura funziona correttamente oppure no. Il lato spietato del gioco è un po’ questo.

Perché i valori di /time set sembrano strani?

Un giorno di Minecraft dura 24000 game tick. Il movimento del sole, il ciclo giorno-notte e il comando /time set funzionano su questa linea. Quando scrivi 6000 nel comando, diventa mezzogiorno. Intorno a 12000 è il tramonto. 18000 può essere considerato circa mezzanotte.

Ma a prima vista la logica dell’orologio non inizia come nel mondo reale. Il tick 0, nel gioco, si legge più o meno come le 06:00. Per questo 6000 tick corrispondono circa alle 12:00. Anche 18000 tick si collocano intorno alle 00:00.

Il calcolo del tick all’interno del giorno guarda il resto del valore inserito rispetto a 24000:

$$
\text{Giorno Tick} = \text{Game Tick} \bmod 24000
$$

Quindi anche se scrivi 25000 tick, il gioco lo interpreta come il tick 1000 del nuovo giorno. Perché dopo 24000 il ciclo ricomincia.

Il calcolo approssimativo usato per ottenere l’ora equivalente è questo:

$$
\text{Ora} = \left\lfloor \left(\frac{\text{Giorno Tick}}{1000} + 6\right) \bmod 24 \right\rfloor
$$

Per i minuti, invece, il valore di tick rimanente viene moltiplicato per 0,06:

$$
\text{Minuto} = \text{round}((\text{Giorno Tick} \bmod 1000) \times 0{,}06)
$$

Per 6000 tick, il calcolo arriva circa a 12:00.

$$
\left(\frac{6000}{1000} + 6\right) \bmod 24 = 12
$$

Chi crea mappe lo usa spesso. È utile anche quando si fanno screenshot. A volte perfino la direzione dell’ombra cambia la scena; chi scatta foto in gioco lo sa, la luce del mattino e quella di mezzogiorno non danno la stessa sensazione.

Questa breve lista è facile da ricordare:

Scrivere 24000 o scrivere 0, nella maggior parte dei casi, porta allo stesso risultato. Il gioco riavvolge il ciclo all’inizio.

Aspettare alla velocità degli hopper è un altro problema

L’hopper è uno dei componenti più silenziosi di Minecraft, ma anche uno di quelli che creano più colli di bottiglia. Per trasferire un item a un altro inventario richiede 8 game tick. A 20 TPS, questo equivale a 0,4 secondi.

$$
1 \text{ trasferimento tramite hopper} = 8 \text{ game tick}
$$

$$
1 \text{ trasferimento tramite hopper} = 0{,}4 \text{ secondo}
$$

La velocità di trasferimento al minuto di un singolo hopper si calcola così:

$$
\text{Item / Minuto} = \frac{\text{TPS} \times 60}{8}
$$

Se TPS è 20:

$$
\frac{20 \times 60}{8} = 150
$$

Quindi un singolo hopper sposta circa 150 item al minuto.

Immaginiamo un gruppo di 400 item. Prima troviamo il corrispettivo in tick:

$$
400 \times 8 = 3200 \text{ game tick}
$$

Poi lo convertiamo in secondi:

$$
\frac{3200}{20} = 160 \text{ secondo}
$$

160 secondi equivalgono a 2 minuti e 40 secondi.

Questo numero può sembrare piccolo, ma quando aspetti davanti al baule mentre la farm è in funzione non sembra poi così piccolo. Soprattutto se il sistema produce 300 item al minuto e tu provi a raccoglierli con un solo hopper, l’intasamento è inevitabile. Gli item si accumulano, poi si forma una coda di hopper, poi inizi a vedere item a terra.

Vedere item a terra è il modo in cui il sistema di stoccaggio dice: “non riesco a stare al passo”.

Nel calcolo degli hopper bisogna evitare un errore: questa velocità vale per un singolo hopper. Se più linee lavorano in parallelo, il flusso aumenta. Se la catena di hopper è molto lunga, ogni trasferimento aggiunge il proprio ritardo. Se ci sono un canale d’acqua, una linea di dropper, un chest minecart o un sistema di trasporto moddato, il discorso cambia. Questo calcolo serve soprattutto per leggere rapidamente il comportamento vanilla degli hopper.

Anche qui i TPS influenzano il tempo reale. Mentre 400 item vengono trasferiti in 160 secondi a 20 TPS, a 10 TPS il tempo sale a 320 secondi.

$$
\frac{3200}{10} = 320 \text{ secondo}
$$

Il numero di tick in gioco è lo stesso, ma il tempo reale di attesa raddoppia. A volte è per questo che su un server qualcuno chiede “si è rotto l’hopper?”. Non si rompe, è solo il mondo che si è appesantito.

Quale modalità va usata e quando?

Se la domanda che hai in mano è “quanti secondi?”, basta una conversione diretta. Per esempio, se dici “la porta deve chiudersi dopo 5 secondi”, 5 secondi corrispondono a 100 game tick.

$$
5 \times 20 = 100 \text{ game tick}
$$

Sapere questo è sufficiente per i command block o per semplici lavori di ritardo.

Se stai costruendo un circuito di redstone, guarda il ritardo dei repeater. Perché ciò che piazzerai nel gioco non sono secondi, ma impostazioni dei repeater. Un ritardo di 2 secondi equivale a 40 game tick, cioè 20 redstone tick.

$$
2 \times 20 = 40 \text{ game tick}
$$

$$
40 \div 2 = 20 \text{ redstone tick}
$$

20 redstone tick possono essere costruiti con 5 repeater da 4 tick.

Per il tempo di Minecraft serve il valore di /time set. Se vuoi il mezzogiorno, usa 6000; se vuoi la mezzanotte, circa 18000. Qui non si parla di secondi, ma della posizione del tick all’interno del giorno.

Dal lato hopper, la domanda è completamente diversa: “quanto tempo impiegano questi item a scorrere?”. Ha più senso inserire il numero di item e vedere il tempo. Si usa soprattutto per capire se un singolo hopper basta nelle uscite delle farm automatiche.

La scelta dell’unità è importante. Anche se game tick, redstone tick, secondi, minuti, trasferimento hopper e giorno di Minecraft sembrano facce diverse della stessa cosa, nel gioco vengono usati per decisioni diverse. Puoi pensare ai secondi come al tempo umano, ai game tick come al tempo del gioco e ai redstone tick come al tempo del circuito.

È un po’ approssimativo, ma funziona.

Se il calcolo è corretto, perché il gioco si comporta diversamente?

Anche quando il calcolo dei tick è corretto, il risultato in gioco potrebbe non coincidere perfettamente. Ci sono alcuni motivi.

Il primo sono i TPS. Se il server non gira a 20 TPS, il tempo reale si allunga. Prima che il gioco dica “sono passati 1200 tick”, nel mondo reale potresti aver aspettato più di 60 secondi. Il comando, la redstone o il calcolo dell’hopper non si rompono; semplicemente vengono completati più tardi.

Il secondo è il caricamento dei chunk. Se un chunk non è caricato, alcuni sistemi al suo interno non funzionano come ti aspetti. Linea di hopper, farm, redstone clock: tutto dipende dal fatto che il mondo resti attivo. Un meccanismo lasciato lontano non sempre continua a funzionare come lo immagini.

Il terzo è l’ordine degli aggiornamenti della redstone. La redstone non è solo calcolo del tempo. Entrano in gioco da dove arriva il segnale, quale blocco si aggiorna per primo, la direzione del repeater, il comportamento del comparator, cosa vede il pistone e quando. A volte 4 tick sono il valore corretto, ma la disposizione del circuito è sbagliata.

Poi ci sono anche le differenze tra Java e Bedrock. Anche se la maggior parte dei rapporti di tempo di base sembra uguale, le differenze di versione nel comportamento della redstone possono causare parecchi grattacapi. Non è sorprendente che un circuito Java visto su YouTube non funzioni allo stesso modo quando lo costruisci in Bedrock.

La calcolatrice, a questo punto, non fa magie. Ti restituisce in modo pulito la parte relativa al tempo. Il resto lo determina la disposizione fisica del gioco.

Alcune piccole abitudini utili

Prima chiarisci a quale “tick” ci si riferisce. Game tick o redstone tick? Iniziare il calcolo di un circuito senza chiederlo è un po’ come piazzare blocchi senza misurare.

Nelle linee di hopper lunghe, non fare affidamento sulla velocità di un singolo hopper. Se una farm produce più di 150 item al minuto, una singola linea a un certo punto si intasa. Servono due linee, è meglio un flusso d’acqua, conviene montare un dropper clock: quello dipende dal progetto.

Nei comandi /time set, invece di memorizzare tutti i numeri, tieni a mente alcuni punti principali: 0 mattina, 6000 mezzogiorno, 12000 sera, 18000 mezzanotte. Il resto si regola a occhio. In fondo Minecraft è anche un gioco da valutare a colpo d’occhio.

Per il ritardo dei repeater, pensare in blocchi da 4 tick rende tutto più semplice. Prima converti il ritardo in redstone tick, poi dividilo in parti da 4. Se resta 1, 2 o 3, aggiungi un altro repeater alla fine.

E non dimenticare del tutto i TPS. In un mondo singleplayer, di solito l’assunzione di 20 TPS è sufficiente. Se su un server le cose diventano strane, controllare prima i TPS è spesso la scelta più intelligente. Prima di smontare la linea di redstone, insomma.