Dia 193 a 197 - Vamos ler um livro 4#

  De Volta a leitura do livro, eu havia parado na pagina 445, que era meio que o meio de um capitulo de colisão, ai parei para participar de uma JAM...

 

Dia 193 - 17/11

Terminei de ler o capítulo no qual tinha parado, não teve nada que eu não soubesse nele, mas ainda sim, por questões de continuidade é melhor eu ler tudo... (Estou na pág. 465 - cap. 17), eu ia ler mais, mas agora vai entrar em algo que é extremamente útil então vou deixar para amanhã.

Dia 194 - 18/11

Agora ler o capitulo sobre Managers e é simples, deixarei a explicação simplificada aqui para servir de nota.

Temos a classe manager, o principal é que deve ter isso na linha 8. uma variável do seu próprio tipo, mas do tipo static. e também deve ter algo como isso dentro do awake,

segundo um site confiável da Microsoft:

Em geral, o modificador static pode ser usado com dados e funções que não precisam de uma instância de classe para ser acessada.

Depois para acessar é só fazer algo como isso

Vale ressaltar que só pode haver um objeto com esse componente em cena.

PS: existe uma coisa importante usar managers para ter referencias de objetos em cena, tem performance melhor do que usar o GameObject.Find

CONDIÇÃO DE CORRIDA

outro conceito interessante da programação, na realidade é um problema que pode ocorrer.

outra forma legal de criar algo, o GameMode não é necessariamente um termo da área. mas a ideia é ter um componente separado que cheque os Managers, para ficar de olho nas condições de vitória ou derrota. O fato de ele ser separado dos managers, facilita a questão de mudanças. como por exemplo, caso haja mais de um modo de jogo, ai podem existir os manager em cena, mas não obrigatoriamente o mesmo GameMode.

e também temos a questão de manter os managers, separados, por exemplo um modo de jogo pode não ter inimigos ai não seria necessário um manager para eles.

Parei na Pag 485.

Dia 195 - 19/11

De volta ao livro, acho que eu deveria fazer um protótipo em breve, para praticar as coisas aprendidas. e fixar, alias tive a ideia de fazer protótipos e publicar na itch.io estou pensando em fazer uma coleção própria de protótipos simples, de meu aprendizado.

Hoje comecei lendo sobre eventos, mais precisamente UnityEvents... eu já sabia que existiam, só não sabia que dá dava para adicionar um listener via código... é uma forma interessante de poupar recursos da maquina.

como adicionar m listener em um unity event

E terminei a parte de eventos na pág. 498.

t

Ai entrei em uma parte de UI, com nada que eu já não soubesse... e uma parte de como usar VFX e animações na questão do script, nada que eu não soubesse novamente... e com isso pararei por aqui.

Parei na pág. 533, cap. 19 (80%)

Dia 196 - 20/11

Isso não tem a ver com o livro mas, hoje visitei o sketchfab e acabei encontrando um software chamado blockbench segundo o site ele é usado por empresas como a mojang, para modelos no estilo minecraft, aquela mistura de 3D com pixelart, e diferente do Blender, dá para pintar pixelart, diretamente no modelo 3D, através do editor mesmo. Futuramente aprenderei o básico e farei uma analise, mas a principio creio que será útil, nem que eu modele no Blender para depois texturizar nele, mas creio que será bom.

Agora ao livro, o capitulo de hoje é sobre AI.

O livro já começa dizendo que o tipo mais comum de se fazer inimigos, é com um sensor de 3 filtros. a ideia é que o primeiro seja distancia, seguido de campo de visão, e depois verificação de oclusão (se tem algo entre o inimigo e a AI).

a tal detecção de 3 filtros...

Alias esqueci de mencionar, isso não é a AI em si é o sensor para detectar o player por assim dizer. O livro sugere que isso seja um objeto empty dentro do inimigo, o que é interessante, já que ele poderia ser colocado como filho do bone da cabeça do inimigo, assim o raio de visão seguiria as animações da cabeça.

teste

e Mais um conceito interessante, FSM ou Finite State Machine pelo que entendi é relativamente simples, mas a forma de se fazer é interessante e organizada, vale ressaltar que é possivel fazer de outras formas até com

Temos um Enum que tem os possíveis estados e uma variável que armazena o estado atual.

no update temos uma simples cadeia de IFs. a magica acontece dentro das funções de cada estado, nelas temos a parte responsável pelas possíveis transições que faz verificações e mudam o estado atual, e a parte responsável pela ação em si.

Parei na Pág. 573/678 (84%)

Queria ter lido mais hoje, mas ainda sim eu diria que hoje foi muito bem aproveitado, hoje aprendi conceitos e formas de se fazer que serão muito úteis.

Dia 197 - 21/11

Li a parte sobre NavMesh, não teve muitas coisas que eu não soubesse... e agora entrarei na parte sobre otimização (pág. 595).

Li sobre otimização de GPU, que inclui LOD e algo de juntar os materials... e oclusion culling... 

E sobre como usar os profiler e o Frame Debug, ainda temos os CPU e GPU bound, que consiste de um terminar o processamento primeiro que o outro e ter que esperar o outro terminar...

E ainda tem uma parte sobre otimizar a memória, mas vai ficar para amanha.

Parei na Pág. 612