Unity Community

Results 1 to 8 of 8

  1. Posts

    How do you deal with relative data? Code design discussion.

    I am building a turnbased gridbased strategy 2d game.
    I have one base TroopClass that holds all data.
    I have one base Terrain class that holds data for terrain, like which type of terrain [forrest, hill, plain].
    I have one script that handles combat and one that handles movement for troops.

    Now the TroopClass got an enum variable MovementType that can be walking, tracked, wheels or flying.
    This must affect how much movement cost and combat modifyers.

    Now the question is, if we consider only combat, where do i place information on what modfiers apply to which terrain?
    As i see it i got three options.
    1. Create a table in TroopClass that says which combat modifyer to apply to which terrain.
    2. Create a table in TerrainClass that says which combat modifyer to apply to which MovementType.
    3. Create a table in the relevant dimension, the combat script, that says which modifyer apply given MovementType and Terrain.

    I have had the convention of having all "real" data in the base classes [TroopClass, TerrainClass], but this is the first "variable" that is truly "relative" in the seance that the output is determined by two different classes.

    I personally am in favor of the third option seance the data could be considers gameplay aspect related and not pure "data". But i store other information such as MovementType, Initiative, weapons and other "real" data in the TroopClass so i am a bit split here.

    I thought it might be an interesting design discussion, give me your thoughts!

  2. Posts
    #3. Simply look up the movement cost and combat modifiers in their respective tables.

  3. Posts
    Are you sure you'll never vary by which type of unit it is as well? Maybe you have tanks that are good on mountains and tanks that are good on sand?

    If you're sure that won't happen, 1 or 3 would be my choices. Probably 1. If it does happen, 1 would probably be the best choice.

    On the other hand, you probably only want the data to exist once. Mirroring it for hundreds or thousands of units could be expensive. So maybe 3 is better after all.

  4. Posts
    Yeah i was also going with 3 intiality.
    But now that you manged we problay want special troops, like engineers or moutain troops, that can ahndle different terrain better so maybe 1 will be better. The amount of units i belvie will maxmum be around 75 for botyh players so the data is not that much i think,

    Thanks for the perspective !

  5. Posts
    #3 is still the best bet. For example, let's take troop movement through different terrain. You would create a 2D table where X axis is Terrain Type and Y axis is Troop Type.

    Simple Example :

    1. .             Terrain A     Terrain B
    2. Toop A         7                3
    3. Troop B        3                9

  6. Posts
    @Diablo: Yeah that is a good and valid table that would work excelent. Except.
    I model my troops from one base data TroopClass then i create different preFabs with different pre set values that thus define them as some sort of troops. Thus no troop is actually different from any other troops in terms of being a different class that i can check vs.

    But i guess i could fix it with a bool 2 dimensionl list/hash in the TroopClass like.
    1. SpecialClass as Boo.Lang.Hash = {enginner: true, MountainTroop: false }

  7. Posts
    But in the end there troops are different because each troop instance end up with different pre-set values, right? Simply assign each different set of troops a different id. Either that, or I'm completely misunderstanding the problem lol!

  8. Posts
    No i think you get it.
    Simply assign each different set of troops a different id
    This is what i meant with the bool hash but maybe i explained it bad. Somewhay to tell if a troops belongs to a set with different rules. Instead of just cheking against MovementType that i orginalal did.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts