Calculadora de ticks do Minecraft

No Minecraft, às vezes você pensa no tempo em segundos, enquanto o jogo conta ticks por trás. Uma porta de Redstone fecha dois passos antes do esperado, uma linha de hopper esvazia mais devagar do que você imaginava, você digita um número no comando /time set, mas o sol não para onde você queria. Na maioria das vezes, o problema não é o jogo estar quebrado; é você tratar tempo real, game tick e redstone tick como se fossem a mesma coisa. Essa confusão acontece bastante, especialmente com quem está começando em Redstone.

O tempo do jogo não flui como segundos

O ritmo básico do Minecraft funciona por game tick. No jogo Vanilla, a velocidade-alvo é de 20 game ticks por segundo. Ou seja:

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

Um game tick também corresponde a 0,05 segundo.

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

No papel, é bem simples.

Se você escrever 60 segundos, isso dá 1200 game ticks. 1 minuto também dá 1200 game ticks. Já 10 minutos dão 12000 game ticks. O fato de um ciclo completo de dia no Minecraft ter 24000 ticks também fica familiar por causa disso; em um mundo rodando a 20 TPS, 24000 ticks são 20 minutos na vida real.

Quando o TPS cai, as coisas mudam. 1200 game ticks duram 60 segundos a 20 TPS. Se o servidor cair para 10 TPS, os mesmos 1200 ticks se espalham desta vez por 120 segundos na vida real. Aquilo que você olha no jogo e pensa “por que isso atrasou?” às vezes não vem do circuito, mas do servidor estar sobrecarregado.

A fórmula principal no cálculo de tempo é esta:

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

O inverso é escrito assim:

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

Para Vanilla, normalmente se usa TPS como 20. Se o servidor estiver com lag e você estiver tentando entender o tempo real de espera, é preciso inserir o TPS como ele está; caso contrário, sua conta ficará apenas teórica.

Essa diferença incomoda especialmente em farms automáticas e circuitos de Redstone. Um mecanismo que funciona bem no Singleplayer pode se comportar de forma mais pesada em um servidor cheio. Porque o jogo ainda exige a mesma quantidade de ticks, apenas processa esses ticks mais lentamente.

Redstone tick fala outra língua

No Minecraft, a palavra “tick” sozinha é meio traiçoeira. Quando alguém diz “coloque 10 tick delay”, primeiro é preciso entender se está falando de game tick ou redstone tick. No lado do Redstone, 1 redstone tick é considerado igual a 2 game ticks. Em velocidade Vanilla, isso é 0,1 segundo.

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

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

10 redstone ticks dão 20 game ticks. Mas 10 game ticks são apenas 5 redstone ticks.

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

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

Quando você mistura os dois, o tempo do circuito erra por um fator de dois. Em portas de piston, travas de item sorter e cadeias de observer, essa diferença aparece imediatamente. A porta trava onde deveria fechar, o piston não consegue pegar um bloco, o sorter deixa passar itens demais. Aí a pessoa culpa o fio. Às vezes o fio é inocente.

Por isso, o atraso do repeater é pensado separadamente. Um repeater pode dar atraso de 1, 2, 3 ou 4 redstone ticks. Se você quiser um atraso mais longo, coloca repeaters em sequência.

Vamos supor que seja necessário um atraso de 46 game ticks. Primeiro convertemos para redstone tick:

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

Para montar 23 redstone ticks com repeater, são necessários 5 repeaters completos de 4-tick, sobrando 3 redstone ticks.

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

Ou seja, o arranjo é lido assim:

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

Aqui também entra a lógica de arredondar para cima. Se a conta não cair exatamente em um redstone tick, é mais seguro completar para o valor superior em vez de dar um atraso menor. Afinal, não existe meia configuração de repeater. Ou é 2 ticks ou é 3 ticks. Não há meio-termo.

A expressão prática usada no lado do repeater é esta:

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

Depois, encontra-se a quantidade de repeaters de 4-tick:

$$
\text{Quantidade de repetidores de 4 ticks} = \left\lfloor \frac{\text{Redstone Tick}}{4} \right\rfloor
$$

O atraso restante também sai pelo cálculo de módulo:

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

No Redstone, essas pequenas diferenças às vezes crescem bastante. Especialmente em mecanismos rápidos de piston, o sinal chegar “um tick mais tarde” pode definir se toda a estrutura funciona corretamente ou não. Esse é um lado um pouco cruel do jogo.

Por que os valores de /time set parecem estranhos?

Um dia do Minecraft dura 24000 game ticks. O movimento do sol, o ciclo dia-noite e o comando /time set funcionam nessa linha. Quando você escreve 6000 no comando, vira meio-dia. Por volta de 12000 é o pôr do sol. 18000 pode ser pensado como algo próximo da meia-noite.

Mas a lógica do relógio, à primeira vista, não começa como no mundo real. O tick 0 é lido no jogo como algo próximo de 06:00. Por isso, 6000 ticks correspondem aproximadamente a 12:00. E 18000 ticks se encaixam por volta de 00:00.

O cálculo de tick dentro do dia olha para o resto do valor de tick informado em relação a 24000:

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

Ou seja, mesmo que você escreva 25000 ticks, o jogo lê isso como o tick 1000 do novo dia. Porque depois de 24000, o ciclo começa de novo.

O cálculo aproximado usado para o equivalente em horas é este:

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

No lado dos minutos, o valor de tick restante é multiplicado por 0,06:

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

Para 6000 ticks, a conta chega aproximadamente a 12:00.

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

Criadores de mapas usam isso bastante. Também é útil ao tirar screenshots. Às vezes até a direção da sombra muda a cena; quem tira fotos no jogo sabe que a luz da manhã e a luz do meio-dia não passam a mesma sensação.

Esta lista curta é fácil de lembrar:

Escrever 24000 e escrever 0 leva, na maioria dos casos, ao mesmo lugar. O jogo reinicia o ciclo.

Esperar na velocidade do hopper é outro problema

O hopper é uma das peças mais silenciosas do Minecraft, mas também uma das que mais cria gargalos. Para transferir um item para outro inventário, ele precisa de 8 game ticks. A 20 TPS, isso dá 0,4 segundo.

$$
1 \text{ transferência por hopper} = 8 \text{ game tick}
$$

$$
1 \text{ transferência por hopper} = 0{,}4 \text{ segundo}
$$

A velocidade de transferência por minuto de um único hopper é calculada assim:

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

Se o TPS for 20:

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

Ou seja, um único hopper move cerca de 150 itens por minuto.

Vamos imaginar uma pilha de 400 itens. Primeiro encontramos o equivalente em ticks:

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

Depois convertemos para segundos:

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

160 segundos dão 2 minutos e 40 segundos.

Esse número pode parecer pequeno, mas quando você está esperando ao lado do baú enquanto a farm funciona, ele não parece tão pequeno assim. Ainda mais se o sistema produz 300 itens por minuto e você está tentando coletar tudo com um único hopper: o travamento é inevitável. Os itens se acumulam, depois surge uma fila de hopper, depois você começa a ver itens no chão.

Ver itens no chão é a forma do sistema de armazenamento dizer: “não estou dando conta”.

No cálculo de hopper, é preciso evitar um erro: essa velocidade é para um único hopper. Se várias linhas trabalham em paralelo, o fluxo aumenta. Se a cadeia de hoppers for muito longa, cada transferência traz seu próprio atraso. Se houver canal de água, linha de dropper, chest minecart ou sistema de transporte modded, o assunto muda. Esta conta serve mais para ler rapidamente o comportamento do hopper vanilla.

Aqui também o TPS afeta o tempo real. Enquanto 400 itens são transferidos em 160 segundos a 20 TPS, a 10 TPS isso aumenta para 320 segundos.

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

A quantidade de ticks dentro do jogo é a mesma, mas o tempo real de espera dobra. Às vezes é por isso que alguém pergunta no servidor: “o hopper quebrou?” Não quebrou; o mundo só ficou mais pesado.

Qual modo usar e quando?

Se a pergunta que você tem é “quantos segundos?”, uma conversão direta basta. Por exemplo, se você diz “a porta deve fechar depois de 5 segundos”, então 5 segundos dão 100 game ticks.

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

Saber isso já é suficiente para command blocks ou trabalhos simples de atraso.

Se você está montando um circuito de Redstone, olhe para o atraso do repeater. Porque aquilo que você colocará no jogo não é segundo, é configuração de repeater. Um atraso de 2 segundos dá 40 game ticks, ou seja, 20 redstone ticks.

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

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

20 redstone ticks também podem ser montados com 5 repeaters de 4-tick.

Para o tempo do Minecraft, é necessário o valor de /time set. Se você quer “que seja meio-dia”, use 6000; se quer “que seja meia-noite”, use algo em torno de 18000. Aqui não se fala de segundos, mas da posição do tick dentro do dia.

No lado do hopper, a pergunta é completamente diferente: “em quanto tempo essa quantidade de itens passa?” Faz mais sentido escrever a quantidade de itens e ver o tempo. Isso é usado especialmente nas saídas de farms automáticas para entender se um único hopper é suficiente.

A escolha da unidade importa. Game tick, redstone tick, segundo, minuto, transferência de hopper e dia do Minecraft podem parecer faces diferentes da mesma coisa, mas são usados para decisões diferentes no jogo. Você pode pensar no segundo como o tempo da pessoa, no game tick como o tempo do jogo e no redstone tick como o tempo do circuito.

É uma simplificação, mas funciona.

Se o cálculo está certo, por que o jogo se comporta diferente?

Mesmo quando o cálculo de tick está correto, o resultado no jogo pode não bater exatamente. Há alguns motivos para isso.

O primeiro é o TPS. Se o servidor não está rodando a 20 TPS, o tempo real aumenta. Até o jogo dizer “1200 ticks se passaram”, você pode ter esperado mais de 60 segundos no mundo real. O cálculo de comando, Redstone ou hopper não se quebra; ele apenas termina mais tarde.

O segundo é o carregamento de chunks. Se um chunk não está carregado, alguns sistemas ali não funcionam como você espera. Linha de hopper, farm, redstone clock; tudo depende de o mundo continuar ativo. Um mecanismo que você deixou longe nem sempre continuará processando como você imagina.

O terceiro é a ordem de atualização do Redstone. Redstone não é apenas cálculo de tempo. De onde o sinal vem, qual bloco é atualizado primeiro, a direção do repeater, o comportamento do comparator, o que o piston vê e quando vê — tudo isso entra na conta. Às vezes 4 ticks é o valor certo, mas o layout do circuito está errado.

Também existem diferenças entre Java e Bedrock. Mesmo que a maioria das proporções básicas de tempo pareça igual, diferenças de versão no comportamento de Redstone podem dar dor de cabeça. Não é surpresa montar no Bedrock, exatamente igual, um circuito Java visto no YouTube e ele não funcionar.

A calculadora não faz mágica nesse ponto. Ela entrega a parte do tempo de forma limpa. O restante é determinado pela organização física do jogo.

Alguns hábitos pequenos, mas úteis

Primeiro, esclareça qual “tick” está sendo mencionado. Game tick ou redstone tick? Entrar no cálculo do circuito sem perguntar isso é um pouco como colocar blocos sem medir.

Em linhas longas de hopper, não confie na velocidade de um único hopper. Se uma farm produz mais de 150 itens por minuto, uma única linha vai entupir em algum ponto. São necessárias duas linhas, um fluxo de água seria melhor, ou um dropper clock? Isso depende do design.

Nos comandos /time set, em vez de decorar todos os números, saiba alguns pontos principais: 0 manhã, 6000 meio-dia, 12000 noite chegando, 18000 meia-noite. O restante se ajusta no olho. Minecraft também é um pouco um jogo de estimativa visual.

No atraso de repeater, pensar em blocos de 4-tick facilita. Primeiro converta o atraso para redstone tick, depois divida em partes de 4. Se o restante for 1, 2 ou 3, você coloca mais um repeater no final.

Também não esqueça completamente o TPS. Em mundos singleplayer, assumir 20 TPS costuma ser suficiente. Se as coisas começarem a ficar estranhas no servidor, é mais inteligente olhar primeiro o TPS. Antes de desmontar a linha de Redstone, digo.