¿Cómo simplificar el código o un mejor diseño?

Question

Estoy desarrollando un juego, el juego tiene un modo diferente. Fácil, Normal y Difícil. Por lo tanto, estoy pensando acerca de cómo almacenar el modo de juego. Mi primera idea está utilizando el número para representar la dificultad.

Easy = 0 = normal 1 = Difícil 2

Por lo tanto, mi código tendrá algo como esto:

switch(gameMode){

case 0:
//easy
break;

case 1:
//normal
break;

case 3:
//difficult
break;

}

Sin embargo, creo que tiene algunos problemas, si añado un nuevo modo, por ejemplo, "extrema", necesito añadir caso 4 ... ... no parece un diseño gd.

Por lo tanto, estoy pensando en hacer un objeto de modo de juego, modo de juego es diferente y subclase de la clase super modo de juego. El objeto modo de juego es algo como esto:

    class GameMode{
    int maxEnemyNumber;
    int maxWeaponNumber;
      public static GameMode init(){
         GameMode gm = GameMode();
         gm.maxEnemyNumber = 0;
         gm.maxWeaponNumber = 0;
         return gm;
      }    

    }

class EasyMode extends GameMode{

      public static GameMode init(){
         GameMode gm = super.init();
         gm.maxEnemyNumber = 10;
         gm.maxWeaponNumber = 100;
         return gm;
      }    
}


class NormalMode extends GameMode{

      public static GameMode init(){
         GameMode gm = super.init();
         gm.maxEnemyNumber = 20;
         gm.maxWeaponNumber = 80;
         return gm;
      }    
}

Sin embargo, creo que se parece demasiado "voluminosos" para crear un objeto de almacenar modo de juego, mi "modo de juego" solamente almacenar diferentes variables para la configuración del juego .... Es esa la forma sencilla de almacenar datos sólo que en lugar de hacer un objeto? THz u.

Answer 1

creo que está intentando representar una tabla de datos de configuración. O bien poner esto en un archivo de configuración si utiliza un lenguaje que soporte eso, o utilizan datos literales en el código.

Por ejemplo, puede escribir esto en C:

typedef enum difficulties {
  DIFFICULTY_EASY,
  DIFFICULTY_MEDIUM,
  DIFFICULTY_HARD
} difficulties;

struct {
  int max_enemies;
  int max_weapons;
} difficulty_settings[] = {
  {10, 4},
  {20, 5},
  {30, 6}
};

Y cuando se quiere leer un ajuste en particular, por ejemplo max_enemies para el nivel fácil, entonces se puede writedifficulty_settings[DIFFICULTY_EASY].max_enemies

Es fácil añadir más de configuración (ya sea más parámetros, o más niveles de dificultad) mediante la extensión de la tabla.

Answer 2

El objetivo primordial que debe tener aquí es centralizar la lógica para recuperar los valores relacionados con los diferentes niveles. Al proporcionar un lugar donde se almacenan estos valores, se minimiza el número de lugares dentro del código que necesita cambiar si se agrega otro nivel, añadir otros valores, etc.

interfaz de clase A es una opción buena para esta solución. Sin embargo, si usted tiene un número limitado de opciones de configuración representados por la clase, no hay ninguna razón que necesita para utilizar la herencia. Puede comenzar con una sola clase que encapsula la lógica. Si el resto de su código recupera su configuración a través de la clase de interfaz se puede introducir posteriormente un diseño más complejo, como subclases para cada modo, si se hace necesario con modificaciones limitadas al resto de su juego.

Por ejemplo, una primera aplicación puede ser algo como

enum mode {
    MODE_EASY = 0,
    MODE_NORMAL = 1,
    MODE_DIFFICULT = 2,
};

class gameSettings {
    public gameSettings(mode GameMode) {
        m_mode = GameMode;
    }

    public int getMaxWeaponNumber() {
        int maxWeaponNumber;
        switch(m_mode) {
            case EASY_MODE:
                maxWeaponNumber = 100;
                break;

            // Other mode settings.               
         }

         return maxWeaponNumber;
    }

    // Other game settings....

    private mode m_mode;

}

Esto combina la sencillez de una sentencia switch () con los beneficios de una interfaz de clase. También puede intercambiar su interruptor () comunicado con una tabla de búsqueda, según lo sugerido por otro cartel, o algún otro mecanismo de acuerdo con su aplicación.

Answer 3

No sé java (que es lo que sus ejemplos se parecen a), por lo que presento mis ideas en algunos simples C #.

Esta es una idea. Utilice el modo de juego como una bandera en su lugar. Si usted comienza con:

[Flags]
enum GameModes
{
    Unknown = 0,
    ModeA = 1,
    ModeB = 2,
    ModeC = 4,
}

Ahora usted tiene niveles 1-7 disponibles.

GameModes Difficulty = GameModes.ModeA | GameModes.ModeB;    // difficulty = 3
GameModes Difficulty = GameModes.ModeB;    // difficulty = 2

Además, cualquiera de los métodos que mostró le requerirá para añadir más opciones debe niveles (modos) de cambio, conseguirá agregado, etc., tienen sus plantillas en modo de lectura a partir de XML (u otra fuente de su elección), excepto los datos de modo de en una clase serializable. No creo que usted debe necesitar clase base ampliada por nada.

Answer 4

El uso del enfoque del interruptor en el constructor de la clase GameMode.

Answer 5

Además de algunos problemas de sintaxis, creo que estás en el camino correcto. No creo que haya que preocuparse acerca de la memoria, teniendo en cuenta que es probable que sólo un modo a la vez. Esta es una forma de la estrategia patrón . Se podría extenderlo por lo que los modos de hacer más. Por ejemplo, en lugar de, básicamente, sólo la celebración de las constantes, tal vez podría haber un método generateEnemies que en realidad crea un conjunto o lista de enemigos. Esto mueve más de la estrategia en el objeto de modo. configuraciones normales en la superclase pueden ayudar a evitar el código redundante.

Answer 6

Su difícil decir qué tipo de refactorización se podía hacer aquí, ya que es demasiado menos información acerca de otras clases. Sin embargo, se puede comprobar la patrón Estado que encapsula diferentes comportamientos en diferentes objetos de estado. Su enfoque de extender una clase GameMode base es muy similar al patrón de estado. Creo que es mejor que un switch de los casos de bloque ... y los patrones son formas confiables de hacer las cosas, si bien aplicado.

Answer 7

¿Por qué cree que el interruptor es más difícil de MANTENER? Si se agrega otro modo, el usuario tiene que agregar código, no importa qué solución usted emplea.

El único caso que se me ocurre donde no tiene que agregar código si se agrega otro modo es si genera los parámetros del juego a partir del valor de gameMode.

Por ejemplo: maxenemy = 5 * gameMode;

creo que a menos que haya muy complicado para llevar a cabo la inicialización de un interruptor es más que suficiente. Lo sé, lo sé, los objetos y las clases son agradables y todo eso, pero si sólo tiene que definir unos VARs y la cosa funciona, invertir tiempo en el desarrollo de una clase de modo de juego complejo puede no ser una solución gratificante después de todo (I , cuántos modos de juego medias que están planeando agregar?).

Answer 8

Hacer uso de la estrategia patrón .

En términos de Java:

public interface Strategy {
    void execute();
}

public class SomeStrategy implements Strategy {
    public void execute() {
        System.out.println("Some logic.");
    }
}

que se utiliza de la siguiente manera:

Map<String, Strategy> strategies = new HashMap<String, Strategy>();
strategies.put("strategyName1", new SomeStrategy1());
strategies.put("strategyName2", new SomeStrategy2());
strategies.put("strategyName3", new SomeStrategy3());

// ...

strategies.get(s).execute();