Aportando mi granito de arena en la excelente movida #GameWorkJam donde voy a hablar sobre [ Esenciales Olvidados a la hora de programar videojuegos ] Suena raro, no? suena extraño pensar que si sabemos programar un poquito dejar atributos de una clase públicos es una PÉSIMA idea ( y no me vengan con la excusa: "pero sino no los veo en el editor" ) .... suena aun mas extraño no tener coding-style haciendo que el código sea una ensalada de fruta y verdura, cosa que sabemos... va a generar que cuando necesitemos ayuda o querramos incorporar alguien nuevo al proyecto vamos a hacerlo sufrir bastante .... e incluso, quizás termine no pudiendo entender la magia de nuestro EXTRAORDINARIO proyecto.

1. Maia
Cordero
Nicolas
Borromeo
Esencialesolvidadosalahorade
programarvideojuegos
Maia
Cordero
Nicolas
Borromeo

2. Buenas
Prácticas
Sercopadoconelequipo

3. ProlijidadProlijidad

4. Code-Style
Hay muchas maneras y mucho debate sobre cuál “CODE-STYLE”
conviene usar. Encontraremos libros enteros sobre dicha
temática y debates interminables.
Pero lo importante es la HOMOGENEIDAD, sea cual sea el
estilo que utilicen, respeten el mismo en TODO el proyecto.
No está bueno que el código tenga distintas personalidades.
Aquí abordaremos algunas cuestiones básicas que a veces se
olvidan...

5. Nomenclaturas
● Todo lleva un nombre, funciones, campos, propiedades,
eventos, etc.
● Hay que marcar una clara diferencia
● No hay que sobrecargar el nombre
● Pascal Case: Primer letra de cada palabra mayúscula
○ Propiedades, Métodos, Eventos
● Camel Case: Primer letra minúscula, luego mayúscula
○ Cámpos

6. Funcioneslargas
● No se debe hacer funciones de más de X cantidad
de líneas.
● Es muy difícil de leer.
● Conviene partir la función en partes.
● Tampoco conviene hacer líneas muy largas
● Partir una línea en varias

7. Regions
● Una clase puede tener muchas funciones y campos
● Las funciones pueden ser acciones públicas, eventos,
funciones utilitarias privadas o estáticas
● Cuando hay muchas suele ser un cáos
● Conviene separar en regiones el código
● Facilita la búsqueda de una parte puntual

8. Namespaces
● Las clases se organizan
en namespaces.
● Son el “apellido” de la
clase.
● Diferencian clases
llamadas igual.
● Útil cuando se usan
librerías

9. Estructuradecarpetas
● El proyecto va a tener
muchos archivos
● Conviene establecer una
estructura común entre todos
● Conviene separar: por un
lado el código común y por
otro lado el del juego
● Una carpeta por cada
“módulo”
● Ejemplo
○ QuestSystem
■ Scripts
○ Physics
■ Scripts
■ Data
○ AwesomeGame
■ Scripts
■ Data
■ Art
● Models
● Textures
● Sprites
● Audio
○ Music
○ SFX

10. ProlijidadBuenas
Prácticas

11. Propiedades
● No conviene dejar todo público
● Es funcional pero tiende al error humano
● No se debe dejar hacer cosas que no se deben
● Toda variable debe ser privada
● Se expone funcionalidad de escritura y lectura a través
de métodos
● Se puede agregar chequeos extra a los métodos, o
restringir la escritura o lectura

12. Abusodeestáticos
● Static is evil
● Nunca se deben hacer campos estáticos
● Los campos deben pertenece a las instancias
● Si no se rompe la separación de responsabilidades
● Único caso admisible es en caso de Singleton

13. Eventos
● Se tiende a chequear cosas en el Update
● Es costoso y tendiente a errores
● Se debe reemplazar por eventos
● Se puede utilizar el patrón Observer
● Se ejecuta un evento cada vez que cambia algo del objeto
● Ejemplo
○ Cambió la Vida
○ Murió el Personaje
○ Se subió de Nivel

14. Escalas
● NO SE DEBEN ESCALAR LAS COSAS
● Se suele ignorar las escalas de los objetos
● Agrandamos y achicamos las cosas hasta que quede bien
● Diversos sistemas dependen de un correcto tamaño
○ Físicas, Audio, etc.
● Los assets deben venir en la escala correcta

15. Plandeentregas
● No alcanza con hacer una lista de tareas (si es que la
vienen haciendo).
● Se deben marcar deadlines, pero no solo al final.
● Conviene hacer “entregas” parciales.
● Facilita ver que no se llega.
● Se ordenan las tareas por importancia.
● Facilita el sacrificio al final cuando no se llega.
● En plan debe ser flexible

16. ProlijidadOptimizaciones

17. ConcatenacióndeStrings
● Concatenar Strings es
costoso
● Se crea un nuevo String
por cada concatenación
● Aumenta el costo del
Garbage Collector
● Conviene usar String
Builder

18. ForvsForeach
● El foreach se usa en TADs
dinámicos
○ LinkedList
● El for sobre TADs estáticos
○ List
● El foreach instancia un
iterador
● El for simplemente aumenta
un número

19. Pools
● Crear objetos es un proceso
costoso (reserva de memoria).
● Crear constantemente objetos
con poca vida cuesta.
● En vez de destruirlos se
“reciclan”
● Se desactivan y agregan a una
lista de reciclaje.
● No conviene sobre objetos de
creación poco frecuente o vida
larga.

20. BuenasPrácticas

21. SerializableField
● Campo serializable por Unity
● Se ve en el editor, A PESAR DE SER PRIVADO
● Ayuda a encapsular campos
● Ejemplo
○ Valor Inicial de la Vida visible en el editor
○ Luego accesible sólo a través de properties
○ Ayuda a clampear entre 0 y la vida máxima
○ Ayuda a detectar la muerte (cuando llega a 0)
○ Eventos!!!!

22. Serializable
● Clase que se ve en el editor
● Contenedor de datos (sin
eventos)
● Reduce cantidad de componentes
● Ejemplos
○ Grupo de SpawnPoints
○ Reemplazo de diccionarios
○ Reemplazo de listas
paralelas

23. ScriptableObjects
● Forma de crear Assets propios
● Permite compartir datos entre
instancias
● Clase que hereda de
ScriptableObject
● Se crear con CreateAssetMenu

24. Cacheodereferencias
● Las operaciones de búsqueda son
costosas
○ GetComponent
○ Transform.Find
○ GameObject.Find
○ GameObject.FindWithTag
● Si el resultado no cambia
hacerlo en el Awake y cachear
el resultado
● Si el resultado cambia utilizar
Listas y mantenerlas
actualizadas

25. Físicas

26. MeshCollider
● UTILIZARLOS COMO ÚLTIMO RECURSO
● Adopta la forma de un mesh
● Es más costoso de procesar
● No colisionan entre sí
● Convex modifica su forma
● Puede que colisionen
● No siempre funciona

27. Colliders
● Estáticos
○ Sin Rigidbody
○ Se aplica optimización
○ NO SE DEBEN MOVER
● Kinemáticos
○ Con Rigidbody Kinemático
○ Se puede mover
○ ÚNICAMENTE CON TRANSFORM O ANIMACIONES
● Físico
○ Con Rigidbody No Kinemático
○ Se puede mover
○ ÚNICAMENTE CON RIGIDBODY
○ Con Fuerzas, Propiedad Velocity o Position

28. LayerCollisionMatrix
● A veces no queremos que ciertos
objetos colisionen con ciertos
otros
○ Enemigo con Trigger de
Personaje
○ Bala con Compañero
● Otras veces queremos colisiones
pero necesitamos filtrar la
reacción según alguna condición
con IFs
● Esto funciona, pero es menos
performance
● La Layer Collision Matrix filtra
colisiones por layers.

29. Gráficos

30. ImportacióndeTexturas
● Las texturas poseen
configuraciones de importado
● Max Size puede achicar la
textura para ocupar menos
memoria
● Tener en cuenta la distancia
a la que se ve el modelo con
dicha textura.

31. ImportacióndeModelos
● Hay diferentes configuraciones a la hora
de importar el modelo a unity
● Una de las más importantes ahora es
Scale Factor
● Los modelos pueden venir medidos en CMS,
METROS, PULGADAS, etc.
● Permite escalar el modelo a la hora de
importar
● Normaliza medidas (a metros
preferentemente).

32. Shaders
● NO UTILIZAR EL STANDARD PARA TODO
● Tener en cuenta los Shaders Mobile
● Tener en cuenta los Shaders Unlit
● A veces las transparencias pueden ser
reemplazadas por Shaders de partículas
● Considerar aprender hacer Shaders
Propios

33. ComunicaciónCPU/GPU
● La PC para dibujar tiene que comunicarse con la placa de
video
● Lo hace a través de un bus (actualmente PCI Express)
● La comunicación es lenta, hay que reducirla lo más
posible
● Una vez que el comando llega, se ejecuta rápido

34. MaterialesySetPassCalls
● Cada material produce uno o más SetPass Calls
● Se combinan los SetPass de objetos con el mismo
material
● Reducir lo más posible los materiales

35. ObjetosyDrawCalls
● Cada objeto produce uno o más DrawCall
● Varía según el material
● Se pueden combinar si comparten el material

36. Profiler
● Herramienta de analisis de performance
● Información detallada frame a frame de cada sistema de
Unity
● Informa sobre que código se ejecuto y su costo
● Habla sobre Draw Calls y Set Pass Calls

37. Objetosestáticos
● Objetos que no se mueven,
rotan, escalan, activan,
desactivan, cambiar
color, etc.
● Se marcan tildando la
propiedad static.
● Se puede marcar como
estático por cada
sistema.

38. ReduccióndeSetPass-Combinartexturas
● Podemos utilizar atlas
● Combinar varias texturas en
una sola
● Cada modelo tiene
diferentes UVs
● Se comparte la misma
textura
● Se puede utilizar el mismo
material.

39. ReduccióndeDraw-Combinarmodelos
● A veces conviene combinar objetos
● A pesar de ocupar mas RAM para
modelos ahorra proceso
● Se puede hacer con objetos que
compartan el mismo material
● Se puede combinar manualmente con
la clase Mesh
● Existen plugins en el asset store
● Reduce Draw Calls, especialmente
en el aspecto de sombreado

40. ReduccióndecostoporDrawCall-LOD
● A.K.A. Level of Detail
● Se puede reducir la calidad de los objetos a la distancia
● Se aplica a shaders automáticamente (o manualmente si son
nuestros).
● Se aplica a modelos 3D, dibujando una geometría más
simple.

41. BakedeVisibilidad-OcclusionCulling
● En un FPS no es suficiente
el Frustrum Culling
● Los objetos detrás de una
pared se siguen dibujando
● Se puede apagar
manualmente según el área
● Unity puede calcularlo por
nosotros
● Solo funciona en objeto
estáticos

42. BakededeLuz-Lightmap
● Se calcula la
información de luz que
no cambia
● Se guarda la iluminación
recibida por objetos
estáticos
● Se guardan en atlas

43. maiacordero@gmail.com
https://aboutmaia.wordpress.com/
Muchas
gracias!
nicolasborromeo@gmail.com
https://ar.linkedin.com/in/borromeus/es
Escribenos !