AMECIII Trading Agent Tournament

IIIA

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
• Auction Protocol
• Trading Agent Protocol
• Hints to build your own agent
• Tournament Evaluation

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:

• each buyer will be endowed with the very same initial credit; and

• every time a new auction is started off, the buyers' credits is reset to their initial value.

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

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.

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.
 

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

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
 

Messages that buyers can receive through their interagents
 

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:

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:
 

Top

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:
 

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.

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:

• login and password: the data directory of your installation's directory contains the passwd.txt file, a list of logins and passwords loaded by FM before starting a tournament session.
• how to allow FM to find your agent: FM will look for you agent's classes at the directory spceficied by the MY_AGENTS environment variable that you are required to set up before running FM (see the README file in the FM user distribution).

Top

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

where B_k (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:
 

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.
 

Top