Archive for November, 2011

AI for Fix

Nov 19 2011 Published by under Flash

Fair warning:  The following is a lengthy deconstruction of a very simple idea (“NPCs that walk around on their own and stuff”).  If you just want to see a video of the system in action, you can go here.

 _____________________________________

The AI for Fix is nearly complete, so I can talk about its overall structure with some confidence now.  This part of the code is immensely important to me, since this game is very character-driven.  The characters need to behave in a believable way so that players can forget that they’re made of sheets of sprites and just think about them as characters, or maybe even as people.

This game’s AI has turned out to be relatively complicated, and it consists of five layers of abstraction (!!!).  From least to most abstracted, they are Trivial Moves, Paths, Behaviors, Scripts, and Triggers.

So what does all that actually mean?  Well, we’re going to have to start at the beginning…

1)  Trivial Moves

A Trivial Move is an instruction so simple that it requires no analysis to follow.  In this particular case, where we’re just talking about making NPCs move around a level, they are capable of three Trivial Moves:

Walk:  Walk any distance to the left or right.

Drop:  Walk off a ledge and fall.

Jump:  Jump up a step, across a gap, etc.

Sometimes, an NPC needs to move somewhere and one of the three Trivial Moves can get him there.  These are the simplest problems to solve, since they only need to figure out which of the three Moves is applicable.  If none of the three Trivial Moves can reach the destination, though, we need to think of something else.  Something like…

2)  Paths

If an NPC is physically capable of reaching a particular destination, then their movements to get there can be defined as an ordered list of Trivial Moves.  Think about MapQuest or Google Maps–Cars can only drive on roads, so they find the shortest path from A to B that follows the roads.  Fix uses a similar system to find a path from A to B that only consists of Trivial Moves.

The general idea is to start at the position of the NPC and find every possible way that they could potentially move.  This system examines the collision data that is already being used for the level.  It finds all of the possible paths simultaneously, expanding them outward from the character at the same rate.  Since they all grow at the same speed, the first one that (accidentally) reaches the destination must be the fastest way to get there.  It’s a very brute-force method, but since the NPCs have a pretty limited range of motion (the presence of gravity makes a huge difference in terms of navigation), they never have that many possible paths to test.

But even if we know how to get from A to B, how do we even know where B is?  The answer is…

3)  Behaviors

A Behavior defines what an NPC is trying to accomplish at any given time.  ”Follow the player” is a simple example of a Behavior.

A more complex Behavior is “Move to a hotspot.”  A hotspot can be any chunk of the level (and a level can contain any number of hotspots).  Though this is an instruction that’s very easy for us to understand, it involves several instructions for different situations.

If the character wants to move to the top floor of a level, for instance, they need to start by checking whether or not they’re already there.  If they’re not, they’ll try to find a path to get there.  If they can’t find one, they’ll wander around until a path opens.  Once they reach the top floor, they’ll wander around some more (making sure to stay inside their destination hotspot) until they receive another instruction.

But wait, where do instructions come from?

4)  Scripts

Gameplay scripting is becoming very popular.  While game engines are written in low-level, high-performance languages like C, scenarios for levels are often written in more abstracted languages.  Overgrowth, for instance, uses AngelScript for gameplay scripting.  Flash is already built on this type of structure–any code I write for my games is written in Actionscript, an abstracted scripting language.  The Flash Player, which is written in a low-level language, interprets this script.

For Fix, gameplay scripts look less like scripts of code and more like theatric scripts.  At least at the time that I’m writing this, if you hit the “Fix Demo” tab at the top of the page, you can see a demo that reads the following script.

(The three floors of the level are defined as hotspots which are named bottomFloor, middleFloor, and topFloor.)

(Jack moves to topFloor)
Jack:  I'm going to the top floor.
Jack:  …boop boop boop…
(Jack moves to bottomFloor)
Jack:  And now I'm going to the bottom floor…
Jack:  …
(Jack moves to middleFloor)
Jack:  And now the middle floor.

 

Aside from the inherent cuteness of this solution, it’s ridiculously easy for me to write these scripts.  Also note that the game’s dialogue is read from these same scripts, so it’ll be very easy for me to write and implement conversations (of which there will be…many).

So that’s all well and good, but how do we know when to start a conversation?

5)  Triggers

Triggers have two parts:  A condition and a conversation to start.  A condition is something like “Kathryn reaches bottomFloor” or “doorOne is open.”  Conditions can be combined, like “Kathryn reaches bottomFloor and Jack reaches topFloor.”  Once all conditions for a given Trigger are met, it starts up its target conversation.

 _____________________________________

So…yeah.

2 responses so far

A screenshot of some words

Nov 14 2011 Published by under Flash

There’s some kind of joke about a picture and a thousand words here, but I can’t seem to find it.

Anyway, hello again!  I’ve been starting to work on the dialogue mechanics for Fix, and I’ve got a nice little screenshot to show what it looks like so far.  The chat bubble graphic is still a placeholder for now, but even so, the presence of dialogue at all is welcome.

The dialogue doesn’t interrupt gameplay, so you’re free to move around normally while the characters discuss their stupid problems.  Gears of War immediately comes to mind–during the parts of the game when your dude is talking on his radio, you’re not allowed to aim, shoot, or run.  You can only walk slowly and wait for the dialogue to end.  It’s kind of infuriating to have your input arbitrarily hindered like this, so I made sure to keep the player control totally normal while dialogue is going on.  Also, some people very plainly won’t give a shit about the dialogue, so these guys don’t even have to worry about it.  They can just spam through it while they’re going about their business.

I’ll admit that a screenshot of a chat bubble may not seem particularly exciting, but the dialogue is an extremely important part of this project…so I’m excited, at least.  Maybe that’s enough for you to be excited, too.

I’d like every level in the game to involve someone saying something, or at least thinking something, so these little talky snippets need to be succinct or else they might get in the player’s way while they’re trying to play the game.  I love writing short dialogues like this–it’s a neat challenge to make people sound natural even though they’re being really terse.

Aside from the obvious story-advancement and tutorial text, though, the dialogue also serves another very important gameplay purpose.

My current goal is something like 40 or 50 levels, so I can’t have the player just solving puzzles for that entire time or else they’ll get worn out and grumpy.  The solution to this problem is pacing!  Every once in a while, a level with no difficult puzzles can give the player’s delicate brain a bit of a breather.  These non-puzzles can easily become boring, though, so these levels involve more dialogue than normal to give the player something non-strenuous to keep occupied with.  I can also use these extended dialogue segments to really bring out the little details about the characters, and it’s difficult to even explain how important this is to me.

And since you bothered to read all the way down here, here’s a little bit of info about the four non-player characters in the game.

Jack:  The protagonist from Company of Myself.  He is friendly and well meaning, but he is also addicted to an unspecified drug which has made him unstable and hard to be around.  He used to be a magician, but his habit made him lose his job and credibility.

Penelope:  Kathryn’s roommate.  She is a good person, but is heavily insecure and needs constant validation from her peers or she gets temperamental and anxious.  As a result, she is dating Thomas.

Thomas/TheSphinx:  “TheSphinx” is a pretentious and irritating video game addict.  He has carefully perfected the art of complimenting women, and because of this alone, he has managed to make himself irresistible to Penelope.

Henry:  Kathryn’s psychologist.  He provides guidance and advice about Kathryn’s smoking addiction, also giving insight about her various friends.

Have a nice Monday!

7 responses so far

A pathfinding test for “Fix,” and some news

Nov 08 2011 Published by under Flash,Site news

So, first off, I’ve been doing more work on Fix (which is going to get a new title some time between now and release), and I’ve got a little video to show one particular aspect of it:  NPCs!  I haven’t worked on the NPCs for very long yet, but it’s already looking promising.  Here’s a video to demonstrate:

Pathfinding test

The behavior that explains how to follow the player is still pretty clunky, but the pathfinding itself is really solid.  It works with more complex levels than this, like ones with doors that open and close, etc.  It’s also insanely fast–way faster than I expected.  The last time I made any pathfinding in ActionScript, I was using AS2 and it was so slow I had to calculate it over the course of several frames.  This time, even though the logic is much more complex (mostly because it’s a platformer, so gravity applies…), a path can usually be computed in less than one millisecond on my machine.  A big part of this is AS3′s improved performance, but I assume that I’ve also gotten at least a little better at coding.  Regardless of the reason, I’m definitely pleased with how it’s coming along and I think that the NPCs in this game will really shine by the time I’m finished.  Since the “other people” are one of the big focuses in this game (in contrast to Company of Myself, which is all about Jack), this is a very, very good thing.

I’ve also got a little bit of news involving what I’ll be doing next year, but first, a little refresher on what I’m doing now.

I’ve been in a four-game sponsorship contract with Armor Games for a long time now.  Viricide was the first game for this contract, followed by Work of Fiction, and most recently, Fisher-Diver.  Fix will be the fourth and final game.  This contract has been incredible for me because it equates to consistent work in a market where I previously never knew the value of a project until it was already completed.  (For all of you who have never tried making Flash games, imagine trying to organize a project involving several paid artists when you don’t have any idea how much money you’ll be able to pay them until some time after all of their work is complete.  Summary:  It’s balls.)

Anyway, recently, I got an email from an old friend about a possible games industry job for me.  I’ve been following through, and it’s looking very plausible.  I don’t want to bother getting into details about it here because I still don’t know how it’ll turn out, but it’s for a very notable company and it seems that they like me.  I’m not looking for a permanent job right now, but having some experience/presence at a company like this seems like a good idea to me.

What does this mean for you guys?  Well, if I don’t get the job, it means nothing will change.  If I do, however, then Fix might be my last independent project for a little while.

I guess that means I’ll have to make it extra good, just in case!

3 responses so far