THE WAR OF THE SHIRES (part 3 of 3)
by Alan Davis
from ZX Computing Jan.1987

To battle! Alan Davis puts the last sliver of warlike code into place.


Although there's been much rumbling of thunder during the last
couple of months, there's been little in the way of real action.
The breaking of the storm is long overdue - so let's get
straight down to business.

To get yourself a "finished" version of "War of the Shires"
(finished, that is, as far as my own development of it is
concerned) all you need to do is load in the BASIC program from
last month's article and then add the program lines I've given
here (Listing 1 [see SHIRES.TAP:SHIRE3L1]). There's no need to
include the REM statements of course (since the program will run
faster without them); their purpose is purely to help you to
relate the new material to the stuff you have already. Notice
that the new line 110 replaces the old one - which was in any
case only a RETURN instruction. Once the typing is finished,
save everything to tape just as you did last month when making
your "temporary" version: SAVE "SHIRES" LINE 8000, with the map
array, machine code, and UDG bytes patched on at the end of the
tape in the correct order.

If you take a look at Listing 1, you'll see that the main
additions comprise the following:
(a) computer controlled movement of the enemy armies;
(b) a battle routine;
(c) an extension to the "explore location" routine;
(d) an extra batch of command options.

Apart from a few other lines interspersed through the program
for general "tidying-up" and "housekeeping" purposes, that's all
there is to it. In play, of course, you'll find that the Shires
are now somewhat less peaceful than they used to be...


Carnage

To see the most immediately obvious difference, load in the
game, select the "View Map" option for Roland, and press key "1"
to enter ARMIES mode. You can then, if you wish, sit back and
watch the invasion taking place as the forces of Darkness move
out from the west. Because the game runs in real-time, the enemy
armies move relentlessly even when you're doing nothing - and
the map is continually updated as you watch, with news of
battles flashed up on the screen as they occur. You can observe
the carnage for as long as you like, unless the character you're
controlling is attacked; if this occurs, the program jumps out
of ARMIES mode to give you full details of the battle.

It's worth bearing in mind that the presence of an army symbol
on the map can mean that either one army, or several, are
currently at that location; this means that if a particular army
moves between two already heavily occupied locations, you won't
actually see any change on the map.

The other important difference concerns what happens when you
instruct your current character to explore keeps or villages.
Provided the leader of the corresponding Shire has been
recruited to the cause, the local populace will assist with
provisions and extra men-at-arms (unless you have an army which
is already so large that it clearly needs no help ...). A
particular keep or village will render this service once, and
only once, because their resources are limited - but each Shire
leader can accumulate stocks of provisions and carry them with
him for later distribution to the men as required.

Once play begins, the strategy is up to you. Obviously, Roland
will need to round up as many warriors and provisions among the
freemen of Greenways as he can. Before setting off to warn the
recruits the leaders of other Shires. [sic. The previous
sentence doesn't make sense. JimG.] As play progresses you'll be
able to change continuously between recruited characters, so as
to conduct the war in whatever way you see fit.

As for the battles themselves - well, not surprisingly the
outcome of a battle is more likely to be in your favour if
you're defending a keep rather than fighting in the open. The
battles occur only between individual armies; the tactics of the
enemy are to wear down their quarry by attacking in waves, one
army at a time - so that even if several enemy armies are
present, you'll find your men engaged with them only one at a
time. Each battle takes its toll on the participants, in terms
of losses, of course, but also of stamina and possibly morale. A
heavy loss will lower morale, which is bad news - though
subsequent light losses will restore it progressively. Stamina
can be recovered either by rest, or by nourishment. The game
ends either by victory (the fall of the Keep of Darkness) or
defeat (all Shire leaders dead). In case you hadn't realised:
the Keep of Darkness is inaccessible for most of the game; you
gain access to it via the "endgame" (more of which later) when
the enemy has suffered catastrophic losses.


Customised warfare

As I promised last month, you now have a game which is readily
playable in its own right, though with ample scope for you to
develop it further. To that end, let's take a look at the
material in Listing 1, starting with the additions to the
"explore" routine. It's clear that we need the program to keep a
record of those keeps and villages which have already supplied
food and men, and an effective way to do this (though not the
most economical in terms of memory) is to have a kind of dummy
"copy" of the map. This takes the form of the array m$(22,32),
in which each array element tells us something about the
goings-on at a particular location.

When this array is dimensioned initially, all its elements will
of course contain CHR$ 32. If the resources of a particular
village or keep have been exhausted, however (or if the people
are scattered as a result of the demise of their leader), we can
arrange for the appropriate element of m$() to be changed to
some other value to record that fact. I chose CHR$ 1 for this
job - though one could use other values to store different kinds
of information of course.

Getting down to the details, then, we find first of all a check
in line 1100 to see if the current location - co-ordinates (x,y)
- contains a village or keep. If it does, then line 1105 checks
to see whether the leader of this shire is still alive and
inserts CHR$ 1 at m$(y,x) it he isn't - which, as we'll see,
prevents recruitment there. Finally, line 1110 causes villagers
to turn up with recruits and supplies provided that (a) the
leader of this shire has already been recruited; (b) the current
character's army isn't too big; (c) m$(y,x) isn't CHR$ 1; and
(d) a gang of recruits isn't already waiting here. Provided all
these conditions are satisfied, the number of recruits (chosen
at random between 100 and 255) is inserted into m$(y,x) in the
guise of the appropriate character code, and your character's
stocks of provisions (stored in a(char,9)) increased by 1.

This little lot immediately produces extra options for your
character of course; if you'd like to glance at the additions to
the "character description and options" section, you'll see that
lines 545 and 546 deal with these. And while we're on the
subject, notice that if the option to recruit reinforcements is
taken, then m$(y,x) is set at CHR$ 1 to prevent further
recruitment (line 565).

The rest of the "explore" routines, lines 1200 to 1220, concern
only the endgame in which a tunnel through the mountains to the
Keep of Darkness becomes accessible. This simply involves
setting the variable "tu", creating the entrance to the tunnel
at the location (xtu,ytu) - which varies somewhat from one game
to another - and finally permitting movement through the tunnel
when the appropriate location(s) are explored. The existence of
this tunnel, by the way, explains my suggestion in an earlier
article that you shouldn't modify the map in this region. If
you'd happened to plonk a mountain so that it coincided with the
tunnel entrance, then it would make life a shade difficult ...

The real-time movement of enemy armies is dealt with in lines
102-125. This routine is called repeatedly either immediately
after one of your own commands, or in any case about once per
second while the program awaits your desperate finger-prod at
the keyboard (see the sub-routine at line 20 in last month's
listing).

While reading what follows, remember that each enemy army is
assigned a specific "target" character, whose code is stored at
the appropriate row in the third column of the array u() - the
only exceptions being armies 66 to 70 inclusive, who have the
doubtful honour of standing guard at the Keep of Darkness.

	This is what each line does:
102: Choose at random one of the 65 mobile armies ("m"),
provided it still survives!
103: Check this army's "target" (fk); if it's already been
despatched to the Great Shire in the Sky, assign another target
at random.
110: Store the armies current location in the temporary
variables ux, uy. Compare these with the location co-ordinates
of the target, and compute new co-ordinates vx, vy which will
bring the army one location closer to its target. Move the army
to this new location by changing u(m,4) and u(m,5).
115: the array t(22,32) stores the TOTAL number ot enemy
warriors at each and every location, and obviously the program
needs to update this array as an army moves - which is what is
happening here. In addition to this, if the program is currently
in ARMIES mode, then the map graphics need updating too - which
is what the remaining conditional instructions are for.
120: If the army hasn't reached its target, this turn is
completed.
122 & 125: Let battle commence! A suitable message is flashed if
the program is in ARMIES mode, before battle is actually joined.
The variable "ind" is used to distinguish between attacks
initiated by the enemy (ind=1) and those mounted by the player
(ind=0).


Into battle

And this, naturally, brings us to what might be described as the
core of the game - the battle sequence. The same routine is used
whether the player or the enemy launches the attack - the only
difference being the entry point; battles initiated by the enemy
and taking place "behind the scenes" enter at line 2005, with
the appropriate variables already assigned by the movement
routine. When text print-out is necessary (i.e. when the
currently controlled character is involved in the rough stuff),
entry is at line 2000. The actual combat begins at line 2005,
and follows a pretty simplistic system.

Two quantities "us" and "them" (!) are calculated for the two
sides according to number, stamina, and morale (this last not
applying to the enemy) of warriors, adding an appropriate boost
to the value of "us" if the home team is defending a keep.
Losses on both sides are calculated on the basis of the
difference between "us" and "them" - lines 2010 and 2017 - with
the appropriate checks to ensure that losses don't exceed the
actual size of the army (negative numbers of men wouldn't
exactly be conducive to realism!) Line 2015 updates the tally of
enemy warriors at the location of the battle, as well as the
variable "tot" which maintains an on-going record of the total
number of enemy warriors in the entire game. The remaining lines
deal with such concerns as the destruction of a keep if its
owner is killed (line 2020); the adjustment of the morale of the
home team according to losses sustained (lines 2025 and 2030);
and the adjustment of the stamina or strength of both armies
(lines 2026/7). All that remains is the printing of any text
needed.

The rest of the program needs no explanation, I think, although
a word about the "IF battle THEN RETURN" lines might be in
order. These are necessary because we don't know precisely what
the player might be doing in the event of a sudden attack by the
enemy, and so the program could be jerked into the battle
sequence from any of several sub-routines. The "IF battle ..."
instructions ensure that the program is channelled back to
"Character description" mode at the end of a battle - whatever
else it might have been in the middle of.

If you play the game exactly as given, then with a bit of
thought and planning you could reasonably expect to achieve a
victory within about a couple of hours - though you'll doubtless
suffer some tragic losses, and things may seem desperately
hair-raising in mid-game. If you find it too easy, then probably
the simplest way of making it more challenging is to increase
the number (or perhaps the initial strength) of the enemy
armies. Personally, I don't worry too much about this side of
things. I find that the fun of this kind of game (which
incidentally is no less fun for the author to play than for
anyone else) lies not so much in the winning as in the sense of
involvement with the characters during play; a noble and
desperate defence, ending in defeat, can be just as
imaginatively satisfying as a glorious victory. This of course
is one of the great strengths of games such as "Lords of
Midnight"; and my own debt to Mike Singleton's genius is pretty
obvious!

Over to you, then. There's plenty of memory left for you to add
ideas of your own. You might like to add some adventure-style
puzzles, perhaps, to add depth to the plot. The endgame could
profit from extra ideas, since it's no more than a sledgehammer
job on the Keep of Darkness at present, and you might like to
make use of the extra character (Ulric) whom I included in last
month's listing but haven't, in fact, used.

But just a moment! What's that? The faint rumble of thunder?
Roland is donning his armour! Deepmeads has fallen! To battle!

Now where did I put that sword ...?


--
Another Fine Product transcribed by:
Jim Grimwood (jimg@globalnet.co.uk), Weardale, England
--
