AMECIII Trading Agent Tournament

ORGANISED BY

 
 
 

  IIIA

 


 


 
 
Tournament Description

And...why auctions?
Auctions have gained enormous popularity in the Internet.  The proliferation of on-line auctions has established auctioning as a
main-stream form of electronic commerce.  Typically negotiation on the Internet amounted to the seller offering his products at fixed prices. Instead, auctions appeared offering a more general, dynamic mechanism for price determination, benefitting from the existence of a vast range of auction protocols.  Auctions have succeeded as a convenient mechanism for automated trading, due mainly to the simplicity of their conventions for interaction when multi-party negotiations are involved, but also to the fact that on-line auctions may successfully reduce storage, delivery or clearing house costs in many markets. An interestinglyauction-based commerce is predicted to continue growing.

From the point of view of multi-agent interactions, auction-based trading is deceivingly simple. Trading within an auction house demands from buyers merely to decide on an appropriate price on which to bid, and from sellers, essentially only to choose a moment when to submit their goods. But those decisions ---if rational--- should profit from whatever information may be available in the market: participating traders, available goods and their expected re-sale value, historical experience on prices and participants' behaviour, etc. However, richness of information is not the only source of complexity in this domain. The actual conditions for deliberation are not only constantly changing and highly uncertain ---new goods become available, buyers come and leave, prices keep on changing; no one really knows for sure what utility functions other agents have, nor what profits might be accrued--- but on top of all that, deliberations are significantly time-bounded. Bidding times are constrained by the bidding protocol which in the case, for instance, of Dutch auctions ---like the traditional fish market--- proceeds at frenetic speeds.

The purpose of the AMEC tournament is to provide researchers with a common, experimental framework wherein both agent artchitectures and  the diverse artificial intelligence techniques employed for deploying trading strategies can be evaluated and compared. Agent developers are required to construct buying agents endowed with trading strategies that allow them to participate in and eventually succeed in a game-like auction-based trading scenario artificially constructed with the aid of FM. Within such trading scenario each buying agent must buy fish with the aim of maximizing his score according to some evaluation function and outperforming his rivals.

A trading scenario will involve a collection of explicit parameters that characterize an artificial market. Such parameters define the bidding conditions (timing restrictions, increment/decrement steps, publicly available information, etc), the way goods are identified and brought into the market, the resources buyers may have available, and the conventions under which buyers are to be evaluated. The following sections discuss these underlying ideas in order to both identify and make explicit all the information that buyer agents need to participate in such trading scenarios, to which henceforth we shall refer as tournaments.


Auctions

A tournament scenario will be composed of a sequence of auctions. Each auction is set up for the auctioning of a particular lot of goods. Each good within a lot is auctioned during a bidding round following a particular auction protocol. Although FM is capable of auctioning goods making use of several auction protocols (namely Dutch, English, First-price sealed-bid and Vickrey) in this tournament we will soley employ the Dutch protocol to auctioning all goods within a lot.

The auctioneer will open a new auction every time that a new lot is meant to be sold. During a given auction, the auctioneer will auction off the goods within a lot one by one. Therefore, every time a new fishbox is to be sold, the auctioneer will open a new bidding round and then will start calling prices till any of the situations described below arises.

What do buyers know about the goods to be auctioned? Before starting off the tournament, buyer agents only know the types of goods to be auctioned, the minimum and maximum number of fishboxes of each type of good, the minimum and maximum starting prices, and the minimum and maximum resale prices. In other words, precise information about the composition of each lot is not provided, but some hints instead. Buyers will be sent detailed information about the composition of lots at run-time.  Since the composition of each lot varies, several market scenarios will be artificially created whose features must be taken into account by participants. Thus, fbuyers may find themselves in scant, balanced or abundant market scenarios, depending on the amount of goods composing the lots.  And yet there is also the matter of the actual composition of the lot. For instance, small-sized lots containing a large ration of expensive goods must be treated differently to small-sized lots containing lots of  low-price goods.

More concretely, the composition lot of goods to be auctioned off during each auction will be generated according to the following uniform distributions:
 
Good
Number of fishboxes
Starting price
Resale price
cod
U[1..15]
U[1200..2000]
U[1500..3000]
tunafish
U[1..15]
U[800..1500]
U[1200..2500]
prawns
U[1..15]
U[4000..5000]
U[4500..9000]
halibut
U[1..15]
U[1000..2000]
U[1500..3500]
haddock
U[1..15]
U[2000..3000]
U[2200..4000]

In order to generate this type of lots, you must choose the tournament mode labelled as Automatic Uniform on the Tournament Parameter Settings panel of FM100. Notice that you must also configure the information revealed to buyers at the Information revelation section on the very same panel by ticking off Reserve price and keeping on the rest of options as shown below.


Figure 1. FM 100 Tournament Parameter Settings panel.

Each buyer will be identified by his login along the tournament (in the figure above david, jar, and KQLAT are the logins of the participants in the sample tournament definition). Notice that:

Buyer's' initial credits will depend on the number of participants. In general, a buyer's initial credit is obtained by dividing 70,000.00 EUR into the total number of participants.

Finally, the tournament will be composed of 10 auctions separated by 8000 ms, i.e. once an auction is over FM will wait for 8000 ms before starting off a new auction. Therefore agent devlopers must take into account since it does affect agents' time-boundedness between consecutive auctions, contstraining the time available for agents to eventually reconfigure their bidding strategies before a new auction starts.

Top

Auction Protocol

Although FM 100 is endowed with several auction protocols (namely Dutch, English, First-price sealed-bid and Vickrey) we will be exclusively employing the Dutch auction protocol. In what follows we explicitly state the actual bidding protocol, focusing on the identification of its parametrization. Thus, FM 100 implements a slight variation of the Dutch auction protocol, that henceforth we shall refer to as downward bidding protocol, composed of he following steps:
[Step 1]
The auctioneer chooses a good out of a lot of goods (usually these are ordered according to their arrival time).
[Step 2]
With a chosen good , the auctioneer opens a bidding round by quoting offers downward from the good's starting price as long as these price quotations are above the good's reserve price.
[Step 3]
For each price called by the auctioneer, several situations might arise during the open round:
Multiple bids:
Several buyers submit their bids at the current price. In this case, a collision comes about, the good is not sold to any buyer, and the auctioneer restarts the round at a higher price. Nevertheless, the auctioneer tracks whether a given number of successive collisions is reached, in order to avoid an infinite collision loop (see Max. number of collisions in Figure 1 above). This loop is broken by randomly selecting one buyer out of the set of colliding bidders.
One bid:
Only one buyer submits a bid at the current price. The good is sold to this buyer whenever his credit can support his bid. Whenever there is an unsupported bid the round is restarted by the auctioneer at a higher price, the unsuccessful bidder is punished with a fine, and he is expelled out of the auction room unless such fine is paid off.
No bids:
No buyer submits a bid at the current price. If the reserve price has not been reached yet, the auctioneer quotes a new price which is obtained by decreasing the current price according to the price step. If the reserve price is reached, the auctioneer declares the good withdrawn(i.e.the good is returned to its owner) and closes the round.
[Step 4]
The first two steps repeat until there are no more goods left.
Notice that six parameters that control the dynamics of the bidding process are implicit in this protocol definition. We shall enumerate them now, and require that they become instantiated as part of a tournament definition. Hence the following:
 
Parameter
Description
Ps Price Step. Increment or decrement of price between two consecutive offers shouted out by the auctioneer
to Minimum time between offers. Delay between consecutive offers.
tr Minimum time between rounds. Delay between the end of a round and the beginning of the next round.
Cmax Maximum number of successive collisions. The auctioneer randomly chooses one buyer out of the set of bidders when the maximum number of successive collisions is reached.
Sf Penalty factor. This coefficient is utilized by the buyers' manager to calculate the amount of the sanction to be imposed on buyers submitting unsupported bids. 
Pi Price increment. This value determines how the new offer is calculated by the auctioneer from the current offer when either a collision, a fine or an expulsion occur.

This set of parameters is what we call the Downward bidding protocol (DBP) dynamics descriptor. Our  tournament will instantiate the DBP dynamics descriptor as follows, as shown also in Figure 1 above.
 

Parameters
Value
Ps 50.0 EUR
to 500ms
tr 4000ms
Cmax 3
Sf 25%
Pi 25%

From this follows that the auctioneer will be calling prices donwards every 500 ms. Buyers will be receiving the prices called by the auctioneer and will have to choose the appropriate time to submit their bids based on their bidding strategies.

Top

Trading Agent Protocol

FM 100 has been conceived and implemented as an extensio of FM96.5, an actual agent-mediated electronic auction house. In FM96.5 the proper workings of the market institution are achieved by means of the coordination of institutional agents ---a set of sofware agents responsible for  realising the services of the market institution (admission, auctioning, accounting, etc.)--- and interagents, a special type of facilitators that mediate all the interactions between external trading agents and the market institution. Interagents constitute the unique  mean through which trading agents interact within  the market scenario.

Similarly, in FM 100 all participating agents will have their interactions mediated by interagents owned and run by the market insittution. Interagents will ensure the proper workings of the coordination mechanisms of the marketplace and will enforce the rules of the game during the tournament.

In what follows we make explicti the communication protocol that buyer agents must employ in order to interact with their interagents. The tables below specify the syntax of the messages that your buyer agents and the market interagents can interchange.

Messages that buyers are allowed to send
 

Message number
Predicate
Parameters
1
admission
login password
2
bid
3
exit

Messages that buyers can receive through their interagents
 

Message number
Predicate
Parameters
4
deny
deny_code
5
tournament_descriptor AUCTION number_of_auctions time_between_auctions time_between_rounds fees BIDDING_PROTOCOLS DBP Ps to Cmax Sf Ps UBP ...
6
accept
{admission | exit}
7
credit
 initial_endowment
8
open_auction
auction_number
9
goods
{good_id good_type  seller_name starting_price reserve_price resale_price {DBP | UBP | FPSB | Vickrey}}*
10
 open_round
round_number 
11
good
good_id good_type starting_price reserve_price resale_price {DBP | UBP | FPSB | Vickrey}
12
buyers
{buyerlogin}*
13
offer
good_id price
14
sold
buyerlogin price
15
sanction
buyerlogin fine
16
expulsion
buyerlogin penalty
17
collision
price
18
out_of_market
good_id price
19
end_round
round_number
20
end_auction
auction_number
21
closed_market

Notice that although the tournament_descriptor message contains parameters for the rest of bidding protocols run by FM, we can ignore them since we are only to employ DBP (downward bidding protocol). This is why we leave out their specification from UBP on.

Notice also that the message numbers along the first columns do not actually belong to the messages' syntax. Messages will be built as strings according to the following syntax:

predicate {blank space} parameters \n

Notice that messages will be ending with CR LF. Nevertheless, you won't have to get into message handling since our templates (described  trhoughout the next section below) will make that work for you. Next, we provide some examples of messages in the table below:
 

Message
Semantics
admission akira d3456784g Buyer requesting admission into the market with loing akira and  password d3456784g.
deny 1 Error: message not accepted by the interagent. Error code = 1.
accept admission Buyer admiited.
open_auction 2 Auction number 2 has been opened.
open_round 3 Round number 3 has been opened.
good g1 tuna David 2300.0 NULL 2500.0 DBP The next good to be auctioned is good g1 of type tuna owned by seller David, its starting price will be 2300.0 EUR, its reserve price is unknown (NULL) and its resale price will be 2500.0 EUR.
buyers warakaman akira fishbroker tindalos ... The buyers taking part in the next bidding round will be: warakaman, akira, fishbroker,...
goods g1 tuna David 2300.0 NULL 2500.0 DBP g2 cod David2300.0 NULL 2500.0 DBP g3 haddock David 2300.0 NULL 2500.0 DBP g4 halibut David 2300.0 NULL 2500.0 DBP g5 tuna David 2100.0 NULL 2500.0 DBP Lot of goods to be auctioned.
offer g1 1500.0 Good g1 is offered at price 1500.
sold akira 1300 Good  sold to akira at price 1300.
sanction tindalos 400 Buyer tindalos has been sanctioned with 400 ptas.
collision 1200 Collision at 1200 ptas. Several buyers sumitted their bids at 1200 ptas.
out_of_market g2 800 Good g2 has been declared out of market by the auctioneer when the offer price reached 800 EUR.
end_round 3 Round number 3 has been closed.
end_auction 2 Auction number 2 has been closed.
Top

Hints to build your own buyer agents

The main purpose of this tournament, as mentioned above, is to investigage on bidding strategies. Thus, it is not desirable to invest too much time on coding evertything an agent needs to participate in a tournament. For that purpose, FM 100 provides a buyer template written in java, along with an agent library containing a collection of examples of buyer agents.

After installing the FM 100 user package, change to the source directory where you will find the agentlib and templates directories. The templates directory contains BuyerTemplate.java, a typical template of a buyer agent. It is prepared to handle both the connection and interaction with an interagen, and also stores conviniently the incoming information received from the market so that it can be exploited by a buyer's bidding strategies. Notice that everything is done for you, and so agent developers are only required to implement the to_bid_or_not_to_bid method, which is expected to encapsulate a buyer's strategy:
 

   /**
     * This method must be implemented by the agent extending BuyerTemplate.
     */
    public abstract void to_bid_or_not_to_bid();

The agentlib directory contains a collection of examples of agents which have been actually built as an extended class of BuyerTemplate. For instance, the code below shows the actual bidding strategy for the agent0 agent.
 
    /**
     *
     */
    public void to_bid_or_not_to_bid() {
        if (canIBid){
            if (theProtocol.equals("DBP")){
                if (theGood != null && theAuction.getBuyers().thereAreBuyers()){
                    if (theBid == NO_BID){
                        theBid = calculateDBPBid();
                        System.out.println("DBP BID: " + theBid);
                    } else {
                        if (theCurrentPrice <= theBid && theAuction.getBuyers().getCredit(theLogin) >= theBid ){
                            theRemoteControl.bid();
                            canIBid = false;
                        }
                    }
                }
            }
            if (theProtocol.equals("UBP")){
                if (theBid == NO_BID)
                    theBid = calculateUBPBid();
                System.out.println("UBP BID: " + theBid);
                if (theCurrentPrice < theBid && (!firstUBPSubmitted || ubpGoingUp)){
                    if (!theUBPBidders.isBidder(theLogin) || theUBPBidders.hasRivals(theLogin))
                        theRemoteControl.bid();
                    canIBid = false;
                }
            }
            if (theProtocol.equals("FPSB")){
                if (theBid == NO_BID){
                    theBid = calculateFirstBid();
                    System.out.println("FPSB BID: " + theBid);
                    theRemoteControl.bid(theBid);
                    canIBid = false;
                }
            }
            if (theProtocol.equals("VICKREY")){
                if (theBid == NO_BID){
                    theBid = calculateVickreyBid();
                    System.out.println("VICKREY BID: " + theBid);
                    theRemoteControl.bid(theBid);
                    canIBid = false;
                }
            }
        }
    }

 

 
 
 
 
 
 
 
 
 

Observe that the agents in agentlib can be actually included in tournament scenarios as customizable dummy agents for training purposes. Simply select the option Build agent at the Tournament Parameter Setting in Figure 1 and you will be presented with the following GUI that allows you to choose and customize the type of dummy agent to be generated.


Figure 2. FM 100 Agent Builder GUI.

If you're interested in a full account of the several bidding strategies used by the agents within agentlib click here, and here for some guidelines about how to include trading agents into your tournament scenarios.

When including your hand-crafted agents into a tournament scenario, there are several issues to take into account:

You may be also interested in tracing the actual interaction of your agent with its interagent during a tournament session. Interagents keep track of the whole interchange with interagents in the log directory of your installation's directory. For instance, the trace information created by the interagent assigned to buyer KQLAT will be named  interagent#KQLAT.log and may look as follows:
 
Input(from agent): admission KQLAT benfresc
Output(to agent): tournament_descriptor AUCTION 10 8000 4000 0.0 BIDDING_PROTOCOLS DBP 50.0 500 3 25.0 25.0 UBP 10.0 25 25.0 10.0 FPSB 3000 25.0 VICKREY 3000 25.0 BUYERS david jar KQLAT BUYERS_CREDIT 3000.0 SELLERS Market TOURNAMENT_MODE 3
Output(to agent): accept admission
Output(to agent): credit 3000.0
Output(to agent): open_auction 1
Output(to agent): goods  g1 tuna David 2300.0 NULL 2500.0 DBP g2 cod David 2300.0 NULL 2500.0 DBP g3 haddock David 2300.0 NULL 2500.0 DBP g4 halibut David 2300.0 NULL 2500.0 DBP g5 tuna David 2100.0 NULL 2500.0 DBP
Output(to agent): open_round 1
Output(to agent): good g1 tuna David 2300.0 NULL 2500.0 DBP
Output(to agent): buyers david jar KQLAT
Output(to agent): offer g1 2300.0
Output(to agent): offer g1 2250.0
Output(to agent): offer g1 2200.0
Output(to agent): offer g1 2150.0
Output(to agent): offer g1 2100.0
Output(to agent): offer g1 2050.0
Output(to agent): offer g1 2000.0
Output(to agent): offer g1 1950.0
Output(to agent): offer g1 1900.0
Output(to agent): offer g1 1850.0
Output(to agent): offer g1 1800.0
Input(from agent): bid
Output(to market): Agent: KQLAT Round: 1 Bid: 1800.0
Output(to agent): sold jar 1850.0
Output(to agent): end_round 1

  

Top



Tournament Evaluation

For this tournament, we define the evaluation function E for a given buyer b as

where Bk (b) stands for the accumulated benefit (resale price - sale price) of buyer b during auction k, being n the toal number of auctions.

The goal of this evaluation function is to weigh higher the fact of winning the auctions which are closer to the end of the tournament. In this way, we try to
value more bidding strategies that improve an agent's performance as the tournament goes by.

FM outputs the net benefits obtained by the participants in the i-th auction in a file called auction#i.dat in the plot directory. The evolution of the participants along the tournament can be visualized with the aid of gnuplot by loading the evaluation.dem file as follows:
 

FMdir/plot $ gnuplot
gnuplot> load "evaluation.dem"

 

 
 
 
 
 
 
 

that will yield a picture of the evolution of the participants similar to the figure below:

where Rounds labelling the x axis represents the number of bidding rounds, and Score labelling the y axis stands for the accumulated benefit obtained by each contender.
 


jarjar@mit.edu
Updated: March, 11th 2000