User Tag List

Página 2 de 4 PrimerPrimer 1234 ÚltimoÚltimo
Resultados 16 al 30 de 47

Tema: He portado el Echo a la RG350, pero va muy bien

  1. #16

    Fecha de ingreso
    Jan 2016
    Ubicación
    Cádiz
    Mensajes
    3,294
    Mencionado
    36 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,525
    Agradecer Thanks Received 
    707
    Thanked in
    Agradecido 464 veces en [ARG:2 UNDEFINED] posts
    Entradas de blog
    3
    Cita Iniciado por Drumpi Ver mensaje
    Si programara más uniformemente...

    Y entre medias de estos 3 años, hay varios proyectos: el que empecé con Futublog, el GoBaUg, diversas GameJam, Space 52... e incluso el Tilemap Editor 2, que fue el principal responsable de los retrasos del Echo. Hubo un intento de recuperar el Screen Break Time, haciendo yo mismo los gráficos que faltaban, pero la falta de un motor o algo que me ayudase a realizar las animaciones entre niveles del modo historia, y el hecho de que ya nadie usase la Wiz ni la Caanoo, pues se canceló... y no veo que se vaya a recuperar a corto plazo, ya que ninguna de las Dingux-Consolas trae pantalla táctil, ni sé usar el port de BennuGD a Android.
    te comprendo, llevo con el editor de caras liadisimo, cada vez que saco una especie de versión estable se me ocurren nuevas caracteristicas que añadir...
    ...y eso que no es un juego, es un programa, un click and point como se suele decir...
    ...y eso que ya hay una versión to puerca ya hecha

  2. #17

    Fecha de ingreso
    Sep 2005
    Mensajes
    15,180
    Mencionado
    247 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    670
    Agradecer Thanks Received 
    1,845
    Thanked in
    Agradecido 1,263 veces en [ARG:2 UNDEFINED] posts
    Bueno, yo he descubierto que la clave del éxito de hacer un programa es hacerlo lo más modular posible, es decir, crear un "núcleo" al que se le puedan ir añadiendo cada vez más cosas, sin que unas no influyan con otras.
    Con un videojuego, eso se traduce en crear las mecánicas de forma independiente, intentando mantener las partes que interactúan con otras (si las hubiera) en una zona muy concreta del código, y luego que cada nivel sea totalmente independiente del resto, y que el hilo conductor lo lleve un método/proceso/función, que sea quien gestione las variables "globales" (vidas, energías, qué nivel cargar a continuación...). Es por eso que ahora estoy ampliando el Echo, a ver si hago de él un "juego completo", que sólo dos niveles se me antojan cortos, y cada mes se me ocurre un nuevo nivel que añadirle

    En cuanto a programas, aunque sea un sistema anticuado, el modelo-vista-controlador se me ha revelado como el mejor sistema para poder crear utilidades que se pueden ampliar hasta el infinito.
    Si no lo conoces, es un sistema que divide el código en tres niveles diferentes:
    - Modelo: son el código destinado a almacenar los datos, y a gestionarlos. Por ejemplo, tus caras, ojos, cuerpos... No es sólo el load_fpg o el unload_fpg, si te creas una lista de gráficos es el código que gestiona el añadir o quitar elementos a esa lista, cambiarlos, ordenarlos. Generalmente son funciones, nunca procesos.
    - Vista: es el código que controla la interfaz, es decir, lo que se ve. Es lo que reacciona cuando se pulsa un botón, lo que maneja el scroll de la pantalla, y el que tiene los procesos con gráficos. En este caso sólo son procesos, rara vez necesitas funciones.
    - Controlador: el lo que realiza las acciones. Se sitúa entre la vista y el modelo, y no usa ni gráficos ni variables que no sean privadas, nunca (o casi). La idea es que si pulsas el botón de "cargar gráfico", el proceso de la vista llame a una función del controlador, diciendo "me han pulsado" o "quieren cargar", el controlador llama al modelo de carga de ficheros para obtener el FPG y luego se los pasa al modelo que guarda la lista de FPGs para que lo añada

    La idea es que el código de la vista nunca usa los datos directamente, los del modelo nunca usan gráficos, y rara vez se comunican entre ellos. Por ejemplo, una vez hecha la carga del FPG ¿cómo actualizas la lista que hay en pantalla? Pues el controlador, tras enviar el dato a la lista, le solicita la lista completa, y se la pasa al proceso que controla todos los gráficos de la lista para que se actualice.
    Puede parecer mucho trabajo, y un poco confuso al principio, y el proceso de control se puede ir haciendo enorme si no tienes cuidado, pero créeme, se lo he aplicado al Tilemap Editor 2, y actualmente puedo añadir tantas cosas como quiera. Es cierto que terminas loco de tanto ir de un lado a otro para hacer algo tan "sencillo" como poner un tile, pero si el día de mañana decido que se pueda usar los cursores en lugar del ratón, sólo tengo que cambiar el proceso de la vista, sin tocar el controlador, con todo lo gordo que es, ni los datos.
    Hay mucha documentación en Internet sobre ello, mucho mejor explicado que yo. Échale un vistazo.

    Y seguro que por aquí alguno me dirá que hay otros esquemas más simples, eficientes o mejores, y puede que tengan razón (o no, recordemos que BennuGD usa procesos, no programación secuencial), pero por el momento, para aplicaciones, es el mejor sistema que he visto. Y con una búsqueda rápida, parece que también es el que más se usa hoy día para la programación Web.
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  3. #18

    Fecha de ingreso
    Feb 2004
    Ubicación
    Madrid
    Mensajes
    22,749
    Mencionado
    226 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    2,240
    Agradecer Thanks Received 
    1,902
    Thanked in
    Agradecido 1,185 veces en [ARG:2 UNDEFINED] posts
    Dado que sacas el tema te recomiendo que leas Game Programming Patterns (https://gameprogrammingpatterns.com/ gratis en la web, pero lo puedes comprar en kindle o en papel).
    Para juegos usar MVC es un poco meh aunque es un principio para separar cosas. Pero te recomiendo Entity-component system por ejemplo. Aun así echa un ojo a ese libro que hay un monton de patrones que se pueden usar no solo en juegos

    Te puedo recomendar otros libros si quieres aprender más sobre arquitectura y/o patrones de diseño porque es un tema que a mi personalmente me fascina y en mis ultimos curros por cuenta ajena he sido arquitecta de software así que se un poco del tema.

  4. Los siguientes 5 usuarios agradecen a ^MiSaTo^ este post:

    Drumpi (10/03/2020), futu-block (11/03/2020), Karkayu (11/03/2020), selecter25 (11/03/2020), swapd0 (10/03/2020)

  5. #19

    Fecha de ingreso
    Sep 2005
    Mensajes
    15,180
    Mencionado
    247 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    670
    Agradecer Thanks Received 
    1,845
    Thanked in
    Agradecido 1,263 veces en [ARG:2 UNDEFINED] posts
    Pues muchas gracias, seguro que es una lectura muy interesante
    Más que nada porque de toda la gente con la que he hablado, ninguno ha sabido darme patrones de programación, de diseño o de organización de videojuegos. Cada uno tenía sus sistema, y los que habían estudiado un poco el tema me comentaban que no había sistemas "estandar" o más efectivos que otros, y que cada equipo trabaja como mejor le viene.

    De todas formas, no, MVC no lo uso con los juegos, sólo con las aplicaciones de escritorio
    También es verdad que el programar con procesos de DIV/Fenix/BennuGD es diferente a la programación secuencial... más o menos. Hay similitudes, pero para según qué cosas, el tratamiento es diferente (concretamente con la forma de interactuar).

    Yo ya más o menos tengo mi método: un proceso principal que llama a las funciones de carga de datos, inicializa resolución, teclas, etc, muestra logos, y luego tiene una máquina de estados para el menú principal, el menú de configuración del juego, jugar un nivel suelto, empezar la partida, créditos...
    Luego tengo eso, un proceso que controla el juego en sí, que llama a "play_level" que ya se encarga de gestionar recursos, crear prota, enemigos, etc, y esperar que alguien le diga si el nivel ha terminado satisfactoriamente (y cómo), si el prota ha muerto, o se ha cancelado la partida, y en función de esos datos, pasar al siguiente nivel con los datos del anterior (vidas, energías...) o salir de nuevo al menú.
    Ya cada proceso se gestiona las cosa por su cuenta: comprobar los controles y actuar en consecuencia, usar los datos de velocidad para mover al personaje, comprobar colisiones con objetos, enemigos y amenazas, y finalmente seleccionar el frame de animación a mostrar en función de la máquina de estados y el momento dentro del mismo. Es casi el esquema que se sigue en Unity.
    Si hubiera algo de MVC, sería con la interfaz, pero al final termino por un tratamiento más directo entre vista y modelo, estilo "bindings" de C#.

    Como los procesos son independientes, añadir un nivel al final se reduce a añadir al "play_level" los nuevos recursos, al motor de scroll tileado los nuevos enemigos (la información de enemigos, items, y demás las guardo en los mapas de tiles, por lo que el motor de scroll es quien genera dichos procesos) y los tipos al gestor de señales (el que hace la pausa, mata los procesos al final del nivel...), y luego indicarle al proceso "game" en qué orden cargarlo y qué hacer cuando se sale del mismo.

    Volviendo al libro, tengo curiosidad por ver cómo administra motores tipo Unity, que es un motor que veo muy fuertemente atado a su interfaz gráfica. A ver, se puede hacer todo programando, pero he visto que, a la larga, es más funcional programar "herramientas" que se puedan modificar visualmente, y que permita a grafistas tener más control sobre la edición de niveles... más que nada para repartir el trabajo, que ya bastante tiene el programador con el trabajo de integrar gráficos, música, animaciones y de programar todos los eventos
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  6. #20

    Fecha de ingreso
    Feb 2004
    Ubicación
    Madrid
    Mensajes
    22,749
    Mencionado
    226 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    2,240
    Agradecer Thanks Received 
    1,902
    Thanked in
    Agradecido 1,185 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por Drumpi Ver mensaje
    Pues muchas gracias, seguro que es una lectura muy interesante
    Más que nada porque de toda la gente con la que he hablado, ninguno ha sabido darme patrones de programación, de diseño o de organización de videojuegos. Cada uno tenía sus sistema, y los que habían estudiado un poco el tema me comentaban que no había sistemas "estandar" o más efectivos que otros, y que cada equipo trabaja como mejor le viene.

    De todas formas, no, MVC no lo uso con los juegos, sólo con las aplicaciones de escritorio
    También es verdad que el programar con procesos de DIV/Fenix/BennuGD es diferente a la programación secuencial... más o menos. Hay similitudes, pero para según qué cosas, el tratamiento es diferente (concretamente con la forma de interactuar).

    Yo ya más o menos tengo mi método: un proceso principal que llama a las funciones de carga de datos, inicializa resolución, teclas, etc, muestra logos, y luego tiene una máquina de estados para el menú principal, el menú de configuración del juego, jugar un nivel suelto, empezar la partida, créditos...
    Luego tengo eso, un proceso que controla el juego en sí, que llama a "play_level" que ya se encarga de gestionar recursos, crear prota, enemigos, etc, y esperar que alguien le diga si el nivel ha terminado satisfactoriamente (y cómo), si el prota ha muerto, o se ha cancelado la partida, y en función de esos datos, pasar al siguiente nivel con los datos del anterior (vidas, energías...) o salir de nuevo al menú.
    Ya cada proceso se gestiona las cosa por su cuenta: comprobar los controles y actuar en consecuencia, usar los datos de velocidad para mover al personaje, comprobar colisiones con objetos, enemigos y amenazas, y finalmente seleccionar el frame de animación a mostrar en función de la máquina de estados y el momento dentro del mismo. Es casi el esquema que se sigue en Unity.
    Si hubiera algo de MVC, sería con la interfaz, pero al final termino por un tratamiento más directo entre vista y modelo, estilo "bindings" de C#.

    Como los procesos son independientes, añadir un nivel al final se reduce a añadir al "play_level" los nuevos recursos, al motor de scroll tileado los nuevos enemigos (la información de enemigos, items, y demás las guardo en los mapas de tiles, por lo que el motor de scroll es quien genera dichos procesos) y los tipos al gestor de señales (el que hace la pausa, mata los procesos al final del nivel...), y luego indicarle al proceso "game" en qué orden cargarlo y qué hacer cuando se sale del mismo.

    Volviendo al libro, tengo curiosidad por ver cómo administra motores tipo Unity, que es un motor que veo muy fuertemente atado a su interfaz gráfica. A ver, se puede hacer todo programando, pero he visto que, a la larga, es más funcional programar "herramientas" que se puedan modificar visualmente, y que permita a grafistas tener más control sobre la edición de niveles... más que nada para repartir el trabajo, que ya bastante tiene el programador con el trabajo de integrar gráficos, música, animaciones y de programar todos los eventos
    Lo que te he pasado son patrones de diseño. No son específicos a ningún motor, pero sí son los que más se usan en juegos.
    Y los que te han dicho eso no tienen ni zorra de programar xD Claro que hay cosas estandard! Precisamente por eso se inventaron los patrones de diseño! Esos son los estándares. Un patrón de diseño es precisamente una manera de resolver un tipo de problema en programación. Es algo más o menos "universal", no atado a cierto lenguaje o motor sino para un tipo de problema "universal". Yo los he usado haciendo webs, haciendo apps de movil y haciendo juegos

  7. #21

    Fecha de ingreso
    Jan 2016
    Ubicación
    Cádiz
    Mensajes
    3,294
    Mencionado
    36 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,525
    Agradecer Thanks Received 
    707
    Thanked in
    Agradecido 464 veces en [ARG:2 UNDEFINED] posts
    Entradas de blog
    3
    bueno, lo que uso yo es mas o menos parecido; un proceso para controlar que botón se ha pulsado que lo que hace es regular que valor tiene determinada variable. Luego están los testigos de botones que muestran según la variable si el botón está pulsado o el selector está en tal posición, etc (si, esto no es visual basic que lo hace automáticamente, hay que programarlo) y por último un proceso por cada parte que se muestra según la variable un gráfico u otro...

    En cuanto a videojuegos, pues llevo tiempo replanteando eso, varios módulos, uno para la situación de los elementos, otro para el régimen del juego donde da igual en que ronda esté siempre actuará de la misma forma, y otro para la visualización de los elementos que se limita a mostrar el primer módulo simplemente

    A pesar de ello me leeré lo que ha puesto Misato porque me gusta tener una ''formación'' a que agarrarme, lo de programar por mi cuenta no termina de cuajar (y eso que ahora le estoy dando pequeñas pinceladas al pitón, lol)

  8. #22

    Fecha de ingreso
    Sep 2005
    Mensajes
    15,180
    Mencionado
    247 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    670
    Agradecer Thanks Received 
    1,845
    Thanked in
    Agradecido 1,263 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por ^MiSaTo^ Ver mensaje
    Lo que te he pasado son patrones de diseño. No son específicos a ningún motor, pero sí son los que más se usan en juegos.
    Y los que te han dicho eso no tienen ni zorra de programar xD Claro que hay cosas estandard! Precisamente por eso se inventaron los patrones de diseño! Esos son los estándares. Un patrón de diseño es precisamente una manera de resolver un tipo de problema en programación. Es algo más o menos "universal", no atado a cierto lenguaje o motor sino para un tipo de problema "universal". Yo los he usado haciendo webs, haciendo apps de movil y haciendo juegos
    ¡Ah! Claro, pero tu hablas de patrones de tipo algoritmo, como singleton, búsqueda de caminos, etc. Yo me refería a patrones tipo MVC, modelo-nosequé-negocio... de cómo se organiza el código en general, si se agrupa por capas, por funcionalidad, por la parte de la secuencia
    También es verdad que yo vengo de una época donde lo más visual que había para programar videojuegos era Visual Studio, Eclipse, y algún caso raro Vim. Hoy día, con Unity o Unreal Engine, eso es diferente.

    Cuando yo hablaba con los programadores de videojuegos, les preguntaba si había alguien encargado de crear el motor, alguien con las físicas, otro con los controles, o si por el contrario había quien se dedicaba al prota, otro a los props, otro a las acciones del escenario... O sea, si se dividían el trabajo por el nivel de profundidad en el código o por la función que desempeñan directamente en el juego. O bien si se asignaban las tareas a los miembros del equipo o hacían una lista y cada uno escogía la que tenía ganas de implementar, o había una lista de prioridades y el primero que llegaba es el que la hacía... Y ahí es donde no se ponían de acuerdo.
    En las empresas, normalmente tienen a alguien que sabe más de una parte que de otra (por lenguaje, por cliente, por proyecto, por complejidad...), y se le añaden tareas específicas a su lista, y cuando terminan, se le asigna el código al tester, luego el despliegue... está más organizado.

    Cita Iniciado por futu-block Ver mensaje
    bueno, lo que uso yo es mas o menos parecido; un proceso para controlar que botón se ha pulsado que lo que hace es regular que valor tiene determinada variable. Luego están los testigos de botones que muestran según la variable si el botón está pulsado o el selector está en tal posición, etc (si, esto no es visual basic que lo hace automáticamente, hay que programarlo) y por último un proceso por cada parte que se muestra según la variable un gráfico u otro...

    En cuanto a videojuegos, pues llevo tiempo replanteando eso, varios módulos, uno para la situación de los elementos, otro para el régimen del juego donde da igual en que ronda esté siempre actuará de la misma forma, y otro para la visualización de los elementos que se limita a mostrar el primer módulo simplemente

    A pesar de ello me leeré lo que ha puesto Misato porque me gusta tener una ''formación'' a que agarrarme, lo de programar por mi cuenta no termina de cuajar (y eso que ahora le estoy dando pequeñas pinceladas al pitón, lol)
    Hombre, Futu, un periodo de adaptación es necesario, hasta para gente que sabe.
    Primero tienes que tener una base teórica. Luego tienes que tener un periodo de aprendizaje con el lenguaje, y ya después empiezas a hacer las cosas por tu cuenta.
    En mi caso personal, cuando me enfrento a un lenguaje nuevo, en el caso ideal (me pasó con Java y PHP) primero me busco un curso que me enseñe las bases, para aprender la sintaxis, cómo funcionan los bucles while, for..., si es programación secuencial, orientada a objetos, si tiene algún elemento nuevo que lo distinga... y así estoy uno o dos meses. Luego me busco algún proyecto ya empezado y me pongo a trastear con él a hacer cosas sencillas hasta que entiendo la forma en la que se organiza el código y los patrones que dice Misato, propios del lenguaje, y después hago uno o dos programas sencillos antes de lanzarme al gran proyecto.

    En el caso no ideal, como ha sido con C# y Xamarin en el trabajo, te lanzan de cabeza a un proyecto de demostración, te piden que le cambies los colores o la Base de Datos con la que trabaja, y vas modificando partes hasta que empiezas a añadir cosas nuevas.

    Nunca te pones desde el minuto cero con un proyecto grande, y hay que dedicarle tiempo... cosa que a los programadores, en general (por lo que he visto) no nos gusta Queremos picar código desde ya, y luego pasa lo que pasa.
    Por eso me gustan las Crap Compo: haces juegos sencillos, cortos, y no importa que tenga fallos, puedes experimentar y si te sale un churro, ya sabes que en el siguiente no lo vas a hacer así... y encima te desahogas de las normas y el libro de estilo de programación (aunque cuando terminas entiendes por qué se han escrito )
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  9. #23

    Fecha de ingreso
    Feb 2004
    Ubicación
    Madrid
    Mensajes
    22,749
    Mencionado
    226 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    2,240
    Agradecer Thanks Received 
    1,902
    Thanked in
    Agradecido 1,185 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por Drumpi Ver mensaje
    ¡Ah! Claro, pero tu hablas de patrones de tipo algoritmo, como singleton, búsqueda de caminos, etc. Yo me refería a patrones tipo MVC, modelo-nosequé-negocio... de cómo se organiza el código en general, si se agrupa por capas, por funcionalidad, por la parte de la secuencia
    También es verdad que yo vengo de una época donde lo más visual que había para programar videojuegos era Visual Studio, Eclipse, y algún caso raro Vim. Hoy día, con Unity o Unreal Engine, eso es diferente.

    Cuando yo hablaba con los programadores de videojuegos, les preguntaba si había alguien encargado de crear el motor, alguien con las físicas, otro con los controles, o si por el contrario había quien se dedicaba al prota, otro a los props, otro a las acciones del escenario... O sea, si se dividían el trabajo por el nivel de profundidad en el código o por la función que desempeñan directamente en el juego. O bien si se asignaban las tareas a los miembros del equipo o hacían una lista y cada uno escogía la que tenía ganas de implementar, o había una lista de prioridades y el primero que llegaba es el que la hacía... Y ahí es donde no se ponían de acuerdo.
    En las empresas, normalmente tienen a alguien que sabe más de una parte que de otra (por lenguaje, por cliente, por proyecto, por complejidad...), y se le añaden tareas específicas a su lista, y cuando terminan, se le asigna el código al tester, luego el despliegue... está más organizado.



    Hombre, Futu, un periodo de adaptación es necesario, hasta para gente que sabe.
    Primero tienes que tener una base teórica. Luego tienes que tener un periodo de aprendizaje con el lenguaje, y ya después empiezas a hacer las cosas por tu cuenta.
    En mi caso personal, cuando me enfrento a un lenguaje nuevo, en el caso ideal (me pasó con Java y PHP) primero me busco un curso que me enseñe las bases, para aprender la sintaxis, cómo funcionan los bucles while, for..., si es programación secuencial, orientada a objetos, si tiene algún elemento nuevo que lo distinga... y así estoy uno o dos meses. Luego me busco algún proyecto ya empezado y me pongo a trastear con él a hacer cosas sencillas hasta que entiendo la forma en la que se organiza el código y los patrones que dice Misato, propios del lenguaje, y después hago uno o dos programas sencillos antes de lanzarme al gran proyecto.

    En el caso no ideal, como ha sido con C# y Xamarin en el trabajo, te lanzan de cabeza a un proyecto de demostración, te piden que le cambies los colores o la Base de Datos con la que trabaja, y vas modificando partes hasta que empiezas a añadir cosas nuevas.

    Nunca te pones desde el minuto cero con un proyecto grande, y hay que dedicarle tiempo... cosa que a los programadores, en general (por lo que he visto) no nos gusta Queremos picar código desde ya, y luego pasa lo que pasa.
    Por eso me gustan las Crap Compo: haces juegos sencillos, cortos, y no importa que tenga fallos, puedes experimentar y si te sale un churro, ya sabes que en el siguiente no lo vas a hacer así... y encima te desahogas de las normas y el libro de estilo de programación (aunque cuando terminas entiendes por qué se han escrito )
    mmm.. estas mezclando cosas, como siempre drumpi xD
    Mirate el libro que te he dicho y luego ya comentamos cosas. También puedes leerte cosas sobre arquitectura (que es lo de que sea MVC, ECS, etc) de software.

    Y no tienes que explicarme como se trabaja en empresas de videojuegos: mi novio ha trabajado en Guerrilla Games haciendo el Killzone, yo he trabajado en otro estudio en España haciendo juegos para DS (por desgracia no tan famosos). Y ahora hago juegos yo por mi cuenta. Vamos que se un poco de qué va el tema xD

    PD. usar un engine u otro no te condiciona a usar ciertos patrones o cierta arquitectura (hasta cierto punto). Todo eso es independiente de lo que uses

  10. #24

    Fecha de ingreso
    Sep 2005
    Mensajes
    15,180
    Mencionado
    247 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    670
    Agradecer Thanks Received 
    1,845
    Thanked in
    Agradecido 1,263 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por ^MiSaTo^ Ver mensaje
    mmm.. estas mezclando cosas, como siempre drumpi xD
    Mirate el libro que te he dicho y luego ya comentamos cosas. También puedes leerte cosas sobre arquitectura (que es lo de que sea MVC, ECS, etc) de software.

    Y no tienes que explicarme como se trabaja en empresas de videojuegos: mi novio ha trabajado en Guerrilla Games haciendo el Killzone, yo he trabajado en otro estudio en España haciendo juegos para DS (por desgracia no tan famosos). Y ahora hago juegos yo por mi cuenta. Vamos que se un poco de qué va el tema xD

    PD. usar un engine u otro no te condiciona a usar ciertos patrones o cierta arquitectura (hasta cierto punto). Todo eso es independiente de lo que uses
    Estoy en ello

    No, no intento decirte cómo se trabaja en la industria, sólo intento aclarar lo que he hablado con otra gente, para que quede claro si estamos hablando de lo mismo o no. A partir de ahí entramos a valorar quien tiene razón o no
    De todas formas, yo soy de los que prefieren experimentar, más que de leer. No me vale que me digan "esto se hace así" o "esta forma es mejor", prefiero probarlo y ver si es verdad o no. Creo que ya lo comenté alguna vez, que hace tiempo hice una especie de compilador, algo que cogía texto y lo convertía en bytecode para un intérprete que hice, sin haberme leído nada previamente de compiladores, y llegué a muchas conclusiones que leí a posteriori, pero si no, no hubiese visto necesaria la compilación en dos pasos, por ejemplo.
    Y aquí es donde mucha gente me dice que lo hago mal, que lo suyo es primero leer y estudiar y luego aplicar, pero prefiero hacer así las cosas: aprendo de mis errores, tengo más flexibilidad y en ocasiones se me ocurren ideas que son mejores que las que aprendo, porque tengo una visión "out of the box". Quizás por eso tengo una forma tan "peculiar" de pensar. También tiene su lado malo: aprendo más despacio que apoyándome en la experiencia general.
    Ojo, es una preferencia, no lo hago siempre así. También leo y aplico.

    Respecto al postdata, estoy de acuerdo, pero no estoy seguro del todo. Mi experiencia con Unity, por ejemplo, es limitada, y cuando he trabajado con él me he limitado a crear módulos para integrarlos en los assets, nunca he trabajado a bajo nivel ni a medio nivel, porque ya te lo da hecho, y sin embargo, en BennuGD, todo, absolutamente todo (bueno, casi, que por debajo hay una capa de SDL que dibuja y pone la música por mi) me lo tengo que guisar y comer yo: motor de scroll tileado, control de colisiones, desarrollo del juego, máquinas de estados de los enemigos, qué gráfico seleccionar...
    En el primer caso, sólo me he preocupado de mantener los módulos independientes los unos de otros, o de asegurarme de que se ponen juntos, o de que pueden ser reutilizables. En el segundo ya entramos que si MVC, que si módulos de control/juego/música...

    Y dada la cantidad de tipos lenguajes, que aunque conozco unos cuantos, aun hay muchos que ni los he olido, así que eso de que "usar un engine u otro no te condiciona a usar ciertos patrones o cierta arquitectura" lo pondría en unas comillas sujetas con pinzas. Ya el cambio de mentalidad de C a Div es brutal, como pasar de programación "normal" a manejar hilos. O cómo acostumbrado a hacer programas que si te dan A produces B, de pronto te metes en interrupciones, o señales enviadas desde la interfaz de Visual Basic, y al día siguiente estás con una WebApi respondiendo a una petición que funciona como si fuera un programa diferente a la siguiente o la anterior petición.
    Probablemente los patrones sean usables en todos los lenguajes, pero ¿es recomendable? ¿permiten usar toda la potencia del mismo? ¿O por adaptarnos a una forma de pensar que conocemos y nos recomiendan, estamos pasando por alto un esquema nuevo más eficiente para ese caso?
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  11. #25

    Fecha de ingreso
    Feb 2004
    Ubicación
    Madrid
    Mensajes
    22,749
    Mencionado
    226 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    2,240
    Agradecer Thanks Received 
    1,902
    Thanked in
    Agradecido 1,185 veces en [ARG:2 UNDEFINED] posts
    Es que creo que estás mezclando conceptos. Los patrones de diseño son más o menos universales. (Digo más o menos porque quizá no todos funcionen para todos los paradigmas de programación, pero dentro del mismo da igual el lenguaje). Usarlos o no claro que permiten usar toda la potencia del lenguaje! Es que eso es independiente de la arquitectura que desarrolles. Y bueno un consejo: no trates de reinventar la rueda. Todos hemos pasado por ello pero NO compensa. Esto lo digo por la última frase que dices que si estamos pasando por alto un esquema nuevo más eficiente: seguramente no. Seguramente ninguno de los que estamos aquí pueda hacer un esquema nuevo más eficiente (sea lo que sea eso).

    Y sobre la comparación de bennu/SDL con Unity... bueno son dos cosas muy distintas. Unity/Unreal son un motor completo. Mientras que Bennu no lo es y SDL son directamente unas librerías (que ni siquiera un motor).

    Yo también aprendo haciendo, pero la experiencia me ha demostrado que es mejor primero leer e informarse antes de experimentar cosas. Así pierdes menos tiempo.

  12. El siguiente usuario agradece a ^MiSaTo^ este mensaje:

    Drumpi (11/03/2020)

  13. #26

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    7,549
    Mencionado
    47 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,660
    Agradecer Thanks Received 
    1,915
    Thanked in
    Agradecido 1,285 veces en [ARG:2 UNDEFINED] posts
    Creo que es bueno llegar a cosas estandarizadas, al igual que pasa con los lenguajes y con las API es importante que, ya que existen soluciones generales a ciertos problemas pues se apliquen, si hay gente que prefiere reinventar la rueda es su problema, ademas que te ahorras mucho tiempo diciendo, las clases tipo manager están implementadas como un singleton y la implementación de las operaciones sobre las entidades he usado el patron visitador.
    No es lo mismo tener diez años de experiencia, que tener un año de experiencia diez veces.


    It is an undisputed truth that the Atari ST gets the best out of coders. No dedicated hardware, just the CPU and a frame buffer! Some call it Spartan, others name it Power Without The Price, and a select few say `challenge accepted'! --- by spkr from smfx

  14. Los siguientes 2 usuarios agradecen a swapd0 este post:

    Drumpi (11/03/2020), ^MiSaTo^ (11/03/2020)

  15. #27

    Fecha de ingreso
    Sep 2005
    Mensajes
    15,180
    Mencionado
    247 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    670
    Agradecer Thanks Received 
    1,845
    Thanked in
    Agradecido 1,263 veces en [ARG:2 UNDEFINED] posts
    No os voy a quitar la razón, y más cuando hoy día se tiende a usar lenguajes muy similares (C++, C#, Objetive-C...) o motores creados por terceros, es más obvio que los patrones van a ser muy útiles.
    Pero el ingeniero que hay en mí siempre tiene dos palabras resonando en la cabeza y que pueden ser una pesadilla: "¿Por qué?"
    No es que no me fíe de años de experiencia de miles de personas con más idea que yo, es por la curiosidad... y por las malas experiencias que he tenido, y sigo teniendo, con esos códigos en plan "caja negra", que una librería no hace lo que le pido y no sé por qué (bindings en C# que no generan el evento "OnPropertyChange", cobros que meto en un programa de contabilidad y que se inventa valores en campos que ni he tocado...)

    También puede ser culpa de la cantidad de lenguajes que he aprend... bueno, más bien, usado de aquella manera . De la secuencia de C a los procesos de Fenix, y de pronto OOP con java (sumándole SQL y alguno más), y un salto al C# de Unity, para meterme en C# a pelo (con sus bindings, sus hilos y la madre que parió al LinQ) y VB.Net antes de tocar Xamarin o VB6. Cada dos años es un paradigma nuevo, vamos, que no me aburro (pero tampoco avanzo demasiado).


    Me gustaría poneros un ejemplo de lo que digo de que, en ocasiones, los patrones no sirven, pero como nunca doy con el ejemplo bueno, prefiero no decir nada, pero se me ha dado el caso.
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  16. #28

    Fecha de ingreso
    Feb 2004
    Ubicación
    Madrid
    Mensajes
    22,749
    Mencionado
    226 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    2,240
    Agradecer Thanks Received 
    1,902
    Thanked in
    Agradecido 1,185 veces en [ARG:2 UNDEFINED] posts
    Cuando lees buenos libros al respecto explican el por qué se hace una cosa u otra. A ver si te crees que el resto de ingenieros no tenemos en la cabeza ese por qué xD

    Y te puedo dar ejemplos de por qué un patrón u otro no sirve. No todos los patrones sirven para resolver todos los problemas. Precisamente un buen arquitecto de software sabe cuándo usar uno u otro y cuándo no usarlos

  17. Los siguientes 2 usuarios agradecen a ^MiSaTo^ este post:

    Karkayu (12/03/2020), selecter25 (19/03/2020)

  18. #29

    Fecha de ingreso
    Sep 2005
    Mensajes
    15,180
    Mencionado
    247 Post(s)
    Tagged
    1 Tema(s)
    Agradecer Thanks Given 
    670
    Agradecer Thanks Received 
    1,845
    Thanked in
    Agradecido 1,263 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por ^MiSaTo^ Ver mensaje
    A ver si te crees que el resto de ingenieros no tenemos en la cabeza ese por qué xD
    Viendo el código de algunos, las preguntas de otros, y el desinterés demostrado por según qué sujetos (con frases "si funciona, déjalo así, cuando haya tiempo se arregla"), y sin referirme a nadie en concreto de este foro, permíteme que lo ponga en duda
    PROYECTOS REALIZADOS: FrikiMusic, Motor Scroll Tileado v3.2, Venturer2X (GP2X/WIZ), Echo, Screen Break Time
    PROYECTOS EN MARCHA (algunos): Bennu GP2X: 95% (necesito ayuda) ¡Antes de Halloween!: 92% SpaceH2H: 8%

  19. #30

    Fecha de ingreso
    Feb 2004
    Ubicación
    Madrid
    Mensajes
    22,749
    Mencionado
    226 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    2,240
    Agradecer Thanks Received 
    1,902
    Thanked in
    Agradecido 1,185 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por Drumpi Ver mensaje
    Viendo el código de algunos, las preguntas de otros, y el desinterés demostrado por según qué sujetos (con frases "si funciona, déjalo así, cuando haya tiempo se arregla"), y sin referirme a nadie en concreto de este foro, permíteme que lo ponga en duda
    Es que a lo mejor con los que has dado no son ingernieros. O bueno si consideras ingeniero a tener un papel... porque para mi esos no lo son tengan papel o no (yo por cierto no lo tengo)

  20. Los siguientes 5 usuarios agradecen a ^MiSaTo^ este post:

    Drumpi (12/03/2020), futu-block (12/03/2020), Karkayu (12/03/2020), selecter25 (19/03/2020), swapd0 (12/03/2020)

Página 2 de 4 PrimerPrimer 1234 ÚltimoÚltimo

Etiquetas para este tema

Permisos de publicación

  • No puedes crear nuevos temas
  • No puedes responder temas
  • No puedes subir archivos adjuntos
  • No puedes editar tus mensajes
  •