Market stall - to buy and sell like we've always wanted to.

[Elros]

Thinking about addressing the problem we might run into where there are just too many market stalls in a location (people died and left them behind, etc.), I was just wondering if we are technically able to make vehicles deteriorate like other objects. Then the solution seems clear, make all stalls subject to fairly quick deterioration, so owners have to maintain them or they will crumble. The primitive ones would be especially susceptible, and much less so for the fancy windowglass-and-steel ones.

Building and Vehicle deterioration is being disscussed now and will be implemented eventually. It has already been accepted.

[Cogliostro]

Nice!

I think one of the main areas I still need community help with is how the hypothetical market stalls would be presented. If they appear like other vehicles in the vehicle list (bunched together like with like, so first it's vehicles, then market stalls) then is it techincally imaginable that unmanned market stalls could be somehow "greyed out" and their "Offers" button absent?

It's crucial that punters can see the entire cornucopia of all the market stalls a town has, without being confused and disoriented.

Or how else could we present that, preferably elegant and nice, and without cluttering the vehicle or building lists?

[Drael]

I prefer vending machines and stackable coins. Trade is better Rp'd IMO.

Still a vehicle for trade while trader is sleeping is all good. Economy generally is too simple for a society simulator. But there are lots of areas this could do with changing. In the end, probably too hard to make it life-like totally.
If off-hours trade could be implemented, and item deterioration made more realistic or important, it could be close though..

[Cogliostro]

Coin-op vending was unfortunately rejected, because it was thought to add an element of at least implied automation. Also, these would clutter the object lists everywhere. I agree, that kind of machine would be nice, it would be nice even if we already had market stalls in the game. The vending machine depends on coins, but on the other hand it doesn't need any shopkeeper to sit inside of it all day. It's an interesting tradeoff/advantage for each of them.

I'm interested in very seriously focusing on the market stalls, for now. To their credit, they don't add even a hint of implied automation into the game, and provide such an important facility for players that two weeks after implementation we're going to wonder how we ever played the game without these.

In this post I am going to focus on the aesthetic options of the implementation only, and ask for your feedback. As I see it, there are *two main ways* that the market stalls could be presented.

A) As their own category, below "Vehicles" but above "Buildings", in the Buildings & Vehicles screen:

((( Vehicles )))
Blacknightrider of Blackness (a brand new bike cart)
Bumboat (a brand new Dinghy)
etc. etc.

((( Market Stalls )))
John Doe's Lil Shoppe (a brand new primitive market stall)

((( Lakeside West - [grassland]: BUILDINGS)))
Town leader house (a brand new stone building)
Prison (a brand new stone building)
etc. etc.

We would then use a simple little trick: when a market stall is unmanned, it appears under "Vehicles", like a normal vehicle would, it has an "enter" button to it, etc. But when someone is already inside, the same market stall now appears under "Market Stalls", together with its convenient "Deals" button, and is now not available in the vehicle list to be entered. The market stalls should allow only one shopkeeper to enter, otherwise think about it, who do the goods go to when trades complete? That'd be awkward in too many ways to mention, so in my opinion it's the best idea to restrict them to 1 person in this way.

B) The second way is sneaky. In the "People" screen. Reason with me for a moment, which screen is the least cluttered one? The People screen, undeniably. And, when you trade, do you trade with a market stall? Or with a person? So why would you click a button on the market stall and not on the person? Though at first less intuitive, such an implementation makes perfect sense: then no special market stall category is needed, and any person who is inside their own market stall gets an extra "Deals" button next to their name in the actual people screen. Exit the stall and the button doesn't show or work any more. The problems with this second way to present it is that it's likely to be a lot harder to implement code-wise, may even be impossible under the current system.

Remember, a large town may "generate" dozens of market stalls, so it's worth brainstorming very seriously how they should be presented in the best way possible.

A separate item to discuss is the presentation for the new screen you see when you click "Deals". From other online games we know very well that people are quickly going to want to sell *groups* of items ("Full set of 100g of every herb!" and so on). To do this, they will look for cheap containers they can use to store the objects, and then they will put that container on the ground of the market stall. No problem, you will be able to price them and sell it just fine. BUT: punters buying the container have no idea if they are being tricked and sold an empty box, or random junk. This ruins the fine possibility of such selling, since people would be too wary to buy anything like that. So when somebody lists a container for sale, we may want to include a way for people to hover with the mouse over it and see the contents, or get this info some other convenient way.

[Doug R.]

After having gained unexpected down time, and read this in detail, I have no objections. Cogliostro seems to have thought of just about everything.

Except, what the hell is a "punter"? Not a clue. Only punters I've heard about either play American Football or drive punts on a river.

One very obvious benefit that I didn't see you mention is that it adds a measure of security to trading. With a market stall, you wouldn't have to worry about the other party walking off with your both halves of the trade.

Perhaps instead of a massive drop-down menu, make it freeform text input. This puts the burden of correct spelling onto the player, but it shouldn't be that much to ask. Just an simple error message if the input doesn't match an existing resource.

[Cogliostro]

A text input - that could be an excellent idea. We could have a convenient short-ish listbox for some commonly traded resources and then right under it, a text input for your custom one if you want to and it wasn't in the list. Great!

[Elros]

After having gained unexpected down time, and read this in detail, I have no objections. Cogliostro seems to have thought of just about everything.

Except, what the hell is a "punter"? Not a clue. Only punters I've heard about either play American Football or drive punts on a river.

One very obvious benefit that I didn't see you mention is that it adds a measure of security to trading. With a market stall, you wouldn't have to worry about the other party walking off with your both halves of the trade.

Perhaps instead of a massive drop-down menu, make it freeform text input. This puts the burden of correct spelling onto the player, but it shouldn't be that much to ask. Just an simple error message if the input doesn't match an existing resource.

Cool, I am glad you read it because I thought it was a pretty good idea as well once I read the whole thing!

I like your idea. A freeform textbox would save a lot of clutter compared to a dropdown menu with every resource in Cantr. Some of these resources might not even be on the characters continent and that would be wierd. I freeform textbox like the searchbox for the manufacturing is a good idea.

[Cogliostro]

Here's an implementation roadmap (as I see it) and notes about some important technical issues.

#1. We need the addition of a new vehicle type called "market stall". Movement speed is 1/4th that of a person on foot. No new coding needed.
One quirky bit: new market stalls need to come with a pre-installed object inside, called "Banner". When clicked, this opens up a note editor, where you can adjust what HTML message your stall displays to customers. Internally, it's one associated always-editable note for each market stall.

#2. A new database table: ObjectPricing. Structure: stall_id, object_id, resource type id, amount. This is where the game will store what object you're selling for how much, and the stall_id is so the game can quickly query for all priced objects in a specific stall, as for example when we display the shopping screen.

#3. Need some hopefully trivial changes in the global drop-item handling code. If current location is a market stall, there is special stuff to do for all objects being dropped. Namely, the objects get a flag indicating that they should be displaying an extra "Price" button. Equally so for pick-up from market stall floors- remove the flag and set back to normal display style.

#4. Global item display/listing code change. Do the normal stuff as before, plus: display the "Price" button if that flag is set for that object.

#5. User interface screens and their handlers. There are a few here, all are very simple though:

- the "set item price" screen, which appears when you click that "Price" button for an item you dropped in a stall. Handler: update the ObjectPrincing table with what the user is asking us to set it to.

- the main "shopping" screen, which appears when customers click on the "Deals" button on the market stall vehicle. To start, very basic. We display the HTML/note the shopowner supplied, and then we display a list of items by iterating ObjectPricing for that stall. Each gets a purchase button, which links to the next screen.

- the "purchase" screen, where customer selects how much of the asked resource they want to give. That's all they get to select, very simple screen. Handler: copy-paste of the normal "give some item to someone" code, with some changes. We remove the specified amount from customer, give it to the shopowner. If the item in question is a resource, we then calculate a possible partial purchase (i.e. getting 300g of potato for 3g iron as we discussed before), else the object is not divisible and the purchase only works if the full amount is entered. If the customer can't hold the amount the bought, it goes on the ground. If the shopowner can't hold the amount they'd been paid, it goes on the floor of the stall. Since no price has been set yet for that fallen object yet, it won't appear for sale, but will just wait for the shopowner to notice and pick it up.

#6. Update the "Buildings and Vehicles" screen of the game to include a new category: "Market stalls", below vehicles but above buildings. All market stalls just go there for now, and will be sorted by "fanciness", and then secondarily by their id, that is build date, the earlier the higher the stall appears toward the top of the list. I described some little tricks with stalls moving from this category to normal vehicles, but it's complex and strictly speaking unnecessary. Just get them in there into the "Stalls" category with all their normal vehicle buttons displayed plus the "Deals" button. Stalls still allow only one person to enter at a time. If possible, chars dying on a stall should be automoved outside (the bodies). If not, fine, it's not a big deal.

Having done this, we'll have the first working implementation of the market stall in the game!

There are some security issues to be aware of though. Malicious users may use the HTML note feature to include misleading code that looks like it's the stall's shopping list, when it's actually fake. We can't allow the "Purchase" button to be easy to hijack this way and cause arbitrary items to be given to the malicious shopowner, even though they never set their part of the trade for sale. So the "Purchase" button/link needs to work the same way many other things currently already do in Cantr, with those auto-generated unique-number links, which are difficult or impossible to hijack.

Another issue is handling various borderline cases. What happens if just as I clicked "Purchase" and confirmed, the shopowner changed the price to something else or picked up the item? There needs to be a check that makes any ambiguity like that not possible, and if it's detected that something like this is occuring, just give an error message and cancel the whole transaction.

Would it be helpful to ProgD if I made the user interface HTML templates and posted here?

[BZR]

You need not to hurry. First, it should go to accepted aand be further discussed, as it's a major change. The quickest way to do it is asking people from GAB. Doug has already written that he has got no objection, but you could also ask someone else, maybe Jos, but before that write a shorter version, otherwise he won't bother reading it. Do it by email, if you want to be sure he receives it.

Personally, I would like to see some automation in trade, maybe not exacly what you propose, but the idea is worth considering.

[Cogliostro]

What disadvantages do you forsee in the proposed way and what alternative ones did you have in mind?

Btw, our "accepted" list is full of stuff that no one knows how to implement. We don't want this suggestion to be one of those, when it isn't all that coding-intensive and very doable as is.

[Doug R.]

This is definitely something that would have to be approved by Jos before being accepted. I can run it by him when I get the chance.

[Doug R.]

Update: I pitched this to Jos and he moved it to the GAC for discussion.

[Elros]

Update: I pitched this to Jos and he moved it to the GAC for discussion.

Cool.

[theguy]

This sounds like an amazing idea if we manage to get it implemented it would really boost trade.

Im totally for it unless somebody else finds a big problem

[Crosshair]

I love this idea.