Combat-esque conversations?!?

So, to open my argument, here it is:

What if you could take the idea of a combat system, and use it for your NPC conversation system?

We all know dialogue trees are a drab workaround to letting a game's main character partake in conversations with the game's make-believe world.

Aren't you sick of that? Can we try to find a way around that somehow? Isn't it worthwhile at least to experiment, see if there is indeed some better way?

Craig Stern has this to say about dialogue trees in his article:

...This emergent quality makes combat a tempting choice to form the backbone of a cRPG, since it offers a much higher ratio of entertaining possibilities relative to development time spent than a more static system (such as, say, dialogue trees) would.

That was actually what led me to think about this whole idea in the first place.

If combat systems were designed to be so emergent (you can explore so many decisions and tactics) while only an economic amount of programming is required, why can't we try the same idea for conversations?

So how is it going to be? For starters, we can take this:

and turn it into this:

Its a very superficial take, but you get the idea, don't you?

When you choose "Attack", you see your character swing his sword and the enemy takes a hit. Then the enemy takes his/her turn.

When you choose "Insult", you perhaps would hear your character say a pre-recorded line of (insulting) dialogue, chosen partly in context and partly in random. And you'd see the expression on the other person's face, and see/hear his/her reaction.

I'm not proposing some sort of procedurally generated lines of dialogue. I certainly don't think our best technology so far can do it reliably.

What I'm thinking is scripts will still be made, its just that instead of choosing exact lines to say, the player "macromanages" the conversation.

Looking at that, its not such a radical idea, really. Many games experimented with this style before.

In Indigo Prophecy, instead of choosing specific lines of dialogue to say, you choose some topic, and your character automatically shifts the conversation to go there.

Same goes for Mass Effect to an extent.

Update: A whole list of other games with similar ideas by reddit include: Monkey Island's Insult Sword Fighting, Leisure Suit Larry, Deus Ex: Human Revolution.

But instead of choosing contextual topics at hand, what I want to see is a fleshed out system with rules akin to combat and everything that supports it: the importance of movement, targeting, stats, skills, perks and whatnot-- but for dialogue.

Skills and perks... all of that sounds overkill for a conversation system. But its worthwhile to study if some things can be translated here.

Interrogations in L.A. Noire comes very close to what I'm getting to.

Here was another impetus for me to jump-start the idea. Tonio Barmadosa has this to say about behavioral game design in this article:

Very interesting indeed. I can't help but draw an analogy with a totally different field, called Pickup Artistry. Pickup artists pick up hot babes in night clubs using methods from Behavioral Psychology. They push a girl's psychological buttons in order to create attraction, qualification, comfort and eventually seduction.

They use the exact same techniques, for example, being unpredictable and pushing and pulling all the time, which is equivalent to variable ratio reward / punishment.

We're getting somewhere here aren't we? "Picking up" can be thought of as a game. But one thing to note here is that you are not the player anymore, at least not purely. You also partake the role of umpire. You hand out the rewards to the player (i.e. the hot babe/guy) when you deem so. You make the player feel like s/he worked hard for something.

This is, of course, for seduction, but I think we can work out how it plays for other goals.

Goals for why we "talk" to NPCs may include:

1. To get useful information¹
2. To get useful feedback (as in suggestions, criticisms)
3. To progress in the story, main storyline or otherwise
4. For romance, as noted earlier
5. To coerce, persuade, or fool them for your advantage (bribes, taunts)
6. etc.

---

[1]: And this can even be while in a hostile environment. Black Widow's first scene in the recent Avengers movie, is where she fakes naïveté while actually collecting information from the enemy.



Let's see all of our tools at hand in a combat system.

In a combat system, the very first thing you want is a way to assess the enemy and the surroundings.

Practically, this means a health bar, maybe a grid to see how far they are, fog-of-war, etc.

In a conversation, maybe you can have a hostility/friendliness meter on your NPCs. Maybe even an irritability meter, or a boredom meter akin to The Sims.

Your high-level options then fall somewhere along these lines:

1. Inspection: assess the enemy
2. Aggression: extinguish the enemy (attack)
3. Conservation: survive/outlive the enemy (heal/defend)
4. Subversion: weaken the enemy from within (poison, slow, etc.)
5. Augmentation: strengthen yourselves (buffs)
6. Concession: surrender, truce, agreement, etc. (forfeit, load game, etc.)

This is all well and good, but how does "extinguish the enemy" translate to "find out why he's hiding from the bandits" for example?

Let's say that's our "victory condition".

For a goal of "find out why he's hiding", the enemy is not "he", it's his reluctance to say his reason for hiding.

These could be some examples of how it would pan out:

1. Inspection: asking questions
2. Aggression: pressuring, convincing the person
3. Conservation: defending your argument
4. Subversion: intimidating, lying
5. Augmentation: make yourself sound credible
6. Concession: bribery, bargaining with the person

Again, these are high-level examples. In the same way that saying "attack" in combat can be done in a multitude of ways, the act of convincing or intimidating would also be achievable in several ways.

I'm particularly interested in how spatial movement of combat can be translated to a conversation system. Perhaps that can represent the topic of conversation?

The same way attacking the rear of an enemy can deal critical damage, perhaps pushing the topic of conversation to something the person is uneasy with will make your persuasions "deal critical damage".

Even with having these commands and "movement" options, I think the end result of the player inputting such commands should still show two guys talking, complete with dialogue text, and prerecorded lines of dialogue if need be.

In this manner you could say in the end this is actually more complex than a simple dialogue tree system. It is, but imagine how this could change your game (I'm actually content with just text dialogue, but having audio dialogue will definitely make it harder).

If the player is losing, he'd usually just load a saved game, but what if he can bargain with his enemy?

What if the player can talk to a merchant to drop his guard or distract him?

It can open up more emergent possibilities.

Unity Game Jam Manila 2012 Part 3

On the final day, things started to get hectic. As the staff needed to go to the associated event to give a talk about game development, Charles and I found ourselves having to man the game jam (I couldn't find the marshals for a time, they probably needed to be elsewhere too!).

We needed to facilitate getting the participant's builds into the officially designated machine to be used to demonstrate the game during judging. We needed them to submit their builds, let them test it on the machine, and make sure they don't do something horrible like delete the other teams' folders.

Then Charles said he needed to assist some guests from the industry looking at the game jam, and I was left to man the machine (see what I did there?).

Occasionally manhandling the mic to nag them about the deadline, I was checking off which teams have submitted at least one build.

Some cut it close to just 10-20 minutes before the 5pm deadline (I'm not actually sure if it was an exact 48-hour jam).

And there was even one who, get this: she only attended the first day, then left for home, did the jam by herself in her house, then came up like 20 minutes from the deadline asking to get submitted.

As facilitator, Brett was a nice guy and let her submit for presentation, but it was up to the judges if she was eligible for the prizes.

Paul Gadi of IGDA Manila came by the jam venue and went just as fast. Apparently he was on short notice.

Then a guy gave me a scoring sheet and said, "You're going to be a judge. Paul Gadi couldn't make it to the judging so you'll stand in as the IGDA representative."

Haha. Oh wow.

Thankfully, all teams were able to submit before the deadline.

I would have loved to post screenshots of each game made but I don't have them.

And so after presenting the games, and us two mentors presenting our games too, I had to go and judge.

There were immediately three games that stood out to me:

Prologue: Primitive Life

Pretty unusual game. You see a planet in XCOM geoscape style, and your goal is to fling asteroids at the right position and moment to start the seeds of primordial life.

Crystal Boom

A shooter reminiscent of Clean Asia (the Attractor ship) and Gradle Unison, you dash to attack instead of shooting bullets. I'm a big fan of these games. As a cool bonus, your super attack is you can set arbitrary way-points and your ship will dash to all of them instantaneously.

Silhouettes

These guys went for a safe bet and made a side-scroller of the popular running-man subgenre (i.e. Canabalt clone) but it was an interesting take in that you need a light source to see where you're going. You need to collect glowing spheres to charge up your light, so in addition to avoiding obstacles, catching lights is very important.

Playable Web Build: http://dl.dropbox.com/u/80881529/Silhouettes.htm

I am going to share my personal opinions here:

• Prologue: Primitive Life
• Pros:
• Has a good amount of challenge, testing your aim and ability to time your shots.
• Impressive graphics for something done in 2 days.
• A very unique game, I don't know of any game similar to this.
• Cons:
• Not enough variation. Once you master the skill needed, the fun wears off. My suggestion is to add more types of asteroids in addition to the life asteroid and death asteroid. Perhaps an asteroid that makes depressions on the planet, or ones that build mountains. Perhaps ice asteroids that make oceans, fire asteroids that make volcanoes, etc.
• The presenters themselves noted there were some bugs.
• The presenters did a poor job of explaining the game to the judges. Brett had to re-explain how the game works to the other judges so they could understand it. Remember, some of the judges know very little about video games beyond what they have in their smartphones, so that needs to be taken into account.
• Crystal Boom
• Pros:
• Again, a challenging game. Like I said, I'm a big fan of shooters like these.
• Cons:
• I find little relevance to the theme of "Primitive Life". Even the title, Crystal Boom doesn't have anything to do with the theme. I think the enemies were supposed to look like biological viruses, so there's that. Thing is, they cajoled an existing game genre into the theme, not the other way around. In the end though, I don't care as a gamer, cause I like to play these kinds of games.
• Graphics weren't so good. Check Clean Asia and Gradle Unison for ideas.
• Same problem with Prologue, the judges couldn't understand how the game works even with the presentation that was made. I had to go and explain them.
• Silhouettes
• Pros:
• Challenging game. Running-man games are inherently challenging.
• Easy to understand how to play. Only one judge didn't get it, and still, after a little explaining, he immediately got it. That's a given though, since running-man games always have simple controls.
• Very very good amount of polish to the game, they can take the game as-is, and release it on the appstore. And they should.
• Cons:
• Not that it matters to me, but I also find little relevance to the theme here, if at all. They explained it was "primitive" in the sense that you're running in fear of the dark, like primitive instincts kicking in. But the truth is, again, they cajoled an existing game genre (Canabalt clones) into the theme. It feels like cheating to me on that bit, resting on some sure-win mechanics that other people came up with. But again, its ok. The thing is, they added their own little twist to the running man genre so it wouldn't be generic.

If it were up to me, all these three would win, but all of us judges had varying opinions. The only thing we could universally agree on was that Silhouettes was very nice overall, so it was no question that that was first place.

What hampered the other two games was that the judges didn't get how those games were played, and presentation was part of the judging categories. In contrast, Silhouettes was easily understandable.

For future games, my tip is to add in-game tutorials, perhaps in the same way Silhouettes does. Also I did that in my game, TopSide.

To the game jammers, here's a tip: NO ONE WILL WANT TO BOTHER READING THE HELP/CONTROLS SCREEN. You can't expect people to be patient when all they want is to see how the game plays.

If you find people getting stuck and you have to explain verbally how the game plays, you're doing it wrong.

The game should naturally teach the player how to play, as part of the playing experience.

It could be in-game tutorial text like in Silhouettes or TopSide, it could be some character in-game talking to you how the game plays, it could be tutorial levels, like in Valve's Portal.

Play again the videogames that you play on your PC's and consoles. You'll see these things. And they're very important. The player won't get to experience the fun part of your game if they can't understand the controls in the first place.

---

Here's part 1 and part 2 of this 3 part post.

Unity Game Jam Manila 2012 Part 2

So with that previous part about the new keyword, I spent time fixing my code for Tactics Ensemble.

By 7pm of Oct 11, Thu, the participants entered. More than 30 people came in (16 teams were ultimately formed).

After the introductions and FYI's with the student's curfews and everything, Brett announced the theme:

"Primitive Life"

Huh.

To help, Brett showed some examples, "Ok, what do you mean by primitive?" It could be, primitive geometry, primitive behaviour, and some other examples I forgot. It was "primitive geometry" that stuck in my head.

Brett told us mentors, "You know, this first half of the jam, you don't need to worry about anything, cause they're still mostly in the planning phase. You might as well get some rest. It could actually get pretty boring so you may even want to actually do the game jam too, you know, while waiting for people to ask for your help, you could do it as well, cause you're gonna get bored."

I actually had a headache that night (was not able to sleep the night prior to that because friends were playing multiplayer Borderlands 2 nearby, shouting all night) so after commiting my changes to Project Tactics Ensemble, I called it a night, & went back home to sleep.

On the way home though, I thought if I was participating too, then I mulled on the theme.

Primitive Life.

Hmm.

The usual thing to go for here is some sort of caveman game. But that's too bland.

What about a game where you beat up programmers who have such a primitive way of thinking in making their code? Yeah that'd be fun, I'd play that. A lot.

All I could remember from Brett's examples was primitive geometry.

So between last night and the following morning, my train of thought led me to this old 1884 novel called Flatland: A Romance of Many Dimensions. I actually found out about that a long time ago in college, thanks to Project Gutenberg.

I never really got around to reading the novel but, long story short, its about a fictional world where 2d shapes were living, breathing characters.

One of them, a hexagon, thought, "What if there's a 3d?". And such ideas were pretty much taboo in 2d land. So she ended up in a journey going to 3d and even 1d. (As a nice bonus, there's actually an animated film adaptation of the novel released back in 2007.)

That was where I got the idea. Some game where you transition between 2d and 3d. And I thought, practically that would most likely be transitioning between side-scroller and 3d isometric.. or should it be between side-scrolling and 3rd person view?

And I thought the idea is good but I'm going the wrong direction here. There's not much sense in doing those.

So I thought, what about a game where you transition between side view and top view? That's probably more useful. There are things you can only do in side view, and things you can only do in top view.

Then I thought, ok, I'll make it that you can only jump in side view, and that you can't in top view, because it's hard to notice such a thing in top view anyway.

Side view is how you normally move left to right, but top view is useful if you want to "change lanes", so to speak, get behind or in front of things.

So the moment I got back to College of St. Benilde, I was surprised to see my other mentor partner (Charles Cue) was already working on his game jam game too!

Ok, a little competition now, is it?

I started working on my idea as soon as I could. I checked around and it seems like the participants have yet to run into problems.

This obstacle was the very first thing I set up to do.

I might as well link the actual game I ended up with here. Make sure to click in the game so it can get keyboard input:

There are only 3 levels so far; the 3rd level simply loops back on itself when you finish it.

I tried making myself useful for the participants but I got the feeling I was being brushed off. All the other mentors there were faculty staff of the school. I was the only outsider. Some of them probably didn't even know I was a mentor! Brett had a better rapport with the students cause, well, he was visibly the guy from Unity Technologies.

I felt I looked rather stupid roaming around and getting strange looks from the students.

Nevertheless there was at least one participant who was friendly with me. Admirably, she was the only one who went solo while the others were all in teams.

---

Ok, I'll stop here. In part 3 I'll explain how the jam ended.

Here's some photos I took (since no one was asking for my help!):

Having neglected to bring a sleeping bag, this was
where I slept. I used some t-shirts as a makeshift pillow.

Toilet paper? Check. Food? Check. Laptop? Check. All set!

Billy here used to be an intern in our company, now he's
landed a job! Not in our company, but I'm still happy for him.

:3

Unity Game Jam Manila 2012 Part 1

I got a rather surprising email last Oct. 2. A notification for a Unity Game Jam here in Manila, Philippines. Amid the looming deadlines I have for both work and personal projects, I thought that more stuff to do was the last thing I wanted to see.

Then I thought, what if the prize is a Unity Pro license?

I read the email more and what I got from it was this was meant more to be for learning Unity, other than it being a game jam (i.e. the whole "learn how to make a game in 48 hours!"). Also it turns out, De La Salle-College of St. Benilde is one of the sponsors of the event, so I take it students will be joining.

So, for the most part, I just ignored it.

The week that game jam is gonna take place, I see the usual announcements on our little IGDA Manila Facebook group, and silly me, I neglected to announce it on our Unity Philippines Users Group too. Though pretty much the people in Unity PUG are in IGDA Manila too. Nevertheless, I probably should have made some announcement too. I was hoping Mars Balisacan would do it; I'm only the guy who answers newbie programming questions in the group!

Then I got a private message, "Hey Ferdi, would it be ok if you come in the game jam as one of the mentors to the participants?" And having gotten that message while I was in the office in the middle of work, it was like a nice little distraction to go on some event for a while.

I also convinced myself that it would look good for the company if we participated in official Unity events. So I decided I would go.

So come the starting day of the event, straight from Quezon City (where our office was) I took the railway transit back to Manila.

When I got to the event's location (i.e. College of St. Benilde) I got stopped by some pretty strict security and it turns out the guards didn't even know the game jam is about to take place in their school.

Fortunately things cleared out amidst many phone calls and forms to sign.

Brett Bibby of Unity Technologies was coming in as the facilitator and the first thing to do was a briefing of us mentors. Apparently his flight got delayed so I was able to take some time to rest and chat with the people there.

When Brett arrived, we set up our things in the game jam's venue, the school's "Alienware Lab". Pretty much a big open space with a bunch of Alienware PC's. Unfortunately those things weren't set up yet so I couldn't get to try them.

So the briefing? It was this: Brett wanted to see how good we are with Unity so he asked us to come up with a game from scratch in 1 hour. Understandably it only needed to use cubes, and spheres, and whatnot.

My throat dried and my heart pounded fast. Being something of a perfectionist, I didn't want to settle for making a game that can't be completed in one hour. You could say I'm a completionist.

Ah, I know which game to make.

The simplest thing I could do: a side-scrolling shooter.

I did one before when Mars and I conducted the seminar about making a game using Unity. But I can easily recreate it from memory, more or less.

The challenge was doing so in under one hour.

So off I went.

I kept on checking for the time, glancing back at Brett. He was eventually getting into small talk with the other facilitators of the event; the faculty staff from College of St. Benilde (CSB).

Oh, good, good, looks like Brett is getting distracted from checking the time. More time for me!

Brett Bibby (left), and Patrick Williamson (right) of Unity Technologies

So I had my player ship moving and shooting, some enemies continually spawning, some particle effects, and I was about to finish some simple powerup feature when Brett called time.

Mine got looked at first, and pretty much the mistakes I did were:

1. If you are continually moving something (via code) that has a collider, you always, always will want to put a kinematic rigidbody on it. Failing to do so will cause Unity to be forced to recompute the whole world's static collision data.
2. Do not instantiate while in the middle of the game. Allocate everything you'll ever need at the loading screen or startup only. i.e. use a resource pool. Regardless if this is a mobile or desktop game you will want a resource pool. The enemy here is Mono's garbage collector. Unity is still in the process of updating the version of Mono that they use. In the meantime we're stuck with the old version (Mono 2.6) which reportedly has a slow garbage collector. [1] [2] [3]

The red line shows how bad Mono 2.6's garbage collector is.
The blue line shows the new garbage collector since Mono 2.8.

Point number 2 was understandable because I can't divide my attention at making a resource pool and the game's code and still complete in one hour.

And so point number 1 was really my mistake there. And Brett said, "Don't worry, even I forget sometimes." The problem also was that you'd only notice this if you have the Profiler, which only comes in Pro.

The effect then, is that people using the free version don't know why their framerate gets so low at times, and in effect they may get the wrong impression that Unity is slow.

Brett was actually wanting that some form of warning be made when the user makes this mistake (a message in the console, some explanation on the user manual perhaps, etc.). They're still arguing about how to go about it, it seems.

NCarter in the Unity IRC chat recommends people read up on the Nvidia PhysX User Manual. Since PhysX is what Unity uses, it will clear up a lot of mysteries for the common user if they read how PhysX works.

The only other mentor who I was with, Charles Cue, did a cool job too. It was about feeding food to a dragon, all in cubes and spheres, yes, but that was the idea. It reminds me of Papo & Yo.

Charles Cue, one of the faculty staff and mentors of the game jam.

The marshalls did an ok job too with the one hour hackaton, some were understandably struggling but they all got somewhere at the very least.

Brett gave some final tips for us:

1. These students who are entering the game jam? They will almost always want to use physics. The problem is that they will likely misuse it and you will end up with something that you might as well throw away. You need to explain the gotchas of combining physics with user-input and animation.
2. Sometimes they will ask how to do some particular thing which sounds rather strange. The proper thing to do is to ask "Wait, what are you trying to achieve in the first place with doing this?". And they go something like "Oh it's because I want to build a bridge that breaks." And then you realize "Ok, what you were asking for? That is totally not what you need to do to make a breakable bridge. You can forget about that. You need to do this instead..." and they realize they were needlessly doing things the hard way.

He then explained some intricacies with the Unity engine.

When Unity gets memory to use, even when garbage collected in Mono, Unity NEVER releases that memory back to the OS. Naturally when the Unity game closes, only then will it get released.

Apparently, this is actually a feature of any professional game engine: you will always want to allocate everything you'll ever need in a loading screen first, and never do any memory allocation while in the middle of the game proper. This is to ensure a reliable framerate for the game.

Second, things you know about .NET do not necessarily apply with Unity. For the simple fact that Unity uses Mono, and not .NET. Structs always get allocated in the stack? Not in Mono (ergo, not in Unity).

Thing is, in Mono, whenever you use the new keyword, that will always make use of the heap (memory allocation). If you're in Update(), you will not want to initialize a Vector3 with new Vector3(0,0,0) because that will make use of the heap.

Instead, use the handy Vector3.zero, or, if you need to give some specific values, do this for example:

Vector3 myPos;
myPos.x = 345;
myPos.y = 0;
myPos.z = 23;

Don't worry, a struct (like Vector3) can never be null, so this is fine. While it is admittedly a little more wordy (what used to be one line is now four lines of code), it will actually be faster this way. The point is, just don't bother with using new if you're in a tight loop (i.e. Update).

I'd like to clarify that this issue with new is because of the way Mono works, not necessarily something Unity Technologies directly chose to do.

They argue about this in length in this Unity forum thread, and here's some tips on the user manual.

---

That's it for now, I think this blog post is long enough as it is. In part 2 of this post I'll explain what happened in the game jam itself and share some more photos I took. Part 3 explains how the jam ended.