Baseline data collection and DEGG goal mechanism defined.

[philipmjohnson]

Must define an approach to "dynamic baselines".

Initial proposal for the dynamic baseline algorithm:

• For any hour of any day (example: Monday at 11am), the baseline is computed as the average of the preceding two instances of that time period (example: the prior two Mondays at 11am).
• Initially, the "goal" reduction is a 5% reduction from the baseline hourly data for each day.
• If the goal is met for a given day, then the reduction goal percentage is reduced for next week by 1%, until the reduction goal reaches 1%. It cannot go below 1%.

Example:

Baseline, week 1: 1000 kWh Baseline, week 2: 1000 kWh Goal, week 3: 950 kWh. Assume the team makes it. New baseline is: 975 kWh Goal, week 4: 936 (4% reduction). Assume team barely makes it. New baseline is: 943 Goal, week 5: 914 (3% reduction). Assume team barely makes it. New baseline is: 925 Goal, week 6: 906 (2% reduction). Assume team barely makes it. New baseline is: 910 Goal, week 7: 900 (1% reduction). Assume team barely makes it. New baseline is: 903 Goal, week 8: 893 (1% reduction). And so forth.

Attributes of this algorithm:

• Over two months, a successful team will decrease consumption by 10%. Thereafter they will slowly get to their maximal reduction and then "see-saw" around it due to constant 1% goal downward pressure that is counteracted by "upward" pressure of baseline readjustment
• Intended to promote "sustainable" changes. Goal is relatively small, in order to de-incentivize unsustainable changes.
• Assumes that all teams can potentially obtain a ~10% decrease in consumption through behavior. If this is structurally not possible, then team could get "stuck" at one of the higher percentages and not be able to produce "see-saw" goal achievement.
• If a team beats the intended reduction by more than the goal, then the baseline recalculation will factor that in and they will flatten out at more than 10%.

[rbrewer]

This sounds good. I wonder if a spreadsheet showing this might be helpful for considering the different scenarios (we'll need one eventually for papers & presentations anyway)

I also think it would be good if we could come up with a term other than "baseline", since I think we're practically redefining it here compared to what others in energy competitions/conservation would understand it to mean. "Dynamic baseline" sounds like we are fudging things to make our conservation look better, when really we're converting this dual-use concept (metric of conservation and game motivator) into a purely game-design concept. Maybe "dynamic goal"?

[philipmjohnson]

I'm not convinced that we need a different term than baseline. It is the value from which we generate our goals.

[philipmjohnson]

Need to worry about vacations for baseline calculation: define "holiday" days which are skipped over when finding the baseline. And we should suspend the competition during holidays (thanksgiving and spring break).

[yongwen]

how about the "warning percentage" that indicates the yellow in the stoplight visualization? when the goal is 5%, the original warning is 3%. when the goal become dynamic, could we set the warning to be goal / 2? so, when goal is 5%, warning will be 2.5%, when goal is 1%, the warning is 0.5%?

[philipmjohnson]

Seems reasonable to me; go ahead.

[yongwen]

1.implemented dynamic baseline as the default baseline method 2.user could choose dynamic baseline or fixed baseline 3.implemented resource blackout date table to specify blackouts for resource competition. the blackout date does not count in baseline calculation and daily energy goal game.

[philipmjohnson]

Try testing with only one week of baseline data.

[rbrewer]

Talking to Yongwen, it appears that the baseline is currently being calculated dynamically at page rendering time. This puts additional load on WattDepot that scales linearly with the number of active players. Since the baseline for a particular day can be calculated before the day starts, it makes sense to calculate the hourly baselines for a day at the same time that the energy goal completions are computed, and cache them in Makahiki's baseline db table.