Jump to content

  • Log In with Google      Sign In   
  • 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
            # 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.


#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
            # 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.


#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