Tique

Quase todos os jogos eletrônicos (incluindo o Minecraft) são movidos por um grande loop de programa. Assim como as engrenagens de um relógio são sincronizadas com o pêndulo, todas as tarefas envolvidas no avanço da simulação do jogo são sincronizadas com o loop do jogo. De forma apropriada, um ciclo de loop do jogo é chamado de tique (ou ciclo, em inglês: tick).

Tique do jogo

Um tique no Minecraft refere-se a uma única execução do loop de jogo. O jogo normalmente opera a uma taxa fixa de 20 tiques por segundo, o que significa que cada tique ocorre a cada 0,05 segundos (50 milissegundos), tornando um dia no jogo durar exatamente 24.000 tiques (20 minutos). No entanto, se o computador não conseguir manter essa velocidade, haverá menos tiques por segundo (TPS). Como a maioria das ações são cronometradas com base na contagem de tiques, isso significa que muitas coisas demoram mais em um computador mais fraco.

Uma estatística relacionada aos ticks por segundo (TPS) é milissegundos por tick (MSPT), que indica o tempo que um servidor realmente utiliza para computar um tick. O TPS pode ser mantido em 20 apenas se o MSPT não for superior a 50. Os seguintes fatores frequentemente contribuem para o lag do lado do servidor:

• Os funis verificam constantemente a presença de itens acima deles. Para evitar essas verificações e reduzir o lag, é recomendável cobrir os funis com blocos sólidos, (exceto colmeias e colmeias artificiais). Alternativamente, o uso de sistemas de transporte de itens baseados em fluxo de água pode ser mais eficiente para transportar grandes quantidades de itens.
• Máquinas de redstone. Componentes de redstone, especialmente o pó de redstone, causam grandes quantidades de atualizações de blocos e podem gerar lag. Desativar circuitos de redstone e relógios quando não estiverem em uso pode ajudar a reduzir esse impacto.
• Inteligência artificial de criaturas. Utilize tochas para controlar a geração de criaturas hostis. Para animais, use fazendas mais eficientes.
• Velocidade de tique aleatório. Ao usar o comando /gamerule randomTickSpeed, se a velocidade de tique aleatório for muito alta, o MSPT pode aumentar de forma anormal.

O valor de MSPT é exibido na tela de depuração F3 como "ms ticks" na Edição Java. O gráfico de tempo de quadro (ativado com (F3 + 2)) mostra o valor de TPS. Ambas as exibições estão disponíveis apenas para o anfitrião em jogos multijogador ou para jogadores em modo singleplayer, pois as estatísticas são provenientes do servidor integrado do seu jogo Minecraft.

Na Edição Java, as taxas de tiques podem ser controladas pelo comando /tick.

Processo do jogo

Na Edição Java, em cada loop do jogo, as seguintes ações são processadas em ordem:

• Redefinir o tempo do próximo tique se estiver atrasado 2 segundos em relação ao tempo esperado do tique.
• Calcular o tempo do próximo tique.
• Incrementar a contagem de tiques.
• Funções com tick ou load são executadas.
• Cada dimensão é processada na ordem superfície, nether, end e dimensões personalizadas. Para cada dimensão:
  • Enviar o tempo a cada 20 tique do jogo para os jogadores
  • Atualizar os limites da barreira do mundo
  • Avançar o ciclo do clima
  • Atualizar o tempo do ciclo de dia e noite
  • Lógica de sono do jogador
  • Executar comandos agendados
  • Tiques agendados de blocos.
  • Tiques agendados de fluídos.
  • Lógica de invasões.
  • Atualizar o nível de carregamento dos chunks.
  • Para todos os chunks em ordem aleatória:
    • Gerar criaturas.
    • Processar tiques de gelo e neve.
    • Tiques aleatórios.
  • Enviar alterações de blocos para os jogadores.
  • Atualizar pontos de interesse.
  • Descarregar chunks.
  • Executar eventos de blocos.
  • Processar a luta contra o dragão.
  • Para todas as entidades que não são passageiros:
    • Verificar se pode desaparecer.
    • Processar a entidade.
    • Processar passageiros.
  • Processar entidades de blocos.
  • Lidar com eventos do jogo.
• Enviar pacotes na fila e lidar com pacotes recebidos para cada jogador.
• Enviar informações dos jogadores para os jogadores.
• Salvamento automático a cada 6000 tiques.
• Executar tarefas pendentes e esperar pelo próximo tique.

Tique de chunk

A extensão do tique aleatório, mostrada com a propagação de grama na terra. Note como a grama segue os limites dos chunks. As setas vermelha e azul no centro marcam as direções +X e +Z. O jogador está na localização (7,7) em um chunk, ligeiramente para o canto noroeste do chunk, o que significa que os centros de dois chunks na borda nas direções -X e -Z são trazidos dentro do raio de 128 blocos, permitindo assim o processamento do tique do chunk. Isso é confirmado pelas duas projeções de grama de um chunk nas bordas norte e oeste. (O norte está para cima)

Como parte de um tique do jogo, chunks específicos são processados em cada tique do jogo.

Na Edição Java, chunks com tipo de carregamento de entidades (veja Chunk#Nível e tipo de carga) e com distância horizontal entre seu centro e um jogador (não no modo espectador) menor que 128 blocos são processados em cada tique do jogo. Algumas coisas devem ser notadas aqui: primeiro, o chunk deve ser carregado como um chunk de processamento de entidades. Segundo, se o chunk recebe o tique do chunk, mesmo que alguns blocos no chunk estejam fora do raio de 128 blocos, eles podem receber tique aleatório normalmente. Terceiro, como 128 blocos é a distância horizontal, a posição do jogador ao longo do eixo y não importa.

Na Edição Bedrock, todos os chunks dentro da distância de simulação (ou especificados no comando /tickingarea) são processados em cada tique do jogo. O tique aleatório ocorre aleatoriamente em blocos nos chunks processados, independentemente da posição do jogador dentro do chunk. A distância de 128 blocos usada na Edição Java não se aplica.

Em ambas as edições, as seguintes coisas acontecem quando um chunk é processado:

• Criaturas geram naturalmente.
• Durante uma tempestade, pode haver um raio em algum lugar no chunk (chance de ¹⁄₁₀₀₀₀₀).
• Chance de ¹⁄₁₆ de que uma coluna seja escolhida para verificações climáticas no bloco mais alto:
  • Se estiver em um bioma nevado, a água congela e se transforma em gelo, se possível.
  • Se estiver nevando, uma camada de neve é colocada, se possível.
    • Além disso, caldeirões podem ser preenchidos com neve fofa.
  • Se estiver chovendo, um caldeirão é preenchido com água.
• Um certo número de blocos dentro do chunk recebem tiques aleatórios de blocos, conforme descrito abaixo.

Tique aleatório

Os chunks consistem em um subchunk para cada 16 blocos de altura, cada um sendo um cubo de 16×16×16=4096 blocos. Os subchunks são distribuídos verticalmente, começando no nível y mais baixo. A cada tique do chunk, alguns blocos são escolhidos aleatoriamente de cada subchunk no chunk. Os blocos nessas posições recebem um "tique aleatório".

Na Edição Java, o número de blocos escolhidos de cada subchunk é especificado pelo comando /gamerule randomTickSpeed (o padrão é 3), e um bloco pode ser escolhido várias vezes em um tique do chunk. Na Edição Bedrock, isso também depende do randomTickSpeed (o padrão é 1), mas especifica apenas a velocidade relativa em vez do número exato.

A maioria dos blocos ignora esse tique, mas alguns o usam para fazer algo:

• Os plantios podem crescer ou ser desenterrados.
• Cogumelos podem se espalhar ou ser desenterrados.
• Trepadeiras podem se espalhar.
• Fogo pode se apagar ou se espalhar.
• Gelo e camadas de neve podem derreter.
• Folhas podem decair.
• A hidratação da terra arada é atualizada.
• Cactos, cana-de-açúcar, [alga], bambu, flor do coro, propágulo de mangue e arbustos de bagas doces podem crescer.
• Blocos de grama e micélio podem se espalhar.
• Blocos de grama, micélio e nicélio podem decair (somente se a condição for atendida).
• Mudas podem crescer.
• Lava pode acender fogos próximos.
• Barro pode se transformar em argila se colocada em cima de um bloco com espeleotema pontiagudo abaixo.
• Minério de redstone aceso se apaga.
• Blocos de portal do Nether podem gerar um piglin-zumbi.
• Ovos de tartaruga racham ou eclodem.
• Fumaça de fogueiras aparecem.
• De uma Drusa de ametista pode crescer um agregado de ametista em qualquer um de seus lados, desde que não haja um bloco sólido.
• Blocos de cobre (ou qualquer uma de suas variantes não oxidadas) podem avançar um estágio na oxidação.
• espeleotemas pontiagudos podem encher um caldeirão abaixo.
• Estalactites pontiagudas podem crescer uma estalagmite/estalactite se as condições forem atendidas.

Como os tiques aleatórios de blocos são concedidos aleatoriamente, não há como prever quando um bloco receberá seu próximo tique. Na Edição Java, o tempo mediano entre tiques é de 47,30 segundos (${\log }_{\frac{4096-3}{4096}}(0.5)\approx$ 946.03 tiques do jogo). Ou seja, há uma chance de 50% de o intervalo ser igual ou menor que 47,30 segundos e uma chance de 50% de ser igual ou maior que 47,30. No entanto, às vezes é muito mais longo ou mais curto: por exemplo, há uma chance de 1,38% de o intervalo ser inferior a um segundo e uma chance de 1,23% de o intervalo ser superior a cinco minutos. Em média, os blocos são atualizados a cada 68,27 segundos ($\frac{4096}{3}\approx$ 1365.33 tiques do jogo). Para a matemática por trás desses números, veja as entradas da Wikipédia para a distribuição geométrica.

Tique agendado

Alguns blocos podem solicitar um tique para um momento no futuro. Esses "tiques agendados" são usados para coisas que precisam acontecer em um padrão previsível — por exemplo, repetidores de redstone agendam um tique para mudar de estado na Edição Java, e a água agenda um tique quando precisa se mover.

Como parte de um tique do jogo, cada posição de bloco que solicitou um tique agendado recebe um tique no tique específico do jogo.

Na Edição Java, existem dois tipos de tiques agendados: tiques de blocos e tiques de fluidos. Os tiques de blocos são executados primeiro com base na prioridade e, em seguida, com base na ordem de agendamento. Um valor mais baixo de prioridade resulta em execução mais cedo durante a fase de tique agendado. Se um repetidor de redstone estiver voltado para a parte traseira ou lateral de outro componente, seu tique de bloco tem uma prioridade de -3. Se um repetidor de redstone estiver desligando, ele tem uma prioridade de -2. Caso contrário, o repetidor tem uma prioridade de -1. Se um comparador de redstone estiver voltado para a parte traseira ou lateral de outro componente, ele tem uma prioridade de -1. Todos os outros tiques de blocos têm uma prioridade de 0. Em seguida, cada bloco com um tique de fluido agendado recebe um tique. Tiques de fluidos não usam prioridades e são ordenados com base na ordem de agendamento.

Na Edição Java, o número máximo de tiques agendados por tique do jogo é 65.536. Na Edição Bedrock, o número máximo de tiques agendados em um chunk por tique do jogo é 100.

Tique de redstone

O termo tique de redstone é uma unidade de tempo que descreve um atraso de dois tiques do jogo, criando um atraso de ¹⁄₁₀ de segundo.

Na Edição Java, os tiques de redstone na verdade não são uma coisa "real" tratada por uma lógica de jogo distinta, mas um termo cunhado pela comunidade para facilitar a comunicação sobre redstone, já que a maioria dos componentes de redstone tem atrasos de múltiplos de 2 tiques do jogo. Por exemplo, um repetidor de redstone pode ter um atraso de 2, 4, 6 ou 8 tiques do jogo, o que pode ser descrito como tendo um atraso de 1 a 4 tiques de redstone.

• Os pontos negativos de usar "tiques de redstone" para descrever o comportamento de tempo são: isso sugere um alinhamento obrigatório (inexistente) a múltiplos de 2 tiques do jogo, e que certos recursos (como andaimes ou folhas propagando atualizações, ou um pistão com atraso inicial de 1tj) introduzem aleatoriamente "meios tiques de redstone", potencialmente introduzindo ao aprendiz a idéia (incorreta) de que outros valores fracionários podem existir. Como resultado, jogadores técnicos mais especializados no Minecraft geralmente preferem usar tiques do jogo como a unidade de medida preferida para atrasos em máquinas de redstone.

Na Edição Bedrock, os tiques de redstone são realmente uma coisa no jogo, pois o sistema de redstone é calculado por threads concorrentes. A transmissão do sinal de redstone é influenciada por tiques de redstone.

Tique de pistão

A Teoria da Atualização Imediata sustenta que o atraso inicial dos pistões é 0, a etapa da entidade para a etapa do evento de bloco é um tique do jogo, ou, em outras palavras, o tique do jogo é dividido pelo final do evento de bloco. Esse tipo de "tique do jogo" é chamado de tique de pistão (tp). O atraso inicial dos blocos musicais é o mesmo que o dos pistões, é 0tp. O atraso dos componentes de tique agendado, com base no tempo do tique de pistão, não é fixo.