Isso é um pouco mais trivial, mas se você não se importa com a precisão perfeita (quem se importa se você dá um segundo ou fala um pouco ao falar de séculos?), Então, como TotalTime
é um duplo, o valor máximo que ele pode armazenar é 1.7976931348623157E+308
.
Não tenho certeza de como os estouros funcionam em C #, mas se você executar o jogo por mais tempo, acho que ele voltaria a algo como -1.798*10^308
ou simplesmente não mudaria. Também depende de como é implementado internamente.
Dito isto, esse número de milissegundos é bastante grande. Se você comparar com a idade hipotética do universo, é ... Bem ... ainda é bem grande .
É claro que, como Sam disse, o tempo é realmente armazenado em ticks (décimos de nanossegundo?), Portanto, você entraria no "limite" após um período de tempo " muito mais curto ". Ainda é algo como um cubo de um googol vezes a idade do universo.
Não sei GameTime
exatamente como armazena o tempo, exatamente, portanto, isso também significa que você nunca verá a TotalMilliseconds
saída "aproximar-se" do seu valor máximo. Embora, se for tempo de empacotamento em dias e anos sempre que o valor dos ticks for alto o suficiente, e não apenas quando você chamar o getter, o cronômetro aumentará até o valor máximo de double
anos , o que é ainda mais alto .
Se, por alguma razão, seu jogo tiver conteúdo tão abundante que exija um período de tempo em que muitos universos nascem e perecem para explorar completamente, existem tipos de dados especializados para armazenar números arbitrariamente grandes. Java tem um BigDecimal
tamanho cujo basicamente é limitado pela sua RAM (e através da memória virtual, até do espaço no disco rígido). Aparentemente, o C # não possui BigDecimal
, mas possui BigInteger
.
Se você fizer um jogo em escala épica, sem dúvida para ser jogado pelos próprios deuses, você provavelmente começará duplicando a BigDecimal
classe e, em seguida, reimplementando a GameTime
classe (ou apenas adicionando periodicamente GameTime
o valor de sua BigDecimal
) para usá-la.