[Trade] Trade Contracts

[ThomasThelen]

[Trade] Trade Contracts

[ThomasThelen]

Because trade dynamics are complex, it's impossible to know what makes a village accept a trade (from villager's perspective). This feature should extend the existing trade feature to allow users to define conditions that make a trade acceptable. This will be based off of the same approach that was taken for trade and village-property dynamics.

The essence is that the user creates a function that returns true or false. Consider a village that is willing to trade maize for fish if there's a calorie deficit.

trade_condition <- function(current_state, proposed_state) {

# 300 calories per fish
fish_calories <- 300

# 200 calories per maize
maize_calories <- 200

# Get the total calories available

total_fish_calories <- current_state$fish_stock * fish_calories
total_maize_calories <- current_state$maize_stock * maize_calories

calories_available <- total_fish_calories + total_maize_calories

# Calculate the total calorie demand
# (let's assume they're american)
calorie_demand <- 2000

total_calorie_demand <- calorie_demand*current_state$population

if (total_calorie_demand > calories_available) {
    # Then we'll definitely want to consider a trade that might help us
    
    # Make sure the trade actually helps us
    total_proposed_fish_calories <- proposed_state$fish_stock * fish_calories
    total_proposed_maize_calories <- proposed_state$maize_stock * maize_calories
    proposed_calories_available <- total_proposed_fish_calories + total_proposed_maize_calories
    if (proposed_calories_available > calories_available) {
        # Then it looks like the trade can help. Better make sure we can afford it.
        # We can only trade our maize for fish at a 1-1 rate (so hopefully they value maize)
        # Check to see if they're asking for maize
        if (proposed_state$maize < current_state$maize) {
            # Looks like they want maize! 
            # Let's confirm that they want fish
            if(proposed_state$fish > current_state_fish) {
                # Looks like they want to trade fish for maize! Let's accept the trade!
                return TRUE
            } else {
                # It looks like they want to trade for something else. Decline
                return FALSE
            } else {
                # Looks like they don't want maize
            }
       } else {
           # We would be losing calories if we traded fish for maize, so decline the trade
           return FALSE
       }
} else {
    # If we meet the calorie demand, deny the trade request
    return FALSE
}

}

We should let people make functions like the above, and then call their method from where ever the trades are being executed. If it returns true, apply the state changes-otherwise pass.

[ThomasThelen]

@zizroc @gvaldana Scratch all of the above. This should be done the same way winik/winik_manager is done.

Behaviour that effects the design

All or nothing trades: Should trades be made conditional on ALL items? For example consider

           Village A.         |        VillageB
          10 fish         ->     <-    5 apples
          40 acorns.  ->     <-    3 oranges

Do we want village B to have the chance to reject part of the trade? Ie not trade the oranges, but still trade the apples for fish?

To handle trade (basics):

1. Create a new trade_manager class
2. Give the village class an instance of one
3. Expose it to users in the custom model
4. Create a trade class
5. Check if trades should execute each day, if so execute them

trade_manager

The trade_manager should handle everything trade related. Trade contracts should be made through this object.

It needs to be able to:

1. Store a list of trade objects
2. Return a trade object, given an identifier
3. Execute trades

trade

In order to represent trades, a new trade object should be created. It should

1. Keep track of the village being traded with
2. Hold a function that represents the trade (this gets executed)