Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


#ActualKhatharr

Posted 29 December 2012 - 12:44 PM

I had intended to suggest a hybrid approach. Most JRPGs I've seen use a kind of markup language for displaying text with escaped characters representing dialog or timing events and allow a dialog to return state codes indicating user selections in interactive situations. I was just commenting on where to store the data. Like I said, I don't know about formal databases, so whatever's clever in that respect. You guys would know better than me.

If I recall correctly the game I'm thinking of examined the game flags and etc and then just used that to feed the dialog proc a pointer to a starting point. After that the dialog continued in a data-driven style. The markup language included things for displaying character names, triggering sound or music effects, changing the font style, waiting for a keypress, presenting a choice and returning a value or setting a flag/variable based on the selection, etc, etc.

The dialog calls were triggered by 'events' which were NPCs, triggers based on passing a line on the map, treasure chests or other things of that nature. There was some bytecode-style scripting that started when an event was triggered and the dialog call was within the script, so that based on the results of the dialog the game could remove or add characters or items. I was actually surprised how similar it was to the method used in RPG Maker, although it was a lot more optimized since it was a console game (string tables, condition tables instead of embedding everything in the event concerned).

#6Khatharr

Posted 29 December 2012 - 12:33 PM

I had intended to suggest a hybrid approach. Most JRPGs I've seen use a kind of markup language for displaying text with escaped characters representing dialog or timing events and allow a dialog to return state codes indicating user selections in interactive situations. I was just commenting on where to store the data. Like I said, I don't know about formal databases, so whatever's clever in that respect. You guys would know better than me.

If I recall correctly the game I'm thinking of examined the game flags and etc and then just used that to feed the dialog proc a pointer to a starting point. After that the dialog continued in a data-driven style. The markup language included things for displaying character names, triggering sound or music effects, changing the font style, waiting for a keypress, presenting a choice and returning a value or setting a flag/variable based on the selection, etc, etc.

The dialog calls were triggered by 'events' which were NPCs, triggers based on passing a line on the map, treasure chests or other things of that nature. There was some bytecode-style scripting that started when an event was triggered and the dialog call was within the script, so that based on the results of the dialog the game could remove or add characters or items. I was actually surprised how similar it was to the method used in RPG Maker, although it was a lot more optimized since it was a console game.

#5Khatharr

Posted 29 December 2012 - 12:32 PM

I had intended to suggest a hybrid approach. Most JRPGs I've seen use a kind of markup language for displaying text with escaped characters representing dialog or timing events and allow a dialog to return state codes indicating user selections in interactive situations. I was just commenting on where to store the data. Like I said, I don't know about formal databases, so whatever's clever in that respect. You guys would know better than me.

If I recall correctly the game I'm thinking of examined the game flags and etc and then just used that to feed the dialog proc a pointer to a starting point. After that the dialog continued in a data-driven style. The markup language included things for displaying character names, triggering sound or music effects, changing the font style, waiting for a keypress, presenting a choice and returning a value or setting a flag/variable based on the selection, etc, etc.

The dialog calls were triggered by 'events' which were NPCs, triggers based on passing a line on the map, treasure chests or other things of that nature. There was some bytecode-style scripting that started when an event was triggered and the dialog call was within the script, so that based on the results of the dialog the game could remove or add characters or items. I was actually surprised how similar it was to the method used in RPG Maker, although it was a lot more optimized since it was a console game.

#4Khatharr

Posted 29 December 2012 - 12:32 PM

<p>I had intended to suggest a hybrid approach. Most JRPGs I've seen use a kind of markup language for displaying text with escaped characters representing dialog or timing events and allow a dialog to return state codes indicating user selections in interactive situations. I was just commenting on where to store the data. Like I said, I don't know about formal databases, so whatever's clever in that respect. You guys would know better than me.<br />
<br />
If I recall correctly the game I'm thinking of examined the game flags and etc and then just used that to feed the dialog proc a pointer to a starting point. After that the dialog continued in a data-driven style. The markup language included things for displaying character names, triggering sound or music effects, changing the font style, waiting for a keypress, presenting a choice and returning a value or setting a flag/variable based on the selection, etc, etc.</p>
<p>&nbsp;</p>
<p>The dialog calls were triggered by 'events' which were NPCs, triggers based on passing a line on the map, treasure chests or other things of that nature. There was some bytecode-style scripting that started when an event was triggered and the dialog call was within the script, so that based on the results of the dialog the game could remove or add characters or items. I was actually surprised how similar it was to the method used in RPG Maker, although it was a lot more optimized since it was a console game.</p>

#3Khatharr

Posted 29 December 2012 - 12:28 PM

I had intended to suggest a hybrid approach. Most JRPGs I've seen use a kind of markup language for displaying text with escaped characters representing dialog or timing events and allow a dialog to return state codes indicating user selections in interactive situations. I was just commenting on where to store the data. Like I said, I don't know about formal databases, so whatever's clever in that respect. You guys would know better than me.

If I recall correctly the game I'm thinking of examined the game flags and etc and then just used that to feed the dialog proc a pointer to a starting point. After that the dialog continued in a data-driven style. The markup language included things for displaying character names, triggering sound or music effects, changing the font style, waiting for a keypress, presenting a choice and returning a value or setting a flag/variable based on the selection, etc, etc.

#2Khatharr

Posted 29 December 2012 - 12:27 PM

<p>I had intended to suggest a hybrid approach. Most JRPGs I've seen use a kind of markup language for displaying text with escaped characters representing dialog or timing events and allow a dialog to return state codes indicating user selections in interactive situations. I was just commenting on where to store the data. Like I said, I don't know about formal databases, so whatever's clever in that respect. You guys would know better than me.</p>
<p>&nbsp;</p>
<p>If I recall correctly the game I'm thinking of examined the game flags and etc and then just used that to feed the dialog proc a pointer to a starting point. After that the dialog continued in a data-driven style. The markup language included things for displaying character names, triggering sound or music effects, changing the font style, waiting for a keypress, presenting a choice and returning a value or setting a flag/variable based on the selection, etc, etc.</p>

PARTNERS