13 Apr, 2013, Idealiad wrote in the 1st comment:
Votes: 0
Does anyone know of a text-based mass combat or wargame campaign simulator?
13 Apr, 2013, quixadhal wrote in the 2nd comment:
Votes: 0
An old one that we used to run, 25 years ago, was Conquer v4. It required you to run clients on the same machine, so you'd need shell access (or setup a chroot shell that can just run that), but was quite fun.

A telnet-based one was empire (wolfpack empire)… but a little different feel. Conquer was fantasy based, on large maps. Empire was modern, usually on smaller maps.

I keep thinking of rewriting conquer, but haven't motivated myself enough to do it.
14 Apr, 2013, Idealiad wrote in the 3rd comment:
Votes: 0
Thanks quix, I was able to find a tar of Conquer.

In looking around I found this article which is rather interesting,


And an old thread at Mudlab which examines things more from a player's perspective,

14 Apr, 2013, quixadhal wrote in the 4th comment:
Votes: 0
I'll dig around a bit and see if I can find my old copy… we did quite a few mods to conquer v4.10… adding things like seasons, relative coordinates (so you couldn't find each other without exploring), etc. At one point, we even added ANSI color to the display.
17 Apr, 2013, Idealiad wrote in the 5th comment:
Votes: 0
Interesting…I'd like to see that if you can find it.

I found a good blog with some articles by a computer wargame developer,


It's been helpful in thinking of what factors would affect the battles. Some of them are,

unit strength (number of fighters)

unit morale
unit fatigue (could be folded into morale)

zone of control(I think mostly an artifact of games played on hex maps)

stack percent (also related to hexes, basically how many fighters are in a hex, however useful for pass-through)

pass-through (moving a unit through another unit, like skirmishers falling back through allied heavy infantry)

formation(phalanx? skirmisher screen?)

reaction test (a morale check in certain situations, for example if an allied unit on your left wing is in rout)

One interesting question is whether to use hexes. In some sense hexes are dead weight in a computer wargame, but they are a useful interface aid for players. Thoughts on that? Let's assume we aren't using a room-based system.
17 Apr, 2013, Orrin wrote in the 6th comment:
Votes: 0
I did a very simple warfare system on Maiden Desmodus. I didn't do any research on war gaming and just pulled most of the numbers out of thin air. It was pretty quick and dirty and I never really got around to refining it, but I think it had the makings of a fun little system.

# class Unit
self.id = set.readString('id') # unique identifier
self.type = set.readString('type') # troop type - knights, infantry, scouts
self.sizename = set.readString('sizename') # squad, platoon, company etc
self.number = set.readInt('number') # actual number of troops
self.fatigue = set.readInt('fatigue') # reduces every movement, when zero will not move
self.morale = set.readInt('morale') # reduces every game month, when zero have chance to refuse orders
self.xp = set.readInt('xp') # UNUSED
self.training = set.readInt('training') # UNUSED
self.name = set.readString('name')
self.commander = set.readString('commander')
self.appearance = set.readString('appearance') # how unit appears in room desc
self.status = set.readString('status') # what the unit is doing currently
self.room = set.readString('room') # proto of room where unit is located
self.kingdom = set.readString('kingdom') # Kneyan or Thirian allegiance
self.owner = set.readString('owner') # city or cabal name
self.paid = set.readInt('paid') # increases each month unit is not paid, gives chance of deserting
self.engaged = set.readInt('engaged') # number of current engagements
self.service = set.readInt('service') # number of years service

# Mountains and high hills 20% bonus
# Hills 10% bonus
# plains 50% bonus for knights
# forest 50% bonus for scouts
# swamp gives 50% penalty to knights and scouts
# morale modifier - up to 50% penalty for zero morale
# commander present increases total modifier by 20%
# calculate final att and def mods
# calculate max troops engaged - number is split between number of engagements, with a penalty if engaged on multiple fronts
# if defenders manning a barricade they get a bonus
# for small units, double the modifier difference
# calculate casualties - each side loses men based on the number of engaged troops from the other side - base is 20%
att_casualties = max(1,int((def_engaged / 5) * def_mod * random.uniform(0.75, 1.25)))
def_casualties = max(1,int((att_engaged / 5) * att_mod * random.uniform(0.75, 1.25)))

Each unit was represented as a single mob but styled to look like multiple troops and was immune from regular attacks.

You could move units from room to room but each movement would take time based on the size of the unit with larger units moving more slowly. Unit types would get a bonus to move speed based on terrain (faster on roads, slower through swamp, scouts could move faster through forest etc) and also certain environments (city, indoors, maybe some more I forget) would have a maximum unit size that could move through them. As an example a unit of 10 knights on a road would take 6 seconds per room and a unit of 500 knights would take 255 seconds. Units could attack from an adjacent location but couldn't move into the same room as enemy units.

The basic idea was that for moving it was better to split your force into many small units but for fighting you wanted a few large units. To change unit sizes you had to dismiss troops from one unit and then muster them into another and this took 1 second per man for each operation (you only had to issue the command once and it would tick along one man at a time). You could only issue orders to one unit at a time so if there were multiple commanders working together you could do it much faster.

I wanted a system that wasn't too complicated and could work alongside the rest of the MUD and that would reward teamwork and careful planning. It was deliberately time consuming and costly as I wanted an invasion to be a major event which took long term planning.

I'm not sure how relevant any of this is to a more traditional wargaming system, but there you go :)
17 Apr, 2013, quixadhal wrote in the 7th comment:
Votes: 0
OK, I managed to dig out my old tarball from back in 2000. This was the version we ran at WMU back in 1994 that was very popular. It didn't have color yet, but had most of the goodies added. There were a few balance issues I started to address later, but never got fully fixed/working.

Flight was waaaaay overpowered. One way to limit this is to change flight movement costs so flying over water is expensive. Another is to limit maximum movement rate. Vampire was also a bit overpowered…. I had an idea there to have the population start to decay, but never finished it properly.

This probably will need fixing up to run on linux.. it worked on the linux we had in 1994, and also on sun/sparc workstations. :)


Maybe I'll tinker with it again.
I always meant to rewrite it so it used network logins, rather than local clients… the difficulty of using curses over telnet (with multiple connections) stopped me.

Let me know if anyone starts doing anything with it.. I'd love to see this become playable. It was a LOT of fun with a dozen or so players and one update per day. :)

EDIT: Oh, since you mentioned hex grids… conquer uses a square map, but version 5 (beta) had support for hex maps, which looked surprisingly good in ASCII. I have that somewhere, but the game is totally unfinished… he was adding a LOT of new features, but it got sidetracked by a commercial offer that eventually fell through. Conquer v5b28 was the last release I'm aware of… not really playable, but interesting.