Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design in skillFilters. #1

yarmyarch opened this issue Sep 27, 2014 · 0 comments

Design in skillFilters. #1

yarmyarch opened this issue Sep 27, 2014 · 0 comments


Copy link

@yarmyarch yarmyarch commented Sep 27, 2014

Basic structure of skills:

     * name {String}
     * action {Function}

How skills triggered:

on unit created

1 Create a unit;
2 Register all filters in it's skillset as filterList

for (all filters in skills of a unit as filter) {
    unit.addFilter(, filter.action);
on skills should be triggered

1 Globle filter triggered
2 if the filter(Filter) configured in filters of effects?

  • Y-> go 3.
  • N-> do nothing;

3 Find the unit{Unit} defined in the argument list;
4 The unit reacts to the filter, if it's registered in filterList.

// translate global triggered filters into unit specified filters.
for (allFilters in allEffects as filter) {
    global.addFilter(, function() {
        if (arguments contains a Unit) {


an effect may define a filter like this:

    getAttrAttack$1 : function(){};

While that means in the globally triggered filter named getAttrAttack.
There might be more than 1 params in the argument list (except for the first value in the arglist as the returned value of the filter) that is an instance of a Unit.
Just like this:

    coh.util.FilterUtil.applyFilter("getAttrAttack", value, unit1, unit2);

While it should be translated into:

    unit1.applyFilter("getAttrAttack", value, unit2);
    unit2.applyFilter("getAttrAttack$2", value, unit1);

when $1 is ignored as the default one.

$1 in getAttrAttack$1 means this effect should react the filter triggered by unit1 only.
If there is only 1 unit in the filter, $1 can be optional.

Note that only when /$\d+/ is written at the end of the filtername would be recognized.

Reasons doing it like this:

  • Skills are bind to single units that's having the same life circle with it's bind unit. Compared with another solution that, creates a global hash indexed by effects and valued by units, this kind of implements won't hold a refer to the unit that may result in a memory leak when units should be removed.
  • Easy to expand and combine, make it possible to create all kinds of unit-related skills based on available filters from global.
  • No injections to the original system without a Skill module. Global filters just work as they should be after all these rules appended.

Problems that can be optimized:

  • Hard core about something like '$1';
  • Non lazy-loading solution that all filters in skills would be scanned while preparing the system during the translating process.

Open to all suggestions.

@yarmyarch yarmyarch self-assigned this Sep 27, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant