2) Skill Revision. Having gone over the arguments of how to model skills
MANY times in the course of designing role-playing games and having
discussed this issue with many people including someone persuing a
graduate degree in education, I do not feel you are going to come up
with a simple "playable" skill system that accurately models all
learning realities. The best you can hope for is a system which
gives the EFFECTS you are looking for while remaining simple to use.
The current system is based on having an "area knowledge" (i.e.
Forestry, Equestrian, Construction) with "tasks" you can perform
in that area. The "task" concept is very important for the player-
game interface because orders must be given reflecting what task
a unit will perform. I feel the "area knowledge" concept is important
as well, not only because it binds the skills into logical groupings
but also because it dishes out the "tasks" in a logical progression
from simple to complex. I don't want to see a newly formed unit
pop up learing how to build galleys from the break, just because
they know the skill number. I don't really see anything wrong with
the current system. The EFFECTS it produces are that as you get more
knowledge in a skill area, you learn more tasks and get better at
them. I think that is a reasonable model at the EFFECTS end. As
for interconnecting skills, I think it is an unnecessary complexity.
If you use Assassination as a model, sure you can say that you not
only need stealth but combat. But you can also say that archery
might factor in (For the Lee Harvey Oswald effect...). On the other
hand, if the assassin simply uses poison, NO other skills are required.
Stealth is ALL that is needed. There could be a seperate "snipe" task
under Archery. There is a point where you have to draw a line between
"realism" and "playability". Both are subjective so you are never going
to make everyone happy at once. One of the questions to ask here is
"does the added complexity add sufficiently to the end EFFECT to justify
it". In the case of interconnectivity, I think the EFFECT end change
is to subtle to justify it. As for levels for the subskills, I
think THAT might be a good idea since it will allow for differentiation
between 2 10th level shipbuilders. Once might specialize in cranking
out galleys and the other might crank out clippers. I see the end
EFFECT as justifying the complexity.
3) Resource Usage. No matter what you do, I feel that any replenishment
of resources should occur THROUGHOUT the month. There should be no
penalty for executing your command on day 20 as opposed to day 1. In
otherwords, I don't want to see resources replenished monthly causing
the great "use-off" at the start of every month to see who can grab the
most first.
4) Recruit dependant on money offered. Isn't this going to be competative
enough once the men available is limited?
5) Land/Structure Ownership. I really think this can be achieved simply at
first. The first unit stacked with it owns it as far as structures and
land goes. If there is one or more structures on the land, the owner
of the first structure owns it. If structures can execute commands, they
could promote other structures so if you build a castle to replace your
old tower, the tower could promote the castle. The owner of a land
or can get funds by issuing a "set tax [percent]" for the land. This
will ADD [percent] to all purchase prices in that land and will
SUBTRACT [percent] from all the sales to merchants, work, and money
making uses (such as street performing) and those funds will go to
the owner of the land. Any changes to the taxes will take place AT
THE END OF THE MONTH, regardless of when they are issued, to simply
avoid the "bait and switch" manuever, screwwing over other players, and
will appear on the location report for the location. The tax percentage
should also have a maxium you can set it to (100%?). A small basic
tax income would also be computed from the population. The owner of a
land or structure will also be able to "set display" for the place.
Structures may also have a tax set for them, applying to transactions
done while stacked with the structure and added to any taxes levied
by the land's owner. With structures you could ALSO "set fee [amount]".
A "fee" is a flat amount of money you must spend (taxed as necessary) to
stack with the structure. There would be another "set" ("set pay
[amount]") representing the maximum gold you are willing to spend to
stack with the structure. This "fee" could represent "rent" for the
stay, a user fee, or a variety of other things. Stacking, taxes, and
fees for locations and structures could be effected by attitudes in the
following manner:
Friendly - can stack, no tax, no fees
Cooperative - can stack, pays taxes, no fees
Neutral - can stack, pays taxes, pays fees
Unfriendly - cannot stack, pays taxes, pays fees (won't happen, but would)
Hostile - cannot stack - ejected (structures only) -
attacked by owner (locations only)
Note that this does not apply to unit stacks for which neutral still
would mean "cannot stack". Attitude checks for locations must be
made when the unit issues a move order and any change in attitude
will have no effect until the unit arrives in the destination. Note
that "unfriendly" will not force a unit away but will not let that
unit return. If a location or structure's attitude can prevent movement
or stacking, than it seems only reasonable that the "move" and "stack"
orders should have a way of specifying the command should be forced.
The effect of a forced stack is to attack the structure being stacked
with. The effect of forcing a move is to move to the destination and
to attack the owners. If the attacker flees, he retreats back down the
exit he or she came from. The above suggestions require the
implentation of the following:
The ownership system whereby the first unit stacked with the
location OR the first structure present on the land owns it.
Something similar is already in place for structures.
The "set display" for locations and structures.
The "set tax" option for land and structures and the corresponding
code for handling the income.
The "set fee" option for structures (I would like to see this
implemented for road exits as well, hint-hint) and the corresponding
code for handling the income. Set fee could be made "monthly"
to represend "montly rent" for stacking with structures.
The "set pay" option to specify the maximum fee a unit will pay.
The attitude systems effects on stacking with locations and structures.
The "force" option for stacks and moves (which ALSO works well for
road exits, hint-hint, and also allows one to attack an unfriendly
or hostile city from outside - the victor of any such battle is
"promoted" to ownership position).
I don't think any of the above are incredibly complex to implement and
I think the EFFECTS these suggestions would have are desirable and
workable. Constructive comments welcomed. Gratuitous flames tolerated.
John Morrow - Varian [856]