Estas son las indicaciones principales para el HITO 3 (tres):

• Es presencial
• Deben mostrar gameplay en vivo de su juego
• La mecánica innovadora que plantearon debe estar implementada de forma evidente
• Su juego debe tener una condición de victoria o término
• Su juego DEBE tener una pantalla de créditos
• Deben presentar el concepto general de su juego como hicieron en el HITO 1 (uno), ya que habrán invitados que no conocen su juego.
• Debe estar todo el grupo (a menos que alguno esté muriendo y le informe a su ayudante con anticipación desde su lecho de muerte. Haremos un (1) minuto de silencio en su honor)
• La presentación debe durar de 7 (siete) a 10 (diez) minutos.

Estas son las indicaciones secundarias pero no menos importantes ni ignorables del HITO 3 (tres):

• No pueden haber assets placeholder
• Si su juego es pixel art, no pueden haber sprites con filtro, ni se deben notar líneas entre las tiles o similares
• Su juego no debe crashear en medio de la presentación
• No pueden utilizar assets para los que no tengan licencia
• Su juego debe ser un solo proyecto, no pueden mostrar 3 (tres) ramas de git por separado

FAQ

• what is a condición de victoria?

• how do I créditos?

• where do I créditos?

• puedo poner en los créditos a mi perro que me dio apoyo emocional durante todo el semestre y me ayudó a progra-

• what if I crediton't?

• PPT?

• entonces PPTn't?

• Cuánto pondera el HITO 3 (tres)?

• Qué es un placeholder?

• Quiero contar todo el lore de mi juego empezando por cómo hace 300 años un demonio intergaláctico invadió la tierra para robarse todo el queso y-

• Puedo invitar a mis amigos a la presentación para que vean mi juego?

6 (seis) tips para el HITO 3 (tres)

• Enfóquense en mostrar el gameplay, no hablen de mecánicas si pueden mostrarlas en acción
• Si quieren hablar del lore o algo por el estilo, aprovechen los segmentos "menos interesantes" del gameplay para hacerlo
• Si bien no son obligatorias, se valoran cosas como sonidos, música, pantalla de título y un tutorial
• Si su juego es muy largo implementen algún comando o menú de debug para saltar a las partes interesantes
• Si su juego está en condiciones de publicarse, consideren exportarlo y subirlo a itch.io (recuerden pasar el link por el telegram si lo hacen)
• Aprovechen de preguntarle a su ayudante todo lo que necesiten en el tiempo que les queda, la idea es que lleguen con un juego presentable al HITO 3 (tres)

Atajos     

Scripting        

• Ctrl + K: Comentar todas las líneas seleccionadas, o la del cursor si no hay selección.    
• Alt + Arriba/Abajo: Mover línea en que está el cursor hacia arriba/abajo                 
• Ctrl + D: Duplicar línea    
• Ctrl + C/X/V: Lo clásico pero si no tienen nada seleccionado copia/corta/pega la línea entera                     
• Ctrl + W: Cerrar script     
• Ctrl + Shift + E: Evaluar la expresión seleccionada (Ej.: (4 * 20) - (10 + 1) evalúa a 69 y lo reemplaza en el código)      
• Ctrl + F: Buscar    
• Ctrl + R: Buscar y reemplazar   
• Ctrl + Click: Abrir la documentación del método/clase/nodo seleccionado    
• Tab con selección: Indentar el bloque seleccionado   
• Shift + Tab: Des-indentar la selección o la línea actual       

General    

• F5: Correr escena principal (está con el nombre en azul en el panel de archivos)                      
• F6: Correr escena actual       
• Ctrl + D: Duplicar selección (funciona también en el árbol de nodos)   
• Ctrl + W: Cerrar pestaña       
• Ctrl + Shift + T: Abrir pestañas cerradas recientemente                 
• Ctrl + A: Agregar nodos     
• Ctrl + Shift + A: Instanciar a escena      
• Q: Modo seleccionar       
• W: Modo Mover                 
• E: Modo rotar      
• S: Modo escalar (2D)                      
• R: Modo escalar (3D)    
• T: Cambiar entre espacio global y local (3D)                   
• Cambiar entre las pestañas de 2D/3D/Scripts: Ctrl + F1/F2/F3     

Consejos útiles/Magia negra    

Scripting       

• Se puede arrastrar cualquier archivo al editor de scripts para pegar su ruta (muy útil al usar load()).     
• Si hacen referencia a un nodo hijo (ej.: $Nodo) en su script, guarden la referencia en una variable onready (ej.: onready var nodo = $Nodo) en vez de acceder directamente al nodo cada vez que lo usen, de esa forma si cambian el nombre o estructura de los nodos solo tienen que hacer el cambio en un lugar.       
• Al definir variables pueden especificar su tipo para tener autocompletado (ej.: var numerito: int = 0, var listita: Array = [1, 2, 3], var camarita: Camera = $Camera).       
• Pueden exportar variables para modificarlas desde el inspector, esto también permite cambiarlas en runtime para probar valores más fácilmente (ej.: export var speed = 200).     
• export puede tomar hints para cambiar la interfaz que da para cambiar datos (ej.: export (String, MULTILINE) var descripcion da una caja de texto grande en vez de solo una línea, export (int, "S", "M", "L", "XL") var tamano = 0 muestra un dropdown con las opciones S, M, L y XL, que se asignan a los números 0, 1, 2 y 3; y export (int, 0, 100) var vida solo permite ingresar valores entre 1 y 100). Aquí pueden ver todas las posibilidades de los export docs.godotengine.org/ ... dscript_exports.html   

General      

• En los inputs numéricos se pueden escribir fórmulas (ej.: se puede escribir directamente cos(PI/3)+3*5 y se evaluará al valor correspondiente).    
• Casi cualquier cosa puede arrastrarse desde el panel de archivos a los slots del inspector.        
• El nodo Tween sirve para interpolar valores y en algunos casos puede ser más útil que el AnimationPlayer (ej.: hacer que elementos de la interfaz de usuario se deslicen en vez de aparecer y desaparecer). Pueden ver los tipos de transiciones de forma visual aquí: easings.net/     
• No escalen los nodos CollisionShape, ajusten el tamaño de la forma a lo que necesitan. Tampoco escalen los nodos raíz (el que es padre de todos los demás nodos de la escena).  
• Cuando guarden un nodo como escena aparte, recuerden centrarlo en (0, 0, 0), de lo contrario quedará con el offset que tenía originalmente.      

2D    

• Si pueden ver líneas entre las tiles de un tilemap, o entre sprites, activen "Use GPU pixel snap" en Project Settings -> Rendering -> 2D.   
• Si usan pixel art, eviten escalar sprites con valores decimales, usen solo enteros.    
• Las CollisionShape deberían tener valores enteros en sus parámetros de tamaño, los decimales podrían causarles problemmas en algunas ocasiones.                  

3D       

• El formato más compatible con Godot es GLTF.      
• Centren los Rigidbody en (0, 0, 0), de lo contrario pueden ocurrir cosas raras con las colisiones.         
• El nodo BoneAttachment permite "colgar" un nodo a un hueso del esqueleto de un modelo. Útil para hacer que un personaje tome objetos.     

Control     

• El nodo NinePatchRect les permite usar un sprite cuadrado para hacer cajas rectangulares de todas las dimensiones que necesiten, es muy útil si necesitan varias cajas para sus menús y quieren que sean consistentes visualmente.    
• El nodo RichTextLabel les permite usar BBCode para dar efectos al texto, como ponerlo en negrita, agitarlo o cambiar el color de ciertas palabras. Pueden leer más sobre esto aquí docs.godotengine.org/ ... n_richtextlabel.html    

Magia negra avanzada    

• Si necesitan manejar estructuras de datos más complejas/específicas de lo que provee Godot, pueden usar Recursos personalizados. 
• Si necesitan automatizar tareas, pueden escribir scripts y ejecutarlos en el editor.       
• Si necesitan extender las funcionalidades del editor para acomodarlo a sus necesidades, pueden darle a sus nodos funcionalidad en modo `tool` o crear plugins de distintos tipos (no se recomienda que hagan plugins para sus juegos ya que les puede quitar mucho tiempo, pero les damos a conocer la posibilidad en caso de que lo necesiten en un proyecto futuro).  

No de Godot pero igual vale la pena mencionarlo                  

• Sean organizados con sus archivos, tener carpetas separadas para cada tipo de archivo (sprites, scripts, etc.) les permitirá encontrarlos mucho más fácilmente cuando los necesiten.     
• Hagan commit frecuentemente, idealmente cada vez que tengan una característica funcionando deberían hacerle commit, no esperen a tener 30 mecánicas nuevas funcionando para hacerlo.   
• Pongan mensajes de commit descriptivos, da lata pero si por algún motivo tienen que volver a un commit anterior se van a arrepentir de haber comentado "uwu", "owo", "uwu2".    
• Hagan merge frecuentemente, avanzar cada quién por su lado mucho tiempo solo aumentará la probabilidad de conflictos y además tendrá al equipo descoordinado. 
• No trabajen simultáneamente sobre su escena principal, creen escenas aparte e implementen lo que necesiten en ellas. Los conflictos en la escena principal pueden ser difíciles de resolver y pueden acabar perdiendo progreso.     
• Guarden los nombres a los que deban dar créditos cuando descarguen algo, no digan "voy a guardar la página para copiarlo luego", se les va a olvidar, y estarán buscando en 20 páginas distintas a última hora. 
• Si cuando descargan algo, el artista dice algo tipo "se aprecia que den créditos pero no es necesario", consideren copiar el nombre y dar créditos de todas formas, les pedimos que den créditos para que 1) sean conscientes de las licencias de uso de los assets que usan, y 2) para que se acostumbren a reconocer y valorar el trabajo de otras personas.    
• Muchos de los alumnos que toman este curso han tomado previamente Metodologías de Programación, es un curso bastante útil que enseña patrones de programación para problemas comunes en el desarrollo de software. Probablemente no necesitarán aplicar esos patrones en este curso. Antes de aplicar algún patrón de diseño a su juego, pregúntense si realmente es necesario para su caso de uso. La mayoría de las veces no lo es.         

FAQ

1. What is the HITO 1 (uno)?
   El HITO 1 (uno) es el primero (1°) de los tres (3) HITOS del curso (los otros dos (2) se llaman HITO 2 (dos) e HITO 3 (tres)).
2. How do I HITO 1 (uno)?
   El HITO 1 (uno) consiste en:
   • Entrega del GDD
   • Presentaciones
3. What is a GDD?
   El Documento de Diseño o GDD (Game Design Document) es el documento donde documentan cómo será el diseño de su juego. En el enunciado de la tarea del HITO 1 (uno) encontrarán el contenido que les exigimos para su GDD.
4. What is a GDDn't?
   El GDD no tiene que ser necesariamente como un informe normal, tienen total libertad para hacerlo como les guste mientras cumpla con lo que se pide en la pauta, la idea es que los ayude a ustedes a medida que desarrollen el juego y les sirva de referencia para que no se desvíen mucho de la idea que plantearon.
5. How do I presentación?
   Para las presentaciones se piden 3 (tres) cosas básicas:
   • Explicar la idea general de su juego
   • Explicar su mecánica innovadora y que entendamos que:
     • Es una mecánica
     • Es innovadora
   • Mostrar una demo con un prototipo de su juego
6. Presentación => ppt?
   No.^*
7. Can I demon't?
   Si no muestran una demo se les descontará mucho puntaje del HITO 1 (uno)
8. How much is mucho?
   Muuucho. No quieren descubrirlo. Es muchísimo.
9. How do I demo?
   La demo no necesita ser muy compleja, basta con que tengan algo moviéndose y que se entienda que ese algo tiene que ver con su juego. No necesitan tener assets finales ni tener todas las mecánicas implementadas.
10. How long do I have to presentación?
    7 (siete).
11. 7 qué?
    7. _(siete).
12. Can I gon't to the presentación?
    Todos los integrantes del grupo deben ir el día que les toca presentar, y al menos uno debe ir el otro día.