As a huge dork who likes to program a lot, I was thinking it might be fun to write a little about what makes the site tick. If there’s interest, I might write more like this in the future. Please feel free to reply with any questions/criticisms/etc about the code. Log in to see images!

This contains spoilers for episode one!

The sTalk Conversation Engine

The conversation system in Forumwarz is heavily influenced by the Lucasarts games I grew up playing. You are given a series of choices, and based on those choices and your current variables you can jump to other choices.

The first iteration I came up with was fairly simple. A subject in the conversation was represented by a row in a table. That subject had many pieces of dialog and many choices, stored in two other tables. The dialog is what would be displayed, the choices were references to other subjects.

As a proof of concept it worked pretty well. I created much of Shallow Esophagus’ first conversation with the player this way. However, once we started implementing it into the game some major flaws became obvious. The first was that many conversations needed to execute conditional logic.

For example, one of the early quests is to obtain a picture for Futanari Moe. If you have the picture the dialog goes one way, if you don’t it goes another. So the system needed to be able to check game variables and act differently depending on what they were.

The second problem was that conversations could trigger so many different things. Sometimes they might give you a bookmark, a mission, flezz or items. Upon realizing this limitation I basically threw away the database storage system and cooked up a DSL for Ruby where conversations could be written simply.

Here’s an example script from Gamble-Bot:

 def start_gambling
    actor_says "Hey there. Looking to win big?"
    
    choice :games, :say => "I sure am!"
    choice_end :say => "God no! Gambling offends my sensibilities!"
  end
  
  def games
    actor_says "You can play:"
    actor_says "- Blackjack"
    actor_says "- Paper, Rock, Scissors"
    
    choice :blackjack, :say => "I'm a fan of Blackjack"
    choice :paper_rock_scissors, :say => "Let's play Paper, Rock, Scissors"
    choice_end :say => "Actually I gotta go!"
  end

Since the scripts for the conversations were still Ruby, I was free to call any in-game functions and do fun conditionals and things like that. I coded up most of Gamble-Bot in an afternoon to test the limits of the flexibility of the system.

I thought the format was pretty simple, but when I showed it to the team they found it confusing. Since the plan was for Jalapeno to do much of the writing, if he wasn’t comfortable writing the Ruby scripts for the conversations then we had a problem. We needed an interface to design the chats!

I started working with the idea of a tree-like widget, but quickly realized that it wasn’t working, since leaf nodes had to link back to parent nodes. The conversations amount to a finite state machine, and building a GUI for that was quite a challenge. I finally sucked it up and started working on a rich Javascript app based on what I’d seen on Yahoo Pipes. It took a week to get a working version up and running, and then there were lots of refinements, but the interface looks like this:

Log in to see images!

Basically you can create as many “States” as you want, and drag them around a large scrolling grid. Then they can be connected to each other by creating “Choices” and linking them to other choices. It uses the canvas tag in Firefox to draw the arrows nicely with some bezier curves.

Sometimes things get a little tangled, but they’re generally not too hard to follow since states can be color coded:

Log in to see images!

Once the conversation is finished in the GUI, it can be compiled into Ruby scripts. The compilation involves a stage where each state is traversed recursively. This is done to create a quick look-up tree so that we can figure out what conversation steps you’ve already looked at. It doesn’t happen too often but sometimes you’ll see a choice is faded out.

The compilation is a one-way street: the Ruby scripts for the conversations cannot be edited and reloaded in the GUI, so all editing must be done visually.

It’s not a perfect system and still needs a lot of work. I will probably enhance it a bit for Episode 2 now that I know some areas where headaches occur. Having said that, I’m pretty proud of it, and considering conversations are so important to the Forumwarz gameplay I think it was worth the effort Log in to see images! Evil Trout edited this message on 02/25/2008 11:06PM

You mean . . . the people I talked to were MADE UP?

I’m going to cry myself to sleep now. I thought they were my friends.

How do I know YOU’RE not fake, Evil Trout? Did you just PROGRAM that evening of karaoke? And all the “friends” you brought?

Log in to see images!

Thanks for this, I always love looking at behind-the-scenes stuff. Do you know if you guys have produced the first browser game… on rails?

That is a sexy GUI for writing out the conversations. I applaud you on it.

Cubear Posted:

is there a reason avatars are 93 by 93? it seems awfully arbitrary.

It does, doesn’t it?

Actually I thought that was the standard size that MSN messenger used for avatars. Looking it up now they use 96×96, so who knows what I was thinking!

Flamebate could actually support higher resolution avatars with its layout, but there are so many other places where I’ve depended on that resolution that I didn’t want to allow people to upload bigger ones.

Ryouga Inverse Posted:

dongs Posted:

Thanks for this, I always love looking at behind-the-scenes stuff. Do you know if you guys have produced the first browser game… on rails?

I’m pretty sure there’ve been a couple other RoR games. Whether or not they succeeded is another story.

A lot of people consider RoR pretty slow (“Ruby on Snails” is a common turn of phrase) but I don’t think it seems that slow here Log in to see images! I think once it’s loaded up it’s just as fast as anything else.

I’ve been designing a browser game in my spare time that I plan on writing in Ruby. It’s a very nice language for almost any application.

There was a game called Unroll (llor.nu), but I’ve never been able to play it because it always seems to be down. The guy who created that now has a start up dedicated to making games in Rails, but I think they’re focusing on the educational market.

Ruby is actually a slow language, there’s no doubt about that. Metrics don’t lie. But nobody codes an app in Rails so that it’ll run fast. The beauty of Rails in my opinion is the speed to develop things. I can knock out features in just a few hours of code.

Also, it’s worth mentioning that it’s usually not the scripting language that causes a web app to be slow, it’s the database. Rails is process based so you could throw another front end server at it to handle twice as many requests at once. However, when those requests contend for the database, you’ll find yourself in a bottleneck Log in to see images!

just read the waxy article linking to this thread and i gotta say, the conversation editor is pretty NEAT! as a dev i loved to read alot more about the tech in the background… bow for the bezier curves! Log in to see images!

Evil Trout Posted:

As a huge dork who likes to program a lot, I was thinking it might be fun to write a little about what makes the site tick. If there’s interest, I might write more like this in the future…

As a huge dork addicted to playing this game and not being able to program stuff like this myself, I thoroughly enjoyed this snipplet and would appreciate to read more stuff like this, as your time permits… thanks for sharing! Log in to see images!

Great job, chaphand.

Who needs books when you have GoogleSentrillion?