Aren't you strawmaning?

Specification for Agora Market


Mission statement and use case:

Agora Market is a great achievement in 1603. It allows real-time entering of buy and sell offers for all the game items and lots, for the user-defined product, quantity and price. The orders stay in the system until canceled or executed. Matching orders are executed automatically and the items and moneretos change owner as a result.

Things to be handled:

- Items and Lots. Items are referred to with their unique Item_id, and Lots with their Lot_id (old version). The DB needs to enforce that the Item_id and Lot_id's remain unique, by disallowing a new Item_id or Lot_id to be generated by any means, if it conflicts with the existing id.

- All Items can be traded, except ones that have Untradable=1 in the ITEMS. ("M" are not tradable due to being the currency to be traded with; "CUL" is forbidden to trade, and some immovable objects properly change owner with the Lot only.)

- Gold, silver and stone are not tradable as such. They are embedded in the items that can be traded (STO1...STO9 are items that all include 1 stone, so can be thought as "stone in Borough #"). Gold objects are always trading with their gold value included. Therefore, a 1,500 CKG bowl that could have cost 15 mil (p.o.) a while ago, would now be 1,115 mil (15 mil item premium on top of 1,100 mil worth of gold).

- There is a command line for quick and accurate entering of buy and sell commands. It is a text box that can also be used to copy-paste the commands in text lines format in bulk. If such a batch is entered, it evaluates from the first line, one by one.

- The syntax for entering buy and sell offers and other commands is as follows (item_id means both item_id and lot_id, as they share the idspace; in GIVE, the recipient may be either specified by his shortname (max 12 alphanumerics, case matters) or char_id (a number of max a few digits) - these also have a common idspace):

BUY item_id max_quantity (max_price)

SELL item_id max_quantity (min_price)

GIVE item_id quantity recipient [char_id OR short_name]

CONSUME item_id quantity

TRANSFER item_id quantity giver recipient


Examples of the commands and their parsing:

BUY 1-C-K 1 10000000000       An offer to buy the Lot 1-C-K (Royal Palace) for 10,000 million

SELL W1601B 2200 44000      An offer to sell W1601B (Friar Maximus Barley Wine) up to 2,200 bottles for 44,000 m a piece

GIVE IC1602 10 31      A command to give 10*IC1602 (IC point of the year) to HH of North Face. Same could be accomplished by:
GIVE IC1602 10 djjacket)

CONSUME MEAD 168      A command to take 168*MEAD (168 liters of mead) from your inventory and add to your health. Anything can be consumed, but not all is healthy.

TRANSFER TS136 1 4 cryptonic      Admin-only command to take 1*TS136 Trade Silver Coin from the Town and give it to cryptonic.

- Using these commands, the command line, the batch command functionality, and the trading API (defined as a means for a character to authorize a software to type to the command line), most of the game's internal needs can be satisfied in this one subsystem. Character #5 "New" is the place where the system can create new things from - it is the only item owner whose balance is negative in all he owns


Script spex when a command is entered


BUY item_id max_quantity max_price

The command enters a new BID to the trading system for the max_quantity units of item_id, at max_price. The price is expressed in moneretos.

if item_id is not a current item_id or lot_id, print "No such item or lot exists." and abort
if max_quantity is not a positive integer, print "Quantity must be a positive integer." and abort
if max_price is not a positive integer, print "Price must be a positive integer." and abort
if (max_quantity * max_price) < (amount of m the character owns), print "Not enough money to place a bid." and abort
quantity_remaining = max_quantity
repeat
         if max_price >= min_price in lowest_ask_for_item_id, call MATCHBID char_id item_id quantity_remaining max_price char_id1 item_id1 max_quantity1 min_price , this returns new quantity_remaining. The parameters char_id1 item_id1 max_quantity1 min_price come from lowest_ask_for_item_id
         if max_price < lowest_ask_for_item_id, abort loop and move on (to 30)
         if quantity_remaining = 0, abort
(30) newBID char_id item_id quantity_remaining max_price , where char_id = active_character_id
print "New bid added for quantity_remaining units of item_id at a limit price of max_price."

NOTE: since an earlier revision, max_price is a mandatory parameter.


SELL item_id max_quantity min_price

The command enters a new ASK to the trading system for the max_quantity units of item_id, at max_price. The price is expressed in moneretos.

if item_id is not a current item_id or lot_id, print "No such item or lot exists." and abort
if max_quantity is not a positive integer, print "Quantity must be a positive integer." and abort
if active_character does not have at least max_quantity units of item_id, print "You do not have item_id (or sufficient quantity of it)." and abort
if min_price is not a positive integer, print "Price must be a positive integer." and abort
quantity_remaining = max_quantity
repeat
         if min_price <= max_price in highest_bid_for_item_id, call MATCHASK char_id item_id quantity_remaining min_price char_id1 item_id1 max_quantity1 max_price , this returns new quantity_remaining. The parameters char_id1 item_id1 max_quantity1 max_price come from highest_bid_for_item_id
         if min_price > highest_bid_for_item_id, abort loop and move on (to 30)
         if quantity_remaining = 0, abort
(30) newASK char_id item_id quantity_remaining min_price , where char_id = active_character_id
print "New ask added for quantity_remaining units of item_id at a limit price of min_price."

NOTE: since an earlier revision, min_price is a mandatory parameter.


GIVE item_id quantity recipient

The command transfers the ownership of quantity units of item_id from active_character to recipient. Recipient can be expressed as char_id or char_shortname.

if item_id is not a current item_id or lot_id, print "No such item or lot exists." and abort
if quantity is not a positive integer, print "Quantity must be a positive integer." and abort
if recipient is not found from char_id and char_shortname tables, print "No such recipient." and abort
if active_character does not have at least quantity units of item_id, print "You do not have item_id (or sufficient quantity of it)." and abort
remove quantity units of item_id from active_character and add quantity units of item_id to recipient
print "quantity units of item_id given to recipient."


CONSUME item_id quantity

The command consumes quantity units of item_id. It is intended for consumption for sustenance (at present: drinks) but it can be used to consume all items to get rid of them.

if item_id is not a current item_id, print "No such item exists." and abort
if quantity is not a positive integer, print "Quantity must be a positive integer." and abort
if active_character does not have at least quantity units of item_id, print "You do not have item_id (or sufficient quantity of it)." and abort
remove quantity units of item_id from active_character
print "quantity units of item_id consumed"
call HEALTH_CHALLENGE_EVALUATOR char_id item_id quantity

NOTE: lots cannot be destroyed, or, hence, consumed.


TRANSFER item_id quantity giver recipient

The command transfers the ownership of quantity units of item_id from giver to recipient. Giver and Recipient can be expressed as char_id or char_shortname.

if item_id is not a current item_id or lot_id, print "No such item or lot exists." and abort
if quantity is not a positive integer, print "Quantity must be a positive integer." and abort
if giver is not found from char_id and char_shortname tables, print "No such giver." and abort
if recipient is not found from char_id and char_shortname tables, print "No such recipient." and abort
if giver does not have at least quantity units of item_id, print "giver does not have item_id (or sufficient quantity of it)." and abort
remove quantity units of item_id from giver and add quantity units of item_id to recipient
print "quantity units of item_id given from giver to recipient."

NOTE: Admin only.


CANCELASK item_id max_quantity min_price

if in Ask table, there is no order active_character item_id max_quantity min_price, print "You do not have such an order active." and abort
remove order from Ask table: char_id item_id max_quantity min_price , where char_id = active_character_id
print "Order removed."


CANCELBID item_id max_quantity max_price

if in Bid table, there is no order active_character item_id max_quantity max_price, print "You do not have such an order active." and abort
remove order from Ask table: char_id item_id max_quantity max_price , where char_id = active_character_id
print "Order removed."


MOVE source_borough_id destination_borough_id amount

This command is used for changing the location of stone, which technically removes STOx items and creates STOy items, against a cost.

if source_borough_id is not a valid borough_id, print "No such source borough." and abort
if destination_borough_id is not a valid borough_id, print "No such destination borough." and abort
if active_character does not have at least amount units of concatenate("STO";source_borough_id) item, print "Not enough stone in borough source_borough_id." and abort
cost = lookup stone_transport_cost_table for concatenate(source_borough_id;"-";destination_borough_id)
if cost * amount > character has money, print "Not enough funds for operation." and abort
remove amount units of concatenate("STO";source_borough_id) from active_character and add amount units of concatenate("STO";destination_borough_id) to active_character.
remove amount * cost of M from active_character and add amount * cost of M to char_id=37
print "amount stone moved from borough source_borough_id to borough destination_borough_id."


Ask and Bid table datatype

Ask table: char_id item_id max_quantity min_price
Bid table: char_id item_id max_quantity max_price

Separately are kept:
lowest_ask_for_item_id: char_id item_id max_quantity min_price
highest_bid_for_item_id: char_id item_id max_quantity max_price

NOTE: In Ask and Bid tables, all orders submitted are kept perpetually until canceled. In lowest_ask_for_item_id and highest_bid_for_item_id, only one instance of data is kept for each item_id (if any). This is used to display the ASK and BID columns in Items listings and used in evaluating the MATCHBID/MATCHASK.


Routines, cannot be commanded

MATCHBID char_id item_id quantity_remaining max_price char_id1 item_id1 max_quantity1 min_price

The routine matches the recently entered bid which the BUY evaluation procedure has deemed needs to be executed.

quantity_traded = min(quantity_remaining;max_quantity1)
remove quantity_traded units of item_id from char_id1 and add quantity_traded units of item_id to char_id
remove quantity_traded * min_price units of M from char_id and add quantity_traded * min_price units of M to char_id1
print "Bought quantity_traded units of item_id at min_price m/unit, for a total of quantity_traded * min_price m."
quantity_remaining -= quantity_traded // reduce quantity_remaining by quantity_traded
if quantity_traded = quantity1; set new lowest_ask_for_item_id // put the new best ask to the lowest_ask_for_item_id (first lower price, if same, earlier order timestamp)
return quantity_remaining


MATCHASK char_id item_id quantity_remaining min_price char_id1 item_id1 max_quantity1 max_price

The routine matches the recently entered ask which the SELL evaluation procedure has deemed needs to be executed.

quantity_traded = min(quantity_remaining;max_quantity1)
remove quantity_traded units of item_id from char_id and add quantity_traded units of item_id to char_id1
remove quantity_traded * max_price units of M from char_id1 and add quantity_traded * max_price units of M to char_id
print "Sold quantity_traded units of item_id at max_price m/unit, for a total of quantity_traded * max_price m."
quantity_remaining -= quantity_traded // reduce quantity_remaining by quantity_traded
if quantity_traded = quantity1; set new highest_bid_for_item_id // put the new best bid to the highest_bid_for_item_id (first higher price, if same, earlier order timestamp)
return quantity_remaining


HEALTH_CHALLENGE_EVALUATOR

return

If you truly do agile, you can fail in:

DEV:
a) your performance may be unsatisfactory
b) estimation of your performance may be inaccurate

CLIENT:
c) estimation of the precision of the other's estimation of his performance may be off
d) estimation of the accuracy (variance) in the other's estimation of his performance may be off.


Our failure of the week was of the d) type. The Wizard had been performing excellently (cross a) and estimated it well (cross b). I had not found problems with c) since such a low precision is anyway needed. This had lead me to think that d) accuracy was also good and less PM contingency was needed, but we had an outlier because of misunderstanding of the scope of one feature. Unluckily it was on the release date when the DB was already closed

We are dealing with professionals now. This is the 6th comparable software project in which I have been the feature-specifying client. All from different companies or teams, based on 4 different countries, over 14 years, with the combined project length measured in years and intensity in man-years. In each case the software has been designed by me from the scratch, been the crucial and integral part of the startup's business without which no operations could profitably be conducted; mostly the startup's valuation has been over € 1 million at the time of ordering it, and I have had the position of CEO/president/whatever and a commanding stake. So yeah there may be more experienced guys in the world but not that many. Show me one who has completely specified this many different systems for his own direct use, and been the client team key person during the implementation, for starters!  

Allow me to vent a little (this is intended that you would receive benefit in learning how not to do, not to lay blame on any individual except myself who cannot always realize how important it is to make it clear to the counterparty that bullshitting with me is a short rope, and a completely stupid idea. I am not of course talking strongly about the Wizard, whose only mistake was to slip 2 features in this week's release, of which features he could not evaluate the coding time accurately, but based on the assessment, I spent hours closing the google DB (this involved massive work in merging the datatypes from 10s of tabs to 4 main types and their attribute_lookup_tables - our DB has about 7,000 lines in Character, Lot, Building and Item tables and each line consists of the data in 10s of fields.

If I take the decision to close the DB, it needs to be based on solid reality and timing, which is accurate to the hour, not to the day or to the week! May the day never come when I enter any business relation again with jokers who cannot estimate their own work with a useful accuracy! (A note to the newbs here - it is not difficult to be able to give an estimate of "1-3 hours in 90% probability" hey wtf if you do anything in your own work, you can probably estimate better, also if you do the household chores, even better). And we are talking about solid professionals here!

The decision that now failed, was the decision to think we can release the game with an exchange-type items trading system, in this week's release. Both the decision to schedule and promise the release to any future date when the system can be ready (and google DB used until that), or stick to the original feature specification of this week's release could have been better. Many people can code, and some can very well. Many can estimate, but even if you cannot, I can compensate because I know how long it should take to make something. But if you can code, and estimate, and suddenly fail on either (which is basically the same thing), problem is at hand.

Whoever thinks he can add to my spex, nice features without realistic estimates, and fail the release, is playing with fire!   The blame is not on me who proposes the features, it is on the one whose estimates fail reality! (Tinkering with the spex yourself without asking me, is beyond belief and whoever is guilty of it hopefully never thinks of it again with other clients - certainly not with me at least.)

Once again: The development process decisions, which I make several each day, depend on the estimates that the coders are providing. In Ultima, we have included features ahead-of-schedule based on the surprisingly fast deployment, and postponed others based on the estimate that they require days to complete. Hey - we don't have days for anything except features that we cannot live without. Items trade being one.

So I assess the degree of my culpability: In the first project team my assessment of their capability was so much off the reality that I continued to believe something could be accomplished in acceptable or even tolerable timeframes, despite none whatsoever proof (the total lack of delivery was indeed fooling me as I could not calibrate my assessment of their productivity nor my assessment of their capability to estimate). Now I was again lured by the tired developer (atypical for him) "yeah-yeah we can make all this by 9pm, let me just finish the office day first, go home, eat and chat with my gf", when I could easily see that the performance per hour had already suffered.

So we decided to have another rescheduling meeting today, after a good sleep, in a few minutes. We have them almost daily and when the deadline approaches, several per day. The decision will be to redefine the features included in the release, redefine the release date and time, and redefine how the game continues meanwhile. Will be posted soon!




Most likely we press on with the decision, but that does not remove the importance of accurate estimation. What kindled my anger really, was the remembrance of the bunch of jokers whose inability to estimate, or deliver, caused a 4-month break in the game. For a long-time businessman like myself, the decision to temporarily close down all operations due to migration is one that is taken only after considerable planning and making of a strict and detailed execution plan. The damage to the game from our previous errors is incalculable, so it would feel good to get it right this time

The time has passed but it is not working.

When the previous development team failed in totality, I swore that no making myself clown by continuously covering up the ungrateful devs' blunders, will ever happen any more. So I will now tell truthfully - the Wizard Developer estimate for getting the exchange system working was too optimistic. He has met and beaten his estimates repeatedly so many times that I came to expect this would be realistic as well. It wasn't.

Nothing else is broken except that since I am totally reliant of the estimates, if they don't hold, my actions such as writing to this thread and closing the google DB are out of place. After living through estimation errors of 8 months in a 1 month project, we can easily live with this. I am just frustrated and promised that this time I say it

We will review the situation first thing tomorrow morning. The Wizard Dev and me are in agreement that this estimation error was the first failure so far in the project. The current progress is visible in the game url, but there is no reason for anyone to test it now as we well know what the missing issues are at the moment.

 

And of course it was partly my fault as well....

The manipulative character of the ask side is visible all the way here.. 

I would not be too scared of the weak bid side, it's proven many times that you can sell XMR low, but buying it low is a more difficult thing to do 

The Prince of OZ is granted a new address; from now on he shall be called His Serene Highness (HSH) The Prince of OZ.

Serenity is granted to this most senior of all princes based on merit. It ranks higher than Excellency and lower than Highness (without Serene). The higher address than Highness is Royal Highness, which might be granted to L14 characters but not necessarily. (It makes them part of the Royal House.)

* * - * *

The Prince of Forte Spagnolo is not demoted, but reminded that due to his previous address His Highness (HH) was based on his previous function as CEO, he is correctly addressed His Excellency (HE), as well as his junior peers, the Princes of Soul and Ramsey.

* * - * *

The rumors that Tavastia would be granted the use of His Excellency have proven to be as false as the rumors that d'Armagnac would never be promoted Marquess. The reason why his (Tavastia's) junior HE The Marquess Cryptoluna is granted their use, is his honorary position as the Chancellor of the University. The other Marquesses have shown no merits to warrant the granting of Excellency to them.

* * - * *

We remind that Magnificence is not restricted and can be used at will, within reason. It must not be shortened to "HM" for reasons clear. In our cultivated opinion, at least Tavastia and White Cross may assume Magnificence properly.

Royal Seal

When I was 5 years old, my father promised me the equivalent of 2,500 EUR when I am 18, if I don't smoke by 30. I collected the money (with interest, it was about 5,000 EUR) and lost it in the Nasdaq bubble. I did not start smoking until I was 33.

Now I have been not smoking for 28 days, to show my wife that it is possible. After 3 days I will start again though. But I only smoke cigars, and only hand-made.

Announcement.

The Royal CryptoArmy is not sitting still despite the shortage of live targets. We have explored the lands in the periphery of HM rule, and found that in many of them, a legacy currency of Bit Coins is still going strong. Many of the inhabitants of these lands have expressed interest in becoming subjects of His Royal Majesty, but they only have their Bit Coins, and the long-planned deal to exchange them for current currency in the land of Polonia has delayed.

The Army is stronger than it seems. Upon inspection, it was revealed that they had collected loot in the days of yore, when Bit Coins were regarded as nothing by the peoples of the Earth, and they were purchasable in thousands in the tall and dreadful mountain of Gox, which many knew but few dared to approach - and for a good reason, because the eventual explosion of the volcano destroyed many a good soul, and a few bad ones as well. (All this happened in the prehistorical times.

It was not difficult for the Army to present a stash of 100 Bit Coins, and divide them into a million pieces each, which were listed as tradable items under the item code UB1, which belong to the item type Depository Shares, the same type as the item M, our currency moneretos.

The way how this might be helping the people in our borders is; it might be difficult for many of them to exchange their currency to the Kingdom currency in their lands. This way they can bring their currency to the Kingdom as such, and the UB1 tokens will be given in return. Since the Royal CryptoArmy is - for a good and obvious reason - in high regard in the Kingdom, and the address where the deposit amount reside is publicly known (as is the feature of Bit Coins, in good as well and mainly as bad), the UB1 tokens might be accepted as if they were 1/1,000,000th parts of Bit Coins themselves. The Royal CryptoArmy does not want to tinker with withdrawals, but will conduct them for any amount of UB1, against the fixed fee of 100,000 UB1. The deposit incurs no fee but must be minimum 1 Bit Coin, which yields 1,000,000 UB1. For the practicalities, you will need to find the contact persons in the game.

Considering the clear and concise rules how the Royal CryptoArmy operates its old and mighty deposit, it will be regarded as evident that the UB1 will trade against M closely in the same ratio as BTC trades against XMR. The Army stands ready to enforce this if need be and buy and sell the currencies to keep the values in close contact. Finally we want to remind that the secure storage of BTC is not free despite their ephemeral appearance. Solid procedures are in place to guard the Secret Codes, and for this service a maximum of 0.02% APR (1% real-year) fee is levied on all the UB1, system-enforced.

TL;DR: PM me if you want to join the game with a BTC deposit of minimum BTC1.

In about 2 hours we will migrate the data, and start giving final accounts to the most active players first.

Mention to me in PM/IRC if you want your account among the first - I will send it to the authorized PM or equivalent.

It is actually rather simple to plot for instance daily moves of BTCUSD and XMRBTC, to find out the greek coefficients. Whether this is any usable information, perhaps. I'd be glad to hear

It seems that we cannot know the date in advance, but we can witness in the power of the Holy Spirit unto all the earth, and this is what I am doing.

Release schedule update


Yesterday, when I had explained the trading system details to the Wizard, there had been a small misunderstanding. He had thought of a single item bulletin board type system (similar to what has been used in /LOT and /F_OWN), while my understanding was a complete order-matching real-time virtual exchange, perhaps similar to Mt.Gox when it was still trading MtG cards.

My wish prevailed, motivated by the simple reasoning that there is no point in releasing Ultima, if its only real supported feature - trading in lots and items - works worse than in the googleDB. So we have now agreed on the specification that it will be an order matching exchange with a CLI, as follows:


The items will be browsable by type (70 types exist) and the bid/ask situation is shown in the list view.

Obviously this takes extra time to code compared to previous schedule.

The remaining feature of the release is the NewPlayerLogin-EXP-Tutorial-Gifting-GoldCreation set.

We are fighting against the final issues. At present the estimated delivery is 4 hours from this post.

If the issues are larger than anticipated, then a strange thing called sleep might be resorted to, adding ~8 hours. That is something not so much used in the last few days, though... 

The number of seats in the table of martyrs is limited, and when it fills up, things start rolling...

immediately afterwards

...and it begins to get uncomfortable for the people who associated themselves with the system, rich and poor alike. The rich and poor have equal chance of exit, and the exit door is open now.

The V3.9U is now estimated to be released in 6-8 hours.

I am sorry for the delay of 1 day compared to the original estimated release date of yesterday (/NewSchedule tab).

The delay was caused by agile last minute changes to the specification, namely: I wanted that the EXP calculation would start from the migration of the database and not some time later. This was accompanied with the Tutorial with a lot of messages and gifts to the new players. And also the new player registration itself was not part of the original spex.

I am still interested if all admins would report to me if they have any time for database cleaning-up in the following 4 hours. This work will be done sooner or later (such as removing of the doublespends of land in lots...) but it causes less trouble if sooner.  

We kindly ask the Noble Palace to provide a storytelling message such as the following:


We also ask what immediate gift the recipients of the message (all characters new and old, reaching the certain EXP that starts at 0 for all) will get.

The clearing works of the collapsed section revealed 1,230*AMBNP (1 kg of amber). It is way less than needed to reconstruct the famed Amber Room, but could be a nice and unique gift for the new ones.

The forum was down for some time so could not update you: We are fixing the always-occurring last minute issues. I have spent the afternoon by writing a 40-message tutorial that will be distributed to the players in the space of their first 10 hours of play It also includes an item gifting plan that was talked about yesterday, so playing the game really gets you the goods 

Help needed!

I am making the intro messages to the new players. They are pop-uped after certain EXP milestones, starting from the entry to the game, and continuing once every 10 minutes or so for quite some time.

Example:

I need the Monero introduction, mainly the out-of game perspective (propaganda/marketing), somehow tied to the game context. The messager would be Monero House.

A tyranny is not fought by petitioning it.

You have to be ready to take the moral high ground you claim to have, and ignore the tyranny to their demise.

There is no guaranteed, visible victory in your lifetime, but they dread to take your life, because it shortens their own rule:


So actually your victory is not dependent whether you live or die, it depends whether you associate with the tyranny or not.