Bartering Part Three

About a year ago, we started building out the concept of bartering in Violet.  In the first post on the subject, we explained where the idea came from, how it could be an interesting mechanic, and the drawbacks associated with it.  In the second post on the subject, we described in a little more detail how the player would be able to choose what to barter and the system that was needing to be updated to make that happen.

When we started working on it again, we wanted to get closer to solving the problem of “making bartering less tedious”.  Before the improvements, the NPC randomly chooses from our inventory items to trade.  We added a way for rejected items in a trade to not reappear randomly.  However, by using random, we would rarely ever get those items right — adding to many rejections until we would give up and choose the items ourselves.  This resulted in many, many clicks, adding tedium to the game.  Buying goods and services in games with an established currency is as simple as choosing the item / service, and confirming the purchase (and assuming enough funds exist for the player to make the said purchase).  This is essentially two clicks.  We wanted to get as close to two clicks as possible.  How could we get closer to solving for this?

If you haven’t guessed, removing the random element for the NPC to choose items was the first step.  In order to get close to “two clicks” we need that initial trade to be what the player would want to trade.  If we can get it right on the first try, we get three clicks:

1. Would you like to barter this burrito? <yes>
2. Will you give me your two hot dogs? <yes>
3. Thanks! <close>

So how do we make the game know that two hot dogs is what we want to trade?  Well, we’re glad you asked!

Coming Up With THE List

Every barterable item in the game has a weight associated with it.  We can think of this weight as “preference” — the bigger the weight, the more preferred the item is for the player.  The least preferred items are sorted at the top of the list while the most preferred items are at the bottom of the list. When the NPC starts determining whether they like the item or not, we start at the top of the list with the player’s least preferred items.  If the NPC likes an item, we add it to the list.  If they don’t like the item, or the combination of items, it doesn’t get pulled into the list.  Since we start at the least preferred items, we’re almost guaranteed that the player will be happy to trade the items.

Defining these weights gets a little bit trickier.  As the games continues to be built, we will add / update these values.  But here’s what we’ve come up with so far:

• When the game boots up, all items start at a weight of 0.
• When a player uses an item, the weight is globally incremented by a small value (weapons = 1, bows = 5, rods = 10, materials = dependent, but a smallish number).
  • Therefore, the more an item is used, the more preferred it is.
• When bartering, if the player rejects a list, (and eventually the player DOES accept a trade), each item’s weight in the rejected list gets incremented by 100 globally.
  • This is because we assume the player rejected the item because they prefer it.
• When bartering a weapon, if there is a difference in rank, we locally increment the weight by rankDifference * 250.
  • If we want a C ranked weapon and the NPC sees a D ranked weapon, the weight locally decrements by 250, making it less preferable.
• When bartering, if the player rejects a list, for the session (locally), each item’s weight in the rejected list gets decremented by 500.
  • This is because when the NPC “searches again”, we don’t want the similar items to appear again.

Though the above isn’t perfect, it gets us much closer to a bartering system that is less tedious and closer to the “two click” dream.

Other Notable Features and Fixes in the Past Two Months

Like usual, I began to think there wasn’t as much accomplished in the game.  But as soon as we look at the commit history, we realize we’ve been busy with many awesome things.  Take a look:

• Any object we want to have collisions with weapons can now do so:
  • For example, we can cut down a tree or break rocks with our weapons
  • Using an axe with a tree won’t level down the axe, or using a pick axe with a rock won’t level down the pick axe
  • However, other items with these said objects will level down them down
• We added a (rough) tree falling animation, as well as stumps for each tree

  

• Any object we want to take damage from temperature extremes can do so now:
  • We really wanted the special weapon “bomb” to explode when near fire, or in extremely hot places
• Fire Transfer on Weapons is much more refined:
  • We currently had it working with arrows, but now we can fairly easily add to whatever
  • We added to the stick weapons, which can now act as a torch for the player

    

• We added more placeholder sound effects:
  • As we started adding more collisions, it was getting jarring that the same effects would play
  • We also added looping sound effects, rain and fire, which ease in and out as there is more of it
• We added slope tiles:
  • If we are moving up and the slope tile is down, our speed will decrease
  • If we are moving down and the slope tile is down, our speed will increase
  • These are currently near cliffs, but we can be added anywhere
• Updated the collision of walls routine:
  • We noticed an anomaly with dodging in that huge amounts of speed were gained, even when colliding with a wall.  This has been patched so there is no clipping through walls this way (sorry speedrunners 😉 )
  • We also added a get unstuck routine, which basically finds the center of the hitbox of an object, and pushes the object that got stuck away from the center
• Updated camera zoom functionality to be more robust
• Fixed a memory leak on the pause screen

We also have two other big features that we’re going to make dedicated posts for:

• Updated / fixed the throwing of objects
• Added a disable rooms script to Game Maker Studio 2