flareteam / flare-game

Fantasy action RPG using the FLARE engine
http://flarerpg.org/
Other
1.12k stars 236 forks source link

Buyback should be separeted each maps. And about Price of Buyback. #657

Open sujiniku opened 6 years ago

sujiniku commented 6 years ago

In alpha_demo , it is strange that Talrych shares Buyback with frontier people. So, for each map, we should separate the Buyback.

If empyrean_campaign likewise, the merchants on a different map share Buyback, it is strange.

If change to separate Buyback each maps, this can be used in future, when a game creater makes multiple shops where he can shop during his/her game.

dorkster commented 6 years ago

I recall having the buyback be global across all vendors being a deliberate decision. It's a tradeoff of gameplay quality-of-life over realism.

dorkster commented 6 years ago

If we do decide to implement this at some point, I think we should go all the way and have the buyback stocks be per-NPC instead of per-map.

JanetHunt commented 6 years ago

More realism would do the game good as I see it. Buyback should be more restricted

  1. separate list for each instance where this feature is available
  2. price difference of 30-50% over sell price when item is not returned in same deal session
  3. time related disappearance of a percentage of the sold items (may be tricky to calculate to not let the list become "all-empty")
JanetHunt commented 6 years ago
  1. perhaps some of the items could appear at other dealers over time, but they should not multiply
dorkster commented 6 years ago

Okay, I've made it so that each NPC has its own buyback: https://github.com/clintbellanger/flare-engine/commit/18e46de130d5fa1b5d7c7ee4fe91c9bf46ff39e6

Play testing revealed that having a shared buyback resulted in the buyback getting cluttered very quickly. Separating the buybacks should reduce this a little.

@JanetHunt Let me address a few of your points:

  1. This would punish players that wanted to take a break. The idea behind saving the buyback in the first place is so that players who play in multiple sessions have a similar experience to those who play in one long session.
  2. This would likely require keeping track of when items get sold, which I think would complicate things too much.
  3. Again, let's keep the buyback system simple and consistent. Items in the an NPC's buyback should stay with that NPC forever until they either get bought back or pushed off the list.
JanetHunt commented 6 years ago

First of all, I don't really want to interfere with the designers of this game, so everything I say here is more to the enjoyment of discussions and perhaps in the hope it might prove helpful.

  1. a price difference makes sense because the user is punished for bad decisions, and that's how it should be in a game. Moreover it looks more credible as real deals would act the same. To alleviate the dealing situations, during one deal session the items remain same price so the user can revoke his moves. I don't see an issue in making breaks, actually. Extra load to implement as you rely on type-related prices, apparently. You could enlarge the topic and make prices adaptive to quest situation, e.g. in remote an dangerous places prices go up for some items. Ok, that's a bit of luxury then.
  2. are you working multi-threaded? on an item-deal you could throw a random on a) whether the item will be removed, and b) on the delay it will be removed. After this you could put an item-remove task into a Timer queue which perhaps exists (or you might have to create). Depending on whether the timer is available, this is more or less plenty of work. :)
  3. this is agreeable; I only wanted to show possibilities.
dorkster commented 6 years ago

So the way to do this seems to be timers for each item in the buyback that persist over sessions. That way the player's playtime is the only thing affecting the prices. Item prices would slowly increase until they reach their original buy value. The time this would take would able to be set by modders.

I think this would be an interesting post-1.0 feature to implement.

JanetHunt commented 6 years ago

I have thought a bit more about it. Your trade panel could come with a set of parameters about the dealership situation, where I walk from assumption that item prices have a type-related base. a) percentage of price level; this raises or lowers prices of all items and refers to an environmental or other game-related situation that wants to play with the price level. b) percentage of sell-price reduction; this is the ratio of price shortage by which items can be sold back to the dealer. Some NCP may be very friendly and the value would be zero, others are leathernecks and the value could be 50. c) boolean whether players can instantly backbuy (not loosing Gold) d) percentage of backbuy wastage; random applied to items sold to the dealer on whether they will get lost (boolean) e) wastage playtime range; value of playtime which is the maximum period after which waste-destined items will disappear from the panel

Actually you wouldn't need a separate list of Timer tasks for each dealer or item, just one Timer structure would suffice as it is the nature of Timer threads that you can load them with plenty of tasks. Above this I think a Timer structure is not really required - as a thread - but you could simulate such a function by operations performed on a task-list when entering a dealership panel (display). What is true - and perhaps most cumbersome - is that you have to serialise and store all these tasks.

sujiniku commented 6 years ago

If flare raise the price of sales over time elapsing, flare need to count the time that the Hero is out of town (such as Perdition or Frontier Outpost). Or flare need to count the number of steps that the Hero walked outside the town.

Walking hours inside the town should be excluded. Because the price rising during shopping is strange.

About the trader in the dungeon, flare should sets not to raise the price as long as the Hero is within a little range area around the trader.

sujiniku commented 6 years ago

If we adopt a plan to raise the price of items sold after over time, I think that it is better that flare should create new tab such as "used" at trade menu tab, and after a certain time flare should move the sold inventory from "Buyback" to "used". In addition to "Inventory", "Buyback" on the tab of trade, it is a further addition of a tab called "used".

In used, I think that it is better to make it possible to buy it at half of the first price.

The way the price gradually increases is complicated for the player. For simplicity, "Buyback" should be able to buy at the same price as the first price.

dorkster commented 6 years ago

I think a lot of the discussion here (mine included) is over-complicating this issue. The purpose of having a separate buyback price is so the player can quickly revert a mistake of having sold an item they didn't want to sell.

The buyback price should not persist over sessions and map changes. Basically, the engine should track which items were sold during the current session/map and use the buyback price only for those items. Any other items should be sold at the normal buy price. That way, there's no need for timers or saving any more game state.

sujiniku commented 6 years ago

It is natural that items sold at stores are ordered as items in the store. It is so in the real economy, and second - hand goods dealers and so on do. Also in the game industry history of USA, in "wizardly" , items sold to the store are added to the product shelf.

At Flare, at shopping, since there are many blank space in the lower half of the item column on the vendor side at the time of purchase, I think that it is good to put a list of used items there.

How to price second hand goods depends on store policy. If the game creator want to sell at the same price as a new one, the store should do so. If the creator want to sell at half the price of a new item, the store should do so. The price rate should not be forced on the engine side.

Also, there may be shops that don't want to handle second hand goods should do so. Of course, in this case, once the item disappears from Buyback, the player can not buy that item at that store anymore.

About the engine side, Flare should be designed to able to deal with whatever management policy of store's owner.

sujiniku commented 6 years ago

Monsters may be attacked during shopping. During the trade with abasi, monsters are often attacked. So, I'm against the plan to extinguish Buyback by the end of the session. I think it is good to shorten the storage period as much as 10 minutes after the session is over.

Also, we need to think about the case of game over in the middle of shopping.

dorkster commented 6 years ago

How to price second hand goods depends on store policy. If the game creator want to sell at the same price as a new one, the store should do so. If the creator want to sell at half the price of a new item, the store should do so. The price rate should not be forced on the engine side.

We can make it an engine config variable, like vendor_ratio. That way, modders can opt to not use it, or make it a percentage other than 100%.

Monsters may be attacked during shopping. During the trade with abasi, monsters are often attacked. So, I'm against the plan to extinguish Buyback by the end of the session. I think it is good to shorten the storage period as much as 10 minutes after the session is over.

It's the player's responsibility to secure their own safety when dealing with traders out in the wild. If the player does die in such a situation, the buyback items won't be gone. They'll just be more expensive.

dorkster commented 6 years ago

Implementation here: https://github.com/clintbellanger/flare-engine/commit/d5a531c8fc03a6e2b4c5f74176078d753db11b84

The default behavior is the same as Flare 1.0, but I've set the value in the empyrean_campaign mod to 100% of the buy price.

sujiniku commented 6 years ago

I played this feature. I think this feature is good. In empyrean, the price of Buyback will rise after the map transition. But in alpha_demo, the price remains at sold price (i.e. price is not raised). I think this is also good. Because , if the player can compare these two mods and compare, the player can understand the mechanism of the Flare engine. Also, since alpha_demo can buy back at a low price, it is easy for players. This is also good. Because the difficulty for players is separated in contrast such as "alpha_demo is easy" and "empyrean is hard".