creacion y manipulacion dinamica de objetos

[rulovive]

buen dia, yo programaba en c++ varios juegos, y creaba objetos como personajes multiples y los movia todos al mismo tempo (úsese de ejemplo los personajes del monopoly, los cuales eran creados de manera dinamica en tiempo de ejecucion dependiendo cuantos personajes se escogian al iniciar el juego, y todos eran iguales, excepto por el color), y los movia conforme al dado y así, pero en c# estoy muy confundido. ciertamente puedo crear objetos de tipo personaje pero... como hago para crear muchos en tiempo de ejecucion, o mas bien, como le hago para moverlos a todos en tiempo de ejecucion, es decir, para que con el pulso de la tecla de direccion yo asigne cual de todos los objetos creados se va a mover?

[Serapis]

Hablas de 'objetos', 'todos ellos', luego tienes necesidad de una colección. Cada uno tendrá un índice asignado, tanto en la colección como en correspondencia con la interfaz. Y como hay varios y quieres mover uno, estamos hablando de 'uno seleccionado', el 'acutal', luego en tu colección sería conforme mantener una referencia al actual. ...y ese será el que se mueva.

Al hacer click sobre uno lo seleccionas, y :

Código [Seleccionar] Expandir


coleccion de personaje s_Personajes
entero      s_IxActual
personaje s_PjActual


funcion Ventana_click(x,y )
    // dadas unas cordenadas de click, devolver el índice dle personaje. Devolver -1 si no hay personaje
    entero indice = IndicePersonajeEnCordenadas(x,y)

   Si (indice>=0) luego
       Si (indice <> s_IxActual ) luego
            s_PjActual.Grafico.QuitFoco  // el que era actualmente selccionado, pierde el foco
            s_IxActual = indice
            s_PjActual = s_Personajes(s_IxActual) //seleccionar como actual el personaje cuyo índice se ha seleccionado.
            s_PjActual.Grafico.SetFoco  // dibuja bajo él una sombra para indicar que es el seleccionado actualmente (algo visual).
       fin si
   fin si
fin funcion

Al pulsar el teclado, las flechas de dirección moverían el gráfico asociado al personaje... se supone que tienes un sprite y por cada plsación tu decides si cambia un solo frame o varios o según el caso...

Código [Seleccionar] Expandir


funcion teclado_Up(entero key)
   Si (s_IxActual >= 0) luego  // si hay algún personaje seleccionado
       Seleccionar key
           caso KeyUp
               s_PjActual.Grafico.Subir
               pararseleccion // break
           caso KeyDown
               s_PjActual.Grafico.Bajar
               pararseleccion //break
           caso KeyRight
               s_PjActual.Grafico.Avanza // a derecha
               pararseleccion
           caso keyLeft
               s_PjActual.Grafico.Retrocede // a izqierda
               pararseleccion
           caso keyHome
               s_PjActual.Grafico.GoToHome // regresa al inicio
               pararseleccion
           caso .... etc...
               // ...
       fin seleccion
   fin si
fin funcion

También podría haber momentos o acciones en los que todos se muevan o solo algunos... si son solo algunos decide cuantos y cuales al azar... y o bien los mueves hacia una dirección específica desde la actual donde están (persiguen), o bien siguen la ruta que llevan (deambulan)

Código [Seleccionar] Expandir


// Cuantos: decide cuantos se mueven: -1=todos. 0=todos excepto seleccionado.
// Cuales: Solo se aplica cuando todos >0, e indica si se eligen al azar, si los que cumplan cierta condición, etc... un valor enumerado podría dar mucho de sí (por ejemplo si los hay de colores, o definidos por 'una característica', por ejemplo 'jinetes', 'arqueros', 'lanceros', etc...
// Adonde: indica si el movimiento es de persecución (se dirigen hacia las cordenadas x,y desde su ubicación actual, o deambulan (cada uno avanza en la dirección que lleva.
// X,Y: Dirección hacia la que se mueven, si 'adonde' =true (esto es, persiguen)
funcion MoverVarios(entero cuantos, enum cuales, buleano adonde, x,y)
   nueva coleccion personajes p

 
   Si (cuantos <= 0) luego   // todos o casi todos.    
       p = s_Personajes    
       Si (cuantos = 0 ) luego  // menos el seleccionado
          p.eliminar(s_IxActual)
       fin si
   sino // algunos
       nueva coleccion s = s_Personajes.CopiaTodo
       entero k = s.Count -1
       personaje j
       entero i, n

       Seleccionar cuales
            caso 0 // random                
                bucle para i desde 1 a cuantos
                    n = random(entre 0 y k)
                    j = s.Item(n) // personaje elegido al azar.
                    p.Add(j)  // se añade a la nueva colección
                     // no queremos elegirlo de nuevo, luego lo eliminamos (de la colección intermedia copia de la original, ojo copia, no referencia).
                    s.Delete(n)
                    k -=1
                fin bucle
            caso 13 // arqueros
                Hacer mientras (n <> cuantos) y (i<= k)                                      
                    Si (s.Item(i).Tipo = ARQUERO luego)  // personaje elegido .
                        p.Add(s.Item(i))  // se añade a la nueva colección                    
                        n +=1
                    fin si                    
                    i +=1                    
                Repetir
           caso ... etc...
               //...
       fin Seleccion
   fin si

   // ahora que se tiene la colección de los que se han de mover, toca moverlos
   Si (adonde = PERSECUCION) luego
       Por cada j en s  // por cada 'j' personaje en la colección 's'
           AcercarHacia( j.Grafico.x , jGrafico.y , x, y)
            j.Grafico.Dibujar  // en su posicion x,y actual
       Siguiente
   sino // DEAMBULAN
       Por cada j en s  // por cada 'j' personaje en la colección 's'
           j.Grafico.x += j.Grafico.Dirx    // DirX= -1, 0 ó +1
           j.Grafico.y += j.Grafico.Diry   // DirY= -1, 0 ó +1
           j.Grafico.Dibujar // en su posicion x,y actual
       Siguiente
   fin si
fin funcion


Mueve un poco acercándose hacia el objetivo...
En realidad aquí no se mueve, solo se calcula la posición adonde moverse

Código [Seleccionar] Expandir


funcion AcercarHacia(desdeX, desdeY, haciaX, haciaY)
    Si (desdeX > haciaX) luego
         desdeX -=1
    sino
         desdeX +=1
    fin si

   Si (desdeY > haciaY) luego
         desdeY -=1
    sino
         desdeY +=1
    fin si
fin funcion


[rulovive]

entiendo entiendo, pero olvide decir que era en consola... varia en algo? emmm no se la verdad si se trate de guardar los objetos en un arreglo dinamico y luego mover cada objeto con el arreglo y su subindice... será igual? porque herevisado en google y salen puros resultados para c++, pero no para c#, y si no hay resultados para c# creo que debe ser porque se hace de una forma totalmente distinta no?

[Serapis]

El modo consola viene bien para ir aprendiendo sin entrar en las complicaciones del lenguaje (te deja hacer cosas sin un dominio total), pero más allá de eso, no le veo mucho sentido.

Si quieres porgramar de forma seria deja el modo consola para los principiantes... o para los linuxeros, que parece que les encanta pasarse la vida escibiendo comandos, memorizando parámetros y perdiendo tiempo en probar a ver si... me sale.

[Eleкtro]

entiendo entiendo, pero olvide decir que era en consola... varia en algo?

Si lo dices por esto:

funcion Ventana_click(x,y )

La consola también tiene coordenadas (filas y columnas), por ende la función de @NEBIRE se podría adaptar tomando como argumento las propiedades System.Console.CursorLeft y System.Console.CursorTop. Claro que nosotros no sabemos muy bien lo que tratas de hacer, me refiero, el funcionamiento/comportamiento del juego. Yo solo te comento la alternativa en caso de necesitarlo.



Más o menos como ya te han dicho, probablemente te iria bien una colección de tamaño autoredimensionable accesible mediante un indizador o indexer numérico, esto viene a ser cualquier tipo de colección dentro de los sub espacios de nombres del espacio de nombres System.Collections excepto algunas colecciones en específico (ej. Stack, Queue, BitArray y otras), y las de solo lectura o read-only; cual tipo de colección elegir dependería de tus necesidades, eso sí, no me vayas a utilizar la clase System.Array.

Luego, podrías declarar una clase o estructura para representar las propiedades de un 'personaje' o sprite, entre ellos la posicion actual, además en esa clase expondrías un método que tome como argumento una enumeración (izquierda=0, derecha=1, arriba=2, abajo=3) o diréctamente un valor de la enumeración System.ConsoleKey, y con eso determinarías la dirección de movimiento de esa instancia de personaje o sprite.

Existen muchas formas para lograr hacer lo mismo, no me atrevo a decir más por falta de datos, ya que no se te puede decir cual podría ser la forma más óptima de implementación, así que basicamente me he limitado a comentar un poco desde otro punto de vista lo que basicamente ya te comentó @NEBIRE.

El modo consola viene bien para ir aprendiendo sin entrar en las complicaciones del lenguaje (te deja hacer cosas sin un dominio total), pero más allá de eso, no le veo mucho sentido.

Si quieres porgramar de forma seria deja el modo consola para los principiantes...

Discrepo completamente, el dominio 'total' de un lenguaje no es lo mismo que el dominio de una tecnología, lo que no tendría sentido sería pensar así y empeñarse en desarrollar un programa con interfaz gráfica de usuario, cuando en realidad resulta que el programa es óptimo para darle un uso mediante interfaz por linea de comandos.

Además, Microsoft Windows y otros sistemas operativos vienen full repletos de aplicaciones en modo consola que pueden llegar a ser esencialmente útiles en el día a día, aplicaciones de todo tipo, pero sin ir más lejos: las herramientas command-line para interoperar con la shell, y desarrolladas no por principiantes precisamente... eso que dices es insultar gratuitamente a toda una comunidad de expertos en la programación.

Saludos.

[rulovive]

Discrepo completamente, el dominio 'total' de un lenguaje no es lo mismo que el dominio de una tecnología, lo que no tendría sentido sería pensar así y empeñarse en desarrollar un programa con interfaz gráfica de usuario, cuando en realidad resulta que el programa es óptimo para darle un uso mediante interfaz por linea de comandos.

Además, Microsoft Windows y otros sistemas operativos vienen full repletos de aplicaciones en modo consola que pueden llegar a ser esencialmente útiles en el día a día, aplicaciones de todo tipo, pero sin ir más lejos: las herramientas command-line para interoperar con la shell, y desarrolladas no por principiantes precisamente... eso que dices es insultar gratuitamente a toda una comunidad de expertos en la programación.

Saludos.

pensé que el manejo por consola era lo mas puro para curtirse en la programacion... digo. si no lo he hecho en modo visual es precisamente porque quiero batallar... aunque ya no se XD

[Eleкtro]

pensé que el manejo por consola era lo mas puro para curtirse en la programacion... digo. si no lo he hecho en modo visual es precisamente porque quiero batallar... aunque ya no se XD

Todo depende de como se mire. En los típicos cursos online de aprendizaje en la programación .NET (desconozco si en las universidades/clases también) se suelen dar ejercicios para resolver en modo consola, suelen ser cosas muy básicas... y quizás ese sea el motivo o uno de los motivos por los que NEBIRE opina de ese modo, pero eso no significa que todo lo que se puede hacer en modo consola sea básico, de principiante, ya que se puede hacer 'de todo' en modo consola y trabajar con conceptos avanzados de programación y programación asincrona, por ejemplo.

Resulta evidentemente que dar el salto a tecnologías como Windows Forms o WPF te introducen en nuevos conceptos que son 'desconocidos' (inexistentes) en modo consola: la interfaz gráfica de usuario, la necesaria novedad del programador para interactuar con la respuesta del usuario a los controles de la interfaz mediante los eventos de los controles, también el manejo de las propiedades de los controles, la representación visual de datos en los controles, el manejo de gráficos 2D o 3D con GDI+ en WinForms o Direct3D en WPF, también puede llegar a ser necesario aprender a interactuar con el área de notificación de Windows (SystemTray), o también con las listas de nuestro programa en la barra de tareas (JumpLists), y en fin, cosas 'gráficas' en general. En el caso de WPF también te enseña a manipular datos mediante el Data Binding basado en código XAML, y en general se aprende a separar el diseño de la interfaz, del código.
Son cosas que en una aplicación de consola pues... sencillamente no es necesario aprender ni usar (aunque si que se puede usar un Form si resultase necesario, que conste, y también se puede adaptar una aplicación gráfica para que sea capaz de tomar argumentos command-line y así evitar tener que crear la aplicación en modo consola).

Bueno, no se si me estoy desviando un poco, el caso es que está claro que desarrollar una app de consola no es lo mismo que una app gráfica, tienen sus diferencias gráficas (y solo eso, gráficas), yo me he centrado mayórmente en algunas diferencias gráficas muy notables, pero no se puede considerar que el desarrollo en modo consola sea algo solo digno de un principiante, como si desarrollar una app de consola fuese lo que deben hacer los novatos y los profesionales no deben hacerlo por que "no hay motivo necesario para hacerlo" (esa afirmación sería una falsedad), pues hay que tener en cuenta que en una app de consola se sigue teniendo acceso a todos y cada uno de los miembros de las librerías de .NET Framework... una app de consola solo se limita asimisma en aspectos gráficos por ser eso, una interfaz command-line.

Saludos.

[Tazmania40]

pensé que el manejo por consola era lo mas puro para curtirse en la programacion... digo. si no lo he hecho en modo visual es precisamente porque quiero batallar... aunque ya no se XD

Buenas, según mi opinión sobre el tema, pensaba hace muchos años al inicio que estudiar ensamblador era lo más para desarrollar juegos y de hecho incluía pequeñas rutinas por aquel entonces cuando programaba en Pascal (naturalmente corrían super rápidas). Con el tiempo y pasado los años (ahora actualizandome a VB.NET (2013-1015) el querer hacer mejores juegos te lleva a utilizar el modo gráfico y no solo el GDI+ del Visual Basic, sino el aprender otras librerias, en mi caso XNA para poder realizar lo que siempre me gusto, esos jueguecillos de los años 80 o 90, puesto que en Visual Basic o C# tenemos el problema de los tiempos de refresco cuando ejecutamos nuestro programa en distintos procesadores o Sistemas Operativos. Por ejemplo en uno de mis juegos llamado "Meteoros" donde utilizaba GDI+ aunque realicé una rutina de tiempo para calcular al principio la velocidad de procesador, no era del todo exacta al probar en un Pentium IV, dual core o I5 o bien en un SO Windows 7 o Windows XP (SP3). Por ello me decante por XNA para Visual Basic 2013 que como bien sabrás esta hecho para C# donde sin problemas soluciona los tiempos y la manipulación de los gráficos.

Aunque como dice Elektro si ha ti te hace ilusión seguir programando en modo consola, pues sigue así, yo por ejemplo XNA esta obsoleto pero me soluciona lo que siempre he querido. Ahora estoy aprendiendo a realizar algun juego estilo hibrido Windows Form y XNA; así aprovecho las caracteristicas de los controles de Windows Forms con el Game Loop que se ejecuta en XNA (60 veces por segundo) para dibujar al mismo tiempo mis objetos y que se muevan a la misma velocidad aunque cambie de procesador o sistema operativo.

Saludetes