Dia 201 - Vamos Ler um livro #5

 Sabe, adoraria continuar no Blender, mas tenho que terminar aquele livro do básico em Unity.

Acho que eu tendo a desvalorizar o que faço, me comparar a outros é meio inevitável e ai a minha arte não fica muito legal, e a considero ruim, Acho que por isso até agora eu ainda não "mergulhei" na parte de modelar personagens.... aff sei lá... mas para os meus projetos que sonho em tornar reais, isso é inevitável, eu preciso modelar personagens e diria que também preciso me dedicar mais ao que ando fazendo...

O Bomb Time, por exemplo eu poderia ter me dedicado mais em tornar o jogo melhor, sei lá... a principio eu tinha pensado em animações, como a chave de fenda desparafusando o parafuso e a tampa saindo e os fios sendo cortados, mas acho que eu procrastinei demais, resolvi simplificar e no final não ficou o resultado ideal, ficou apenas algo funcional. eu até fiz mais cortes no roteiro eu tinha falado de uma caixa, eu tinha pensado em uma animação da caixa se desmontando. eu até comecei a fazer a cena da porta, mas olhei e vi como estava, meio que com aquela mentalidade de me comparar a outros e não achei legal.

Agora Ao Livro

Eu havia parado na Pag. 612/678, nessa parte começa a falar sobre otimização de memoria.

Capítulo interessante, entendo em parte, mas estou meio confuso, e ainda nem terminei, mas para explicar:

Mas para explicar em algumas linguagens você precisar Alocar e "desalocar" da memoria manualmente, mas o C# tem um "coletor de lixo" que faz isso para você, ele meio que observa quantas referencias existem a um objeto na memória e quando chega a 0, ele "desaloca" (essa palavra existe..).

Quando isso acontece, como em jogos que ocorre com uma boa frequencia, isso meio que cria fragmentação, cria espaços pequenos demais para couber um bloco de memoria novo que precisa ser "armazenado inteiro".

Normalmente o "coletor de lixo" resolve isso, movendo objetos guardados e os comprimindo e coisa e tal, mas o Unity possui o seu próprio "coletor de lixo" que não faz isso...

Agora uma solução interessante de otimização de memoria

Nessa imagem ele usou a versão NonAlloc do OverlapSphere e alem disso, notem que ele criou uma variavel statica para armazenar os colliders, essa variável ela seria compartilhada entre todos os inimigos, e com isso, em vez de caso tenha 200 inimigos, ter 200 arrays ocupando a memoria, mesmo com 200, ai a ver só 1 array, e ele deixou esse array, com 100 espaços, para não ter risco do OverlapSphere retornar uma array maior que o limite dela.

O que eu não entendi, é por que não executa em paralelo... tudo bem que computadores, processam uma coisa por vez, mas os processadores hoje em dia tem até 12 núcleos... então de onde vem essa certeza que é passada no livro ? tem algo a ver com o NonAlloc ? ou algo com a variável tipo static ?

(pesquisar depois)

e também diz que é melhor usar o StringBuilder (nunca nem vi) ou o format em vez de apenas concatenar.

e recomenda o uso de Pooling, que consiste de em vez de instanciar e destruir objetos apenas reutiliza-los, já que o instantiate e o destroy, podem acabar gerando fragmentação na memoria.

Pooling Básico

Esse Script de Pool é bem simples, ele basicamente, instancia quando não tem guardado e desativa em vez de destruir. Alias a Unity já possui esse sistema de forma nativa...

Alias isso de Polling é bom para coisas como balas, efeitos de partículas, coisas que são instanciadas e destruídas com frequência.

Agora vamos ao cap. de como buildar o jogo...

Não sabia que havia a opção de colocar o seu logo, junto com a da Unity... que útil e achei onde tira uma tira irritante que fica nos jogos html gerados no unity

E ainda não terminou temos um outro cap. ;=;

e agora finalmente pag. 640 ! agora tem um capitulo bônus sobre AR

Apesar da minha vontade de considerar o livro como lido, e apesar da minha não vontade de implementar algo com AR, vou ler esse cap. apenas para terminar com esse livro de uma vez por todas, mas isso não vai ser agora. e nem vou fazer essas anotações 🗒 

e por hoje é isso.