Gameplay Survey 2: Army Structure.

This week’s survey will wrap up our questions about units and armies and after tabulation work can begin on the Create Army Module. General Staff is a simulation of 18th and 19th century warfare. We hope to use the same engine for an Ancient and Modern wargames as well.

We have just three survey questions:

What unit types should we include in the Create Army Module? Armies will be created by clicking and dragging unit icons from a pallet; consequently we need to know in advance what the ‘pre-designed’ unit types will be.

Will the armies have a hierarchical structure (e.g. Division → Brigade → Regiment) or a ‘flat’ structure (i.e. units do not belong to a superior command structure but, rather, can be given orders without consideration to other units).

What is your preferred screen resolution? We’re thinking of writing for 1440 x 900 resolution. Does anybody have a problem with this?

6 thoughts on “Gameplay Survey 2: Army Structure.

  1. g

    1. So a pallet like “infantry regiment, 6 companies” or “cavalry squadron, sabre/carbine/lance” or “12lb gun battery, 4 guns”? I’m 1920+ gamer, so I might be nerfing those, but in general, I think the more you let people make/play the game they want to (i.e. options), I think the better off you’ll be in general. So in context of this game, maybe four major categories: infantry, cavalry, artillery, and “auxiliary”, which would be signal units and logistics and medical staff, etc., with various sub-units relevant to the time period underneath.

    2. I prefer hierarchical.

    3. 1980×1020, and have been for many years now. Any lower than that, and I’d be kinda ornery.

    Reply
    1. EzraSidran Post author

      Thanks for the feedback. You’re running a higher resolution monitor than I am. I’ll have to look into that.

      Reply
  2. Brett Bayley

    What unit types should we include in the Create Army Module? Armies will be created by clicking and dragging unit icons from a pallet; consequently we need to know in advance what the ‘pre-designed’ unit types will be?

    With a Napoleonic era or earlier game. Nation specific troop types should be considered. Within nations defining a Dragoon or a Cuirassier as heavy cav. would be OK but the 2 had very different weapon types, numbers and uses. This all depends on how much research you want to do, how much detail you want to simulate. If this is just going to be a basic block fighting game with a strength/Morale?Maneuver number you will be fine with just the basics. However the inner historians in us love the detail. Since the graphics aren’t going to be at a Total War level, and you are replacing miniatures on a war-gaming table. The need for flavor increases, to draw and keep the interest of the player.

    Looking at some of the computer analysis you’ve done in the past. Simple rules can lead to a realistic analysis of a situation and a good, AI output. However as you build the engine, would the results not get more accurate and the AI become more challenging if its analysis was more complete from a more complete input of information. I guess what I am arguing for is add complexity and get the AI to be robust as possible in crunching the numbers to output the most desired result on its flowchart decision chain to effect a realistic result.

    Will the armies have a hierarchical structure (e.g. Division → Brigade → Regiment) or a ‘flat’ structure (i.e. units do not belong to a superior command structure but, rather, can be given orders without consideration to other units).

    Depending on the size of an engagement, the player is going to want options to utilize both options. From detatchin cavalry to operate independently as scouts. Sending out skirmishers from the line etc.

    Another thing to consider when a messenger is sent is whether the messangers path allows him to be intercepted terrain to be traversed etc. Some of this can be done by taking the most likely path and using terrain modifiers in a percentage roll to determine chance of success or times.

    Hierarchical structures allow a bigger picture role of generalship, like in Graviteam Tactics, but as you can in that game, micromanagement of individual squads is allowable with conditional modifiers in place (morale, leadership, under fire etc).

    What is your preferred screen resolution? We’re thinking of writing for 1440 x 900 resolution. Does anybody have a problem with this?

    Consider allowing the game to play in windowed modes to allow it to be played on the widest number of displays possible. The display market is on the cusp of changing from 1080p HD displays into the 4K resolution range. Don’t limit your market by restricting the game to be played in one resolution.

    Sorry about the long posts. Feel free to ignore the ramblings.

    Reply
      1. Brett Bayley

        Level of detail. Its a subjective experience. Flight sims are heavily dependent on physics to provide a realistic experience but does a combat AI need to be? Of course not. On the one hand simple tables like the original Kriegsspiel provides allow for a perfectly functioning game. However there is an argument that a more challenging AI experience can be provided by a more stat heavy game.

        Command: Modern Air Naval Operations (successor to Harpoon) does something like this, with a stat heavy back end, but the user Interface is clunky and doesn’t make for a good learning curve for a player. In tabletop games take a look at https://boardgamegeek.com/boardgame/37998/carnage-and-glory-ii where the same concept of complex factors being auto resolved by a computer to provide realistic outputs. However since its a tabletop aid it lacks any gameification or display.

        Modern military intelligence preparation of the battlefield is extensive and complex. The battlefield needs to be defined, threats evaluated, doctrines, tactics, goals, areas of interest, threat course of action, weather, all taken into account, as well as wargaming :), to define a plan of action. Information and details are the life blood of this input and the more detail you have the quicker a commander can adjust his OODALOOP to a changing battlespace. Similarly the AI will be continually receiving the same type of information and reacting to it.

        The COA from the IPB is only as good as the inflow of intel. Which is why I would argue that the more detailed the better the simulation and the better the experience. However the downside to you the developer is, not only programming the delays to delivery of information, and flow charts modelling doctrine for the decision making process, but the more risk there is of something going wrong and the amount of time it will take to chase down and debug where your quirky, erroneous result is coming through.

        Enjoying the progress and direction you have been going with this.

        I remain yous etc.

        Reply

Leave a Reply

Your email address will not be published. Required fields are marked *