¿Qué es MVC? ¡En 5 minutos, en Unity y Godot!
HTML-код
- Опубликовано: 8 июл 2024
- Hoy aprovechamos 5 minutos para ver qué es el patrón de diseño de software MVC, y cómo podemos implementarlo en Unity, Godot y cualquier otro motor que se nos ocurra.
Si tienes alguna duda o comentario, no dudes en dejármelo en los comentarios ❤
Para apoyarme, ¡puedes invitarme a un café a través de ko-fi! ko-fi.com/buscalaexcusa
------------------- ¡Más contenido interesante! --------------------
· Otros patrones de diseño
¿Qué es ECS? ¡Próximamente! ⚠🕳
· Inteligencia Artificial y Generación Procedural
Tu Primer Terreno Procedural • Unity - Tu primer Terr...
¡Terrenos Procedurales Avanzados! • Unity C# - Generación ...
¡Aprende a hacer NPCs e Inteligencias Artificiales! • Todo lo que necesitas ...
· Shaders
¿Cómo instalar URP? • ¡Aprende cómo instalar...
¿Cómo funcionan los shaders? • Introducción a los sha...
¡Cómo empezar con Shadergraph! • Las bases de Shadergra...
¿Qué son los modelos de iluminación? • ¿Qué son los Modelos d...
Hablemos de las mallas y sus propiedades • Hablemos de las mallas...
Tu primer Toon Shader • Unity - Cómo hacer el ...
· ¡Y muchas más cosas que puedes encontrar en el canal!
/ @buscalaexcusa
---------------------------------- Capítulos ----------------------------------
00:00 - Búscate una excusa
00:21 - ¿Qué es MVC?
00:50 - Cómo aplicar MVC a un videojuego
01:53 - Empezar desde un sólo archivo
02:33 - Aclarando el papel del Update
03:19 - Pasar de un sólo script a MVC
03:40 - Aplicarlo a Unity y Godot
05:00 - Mejorando el Controlador
________________________________________________________
Muy, muy buen vídeo! Me costó trabajo aprender a aterrizar correctamente MVC en el diseño de mis clases en videojuegos, ojalá haber visto tu vídeo unos años atrás. Felicidades!
Buenisimo video!!
Justo ando entrando al mundo del gamedev y andaba con la duda de como organizar mis scripts.
Mil gracias!!
like, tremendo video
Genial! Me ha ENCANTADO el enfoque :) La verdad que nunca lo había visto así.
Mucho más intuitivo pensar en objetos que en capas; aunque al final sería "lo mismo", pero visto de otro modo.
Con esta nueva perspectiva, mi cerebro ha hecho "click" :)
PD: nuevo suscriptor! :)
Muy buen análisis y re bueno el video.. explícate todo lo que más puedas.
Interesante... buen video
¡Hola! Acabo de descubrir tu canal y me parece genial. Realmente aprecio el hecho de que estés compartiendo contenido sobre Godot en español. Hay muy poca información en nuestro idioma sobre este tema, así que gracias por ayudar a la comunidad. ¡Espero seguir aprendiendo y explorando contigo! 😊🎮
P.D. ¿Sería posible que hicieras un tutorial similar sobre cómo crear una isla procedural en Godot? Sería increíble ver cómo implementas esto en esta plataforma. ¡Gracias de nuevo!
Apoyo el request de la isla procedural en godot, plssss!!!
No controlo mucho de Godot pero veré qué puedo hacer :D
Excelente video, yo intuitivamente uso MVC y en unity la clase de vista la uso para manipular la interfaz grafica y algunas otras cosas del juego. Gracias por compartir.
Buena explicación, he visto que la programación de videojuegos cada quien la hace un poco como le salga y poco se habla de los diseños y arquitecturas de otros tipos de desarrollo que bien se podrían aplicar.
Buen video!! Te ganaste un subscriptor!!
gracias a tu explicacion me sirvio para entender que mi carreara de ing de sistemas sirvio para algo y no por haber aprendido otras tecnologias que nada que ver con video juegos no pueda implementarlas gracias
¡Me ha hecho much ilusión tu comentario! Me alegra haberte podido transmitido eso. Al final la programación es programación y todo lo que aprendamos de un sitio se puede traducir y adaptar a otros, nada se pierde. Mucho ánimo!
Gracias.
Muy buena remera ! Y buen video obvio
Sí, sin embargo, se suele usar el patrón de Observer, para hacer videojuego por temas de rendimiento
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!
Molaría ver un curso de gdscript que no hay en español y tú explicas muy bien😢
Veré a ver qué puedo hacer ^^
Ya. Me suscribo y a esperar a que tu canal explote a los 500000
Te esperamos en GODOT! saludos
Nice, seria interesante verlo aplicado en un generador de niveles plataformeros procedural en GODOT
Me lo apunto ;)
Buenas, una pregunta, soy desarrolladora backend, y allí tenemos muchos conceptos de arquitectura hexagonal, solid, clean code, tdd etc, que partes se pueden aplicar a desarrollar juegos?
Muchas gracias por tu pregunta ^^ Tengo intención de explorar más sobre esto en futuros vídeos, pero en resumen se puede aplicar todo. Al final la programación es programación y todo esto son herramientas. Como en todo algunas funcionarán mejor o peor o tendrán que ser adaptadas, pero un videojuego no deja de ser nada más que un programa.
Con motores como Unity y Godot el mayor problema está en que más de la mitad nos lo dan ya hecho y no podemos cambiarlo (a priori), pero se pueden hacer cositas jaja
Hola donde funciona mejor este modelo? lo hago en Unity pero por ahi lo hago mas implicito.... creo ue scriptable object? para datos. digamos en Unity datos o una clase NO monobehaviour con constructor o sino...un scriptable object... y para las capas de logica... un monobehaviour.... y para UI, un ciclo de update en alguna clase specifica apra UI, creo que en Unity , lo Drawcalls va en monobehaviour y se renderiza lo ulitimo junto a los gizmos.
¡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.
¿En goddot recomiendan compensarlo con C# o es mejor comenzar de cero con su lenguaje?
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
MVC es la onda
no entendi ni madres. pero lo que si se esque: la arquitectura orientada a componentes de godot es bastante simple y efectiva. la vida, velocidad etc.. son propiedades, atributos dentro del componente deberian ir dentro del mismo componente. junto con sus metodos.
yo no veo necesidad de separarlos. almenos no en el ejemplo que mostraste. y como tu dijiste en el mismo script de componente cada cosa tiene su seccion
¡Gracias por tu comentario!
MVC no es más que una manera de ordenar código y acelerar el desarrollo y mantenimiento del código, hay muchas otras maneras de hacerlo si esta no te convence. Ninguna es mejor o peor (digan lo que digan), la mejor es la que te funcione a ti.
El ejemplo era sólo para ilustrar cómo hacerlo. El coche es muy sencillo, pero por ejemplo, un controlador de personaje no lo es. Es fácil acabar mezclando animaciones con lógica (p.e. animator.trigger("run left") justo cuando el usuario ha pulsado A), y a la larga se vuelve un nudo de código. Separarlo hace que cada capa se comporte como una caja negra que recibe inputs y produce efectos, sin importarle lo que hace otra capa.
Por eso, explicaba que en muchos objetos serán muy sencillos al principio (como el objeto del coche) y que quizá desarrollar toda la estructura sea overkill nada más empezar. Aún así, eso no nos impide no perder de vista la separación de las capas para así luego hacer más fácil el proceso de conversión; a MVC o al patrón que quieras!
todo bien pero para que la bandera atras? quisiera que expliquen
Es mi bandera del Orgullo, y está colgada en mi puerta siempre. No te gusta? :)
Yo aprendi mvc por mi trabajo.
Vista*
Diseño o arquitectura de software? 😮
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.
Casate conmigo
vi la banderita del lobby socialista y quité enseguida.
🤣🤣🤣🤣🤣 yo me quedo solo porque va de juegos y tiene camiseta de Aperture
Que decis pa? Esa es la bandera de bolivia
@@amedjuzwyhruiz4827 la info esta por todos lados, el reto de hoy en dia no es encontrar info sino una buena fuente. El tiempo es escazo, hay que discriminar el gasto de tiempo, Saludos.
no sé bro yo me quedé por querer aprender