Check out our blog!
Forumwarz is the first "Massively Single-Player" online RPG completely built around Internet culture.

You are currently looking at Flamebate, our community forums. Players can discuss the game here, strategize, and role play as their characters.

You need to be logged in to post and to see the uncensored versions of these forums.

Log in or Learn about Forumwarz

Civil Discussion
Switch to Role-Playing Civil Discussion

Viewing a Post

Evil Trout

MODERATOR
Avatar: 35 2023-04-24 23:24:10 +0000

[Crotch Zombie]

Level 21 Hacker

this site is deader than the toddlers in my basement

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

Internet Delay Chat
Have fun playing!
To chat with other players, you must Join Forumwarz or Log In now!