[VX] Level scaled shopkeepers

[Hoodlum]

Level scaled shopkeepers

Summary
'Level scaling shopkeepers' would be a script, that would allow us to create the shopkeepers with buyable items, that change during the game and depending on the level of the team. For example:
We have a shopkeeper Tom, who sells armor. Our party is on level 1, when we ask him for his good, we see buyable items like this:
- Leather armor
- Leather boots
- Leather cap
- Old gloves
But when party is at level 2, we could see:
- Iron armor
- Iron helmet
etc.
It should be highly customizable and processed via script command (Game_Interpreter class). Code should look something like this:

Code Select Expand

#-------------------------------------------------------------------------
# * Level scaled shopkeepers
#-------------------------------------------------------------------------

Shop1 = {
1 => [1, 30], [2, 25],   # Level => [item ID, price]
2 => [3, 45], [2, 15] }

Well, I'm not a scripter, it's just my idea of how it should like from RGSS way. I hope you know what I mean by this description and that's not so difficult to create.

Features Desired

• Customizing items depended on party's level in RGSS
• Calling the shop menu by Script command (Game_Interpreter)

Games its been in

• Skyrim, Oblivion, etc.

[modern algebra]

Wouldn't it be just as easy to do this with events?

Ie. have a common event which calculates the party's level, and then just have something like this in the shopkeeper event (or another common event, if you want to use the same shopkeeper elsewhere):

@>Conditional Branch: Level == 1
  @ShopProcessing
Else
@>Conditional Branch: Level == 2
  @>Shop Processing
Etc..


You could use a binary tree to reduce the number of checks you need to do of course.

[Hoodlum]

These branches are really painful, that's why I wanted to have it in RGSS. BTW, what's binary tree?

[modern algebra]

I really don't see how conditional branches are painful - it's mostly copy and paste. I would think a scripted solution would be far more painful to set up because you are working only with numbers, which means that for every item you need to close the Script Editor, open the database, find the item, get its ID, return to the Script Editor, add it to the array, and then repeat. The time saved by working with the regular shop mechanism more than makes up for any headache that conditional branches might cause.

With respect to the binary tree, It wouldn't reduce the number of conditional branches you had to make, but what it does is make it so that you don't have to run as many at any given time. It's very useful for eventing, especially for complicated eventing.

Basically, it's an alternative to the straightforward check, which is this:

@>Conditional Branch: Variable == 1
  # Shop when Variable == 1
Else
  @>Conditional Branch: Variable == 2
    # Shop when Variable == 2
  Else
    @>Conditional Branch: Variable == 3
      # Shop when Variable == 3
    Else
      @>Conditional Branch: Variable == 4
        # Shop when Variable == 4
      Else
        @>Conditional Branch: Variable == 5
          # Shop when Variable == 5
        Else
          @>Conditional Branch: Variable == 6
            # Shop when Variable == 6
          Else
            @>Conditional Branch: Variable == 7
              # Shop when Variable == 7
            Else
              @>Conditional Branch: Variable == 8
                # Shop when Variable == 8
              End
            End
          End
        End
      End
    End
  End
End

That's great when the variable is equal to 1, since it will only do one check, but as the variable increases, you need to do more and more checks. The above example is only 8 gradations, but it could go much higher. Anyway, with enough of these types of events, you may generate some lag in-game.

A binary tree would be set up as follows:

Conditional Branch: Variable < 5
  Conditional Branch: Variable < 3
    Conditional Branch: Variable == 1
      # Shop when Variable == 1
    Else
      # Shop when Variable == 2
    End
  Else
    Conditional Branch: Variable == 3
      # Shop when Variable == 3
    Else
      # Shop when Variable == 4
    End
  End
Else
  Conditional Branch: Variable < 7
    Conditional Branch: Variable == 5
      # Shop when Variable == 5
    Else
      # Shop when Variable == 6
    End
  Else
    Conditional Branch == 7
      # Shop when Variable == 7
    Else
      # Shop when Variable == 8
    End
  End
End

This is a binary tree, and what it does is essentially check a value in the middle first, knowing that if the variable is > than that, then you won't need to check any values less than that. Think of it the way you would search a dictionary. You don't open to the first page and check every entry for your word. You open to somewhere in the middle, if the first word on the page you flip to is alphabetically before the word you are looking for, then you know you don't have to check any of the pages preceding the one you flipped to.

This reduces the number of checks you have to do. In the above example, you will never need to do more than three checks no matter what the value of the variable is. So, if the value is 1 or 2, then the straight search would be faster, but the binary tree search would be the same for 3 and faster for any values greater than 3.

The more values you need to check, the more efficient the binary tree is. SO, if you had to check, say, 100 entries, than using the straightforward method you would potentially need to do 100 checks in one frame. Using this method, you would only ever need to do 6.