• Create Account

### #ActualKhatharr

Posted 29 December 2012 - 01:08 PM

The RMXP method was to create a set of 'canned' dialog reactions inside the main game script in a section called "Interpreter". Events had different kinds of triggers that were configurable in the main RMXP UI and those were basically converted into Ruby objects and marshalled for use at runtime. When an event trigger happened the event's internal store of Interpreter commands would get executed, so it was basically a doubly scripted system, which made editing events in the UI very easy but managing events from the Ruby side (which there was no real need for) was very clumsy since the event objects got incredibly complex.

Example of 'Interpreter' method:

class Interpreter
#--------------------------------------------------------------------------
# * Show Text
#--------------------------------------------------------------------------
def command_101
# If other text has been set to message_text
if $game_temp.message_text != nil # End return false end # Set message end waiting flag and callback @message_waiting = true$game_temp.message_proc = Proc.new { @message_waiting = false }
# Set message text on first line
$game_temp.message_text = @list[@index].parameters[0] + "\n" line_count = 1 # Loop loop do # If next event command text is on the second line or after if @list[@index+1].code == 401 # Add the second line or after to message_text$game_temp.message_text += @list[@index+1].parameters[0] + "\n"
line_count += 1
# If event command is not on the second line or after
else
# If next event command is show choices
if @list[@index+1].code == 102
# If choices fit on screen
if @list[@index+1].parameters[0].size <= 4 - line_count
@index += 1
# Choices setup
$game_temp.choice_start = line_count setup_choices(@list[@index].parameters) end # If next event command is input number elsif @list[@index+1].code == 103 # If number input window fits on screen if line_count < 4 # Advance index @index += 1 # Number input setup$game_temp.num_input_start = line_count
$game_temp.num_input_variable_id = @list[@index].parameters[0]$game_temp.num_input_digits_max = @list[@index].parameters[1]
end
end
# Continue
return true
end
@index += 1
end
end

Example of actually setting up an event in the UI:

[attachment=13010:rmxp.JPG]

The improvements in the console game were that the script commands were written in a proprietary bytecode stored in a table. Events were placed on the map and initialized with a specific set of triggers linked to specific entry points in the table. Strings were stored separately in other tables and referenced by the scripts to display dialog. This made the events a lot more lightweight than an RMXP event would be since the logic contained in the event object was very small and just included different entry points to the main logic table.

### #3Khatharr

Posted 29 December 2012 - 01:06 PM

The RMXP method was to create a set of 'canned' dialog reactions inside the main game script in a section called "Interpreter". Events had different kinds of triggers that were configurable in the main RMXP UI and those were basically converted into Ruby objects and marshalled for use at runtime. When an event trigger happened the event's internal store of Interpreter commands would get executed, so it was basically a doubly scripted system, which made editing events in the UI very easy but managing events from the Ruby side (which there was no real need for) was very clumsy since the event objects got incredibly complex.

Example of 'Interpreter' method:
class Interpreter  #--------------------------------------------------------------------------  # * Show Text  #--------------------------------------------------------------------------  def command_101    # If other text has been set to message_text    if $game_temp.message_text != nil # End return false end # Set message end waiting flag and callback @message_waiting = true$game_temp.message_proc = Proc.new { @message_waiting = false }    # Set message text on first line    $game_temp.message_text = @list[@index].parameters[0] + "\n" line_count = 1 # Loop loop do # If next event command text is on the second line or after if @list[@index+1].code == 401 # Add the second line or after to message_text$game_temp.message_text += @list[@index+1].parameters[0] + "\n"        line_count += 1      # If event command is not on the second line or after      else        # If next event command is show choices        if @list[@index+1].code == 102          # If choices fit on screen          if @list[@index+1].parameters[0].size <= 4 - line_count            # Advance index            @index += 1            # Choices setup            $game_temp.choice_start = line_count setup_choices(@list[@index].parameters) end # If next event command is input number elsif @list[@index+1].code == 103 # If number input window fits on screen if line_count < 4 # Advance index @index += 1 # Number input setup$game_temp.num_input_start = line_count            $game_temp.num_input_variable_id = @list[@index].parameters[0]$game_temp.num_input_digits_max = @list[@index].parameters[1]          end        end        # Continue        return true      end      # Advance index      @index += 1    end  end
Example of actually setting up an event in the UI:

[attachment=13010:rmxp.JPG]

The improvements in the console game were that the script commands were written in a proprietary bytecode stored in a table. Events were placed on the map and initialized with a specific set of triggers linked to specific entry points in the table. Strings were stored separately in other tables and referenced by the scripts to display dialog. This made the events a lot more lightweight than an RMXP event would be since the logic contained in the event object was very small and just included different entry points to the main logic table.

### #2Khatharr

Posted 29 December 2012 - 01:03 PM

The RMXP method was to create a set of 'canned' dialog reactions inside the main game script in a section called "Interpreter". Events had different kinds of triggers that were configurable in the main RMXP UI and those were basically converted into Ruby objects and marshalled for use at runtime. When an event trigger happened the event's internal store of Interpreter commands (stored in string format, IIRC) would get executed, so it was basically a doubly scripted system, which made editing events in the UI very easy but managing events from the Ruby side (which there was no real need for) was very clumsy since the event objects got incredibly complex.

Example of 'Interpreter' method:

class Interpreter
#--------------------------------------------------------------------------
# * Show Text
#--------------------------------------------------------------------------
def command_101
# If other text has been set to message_text
if $game_temp.message_text != nil # End return false end # Set message end waiting flag and callback @message_waiting = true$game_temp.message_proc = Proc.new { @message_waiting = false }
# Set message text on first line
$game_temp.message_text = @list[@index].parameters[0] + "\n" line_count = 1 # Loop loop do # If next event command text is on the second line or after if @list[@index+1].code == 401 # Add the second line or after to message_text$game_temp.message_text += @list[@index+1].parameters[0] + "\n"
line_count += 1
# If event command is not on the second line or after
else
# If next event command is show choices
if @list[@index+1].code == 102
# If choices fit on screen
if @list[@index+1].parameters[0].size <= 4 - line_count
@index += 1
# Choices setup
$game_temp.choice_start = line_count setup_choices(@list[@index].parameters) end # If next event command is input number elsif @list[@index+1].code == 103 # If number input window fits on screen if line_count < 4 # Advance index @index += 1 # Number input setup$game_temp.num_input_start = line_count
$game_temp.num_input_variable_id = @list[@index].parameters[0]$game_temp.num_input_digits_max = @list[@index].parameters[1]
end
end
# Continue
return true
end
@index += 1
end
end

Example of actually setting up an event in the UI:

[attachment=13010:rmxp.JPG]

The improvements in the console game were that the script commands were written in a proprietary bytecode stored in a table. Events were placed on the map and initialized with a specific set of triggers linked to specific entry points in the table. Strings were stored separately in other tables and referenced by the scripts to display dialog. This made the events a lot more lightweight than an RMXP event would be since the logic contained in the event object was very small and just included different entry points to the main logic table.

### #1Khatharr

Posted 29 December 2012 - 12:54 PM

The RMXP method was to create a set of 'canned' dialog reactions inside the main game script in a section called "Interpreter". Events had different kinds of triggers that were configurable in the main RMXP UI and those were basically converted into Ruby objects and marshalled for use at runtime. When an event trigger happened the event's internal store of Interpreter commands (stored in string format, IIRC) would get executed, so it was basically a doubly scripted system, which made editing events in the UI very easy but managing events from the Ruby side (which there was no real need for) was very clumsy since the event objects got incredibly complex.

The improvements in the console game were that the script commands were written in a proprietary bytecode stored in a table. Events were placed on the map and initialized with a specific set of triggers linked to specific entry points in the table. Strings were stored separately in other tables and referenced by the scripts to display dialog. This made the events a lot more lightweight than an RMXP event would be since the logic contained in the event object was very small and just included different entry points to the main logic table.

PARTNERS