Видео

Aupi! Claro, me encantaría. He visto que has subido un vídeo hace poco, lo veo cuando pueda y te dejo un comentario :)

¡Gracias! Estoy montando una serie de vídeos para hacer un plataformas entero desde 0, pero es cierto que el dar posibles ejercicios siempre me ha parecido la mejor manera de enseñar y aprender. Lo que no tengo muy claro es cómo llegar a ese formato con el gamedev. ¿Tenías algo en mente?

Por lo q yo escuche y e llegado a leer, el compilador de C# no esta del todo pulido en godot, y el gdscript tiene una sintaxis sencilla de acostumbrarse

Ala en serio??? Muchas gracias!!!

Aupa! Yo creo que no tienes de qué preocuparte. Son herramientas parecidas, y todo conocimiento que ganes en un lado te servirá en el otro. Incluso podrías moverte a Unreal si te diera por ahí, aunque con un poquito más de trabajo jeje. Entre tú y yo; al final todo acaba en "cómo monto este sistema", que casi siempre empieza por pelearse un poquito con la jerarquía y acaba en hacer las estructuras de código lo más sencillas posible para poder iterar sobre ellas. Ánimo con el curso ^^

@@BuscaLaExcusa Muchas Gracias! Saludos

MVC es un patrón de arquitectura (cómo está organizado el código) de OOP, mientras que Observer es un patrón de comportamiento (cómo responden los objetos y quién es el responsable de mandar esas señales). No son incompatibles, ¡de hecho lo más habitual es que se usen juntos!

¡Hola! Pues hace mucho que hice este vídeo. A día de hoy, con todas las actualizaciones que ha tenido Godot, me está gustando mucho y cada vez más. Diría que depende de tus objetivos: ¿sólo quieres hacer videojuegos como hobby y/o quizá algún día publicar algo por tu cuenta? Ambas son buenas opciones, sobre todo Godot si quieres tirar por 2D. ¿Te interesa más a nivel profesional? Te diría que Unity por usar C# y porque se utiliza en muchísimos estudios de videojuegos y aplicaciones de simulación (medicina, arquitectura, simuladores, etc.)

Básicamente, así solo recuperas los datos de cada objeto y el código usa estos para darle comportamiento a cada uno sin saltar de objeto en objeto.

GDScript no permite hacer nada estático como tal; no fue diseñado así. Lo que lo suple es poner código en un nodo que va al nodo raíz supremo, de manera que aguanta toda la vida del programa aunque cambies de escena. Pero vamos, es el equivalente al Don't Destroy On Load de Unity. En C# puedes hacer cosas estáticas, claro, pero cada objeto es una instancia distinta. Lo ideal sería que una clase estática NO mono behaviour fuera la que updateara todo y el resto se acoplara. Sabiendo estructurarlo es posible pero no va a ser tan eficiente como hacerlo directamente en C++!

@@BuscaLaExcusa Ok entiendo. El eterno problema de programar videojuegos: tener que bajar de nivel para optimizar código. Hace siglos, cuando enredaba con estas cosas y no había estos motores, en más de una ocasión había hasta que tirar de rutinas en ensamblador para que la cosa fuera fluida... Gracias por tus vídeos, me estoy reenganchando con esto y veo que ha evolucionado muchísicmo.

Sí, lo has oído bien ^^

Te vas a morir por eso? Si quiere usar esos pronombres pues bien , más importante es la información que expone en este video.

Es muy buena pregunta. La cosa es que la única manera de unir un objeto, la capa UI digamos, a unos datos, es pasando por un MonoBehaviour. Mínimo necesitaremos 1 que correlacione N objetos con sus N datos. No es imposible hacerlo así, pero el código se vuelve locura rápido si nos negamos a separar en MB. Y aún así, cada vez que llamamos a .transform hay una traducción Cpp a C# muy costosa. Se puede optimizar pero por desgracia tenemos estas limitaciones

Para mí es una magia diferente, el poder controlar los esfuerzos de la máquina para poder engañar a los sentidos de quien juega y hacerle ver comportamientos todavía más complejos y ricos. Quizá el código sea menos discernible desde la perspectiva humana, pero nos habilita para crear experiencias más orgánicas ;)

En este caso es diseño (creo) porque aplicar MVC no afecta a la estructura del programa en sí, más allá de que se trata de una estructura para Programación Orientada a Objetos, pero POO se puede implementar con otros diseños. Diseño no en el sentido de "qué hace el programa" sino "cómo está ordenado el programa por dentro" :P

@@BuscaLaExcusa Sí, es diseño. Cuando se habla de arquitectura usualmente se habla de paquetes (conjuntos de clases). Y también se puede hacer MVC a nivel arquitectura no solo a nivel de diseño.

¡Muy buena pregunta! La respuesta tiene muchos matices, pero allá vamos. Para la capa de datos tienes dos opciones: Scriptable Objects, como decías, o una clase normal (no MB). La mayoría de veces yo prefiero la segunda opción, pero depende de las herramientas con las que quiera trabajar tu equipo de diseñadores y escritores. Los SO se manejan en Unity, las clases puras vas a tener que cargarlas de un archivo externo con JSON, por ejemplo (o CSV, XML, YAML, algo custom... lo que decidáis, vaya). Si has elegido SO, ten en cuenta que debes evitar cambiar sus datos en runtime porque permanecerá de una ejecución a la siguiente, y debes tener un plan de contingencia para resetearlos si tuvieras qur cambiarlos. Los SO te dan la opción de añadir la capa de lógica al propio archivo, ya que son programables. Yo aquí seguiría tirando por la opción de hacer otra clase pura que se comunique con los datos, o dejarlo en el propio MB (depende otra vez de si necesitas permanencia de estado o no). Por último, necesitamos un MonoBehaviour. Su función va a ser comunicar la UI (que Unity nos da ya hecha) con el resto de cosas. El MB va a estar para controlar los gráficos (llamar al animador, encender y apagar objetos, etc.) y demás. Espero haberte podido ayudar

@@BuscaLaExcusa claro yo estoy justamente con algo de datos...me di cuenta mas temprano que tarde el beneficio y desventaja de los SO... pero aveces me resulta un poco dificil desprenderme de los Monobehaviours con clases normales que no son MB. Si bien uso interfaces para muchas cosas a veces me preocupa la situacion de no poder manejarme con un constructor en Unity entoces como que pienso o me estreso con el plan.... y hay que planificar!. SI estoy justamente en eso como guardo mis datos , de momento en Json para ir haciendo pruebas de salvar y cargar datos en partidas. Gracias.