Friday, January 13, 2012

Fear Like a Disease: Applying Epidemiology Models to Crowd Simulations in Games

This post was originally the research paper portion of my graduate capstone project. Since it's relatively long I'm also offering it as a PDF here.

1      Abstract

In many games, crowd simulations are not usually as dynamic as real crowds. By applying an epidemiologic system to the crowd model we can make it more interesting. When the “fear” attribute of an AI character in the game Remote Shepherd was treated as a transmissible virus the crowd did, in fact, become more dynamic and difficult to predict. Future extensions of this work may involve applying a similar system to AI control structures or to social phenomena other than crowds.

Friday, December 30, 2011

Watching It For Hours: Making Character Animations Less Predictable, More Interesting and More Controllable

For my graduate school capstone project I worked on a game called Remote Shepherd, which, more so than many other games, consisted largely of sitting back and watching virtual people. For the development team this meant that the player is spending a lot of time watching and considering our character animations. To try to make this more interesting, and to keep the animation and AI systems from becoming entangled, I developed an animation control system that would allow character animations to be more dynamic, thus more interesting. The system also allowed the use of many different sets of character animations by combining atomic animations, as well as allowed the AI system to control the character animations in as simple a way as possible. I called the system the State-subState-Set Animation Engine [3SAE].

Wednesday, August 10, 2011

Adobe Licensing Issues

A few days ago I started getting this error when I tried to run any Adobe product:


I tried restarting my computer, which, of course, didn't work. I tried unleashing the full force of all my virus and malware scanners, to no avail. Finally, I broke down and called Adobe support. I'll give it to the guy who tried to help me, he must've gone through every solution in his manual. Even so, I was on the phone for over two hours, only to have it end with "It's not a problem with our product, it's a problem with your .NET Framework." How did we figure that out? By doing something we could have done in the first five minutes of the call, instead of the last, but the tech support manual told him not to tell me to do. So you don't have to wait on the phone for hours and miss days of productivity, here's a quick and easy way to determine if your problem is the .NET Framework and how to fix it in about 10 minutes.

Friday, June 17, 2011

"A Spy Game About Subtle Behavior" and "A Puzzle Game About Observing People": Spy Party and Remote Shepherd

I'm reading this month's issue of GameInformer, and there's an interview with some guy named Chris Hecker. Some of you may have heard of him. Anyways, he's talking about this game he's working on, Spy Party. As I'm reading about this game where one player tries to blend in with a crowd of NPCs, and another with a sniper rifle tries to identify that player via behavioral cues, I think to myself: this sounds familiar.

Oh right, I just finished making a single player version of this game.

The World Is Not A Round, Spherical Place: Nav Meshes vs. Path Nodes

First printed as "The World Is Not A Round, Spherical Place" on the Remote Shepherd Dev' Blog


AI characters need a way to get around the world, and we considered three ways to let them do this. The first was local avoidance, but this can very easily devolve into dithering unless the level is specifically designed to prevent it. As such we decided to do actual path finding, the only decision left being whether to use a node graph or a navigation mesh. We decided to go with a navigation mesh based on the recommendations of this article. I'll summarize the relevant points here.

Tuesday, April 19, 2011

Spinning Class - FSMs versus Behavior Trees

Being the sole AI guy on my capstone project (Remote Shepherd) has had me buried in finite state machines and behavior trees for the past 17 weeks. Obviously there are differences in the two approaches, both have pros and cons, but as I was working out the behaviors of a particular NPC for Remote Shepherd (specifically, the Mob Agent) I came across something interesting and useful: the differences in the way each implementation handles spinning on a behavior. The short version is that when an FSM spins on a state it only cares about that single state, when a behavior tree spins on a node it still checks the relevance functions of every node with higher priority. For the long version I'll start with describing the behavior I was trying to model that led to this realization.