No announcement yet.


  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    To get back on topic...

    I don't necissarily think that mountains need to be more than a single tile, but they should be restricted to 'grouping'.

    It is not very often that you single a single mountain in the middle of a plain. Instead we see clusters and ranges. Meaning, if mountains appear on the map, they should generate in a cluster of at least four tiles, or a range of at least three tiles.

    As for unit scale, I agree with most others, the default cIV scale is awful. CivII seemed to have it about right.


    • #17
      Originally posted by Sn00py
      I just want you all to know that the bigger the mountain, the more we can do with it, (more resources per mountain/hill, fortress, lookout, gunneries, etc).
      Are large mountain really so relevant in game mechanics? I mean, not so much happened (on a civilization scale) on mountain.

      Battles? Explorations? Yes. But empires needs grassland, plain and probably a better use of hills as resources for food, wine, tobacco, coffee luxury.

      A fluid model to create and show chain of hills and mountains will do the job, IMHO, better than a single "larger than a tile" mountain.

      On the unit scale, I have the feeling that the right scale for units depends from the use of them as "status bar" or not. If, as in Civ 4, you use the number of soldier showed as an implicit "strenght status" you must show them large enough to be counted at a glance.

      If you want an epic feeling you must "zoom out", reducing units dimension compared to cities (and some CIV IV screenshot available show this level of zoom), but numbers are lost.

      Animated mill, farm, etc. have similar trouble: if you use animation to show terrain worked you have to keep buildings large enough that animation is visible. I'd prefer a "grayed out", a bit ruined or subtly incomplete static version of the mill and a coloured (but static) version for worked tile.

      I suppose the "grayed out" style can mix well with "fog of war" effect: if the enemy tile is out of you sight you can't really know if it's worked or not.

      I keep remember myself: in Civ the map *IS* the territory, so you must be really carefully with too much realistic enhancement, if you end losing the game info into the process.
      "We are reducing all the complexity of billions of people over 6000 years into a Civ box. Let me say: That's not only a PkZip's a real 'picture to Jpeg heavy loss in translation' kind of thing."
      - Admiral Naismith


      • #18
        no giants in game

        IMO unappealing
        anti steam and proud of it

        CDO ....its OCD in alpha order like it should be


        • #19
          Well, if you are concerned about people and numbers (i.e., there are exact numbers of citizens in cities--not approximations), units should be made of variable sizes (and when stacked, my next idea applies especially).

          What I mean is...they should be smaller units--but there should be quite a few of them. When you decide five soldiers = the graphical representation of a unit or whatever, it gives a grander picture.

          So, if a person stacks or makes an army, those units should then look like a horde of soldiers all going for the enemy.

          Of course...that might be a little hard to draw...but...yeah...


          • #20
            how big of a group is too big?

            I think the largest stack I moved was 18

            what about a different style helmet or other design to designate 10 units in that if you have 35

            3 red helmets anf 5 regular
            anti steam and proud of it

            CDO ....its OCD in alpha order like it should be


            • #21
              I'd rather have rectangles with abstract symbols than fancy graphics. This isn't an arcade game. But that's just me...
              (\__/) Save a bunny, eat more Smurf!
              (='.'=) Sponsored by the National Smurfmeat Council
              (")_(") Smurf, the original blue meat! © 1999, patent pending, ® and ™ (except that "Smurf" bit)