Magnum Opus, I: Creating Procedural Dialogue

It may be early to claim what my life's work will be, but I'll do it anyway.  I want to create an RPG system on the complexity level of Dwarf Fortress, but where DF focuses on Fortress building and exploration, I want to focus on creating immersive villages and cities that feel alive.  This system would be open source and portable to other games, alleviating the problem of creating economic and social systems, so the designers could focus more time on creating other aspects of the game world.  

One aspect of this system is that different NPCs (non-playable characters) seamlessly communicate with each other.  I mean full sentences of dialogue where each interprets the other's message.  This doesn't have to be complete AI, it just has to be a Turing-level of convincing.  When a player stumbles upon two characters talking, she'll think the dialogue was prewritten or that the characters are alive.

Example:

Paul: "Good morning, Cindy."

Cindy: "Hello again, Paul."

Paul: "Do you have any fresh bread?"

Cindy: "I'm sorry; I'm all out."

Paul: "Damn, any bagels?"

Cindy: "Yes!  Would you like those toasted?"

Paul: "Please, and with some cinnamon spread."

Cindy: "Here you go.  Is that all?"

Paul: "Yes, thanks!"

Cindy: "Have a great day."

That's on the simple side of transactions, basically the first milestone of a huge undertaking.  So what's required for this?  How am I going to break up a vastly complex system of communication into a doable project for one mere mortal?

Taking the straight forward road, this would be impossible with current tech.  It would require the holy grail of AI.  And game making is anything but direct; it tends to be smoke and mirrors.  So to accomplish the same conversation, I am first looking at the following system.

Split conversation into dialogue and intent.  The dialogue is what's created based on intent.  Intent is the universal language that the game entities speak to each other.  Here's that interaction in pseudo code.

Paul.update(isHungry = True)

Paul.goes(breadstore)

Paul.sees(Cindy)

Paul.greeting().  

#If Cindy isn't busy, conversation starts successfully by her returning:

Cindy.greeting().  

Paul.requests(bread)  

Cindy.checks(bread) #on her inventory.  

Cindy.answers(False)  

Paul.requests(bagel)

Cindy.checks(bagel)

Cindy.answers(True)  

Paul.requests(cinnamon spread).

Cindy.checks(cinnamon spread)

Cindy.answers(True)

Cindy.trade(Paul, [bagel, cinnamon spread], items.cost())

Paul.acceptTrade()

Cindy.requests(MoreRequests)

Paul.answers(False)

Paul.Goodbye()

Cindy.Goodbye()

So there's the metaconversation, the Intent.  That's the simple part.  If you've ever worked with network programming patterns, some of those methods should look pretty familiar.  That conversation could be accomplished with two instances of one class with an inventory attribute and a few different communication methods.  The part I'm most excited about tackling is the conversion of intent to human readable language using grammatical patterns and simplified thesauruses.

So greeting can be "{Identifier}, {Greeting}{Punctuation}" and you could feed in random words like Greeting = ["Hello", "Good Morning", "Hi", "Salutations"]  and Identifier = [Target.Name, "Stranger", "Sir", "Friend"].  Ideally, I would feed in nonrandom words.  So stranger would be use in the condition that Speaker does not know Target, i.e. Cindy does not know Paul and is meeting him for the first time.    The request would be "{Question {item}}?", as in ["Do you have %item", "I would like a %item", "May I have a %item"].

The next time I write about this, I want to have a small, working prototype.  The conversation it outputs may look very familiar...

Elementa: Level Design Process

This is way old now, but it was either let it sit forever, delete it, or publish it.  The first two seemed cruel.  It was a good set of design meetings.  In the end we built out the pieces of the level but set them aside to try an easier level.

For the first level of Elementa, we decided to build the Air Challenge.  I focused my initial design on the concept of air movement and how the elemental aspect of the level would tie in with the game as a whole.  I considered keywords such as weathered rocks, floating, flying, being high above the clouds, canyons, and anything seemed breezy or blowing.

Draft I

Summary: An angry god of air roamed these cliff sides for years, gouging a narrow circular path.  But now, he's bound at the pinnacle.  You must defeat his guardians to summon him down.  When he arrives, he'll continue to roam the paths of the canyon, tearing down boulders and elemental shards that you'll have to avoid while you attack him.

Brainstorm: The team wants to move away from bosses.

Solution: Take out the boss element.  Since there was no reason for the canyons with him gone, I tried a different system, one that would require fewer objects, since the walls of the canyon would have been a lot of work to build and texture.

Draft II

Summary: On top of a pinnacle, the elemental creatures are tearing down four Sigils protecting the cliffs.  They have already destroyed one.  Each sigil is being attacked by a giant.

Brainstorm: Make the areas fit within the camera.  You don't get much chance to see the ground below.  Also, why are you doing the same thing three times?


Solution:  Separated the pinnacles into four separate mountains

Draft III

Summary: On top of four pinnacles, the elemental creatures are tearing down four Sigils protecting the cliffs.  They have already destroyed one.  Each pinnacle has a different challenge [in progress].  You start at the northwest tip so you can see the base of the cliff far below.

Brainstorm:  What if the mountains are floating islands (then the concept artist drew chains holding them to the ground and I was struck by inspiration).  Why is each challenge the same? Also, why are there Sigils?

Draft IV

Summary: On top of four floating islands chained to the earth, elemental creatures are tearing down the four Sigils that anchor the islands.  One has been destroyed and the island is floating off.  You start there.  Each sigil is being attack by different monsters.  The first sigil is being attacked by small creatures, the second by a giant, and the third by a mix of giants and critters.  If the monsters destroy any of the sigils, the story changes.  If you die, you start over at the beginning of that individual isle.

Brainstorm: Let's build this!

Yore Playtest 8, 9, 10, and 11: In which dice make a welcomed reappearance.

 After the seventh playtest, I took some time to gather my thoughts.  Failure is a necessary experience, but that doesn't make it any less a bitter draught.  Cards were getting out of hand and they were not any less random or rewarding than dice.  So I decided to try dice again.  Golem uses dice efficiently, so I modeled the combat system after it.

There are still three stats (mental, magic, combat), but they now control how many dice you roll, what counts as a victory, and whether you can reroll dice.  It's still not quite there, but it makes for a quick and eventful game.

Also, I'm playtesting all of the mechanics together this time.  We play a shortened game where only half of the board is available.  No more empty rooms clutter the board, which keeps players from having boring turns.

Players also have more choice.  The object of the game is to gather as many orbs as you can.  But those orbs can also be used to buy items or learn new skills.  So there is a cost-benefit theme to the game.  You can level your character up or you can hoard.  There comes a point when hoarding isn't that efficient.  There also comes a point when leveling up isn't efficent, but I leave that to the player to decide.

So far, over the course of playtesting, the game is better.  Some of the characters are a bit unbalanced.  I'm working to address them. There is certain sterileness to it though, possibly because of it being a thinly-veiled probability game.  So that's my next step: making the gameplay a little less sterile and tweaking some of the numbers to make things more balanced.

Yore Playtest 7: In which someone loses an eye.

Many days ago, we untook the second major playtest.  It was brutally painful.  Until that point, I had been playtesting a subsection of the game: the combat.  But when I brought all the pieces back together, blood was shed.  The blood of the innocent.  Write this in your fancy leather-bound game notebook: parts are not representative of the whole.  While I had balanced one aspect of the game, the rest of the game did not mesh well with it.   The resulting game was as stillborn as a pickled fetal pig.

What did the game look like?

The game involved exploring a system of dungeons.  You could encounter an empty room, treasure, or a monster.  If you encountered a monster, a card-based combat system started.  In combat, you had abilities you could chain together to match the symbols in front of the monster.  If you beat a monster, you could turn it in to learn new skills.  The object of the game was to end with the most number of points, granted by treasure cards.

Why was it frustrating?

1. Empty Rooms.  1/3 of the rooms were empty, so an entire turn would be spent for a player to do nothing.  One player ended up with six empty rooms in a row.
2. Treasures were 50% potions.  Two players ended up with all of the treasure.  One had all of the potions and was unbeatable.  The other had all of the valuable cards and won the game.  The remaining players had nothing.
3. Cards were everywhere.  The game had ten stacks of cards, took up a lot of space, and involved a lot of maintenance.
4. No choice.  The game offered a number of choices for what you could spend experience points on.  However, the abilities were all mainly the same.  There were no compelling reasons to pick one strategy over another.

Read tomorrow for how I have addressed those problems.

Piecing Together GOLEM

The title is clever because golems are made of pieces of things. That's what I told myself when I wrote it. Please keep reading my blog post.

I'm sitting on a decent amount of feedback for GOLEM after holding play tests 2 and 3 and I'm finding it hard to know where to start making my first improvements. People "have fun" playing the game. They seem to find it "enjoyable" every time. I feel like that's a "good" thing. I think I'll try to keep that going and "not blow it".

Biggest problems:

• Too many pieces ::
• I need to consolidate. This problem is worsened when we're reduced to using pennies, quarters, and a few glass mermaid tears as game tokens for money, victory points and health. Plus dice. I also have three different types of collectable items. Plus player tokens (observe in the picture below how player 2 is playing the role of a small tomato).
• Set-up and game time is too damn long ::
• Plain index cards don't shuffle very well at all. It's like trying to flip through a magazine with your nipples. No clever or exotic nipple contraptions to assist you. Just bare nipple on bare paper.
•  The math is off ::
• Well shit, I knew that. The problem is that other people have figured it out too. I need to make up some formulas for balanced card creation. Items and characters need fine tuning.
• Secret goals are pig ::
• Pig is the first word that came to my mind when I couldn't think of a word. So... as a key component, GOLEM uses secret goals. Wait, let me get out of these bullet points.

Please ignore the apples in the background. They're a future game expansion involving only fruit.

So... as a key component, GOLEM has secret goals which each player draws and reads at the start of the game. It's supposed to be one of the major ways players score victory points while still cooperating to defeat the GOLEM at the end of the game. A good example of a secret goal would be "Greed: Gain 1VP for each coin you have at the end of the game."

I need to rework them. Some of them are good but don't have enough of a reward, and some are straight up unobtainable within the confines of the game or even due to the random chance that an Island will be made of locations that don't give you what you need. From now on, I plan to record more details during play tests. Things like the number of potions and coins people have left. The number of Items. How many times they fought a monster. Their entire play experience. Knowing all of that might let me go back in later and create secret goals that fit their experience. It will also help me balance the ever important "distribution of crap."


I'm out. Rainbow rainbow.