As I've mentioned before, I'm currently working on a proof-of-
concept prototype for VG Vietnam's pacification chart.
In game, the Pacification phase consists of updating RVN population
controlled in each of 35 provinces on the basis of:
* 2d6 (DR)
* Total pop in province (TP)
* Last Turns pop controlled (LPC)
* DRMs from the board. (DRM)
Resolution entails two cross-indexes:
LPC X TP = Column number (COL)
(DR+DRM) X COL = Change in PC. (^PC) (where "^" = "delta" not
exponent.
Then
(^PC)+LPC = PC (where 0<PC<TP)
How to implement within Vassal (without learning Java)...
I wanted to share the concept before proofing it, in case anybody
has suggestions. ("Learn Java because" will be acceptable :-) )
The first step has been to build an array usable within Vassal from
a 12x17 board and a corresponding set of at-start stacks with game
pieces representing results. (Much copy-pasting and find-replacing
in buildfile.txt).
Second step will be to build a set of 35 Game pieces (1 per
province) with a series of 3-5 layer functions (2 for 2d6, 1 for
PC/LPC, 1 For COL (perhaps, this may simply be a dynamic variable),
1 for DRM (again, probably a dynamic variable). I'm struggling to
figure out how to assign COL each pacification phase -- I don't
think there's a way to avoid hard-coding 6 triggers for 11 sub-
classes of widget.
A global key command will fire a randomization of the two d6 layers.
Given Col and a Dynamic MDR (where MDR=DR+DRM), a global key command
will send the 35 pieces to locations on the 12x17 resolution board
corresponding to Column = COL and Row = MDR.
A second global key command will fire a range zero command to the
result pieces pre-arranged on the 12x17 board. The activated result
pieces will in turn fire one of 13 result commands to the Population
pieces stacked with them -- these commands will be to increment or
decrement the LPC/PC layer of the population by an amound somewhere
between -7 and +6.
A final key command will return these game pieces to their original
position on the main map.
-------------------------------------
So, the questions this raises:
* Any obvious reasons why this won't work?
* This results table will add 35 pretty complicated pieces and ~200
relatively simple pieces to the game. Is there a way of predicting
the memory load these new pieces and their associated commands will
create?
* Have I missed a more obvious way of scripting interactions between
stacked counters -- the fire/counterfire mechanic I envision seems
rather kludgy, but it results from not having been able to find a
way of explicitly passing variables between counters.
* How to generalize this? I'd like to do a combat table for VG
Vietnam as well, and given an array defined of at-start stacks,
elements of such a table become much easier to design. But I'd like
to find a way of avoiding the "hard-coded" triggers to determine the
column number-- given that VGvietnam's combat table returns losses
from a cross-index of strength and a die role, it'd be nice to be
able to march my combat widget East until it meets a counter whose
value > than its strength, then march it south a number of spaces =
to the die roll. To do this, i'd need to be able to compare one
counter's strength to another -- I have yet to find a function
allowing me to do this.
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/vassalengine/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/vassalengine/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
