My Solution to RMDC #1
A week ago I had published an RMdev challenge. You can read the problem here.
A number of solutions have been presented. Some of them are purely evented, and others use a mix of events and scripts. Here is my solution to the challenge, which also uses a mix of events and scripts.
The challenge requires us to display up to three villages that we can choose to teleport to. A village would only appear if we have already visited it, and the order that the village appears is based on the order that we visited them.
We can treat these as two separate problems
- How to keep track of the order that the villages are visited, and
- How to display them in that order in our choice selection
Tracking Visit Order
In order to keep track of village visit order, I will use events.
- One variable is used to keep track of how many villages have been visited so far. Initially it starts with 0, which means I have not visited any villages. Let’s call this the “total_villages_visited” variable.
- I assign a variable for each village. The value of the variable represents the visit order. If it’s 0, then it hasn’t been visited.
- When a village is visited for the first time, I would run an event that increases the total_villages_visited variable by 1, and then I assign this value to the variable for this village.
For example, if village A was the first village I visited, then my total_villages_visited variable would be increased from 0 to 1, and 1 would be assigned to village A’s variable. Now I know that village A was visited first.
Now, when I go and visit village C, my total would be increased from 1 to 2, and 2 would be assigned to village C’s variable. Now I know that village C was visited second.
Here’s an example of how Village A’s village tracking event would be set up. I use two pages: one for the initial visit, and the other for subsequent visits.
Because the order always increases by 1, we can just copy and paste this event to other villages and adjust the variables as needed.
Displaying Village Choices
This is where it becomes a bit tricky. Given that we only have three villages, and each display can have any combination of the three villages, in any permutation, there’s only so many cases to consider, but it’s still quite a lot
- None
- A
- B
- C
- AB, BA
- AC, CA
- BC, CB
- ABC, ACB, BAC, BCA, CAB, CBA
Which is not really something I would like to do manually because that’s a lot of work and a lot of duplication. Moving the actual transfer to common events would help, but it’s still a lot of work.
A Unified Common Event
Ideally, I would like to have just one event, preferably a common event, handle this teleport event for every case. It’ll look something like this:
However, the event editor does not provide the ability to set conditions for each option manually, so we’re kind of stuck if we went the pure event route.
Modifying our Choices
Because scripting is available to use, we can take advantage of it. The approach I use here is to create a new “filter and sort” method. Basically,
- Filter out all of the options that should not be shown, and
- Sort the options based on the order they are visited
The way the events are designed, we assume that when the visit order is 0, then it has not been visited. This can be used in our method as well: we filter out any choices whose visit order is 0.
The filter and sort method is pretty rough and looks like this
def sort_choices new_choices = [] @sort_order.each_with_index do |order, i| next if order == 0 new_choices[order] = @choices[i] end new_choices.compact! new_choices.each do |s| @choice_order << @choices.index(s) end @choices = new_choices end
You can see how I integrated this with the event system, but this is how I use it.
I basically took the original event and inserted a script call. This script call tells the engine what the order of the choices should be. Remember that the visit order is stored in variables. I defined a method called “var” that will allow me to access variables by name, but I could have easily just say $game_variables[2], $game_variables[3], and so on.
Now, I can have my teleport device run this event, and it will display only the villages that I have visited, and in the same order that I visited them:
Demo
I have setup a demo with all of the material that I used above. You can download it by clicking here
Summary
You may have noticed that there are common elements between different solutions. This is pretty normal. The difference lies in how the actual approach was implemented, and whether it can be extended to include additional cases.
In the end though, all that may matter is whether it works or not, as players probably aren’t going to care too much about the implementation details as much as whether it does what they think it does.
Spread the Word
If you liked the post and feel that others could benefit from it, consider tweeting it or sharing it on whichever social media channels that you use. You can also follow @HimeWorks on Twitter or like my Facebook page to get the latest updates or suggest topics that you would like to read about.
I like this challenge and the solution you demonstrated. Do you know of any other methods that would be more scalable for if you had 30+ villages?
Could’nt you use binary to make up the visited order? and then parse out that information from a variable? I guess using more variables takes out the middlepart of parsing, but it does use more variables instead. hmm hmm.
How do you propose using a variable to keep track of visit order, instead of a bunch of switches?
Huh, that’s interesting. What’s the use of ordering the villages by order visited instead of a pre-defined order, just an aesthetic preference, or so that player won’t know the canonical village order?
The value of the challenge is not so much whether there’s any practical value in having a specific order for your villages, but a way to actually order your event choices.
For example, instead of villages, what if it was a list of party members currently in the party? Would order suddenly make sense?
Yeah, I see what you mean there.