Llegó el día. Godot 3.0 salió a la luz. Se trata de una versión con muchas mejoras respecto a Godot 2.x. Godot es un motor de videojuegos software libre compatible con la mayoría de sistemas operativos (y consolas a través de una compañía privada). Aprovechando la ocasión voy a explicar cómo hacer un juego simple usando C# y el motor 2D de Godot. Este tutorial sirve para familiarizarse con el motor.
Comentarios
Un ejemplo muy atractivo de lo que se puede hacer en Godot 3 (y hablo de cuando 3.x no era estable)
#15 Esas micropausas se evitan muy fácilmente no creando y destruyendo objetos durante el nivel de juego. Ahora, que la gente programe como el culo, esa es otra historia.
#c-17" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2896065/order/17">#17 la teoría dice que es todo cojunudo y la práctica que la gente hace juegos de NES en un i5 a 30fps, cuando en la NES iban a 60fps con un 6502 a 1.7Mhz.
Algo de rendimiento se estará perdiendo por algún sitio, y no solo por C#
#19 Eso no es por pérdida de rendimiento, eso es por gente jeta que intenta hacer pasar juegos cutres y mal hechos por juegos "retro" a ver si suena la flauta y se forran como el creador del Undertale, el del Cave Story y varios más.
#c-17" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2896065/order/17">#17 Precisamente una de las limitaciones de C# es que no te permite ningún tipo de gestión de los objetos. Todo va por el garbage collector. Puedes intentar utilizar struct en vez de class y gestionar la memoria con el stack, que es una forma más natural. Pero entonces te das de narices con las limitaciones y las inconsistencias de los structs en C#.
#21 Lo que se hace en lenguajes con recolector de basura es reciclar la memoria ya reservada, como ya te ha dicho #17. Es más viejo que el catarro (ya se utilizaba en lenguajes similares hace años) y no es precisamente difícil de hacer.
La idea es básicamente no destruir objetos de juego, sino darles un estado "inactivo" o "destruido" dentro del pool de objetos para que el juego los ignore, y cuando haya la necesidad de crear uno nuevo, resetear sus propiedades a un estado válido de nuevo.
Dicho pool de objetos nunca crecerá más allá de lo necesario y de hecho es más eficiente (en tiempo) que destruir los objetos en memoria, pagando el pequeño precio de que no se libera memoria en este concepto hasta que se decide destruir el pool entero.
De esta forma nunca salta el recolector de basura hasta que el objeto es realmente destruido, lo cual debería ocurrir al terminar el nivel/pantalla/partida lo que sea y se evitan los parones.
La técnica no se utiliza únicamente en lenguajes con recolector de basura ya que es igual de válida para C++ y similares y es más eficiente que destruir los objetos durante la partida.
#24 Los pools de memoria es otra técnica para evitar el garbage collector, pero además de complicar la programación, la memoria que requiere se te puede disparar, porque básicamente consiste en cargar en memoria todo lo que necesitas al principio. Si es un PC, la memoria no suele ser un problema, pero cuando piensas en móbiles, la memoria suele ser bastante más limitada.
Pero al final volvemos a lo mismo. Tenemos que andar complicando el código con cosas raras para evitar el garbage collector, porque el propio lenguaje limita tus opciones.
Lo de si es más eficiente, depende. Porque un pool siempre qued en el heap, mientras que utilizando el stack das la posibilidad de que el objeto se cree y se destruya en la propia caché.
#32 Depende de como sea no es mas complicado que crear un struc o un POCO y no tiene por qué usar más memoria de la necesaria si se utiliza para lo que está pensado y apuras la capacidad al número de objetos simultáneos que de todas formas va a tener tu aplicación. El problema está en el mal uso, como todo.
#15 ¿Lo solucionas si programas en JS?
Aparte, como dice #17, el object pooling puede solucionarte los problemas que el GC pueda causar.
Pues un motor que no conocía.... y un desarrollo bien explicado !!!
#1 Lo del desarrollo bien explicado es lo que me ha hecho leerlo a gusto de principio a fin. Tengo que mandar esto a mis compañeros, no para que empecemos a usar Godot, sino para que vean cómo se comenta y se explica un código.
#13 No pierdan el tiempo con este motor. UE4 o Unity y a correr.
#23 #13 Es libre y muy cómodo de utilizar, no veo por qué debería ser ignorado este motor.
#13 Este articulo no muetra un buen ejemplo de como comentar, la mayoria son comentarios mas bien innecesarios (aunque utiles para un tutorial). Comenar en exceso es tan mala practica (o peor) como no hacerlo en absoluto.
#27 Pues en el insti donde hice el ciclo superior de programación comentábamos hasta las líneas de i = i + 1; (poniendo chorradas obvias como "incrementamos el valor de 'i' en uno)" porque nuestro profe estaba obsesionado con que el código tenía que ir siempre perfectamente comentado y, si en los exámenes o prácticas él consideraba, de forma unilateral, que no habíamos puesto suficientes comentarios, nos anulaba el exámen / práctica (no nos bajaba la nota o nos ponía un cero, no... LO ANULABA) y nos quedábamos con un bonito "no presentado".
Lo mejor es cuando luego empecé a currar de esto en consultoras y sitios de mierda similares y prácticamente todo el código que me tocaba retocar / arreglar tenía CERO comentarios (y en ocasiones también CERO documentación).
#42 Es un debate que sigue vigente, pero desde luego ningún programador digno de ese nombre dice que es bueno comentar todas las líneas (o incluso comentar líneas asecas: https://www.tomdalling.com/blog/coding-styleconventions/why-inline-comments-are-generally-a-bad-idea/).
Se lleva mas el enfoque minimalista de comentar solo y solo si es realmente necesario. Basicamente se parte de la idea que tu codigo debe ser "autoexplicativo" y si no es asi es que esta mal pensado.
Otros articulos sobre el tema:
https://improvingsoftware.com/2011/06/27/5-best-practices-for-commenting-your-code/
https://softwareengineering.stackexchange.com/questions/1/comments-are-a-code-smell
https://blog.codinghorror.com/coding-without-comments/
https://visualstudiomagazine.com/articles/2013/07/26/why-commenting-code-is-still-bad.aspx
El problema de tu profesor parece más bien que mezcla la teoría con la práctica, en un examen escrito que te pida describir el codigo linea a linea es normal, en una práctica no.
#38 Échale un vistazo a sus alternativas por si alguna te sirve
https://alternativeto.net/software/rpg-maker/
Vaya, justamente le había echado el ojo a este framework para un proyectillo que tengo en mente de hacer un rpg de estilo japonés en 2D (al estilo de los clásicos de la supernintendo). Me será muy útil este meneo, muchísimas gracias
#5 ¿El Rpg Maker no te sirve?
#25 Me olvidé de decirlo en mi mensaje: seguramente me serviría, pero es que mucha gente dice pestes del rpgmaker, que si solo puedes hacer juegos muy genericos, que quedan todos iguales porque incluso aunque uses gráficos propios se "nota" el engine del rpgmaker por debajo, etc.
Aunque si veo que el Godot se me hace muy cuesta arriba, igual sí que me paso al rpgmaker. Hice algunas chorradillas con él hace cosa de 15 años, pero nunca hice nada serio, solo pequeñas pruebas.
#5 Para un juego de ese tipo creo que es mejor hacerlo a 'pelo', hay multitud de ejemplos por ahí para arrancar.
La documentación de Godos es fantástica
http://docs.godotengine.org/en/3.0/index.html
#3 la Documentación la lleva el gran GDquest , entre otros
El mejor motor que vi, gratuito, y más fácil de manejar, es el FPS Creator Classic, obviamente no sirve para todo tipo de juegos sino para FPS (First Person Shoot, o juegos de tiros o disparos en primera persona). Pero unido a su añadido BlackIce que mejora algunas cosas, especialmente hace que funcione mejor en S.O modernos. Es un mes creas un juego completo:
Ya saliese en Menéame si mal no recuerdo, pero de todas formas:
http://www.blackicemod.org/download.html
De hecho no conozco motor/creador de videojuegos 3D más fácil que ese. Hace años había uno que era el Klik & Play, que era un poco infantil, pero le podías sacar bastante potencial. Para hacer un juego de naves, space invaders, pangs, puzzle bubble, juegos de plataformas, era más que suficiente.
Obviamente hay otra versión bastante mejor, pero no es gratuita, llamada FPS Reloaded y conocida ahora como Game Guru. De hecho sus creador "The Games Creators", pues ya lo dice el nombre, se dedican a crear muchos programas para crear videojuegos, y crear esos videojuegos claro.
Salu2
Oh puedo hacer un snake, juego que se programa en 10 líneas. Un bucle y if y else pintando cuadrados. Viva el software libre. A ver si soporta el tetris.
#6 Con tu razonamiento he de suponer que los lenguajes de programación sólo sirven para imprimir por pantalla "Hello World!".
#c-49" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2896065/order/49">#49 .NET fue liberado en 2014 y Unity funciona con el framework Mono (que ya era libre), no soy muy experto en licencias pero eso significa que C# ya no es "propietario" en ninguno de los casos, no?
Por lo demás, yo tampoco termino de cogerle gusto al lenguaje pero sospecho que es culpa del diseño de Unity, que si que es opaco a menos que pagues los +5000€ de la licencia con el codigo.
#50 ¡Vaya! ¡mola, entonces quita el "propietario" de mi frase
no puedo jugar, no sé dónde está el botón de inicio y la serpiente no se mueve
Muy interesante... Imagino que esta librería es más limitada que el viejuno Allegro, no? Hace unos años estuve haciendo pinitos con él, alguien sabe cuál es su estado de desarrollo actual?
Una pregunta de un novicio... ¿Tiene librería de efectos de sonido y demás?
#4 Sí, y además con multitud de efectos (sonido 3d, doppler, ecos configurables tipo caverna, salón, etc). Aparte del sonido tiene todo lo que necesitas para hacer juegos 2d o 3d en cualquier plataforma.
#29 gracias por la info, Garred
Se vuelve a confirmar que el 99% de usuarios de Meneame, son informáticos que no tienen con quién salir un viernes por la noche.
Fdo. Un informático
#16 se confirma que el 99% de los usuarios de meneame comentan sin saber.
Llevo usando Godoy varios meses y estoy alucinando con lo fácil que es desarrollar videojuegos con él. Tiene además una comunidad hispana muy importante que ha traducido toda la documentación y además los cambios para Godoy 3.0 son alucinantes.
En fin,una maravilla de programa y además software libre
#36 Nerd alert!!!!
#46 Gracias
#16 Ah, pero aún lo dudabas?
Yo me compre y use div studio.
Que tiempos!
Yo usaba div2 y ahora creo que estan adaptando div3 retocando el 2 y tambien esta el divgo super sencillo
¿Alguien dijo Godot?
En c#... que triste...
#c-7" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2896065/order/7">#7 en que crees que se desarrolla en Unity? y es junto con el UE4 de los motores más usados.
Siento que te cause tristeza, pero te puedo decir que de ser así, cada vez vas a estar más triste por la expansión de .NET/C#... Hasta las teles Tizen (4.0) nuevas se van a programar con C#
#9 Unity es seguramente el motor mas usado y a la vez un cáncer para la industria. Cosa más anti-computer-science no la hay.
#c-9" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2896065/order/9">#9 #10 #14 No, si yo no tengo ningún problema con c#, no es una queja, es un lenguaje propietario de alto nivel fantástico, una herramienta de producción estupenda, perfecta para los usuarios de unity.
Solo que me pone triste...
#c-7" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2896065/order/7">#7 ¿C# triste? ¿perdón? ¿puedes desarrollar tu queja?
Qué raro se me hace que alguien hable mal de C#, un lenguaje que te proporciona unas oportunidades para realizar código asíncrono lineal y trabajo en código limpio de este nivel. Y además tipado, proporcionando robustez y seguridad.
Creo que ese tipo de comentarios deben ser defendidos con algo más de una línea.
#10 Ningún lenguaje de programación es perfecto. Uno de los problemas que más rechinan en Unity son las micropausas que vienen de las propias limitaciones del lenguaje. Con esto tampoco estoy diciendo que programar con C++ sea la panacea.
#7 Richard Stallman, ¿Eres tú?
#11 Stallman programaba en Lisp. Si el lenguaje, compilador, bibliotecas, son libres, creo que por Stallman estará ok.
#7 Decir eso es demostrar que no se sabe de lo que se habla
#7 En godot se puede desarrollar en GDScript, que es un hijo bastardo de Python
#c-7" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2896065/order/7">#7 Godot de hecho te permite desarrollar en casi cualquier lenguaje según tengo entendido con una cosa que llaman GDNative. No es que me interese especialmente porque con su GDScript (un subconjunto de Python) estoy muy contento. C# lo han añadido para que venga gente de Unity.
#c-7" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2896065/order/7">#7 Como bien ha añadido #30 existen GDScript, y también GDNative, que permite cargar librerías. Aparte de eso, al estar abierto el código del motor podrías desarrollar el juego totalmente en C++.
Personalmente yo también prefiero C++ a C#, pero me cansan muchísimo las guerras éstas, especialmente cuando no se aportan argumentos ni contexto.