??žVirtual Goods / Digital Assets“ Virtual Goods (VAs) represent digitally goods of the real world. Properties : [url removed, login to view] (picture) [url removed, login to view] / name 3.a value measured in chips 4.a unique id. [url removed, login to view] belong to exactly one category when acquired by an user [url removed, login to view] (when they were bought) [url removed, login to view] (active / not active) Their lifecycle from the player point of view is: Acquisition (purchase/donation), Ownership and visualization (on profile and table) and expiry . The player can choose which of the digital assets is displayed at the table by activating one. This is done via his ??žmedium profile“. Purchasing Virtual Goods VGs (also referred to as items here) are organized in a catalogue sorted by categories. They can be purchased by selecting one with a single click for the player himself, a certain player, all his buddies or the players at the table he is sitting (maybe a combination of all buddies and all players at the table). There are three main views of the catalogue: Personal view You can get there from the main navigation entry ??žShop“. Catalogue with default category (1st) opens next to profile pic and nick of the player. Category can be changed by clicking one of index tabs on the left. For buying the user has to select an item. After that he has the following possibilities: a)Buy ??" to buy an item for himself ??" the button displays the amount of chips necessary for purchasing b)Buy for Buddies ??" player buys this item for all buddies ??" button displays the grand total (price of item multiplied by no. Of buddies, who accept gifts.
A1) Complete and precise implementation of the description of the bid request.
A2) Complete and fully-functional working program(s) in executable form as well as complete source code of all work done.
A3) Buyer will receive exclusive and complete copyrights to all work purchased. Third party software may be included as long as they are published under a license compatible with the GNU GPL.
A4) Software must be platform, browser and os independent.
A5) Software must be provided with a mercurial repository initialized when the work started (typically by unarchiving the sources and running hg init + hg commit at the toplevel)
A6) The work must be commited under mercurial on a daily basis.
A7) The reason for each change (not the change itself) must be explained in the ChangeLog file at the root the package tree.
A8) The software must be delivered in source form exclusively and it must be possible to create the binary form with a single command line.
R1) A set of unit tests covering 100% of the code written or modified for the job. There is no need to cover the code that already existed and that was not modified.
R3) Implement a verbose mode for running the tests so identifying which unit test fails and why is straightforward.
R5) The tests must be implemented using the same techniques as the pre-existing tests of the software being modified. It is not acceptable to create a new test environment. S1) Complete and precise implementation of the description of the bid request.
S2) Complete and fully-functional working web site(s) with no absolute URL in it.
SP1) The tests can be run individually (in addition to all at once) using either a URL permalink or a command line option. Each functionality described in the specifications must be associated with a permanlink and/or option.
SP2) The specifications must be modified to add a link to the test(s) that demonstrate its implementation.