CM Strategic Layer Computer Software.

[Bamse]

My last post on the CMSL was somewhat blurry and I hope that this subject will be clearer

I'm writing a Totally Computerized campaign game on the strategic level. The Tactical combat will be solved in combat mission. Some of you might ask how that is possible without knowledge of the savegameformat. It is possible with some difficulty.........BTS is finding it hard to motivate a load/save to textfile feature because there is no Campaign game out there. But if there is a working SL with both manually purchase and Load/Create txtfile feature that people use.........it's a completely different question then (I think).

http://www.mycgiserver.com/~elfbj97/CMSL_ALPHA.JPG

What (basic) features would you expect from the CMSL:

-wego

-TCP/IP

-Load/Create textfile (that CMBB hopefully will support in a later patch)

-Merge depleted squads.

-Tools for Campaign making (mapmaking tools, unit purchase and more.....)

This could be added indefinitely with things like

-Prebombardment with artillery

-supply

-building fortifications/Bridges

What I'm wrestling with now is an accurate moving model, the pieces are moving perfectly but i must decide how! My first thought was to give mechanized units the capability to move 2 hexes and non-motorized units the ability to move 1. That would be a serious design flaw on something as important as movement.

my present idea(not fully implemented, but almost) is to subtract from a units 60 minutes (one turn in CM tactical layer 60 seconds--> CMSL one turn 60 minutes)

private int maxspeed = 15; //THE UNITS MAXSPEED IN KM/H

private final static int tacticalmapsize = 5000; //meters*meters

private final static String moving_at_speed_StringArray[] = {"Carefull","Normal","Fast","Reckless"};

private final static double moving_at_speed_IntArray[] = {0.3,0.5,0.7,0.9};

private double movingatspeed[];

private final static double terrainmodifier[] = {1.0,1.2,1.5,1.7,2.0};

private double time=60.0; //minuter till godo

so if a unit at first move from HEX 6,7 to hex 6,8 in Fast speed that means that (15*1000/60*0.7)/terrain modifier 1.1 (meters/minutes at 70 % of maximum speed/the present terrain modifier in this case 1.1) in a 5km*5km map would have consumed 31 minutes. Is this model accurate enough? If someone have suggestions, different approaches, please respond.

I would appreciate if any response to this (if any) is short. Time is in short supply, even shorter after I have started this CMSL thingi....

/Björn Elfström

PS. My native tongue is not English so any comments on that have to be written in flawless Swedish DS

[dima]

Idea sounds great ! Does it mean you will still need to understand structure of Savegame ? If so, just make sure you don't live in good old US of A otherwise you'll have DMCA violation law-suite on your A*S in no time.

[ February 25, 2002, 06:53 PM: Message edited by: dima ]

[Bamse]

I'm not going to do anything illegal. No I don't want the savegameformat. I wan't CM to be able too read my(or any outher) txt style file format.

/Björn Elfström

[dima]

I was just kidding, forgot smiley

[Captain Wacky]

The idea sounds great, but it only took one look at that stuff you wrote for me to realize my programing skills, which are virtually non existent-no, just non existent, aren'y quite up to helping you out. Good luck though!

[JAK]

If this is for real then all I have to say is go swede go! Thanks and good luck!

Jake

[Larsen]

There are a few things to consider. First is what scale do you want to permit for your operation. There are two types of campaigns:

1. Operational level. Each side has a huge number of untis (preset) that battle on a map consisting of huge number of smaller maps of CM scale. Either side cannot produce new units but rather utilize those that it has in the beginning of the campaign.

2. Strategical level. Each side has some number of units in hte very beginning. The number could be eitehr large or small. That is of no importance. The important thing that each side can either produce new units or buy them. There are some resources involved that have to be managed and so on.

This two campaign are significantly different. The first one does not have any resource managment and one has only rely on the units it has in the very beginning and in the otehr on each side can decide which way to develop its army and how to manage the available resources to win.

There is yet another thing to consider -that is the scale of the campaign and thus the number of units involved. That will detemine how large you will need the map, how large will be the maps for the tactical battels and how fast the reserves can arrive.

The scale is very important. Basically it determines charactristical lenght at which the units will be affected by the current tactical battle. For example if you decide that each sector represented by a hex in your map has the characteristical length of 10km and the tactical battle say has a characteristical length of 40 minutes you will not need to consider the infantry reserved that are not motorized at all because they will not be able to come from the adjacent cells unless motorized. Of course motorized units will have a different correlation length than non motorized ones.

Larsen

[JAK]

Bump!

Jake

[Louie the Toad]

Bamse, I am excited !!!!

Your attempt has been anticpated by many as the solution to these questions: Why are we fighting HERE? Why is that hill important but not the bridge? I maight as well fight to the last man. Right? Withdraw? Why should I ? Etc, etc, etc.

I suggest you keep the CMSL (Strategic Level) very, very simple.

I think you should stay clear of anything to do with the production of units, possibly even the supply of units (although fighting for supply areas can get nastily exciting).

Someone above was writing about distance and time scale and the ability to get reinforcements into a battle, this is very important.

I think many players want to have:

Meeting engagements that lead to something else, either advances or retreats or assaults.

Probes that actually are useful in discovering the enemy.

The ability to run away to fight another day in another place.

The ability to have interdiction battles where your squadron of whatever is attacking an enemy rear position or a supply column.

And other stuff that will be mentioned in this thread by other Forum members.

I would say that most if not all players want the CMSL events to be decided by the tactical battles in CMBO and CMBB and so forth.

This is going to be very difficult when you also consider air power.

Coming from a board gamer background there are probably several out there that can be researched that may help keep you from reinventing the wheel.

My own suggestion would be to look at the workings of Blitzkrieg by Avalon Hill. Now out of print. I am sure there are some others (probably more suitable) that members of the Forum can suggest.

It is just that keeping it very simple will help to keep CMSL from becoming the game itself.

If I had the time and the funds to work on this, well, I would be talking to you about doing the computer programming part.

My last urging is to try 'thinking out of the box, or out of the hexagon', as the case may be.

My toes are crossed... Louie the Toad

[Midnight Warrior]

I would suggest that you might look at the John Tiller Panzer Campaigns series for general ideas.

http://www.hpssims.com/Pages/Patch_pages/Patch_panzer_camps/Patches_panzer_camps.html

Also you might look at Shrapnel Combat Command series for ideas.

http://www.shrapnelgames.com/boku/cc2_danger/

Both of these would beclose to your scale.

[Grisha]

Have you considered making use of the QJM algorithms developed by the Trevor Dupuy Istitute? They may come in quite useful for determining movement rates, and basic non-combat attrition. I believe it also addresses the effects of 'friction', or the corelation of combat with movement.

Do you intend on allowing players to determine the overall scale of the game?

[FinnN]

For your text files, can I strongly recommend you produce them in XML format. This would be ideal for computer processing and the sharing of this data across different systems, but still be readable for humans too.

Have fun

Finn

[JAK]

Hey bamse! When are you thinking of releasing this? How far from finished are you I mean?

Jake

[Urban Shocker]

Bamse,

The answers to many of your questions could probably be found here.

http://www.combatmission.com/CMMC/Academy/academy.htm

Since the CMMC guys have thought about all of these issues. Some of them might even be downright helpful. No sense in reinventing the wheel, as the saying goes.

[Jeff Duquette]

Bamse:

Very cool idea, and I hope you push forward with it. Some of us would like to see the game add some strategic\operational context. Have you tried contacting BTS directly?

Regards

Jeff Duquette

==================

P.S. Grisha…be sure to incorporate QJM multipliers for German Unit Combat Effectiveness vs. Soviet units.

[Wolfpack]

Hehe...looking at the alpha picture there, I see a "Regret Move" button...I can't tell you how many moves I've regretted making playing CM. If you get this done and out, I'd love it. I'm one of those people who likes a good (Great) tactical game like CM, but I really really enjoy playing in the "Big Picture" too.

[Midnight Warrior]

I second the nomination to use XML for your text files. That is the direction the wargamming industry needs to go IMHO.

[ February 26, 2002, 10:29 PM: Message edited by: Midnight Warrior ]

[Grisha]

Originally posted by Jeff Duquette:

Bamse:

P.S. Grisha…be sure to incorporate QJM multipliers for German Unit Combat Effectiveness vs. Soviet units.

Jeff, whatever are you talking about? CMBB would handle all the combat aspects. My suggestion was only meant to facilitate calculation of maneuver between or after contact, as well as logistical concerns. But, you knew that - you bum

[Urban Shocker]

Bamse,

If those are divisions in your image the scale is too big. I would think a battalion is as big as most people want to play. On a 4 sq. km map, too many units will bog down the computer. A "stacking limit" of a battalion of infantry + armor + arty, etc. is probably a good starting point.

The "hex sizes and thus, map sizes can be adjusted to this fact. I read that a WWII American battalion could be expected to hold between 1-5 km of frontage depending on the situation.

Does this seem appropriate?

What about people who have or are running campaigns "manually" do you have any guidance for Bamse?

[ February 27, 2002, 12:53 PM: Message edited by: Urban Shocker ]

[M Hofbauer]

first of all: very very commendable!

terrain modifers a must have. different weather will modify the basic terrain modifier, for example, open steppe with a basic terrain movement value can become wet and muddy, or snowy, or frozen, with new terrain movement values.

lastly, I hate XML. My computer doesn't like XML and SGML. Seems there is always s.th. going wrong with the dtd files or some headers get jumbled whatever. Besides, a text that is 5k in plain *.txt will get enlarged to 10k in that xml and sgmal stuff.

Can your Macs not read plain *.txt or some sort of rich text format ?

[FinnN]

Originally posted by Midnight Warrior:

I second the nomination to use XML for your text files. That is the direction the wargamming industry needs to go IMHO.

I think it might be worth mentioning why XML is a good thing. Basically XML in itself doesn't do anything, all it is is a standard way of defining how something is described. Once something is in XML format it becomes easy to reuse and connect to all sorts of other systems that can understand XML - even if the description is different it can be 'transformed'. Let's say you had a strategic game, it could use one definition for all its bits and pieces, that could then be transformed into a definition that could be used to generate games for a tactical level game - or into an engine that calculates results or whatever. This might sound a bit theoretical at this point, but I'm aware of at least one other strategy game in development that uses XML and I bet others will follow.

And it's no more difficult to write an XML file than it is to write any other text file - or to get it working. If you're not having a good experience with XML then it's a problem with whoever wrote those files. It's a bit like saying HTML is responsible for all the rubbish error ridden websites out there...well...maybe...

Have fun

Finn

[SenorBeef]

I brought this up a while back here. BTS weren't friendly to the idea of exporting battle results into a text file. I tried searching for the thread, but I can't find anything I've ever posted here - it looks like they lost or reset the database since I last posted here, which was several months ago.

[Talon xBMCx]

Ill third the nomination for XML. Im in the process of writing a gaming tool for another game using XML on the backend. Im using at as means of storage as well as for front end display.

One of the many things going for its use is that it is usable across multiple platforms.

Its query-able like a database without all the overhead, its fast, smaller in size ... and less likely to corrupt.

Finn has it right. Problems with xml is the developers fault.

Talon

[SenorBeef]

Spoke too soon, just found it in the archives:

http://www.battlefront.com/cgi-bin/bbs/ultimatebb.cgi?ubb=get_topic;f=16;t=019304

[kipanderson]

Bjorn,

I am very much on your side. Best of luck, and if you are able to find the time to finish your project, I will want to use it.

All the best,

Kip.