My Solution to RMDC #1

Help spread the word!Share on FacebookShare on TumblrTweet about this on TwitterShare on Google+Share on LinkedInShare on RedditFlattr the author

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

  1. How to keep track of the order that the villages are visited, and
  2. 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.

rmdc1_solution3

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.

rmdc1_solution2

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:

rmdc1_solution4

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.

rmdc1_solution5

 

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:

rmdc1_solution6

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.

Help spread the word!Share on FacebookShare on TumblrTweet about this on TwitterShare on Google+Share on LinkedInShare on RedditFlattr the author

You may also like...

5 Responses

  1. Mireneye says:

    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.

  2. Arsist says:

    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?

    • Hime says:

      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?

Leave a Reply

Your email address will not be published.

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax