Mostrar Mensajes

Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.

Mensajes - ferhand

...

8 9 10 11 12

...

136

Preguntas y respuestas / Re:Marcos de trabajo para grupos de desarrollo

Enero 09, 2013, 11:27:15 PM

Saludos makeros involucrados en el debate:

En las metodologías mencionan a distintos roles (trabajos) que se deben desempeñar por los miembros del equipo. Esto tributa a que en los diagramas intervengan la mayoría del equipo.

Sin embargo, particularmente prefiero realizar los diagramas solo y en intervención del diseñador, en caso de no ser yo. De esta manera las documentación tendrá un mismo estilo. Hay veces que aunque se siga una misma metodología, cada persona tiende a entenderla a su manera y de esa forma lo plasma. Una documentación escrita por varias personas tiende a ser poco comprensible.

En la escuela siempre eramos un programador web, un programador "descktop", un ingeniero en sistemas y un grafista digital. El ingeniero en sistema era el encargado de realizar la documentación aún no siendo él el diseñador del proyecto inicialmente.

137

Noticias / Re:La hora del ultimo cambio: bajamos el telon tras 8 años de gloria.

Enero 09, 2013, 11:20:08 PM

Saludos makero Fenris78:

Ya, ya, ya se que fue una "broma". :D ¡Ño, pero que pesada! :-X

El problema es que estoy muy preocupado por mi aporte a la comunidad y siempre estoy previendo el fin. De pronto veo la noticia y no pude leer más, se me congeló la sangre; lo cual es bien difícil pues soy del Caribe. Sumado todo esto a la falta de "cultura del día del inocente" y al material de inocente que presento, simplemente me alarmé. :)

Saludos reiterados.

138

Noticias / Re:La hora del ultimo cambio: bajamos el telon tras 8 años de gloria.

Enero 08, 2013, 07:23:52 PM

Saludos Makeros:

Fenris78, ¿pero cómo se les ocurre decir semejante barbaridad? >:(

Acá no celebramos propiamente el día de los inocentes y siempre entre las bromas que se realizan se trabaja con la torpeza ajena, no con el engaño elaborado y creíble por venir de fuentes fidedignas... >:(

Eso no es para tomarlo como un juego. Fue en realidad muy cruel por parte de todos los del equipo que estuvieron involucrados. Estoy contento porque el makero penumbra lo aclaró, pero me costó trabajo por la diferencia cultural. :-[

Se puede jugar con muchas cosas, pero no con la razón de ser muchos de nosotros...

Aunque no lo crean yo siento a esta comunidad como parte de mi vida social, así a sido y me gustaría que siguiera siendo. :)

139

Preguntas y respuestas / Re:Marcos de trabajo para grupos de desarrollo

Enero 08, 2013, 07:06:07 PM

Saludos makero licshendu:

En realidad si está expresando bien la idea, lo que como toda idea tiene puntos de vistas diferentes en diferentes personas. ¿Recuerdas el cuento de los cuatro ciegos y el elefante? XD

Esto es algo muy engorroso que se ha estado tratando de estandarizar desde hace mucho tiempo, pero solo es posible establecer marcos de trabajos y metodologías para un mismo sistema, al exportarlo a otro comienzan los fallos.

Yo pienso que cuando ya están hechos los planos de una casa y los mismos indican cómo y dónde poner cada piedra y cual va primero, no habrá problemas con los constructores siempre que sepan interpretar los planos.

Por eso insisto en tener primero un diseño completo del software (juego) a implementar. Cuando ya estén todas las especificaciones, los métodos, variables, objetos y pantallas del juego bien explicados, de forma tal que se pueda calcular el flujo completo en la mente o en papel, entonces será muy fácil decidir que tiene que hacer cada programador. Todo es posible una vez que esté todo documentado.

Dónde radica la diferencia, en el diseño del software. Por ejemplo:
* una forma es llegar a diseñarlo tal cual hemos explicado, detallado al punto que simplemente hay que escribir lo que dice en el documento de diseño.

* Otra forma puede ser solo llegar a determinar las variables y las funciones que utilizarán esas variables sin llegar a especificar el código dentro de ellas, dejando a los programadores desarrollar las funciones por dentro, pero sabiendo lo que debe hacer cada una.

* Otra forma es detallando el juego en módulos independientes unos de otros y brindando la posibilidad a los programadores que desarrollen cada módulo por su lado siempre teniendo en cuanta las especificaciones para interactuar entre ellos.

Ya eso depende de la metodología de trabajo que escoja el diseñador y el equipo en conjunto, pero siempre partiendo de un diseño previo bien completo.

Citarsi lo conozco ^^ es un diagrama también de UML, aunque no sabría como usarlo , también pensé en usar los diagramas de casos de uso, alguna idea compadre de como podríamos usarlos en GM, o convendría usarlos tal cual son, tu que harias?

Utilizo los casos de uso cuando el proyecto es muy grande y no logro determinar las partes que lo componen en una simple mirada sin esfuerzo. De todas formas, los casos de uso son super importantes para determinar las funciones del programa. Eso sí, todo comienza desde el punto de vista del usuario, en este caso el jugador.

En el ejemplo de "space invaders" los casos de uso del negocio que yo veo podrían ser "inicializar el juego", "presionar la flecha derecha", "presionar la flecha izquierda", "presionar el botón de disparo" y "cerrar juego". Todos esos porque son inicializados por el usuario (jugador).

Luego realizaría un diagrama de actividades por cada caso de uso donde intervengan las acciones del usuario y las respuestas del sistema. Estos me permitirán ver los casos de usos más desde dentro.

Con todo esto ya es posible determinar los requerimientos funcionales del software: una lista de "cosas" que no pueden faltar en nuestro software, algunas de ellas no salen del todo dentro de los diagramas, pero debemos incluirlas, por eso es iterativo e incremental. XD

Ya hasta aquí llega el modelado del negocio y debe comenzar el modelado del sistema.

Particularmente estoy tratando de desarrollar un proyecto entre dos programadores a mucha distancia. Primero estoy realizando aproximaciones del diseño dentro del modelado que quiero hacer. El proyecto es mediano y lo estoy diseñando por módulos lo más independientes posibles, para que podamos trabajar separados y aún así funcionen en conjunto. Una vez que terminemos quedará el documento de diseño y pensamos publicarlo acá en la comunidad a modo de ayuda como una forma más de hacerlo. XD

La forma en que modelé el sistema es bien enredada, casi nada es un objeto completo. Las características como posición, "sprites", colisiones son solo variables con datos. Quiero que la IA de cada uno sea de la misma forma. Así tendré control sobre todos los elementos sin depender de la estructura objeto de GM que trae muchas características que no necesito. También deseo alcanzar la posibilidad de ingresar elementos nuevos una vez el juego esté hecho completamente para no tener tener que tocar el código más de una vez.

Veamos que tal me resulta...Pues me he enredado bastante... :-[ :-[ :-[ y todo por la posibilidad de que corra bien en PC de pocos recursos.

La optimización prematura es el enemigo de todo programador. XD XD XD

140

Preguntas y respuestas / Re:Metodo para recibir coordenadas de varias instancias (39DLL)

Enero 08, 2013, 05:52:59 PM

Estoy de regreso ... con información fresca:

Saludos y al debate...

Los "arrays" son estructuras que guardan datos en "Ram" en espacios de memoria contiguos. Cuando se desea insertar otro elemento se debe crear un "array" nuevo con un elemento de más y copiarle la información que existía en el otro "array" incluyendo el cambio. Todo este trabajo es por la razón de que el sistema debe encontrar un espacio lo suficientemente grande para que quepa el nuevo "array" todo de un golpe. A la hora de ir directamente a algún indice, el sistema tiene como llegar sin mayores complicaciones.

Si embargo, las listas se guardan en la "Ram" de otra forma. Cada elemento de la lista es una estructura llamada nodo, formada por dos piezas, en una está el valor y en la otra está la dirección de memoria del próximo nodo (índice). Para alcanzar algún nodo (indice) dentro de la lista hay que recorrerla pues la dirección de memoria de dicho nodo está en el nodo anterior. Si queremos alcanzar el nodo (índice) 3 debemos acceder al nodo 2 pues en él esta la dirección del nodo 3, pero para acceder al nodo 2 debemos acceder al nodo 1 pues en él está la dirección del nodo 2. Todo esto lo hace el sistema por detrás, pero es bien lento cuando se tiene una lista muy grande.

Yo no recordaba estos detalles de cuando estudiaba progarmamción. Aún así la documentación de GM dice "They are implemented using simple arrays but, as this is done in compiled code it is a lot faster than using an array yourself." Lo cual es irrefutable por mi.

¡Por lo tanto ha usar listas....!!!! XD XD XD XD

¡Texic, tenías razón...! ;D

141

Preguntas y respuestas / Re:Marcos de trabajo para grupos de desarrollo

Enero 07, 2013, 11:34:38 PM

Makero licshendu:

Te lo has tomado a pecho y eso es bueno, quién sabe si de todo este tema saldrá una metodología de diseño de software para videojuegos utilizando la herramienta GM. XD XD XD

Por lo pronto estoy de acuerdo con el makero penumbra sobre aquello de que cuesta descifrar el diagrama de relación. Conozco la metodología RUP (Rational Unified Process), una metodología más lenta que Scrum. Entre los diagramas que se emplean en ella está uno llamado diagrama de actividades. En él se explica visual y textualmente como interactuan los diferentes elementos de un posible software, (usuarios, trabajadores, otros sistemas envueltos en el negocio). Es un diagrama muy explicativo y fácil de entender pues expone un grupo de interacciones como una máquina de estados finitos. Te invito a que le eches un vistazo.

El comentario que hago es que desde el comienzo tratas a los elementos del juego como objetos. O sea cada elemento del juego lo denominas objeto desde un inicio. Todas las metodologías lo que tratan es de brindarnos pasos para transformar una "idea", una necesidad de un cliente, en "software". La mayoría de las veces es difícil saber cuando un elemento de la "idea" es un objeto completo o parte de un objeto y si debería ser así. Las metodologías nos orientan en ese camino, pero nunca al principio. Después de varias etapas dentro del desarrollo con sus diagramas correspondientes es que comienza a dilucidarse qué conforma cada elemento.

No es para mal mi comentario, sino para bien y mejora. No siempre es lo más optimo convertir todo lo que "veamos" en un objeto, hay veces, muchas, en que la estructura "objeto" está sobre valorada y llega a convertirse en un lastre. :-[

142

Preguntas y respuestas / Re:Metodo para recibir coordenadas de varias instancias (39DLL)

Enero 07, 2013, 07:50:59 PM

Cita de: Texic en Enero 07, 2013, 06:24:24 PMLa diferencia principal radica en que las funciones internas que ejecuta la ds_list están previamente compiladas, y los scripts o códigos que vos crees con tus arrays son interpretados, la diferencia de velocidad es abismal

¡Anjá, yo sabía que me pasaba algo por alto! En ese caso la ejecución de lista debe ser mucho más rápida... Pido disculpas por mi error y le sugiero a Silver_light que considere tu consejo.

Hermano, particularmente estoy utilizando "arrays" en el diseño de mi juego. Los utilizo por el aquello de los índices, los necesito, pero si las listas son mejores...¿Crees que las estructuras como los "grid" sean más eficientes que un "array" 2D? Lo pregunto pues en mi diseño tengo montones de "arrays" bidimensionales en memoria ram.

Pido disculpas si ya esto se sale del tema...¿Debería crear uno nuevo...? :-[

143

Preguntas y respuestas / Re:Metodo para recibir coordenadas de varias instancias (39DLL)

Enero 07, 2013, 05:23:03 PM

Saludos Makera Silver_light y Makero Texic:

Disculpa hermana si tomo tu espacio de pregunta para una corta discusión. :-*

Lo siento hermano Texic, pero estoy en desacuerdo contigo. :-[

Las listas en el tras fondo están programadas utilizando Arreglos (array[a,b]), por lo que son una interfaz para el trato con los mismos. En lo único que yo veo eficiencia en las listas es que desde el lado del programador es menos engorroso a la hora de insertar un nuevo elemento en cualquier posición de la lista, o a la hora de organizar sus elementos basados en algún criterio. Aún así el programa guarda por cada lista una serie de parámetros que muchas veces no vamos a utilizar y sin embargo ocupan espacio en memoria.

Los arreglos se pueden utilizar del mismo modo, la dificultad es que tenemos que programar las acciones que necesitamos ya sean insertar un elemento, ordenar o eliminar, etc. Lo bueno es que es una primitiva del lenguaje y no guardará parámetros extras al tiempo que se ejecutan con rapidez. 8)

Es solo mi opinión, a lo mejor estoy dejando pasar algo por alto. El problema es que me encanta discutir y vi la oportunidad para hacerlo. :P Disculpa Silver_light y Texic. Todo es para aprender y divertirnos. ;D

144

Preguntas y respuestas / Re:Marcos de trabajo para grupos de desarrollo

Enero 04, 2013, 09:36:13 PM

Saludos makero licshendu:

Primero ¡Feliz año nuevo! Te deso mucha salud y dinero... ...que el resto se puede comprar. XD

Preguntas por marcos de trabajo. Bien, creo que antes habría que tener en cuenta el documento de diseño. Ya luego es más facil repartir el trabajo pues se sabe qué se va a hacer y cómo se va a hacer.

Un documento de diseño de un videojuego viene siendo los planos de un puente que un ingeniero dibujó. En los planosdebe estar reflejado todo, desde las estructuras más grandes hasta las más pequeñas, incluso los cálculos de los materiales a emplear, sus proporciones en las mezclas, todo.

Un documento (documentos) de diseño de un videojuego debe ser igual de explicativo y abarcador. Comienza por lo más general del juego (puede ser la historia, la mecánica, etc.), determina elementos del modelo como módulos y objetos a emplear y llega a lo más particular como funciones a crear para dar respuestas a las necesidades de cada módulo u objeto. Debe ser tan específico que no deje nada al azahar. Cuando el programador vea el documento sepa que programar y tenga una sólida idea de cómo hacerlo. Algo así como: debes escribir una función que recibe cuatro números enteros, que son las coordenadas de dos puntos, y debe devolver la distancia entre los mismos.

De esta forma todos los códigos que se programen son compatibles y ninguno estará duplicado o sin uso.

Insisto que el documento de diseño es muy importante, cuando más grande es el proyecto, más importante se vuelve la documentación, incluso si es para un solo programador.

Espero te sirva de algo, saludos.

145

Preguntas y respuestas / Re:Metodo para recibir coordenadas de varias instancias (39DLL)

Enero 04, 2013, 08:12:42 PM

Saludos makera Silver_light:

Ante todo ¡feliz año nuevo!, te deseo mucha salud y dinero... que el resto se puede comprar... XD

Mi propuesta es que no solo envíes al cliente las coordenadas del objeto arma creado en el servidor, sino que también envíes el identificador de esa arma. Por ejemplo: (arma1, x, y), (arma2, x, y), etc. Asi sabrás de que arma es cada coordenada. Y por supuesto que el uso de arreglos es recomendado para llevar el control de todos estos datos. Tengo entendido que son más eficientes que las listas.

Cada arma creada en el servidor debe ser enviada al cliente y de esta forma es que se pueden leer. Consejo, crea una lista de las armas creadas y sus coordenadas en el cliente y en el servidor. De esta forma tendrás más control de cada arma desde ambos lados.

Espero te sirva de algo, un saludo. ;D

146

Mercado / Re:Cómo desarrollar un juego para Nintendo Wii

Enero 03, 2013, 09:25:36 PM

Nintendo siempre a sido mi preferida por la calidad de sus juegos.

Esta noticia no es precisamente de celebrar por los exquisitos requisitos solicitados sin contar el alto precio de sus SDK.

Si Nintendo no cambia sus políticas está condenado a retroceder en el mercado. Mira lo que le pasó a Sega.

Por el momento me mantengo con Microsoft y su XNA para Xbox Live sin dejar de reconocer que Mario, Zelda, Donkey Kong Metroid y otros tantos son títulos muy completos que han hecho historia en mundo... y continúan sorprendiendo.

Muchas gracias por el artículo, Shaoran. ;D

¡Felicidades en este nuevo año 2013! ¡Mucha salud y dinero para todos les deseo! El resto se puede comprar... XD

147

Noticias / Re:Reajustes en el reglamento del concurso: validez de votos

Diciembre 20, 2012, 04:38:07 PM

Saludos makero Fenris78:

Estoy de acuerdo con la medida cautelar aplicada. :D

Ya se que no está abierta a debate democrático, aun así decidí escribir mi apoyo a la misma. :D

Mi único problema es que la conexión acá es una mie... y por eso no puedo disfrutar de los trabajos. >:( >:( >:(

Felicidades a todos los participantes. XD XD XD

El simple hecho de terminar un proyecto y presentarlo merece respeto. ;D

148

Noticias / Re:[Concurso] CONCURSO CGM 2012 ¡FECHA LIMITE!

Diciembre 14, 2012, 06:00:50 PM

Cita de: shaoran en Diciembre 14, 2012, 05:48:01 PM
En Breve estare el tema con los enlaces para poder Jugar y Votar dichos juegos.

Saludos makero shaoran:

Gracias por responder, esperaré entonces. XD XD XD

149

Noticias / Re:[Concurso] CONCURSO CGM 2012 ¡FECHA LIMITE!

Diciembre 14, 2012, 05:34:21 PM

Saludos makeros:

Disculpen, pero no logro ver donde están los trabajos para jugarlos y votar... ???

150

Preguntas y respuestas / Re:Movimiento de sprite a lo largo de una circunferencia.

Diciembre 13, 2012, 04:32:57 PM

Saludos makero Strod:

Como bien dice mi amigo Mgbu, un "path" es una solución a tu duda.

Hace tiempo tuve la misma pregunta y experimenté con varias formas. Una de las mejores para lograr hacer desplazar a un objeto por una línea imaginaria de curvas precisas y además orientado según la dirección del movimiento es utilizar un "path". En mi caso particular divido el "path" en varios puntos, por ejemplo mil (1000) y cada uno lo guardo en un "array" bidimensional. Cada vez que vaya a dibujar, o mover algún elemento por esa línea, simplemente localizo los puntos guardados en el "array". De esta forma, a la hora de mover, no necesito calcular en cada momento la posición del elemento con respecto al "path", simplemente selecciono de puntos ya existentes. Creo que es un poco más eficiente.

En caso de que necesites describir un círculo, simplemente puedes utilizar las funciones trigonométricas para localizar las coordenadas "X" y "Y" en los límites del círculo. Aun así, siempre recomiendo que es mejor guardar los puntos a utilizar que calcular a tiempo real cada posición en el momento.

Espero resuelvas la duda, de lo contrario, sigue preguntando que estamos para responder... ;D

...

8 9 10 11 12

...