[messages] [Module Design] Module speed

dsdhornet david.a.fenton at gmail.com
Mon Apr 28 00:24:34 CEST 2014

I have a somewhat open question regarding module speed.  Once units get
fairly complex with lots of traits, things start slowing down pretty bad
(taking a few seconds to simply move a piece, etc).  The easy answer to
this is of course...simplify things (and believe me, I've tried).

However, when you have a decent amount of logic in a unit, something as
simple as an If...Then statement requires 5-7 traits (one to trigger via
menu, two to represent separate conditions, two more to represent
actions, plus two more if you want it to report the actions taken in the
log, requiring a minimum of 3 triggers).  Having things like movement
through varied terrain (which have multiple if..then statements) bloat
things greatly.  A simple, select A or B and perform related actions
(such as send to VP stack) takes 6 actions (one to trigger, dynamic to
store value, then see above for if statement for a minimum of 4
triggers).  Something as crazy as a switch statement has even more,
which with sequential if statements, the number of triggers gets insane.

What actually impacts game speed?  Is it number of traits (regardless of
type)?  Number of triggers (so markers and calcs have little effect)?

More specifically: 
1.  Do calculated variables slow things down?  Of course they need a bit
of processing time, but does the engine have to go through them which
hunting for triggers or such?

2.  Is it better to have several DPs with simple triggers, or one DP
with more complex triggers?  An example would be 4 on-off variables. 
You could use 4 DPs with 2 triggers each, or 1 DP with 8 complex
triggers (using binary logic).  Same number of triggers and actions, but
which would be faster?

3.  For just storing fixed values (such as base Defense or base Attack
values for each unit) are Markers more efficient than DPs (without
triggers)?  Would storing things in global variables be even efficient
since it would reduce number of traits (though it'd be a nightmare to
work with when you have many unit types)?

4.  If triggers (and hunting for traits they change) are the slow point,
might it be possible to use variable / calculated triggers?  Similar to
the way you can use an expression to choose the global property in a
"Set Global Property" trait?  Then you could have one complicated
Calculated Property to use as many inputs as you want in nested if
statements to call a resulting trigger (rather than needing 3 traits for
every nested if..then).

Read this topic online here:

More information about the messages mailing list