Quote:
Originally Posted by Yawgmoth
Remember that the original idea was to make the system as simple as possible, and all the searching improvements based on coding some information into the data that gets broadcasted by PartySearch may be more complicated than the rest of the system to design and implement. It may be just going too far while it's not necessarily needed. The simpliest possible idea was to not change anything in the PartySearch at all except for adding that [View Items] button. And it would be ages ahead of what we got now.
|
I've never believed your claim about this being as simple to implement as you claim. And while it will be better than what we have now, we can still propose tweaks to make it better. So lets give ANET various options under the same basic idea to work with, and let them decide which is better to implement.
I'm also operating under the assumption that, because of the number of stores, the stall window will be separate from the party search window to save bandwidth for ANET.
[quote[However some kind of searching would be a nice improvement and your idea of completely abandoning store names set by users to use all the space for automated coding information about the sold items for searching purposes could be fine if designed right. But it's really not an easy task, and after some serious thought I know that I wouldn't be able to plan a design for it.[/quote]
Here is a rather inefficient way to do it:
- 1 byte for the item type (sword, staff, shield, etc), including the items attribute for things with multiple attributes (wands, shields, etc). The remaining number will be used to indicate non-weapon items (in which case the following bytes will be used for other data).
- 1 byte for the skin. If we assume an 8-bit byte, we can have up to 256 skins to chose from. So make one skin number mean a green and there will be lots of room to add new items later.
- 1 byte for the weapon req. If the skin number says a green weapon, this will say which green.
- 1 byte to specify the inherent mod type. An inscription slot (empty or full) will count as an inherent mod.
So thats 4 8-bit bytes for each item. With 31 bytes we get 7 items and 3 extra bytes. But because GW supports non-english characters, I think we are dealing with more than 8 bits for each character in the party search window. So with 16 or 32 bit bytes, or a more efficient algorithm, we can either have more items or include other data (price is the only other one I can think of).
Quote:
The problem is designing an efficient way to use all the space and selecting the most important data to be encrypted there. As the only way of actually finding something there would be through these searches, it may become a barrier for the more casual players/buyers. Also it may be hard to find the most important qualities of items to be used there which would apply to any kind of item someone might want to sell, so that the new search engine could find any item existing in game. Even the new searching interface would have to be pretty massive to include all the options and filters.
|
For sellers placing an item in the stall, they will go through the following steps:
1 - Decide items price
2 - Place item in stall
3 - Decide stall name
4 - Wait for sale
Step 3 is removed by auto-generated names.
For buyers its just a matter of selecting checkboxes at each step, then browsing the stalls to find the item he wants to buy. I don't see these steps being misunderstood easily. But if we remove a step, it means the list of stalls will display more stalls with no items the buyer wants.
Though once the search is completed, it might be possible to have your GW client automatically open up each stall to get the info on the item, then display them into a list (sorted by price) while hiding all the other items being sold. This would ruin the stall feel, but will probably make the trading easier for players.
Quote:
Apart from that, I see no reason of disallowing any items from being sold there (maybe with an exception of customized items to prevent scamming). If people want to sell crap, let them do it. There would still be 1 shop and a limited number of items to be sold per player, so no difference what is being sold. I'm sure nobody at Anet would want to work on a detailed list of allowed and disallowed items when there's no need for that.
|
Disallowing items does the following:
- Reduces the amount of crap a player would have to skip to find the items they want to buy. Even with the exclusions I proposed a lot of crap will still get in.
- Makes it easier to design a filtering system.
-
Reduces the server load of the stalls, meaning less lag. Even if they don't cause enough load to cause lag, more crap means more stalls, meaning higher bandwidth costs for ANET.
- Lets people know that their non-max white FDS is worthless, so they don't get their hopes up.
- For items that the traders can handle, the more that go via the trader the better its price reflects market value. The trader probably will use a lot less server resources to do so.
Quote:
We also have to remember that the whole thing should be easy to use by anyone, even the most casual players. That and the difficulty to design are the reasons I think a simple text string based filtering + possible several filtering checkboxes, like those presented in my post #62
|
A fully auto-generated name means the entire filtering can be done with checkboxes, which should be easier to use than a text string search.
My intent is for the stall name generation and the entire filtering system to be handled clientside, meaning that at worst it takes a while to do on slower machines. If ANET decides that running the search serverside is a better idea than transferring the entire store list to the clients then I expect that they will optimize the database for the search. This will make it hard to view all the items any particular player is selling (I'll elaborate on this if asked), so the search will only return the items we specify in the search.