Team navi has had to make many decisions along the way about what direction to take our game both programmatically as well as thematically. We hope that the end result is a rich environment that a player can really get into.

DESIGN TRADEOFFS:

Very early on we wanted to have two main parts to the game. One part was going to be the information collection part. In this mode, the player would walk around and discover clues in order to help them figure out what painting they should steal. This is Art Thief as it stands today. We had further aspirations of making more dynamic ways of discovering clues than is currently present. We wanted to have objects that you could find and pick up from the ground that would tell you something, mini side-quests that help you gain a museum patrons support, etc.

Another part of the game we wanted to implement was an actual theif portion. As it stands now you simply select a painting to steal and a closing sequence is played. We had many ideas about a stealth mode in which you would have to sneak into the musuem, avoid the night guard (with whom you have hilarious reparte earlier in the game), avoid the security cameras, disable some alarms, and then finally take the painting. This proved to be too big of a scope for just this semester.

OVERALL SOFTWARE DESIGN:

The game is one giant Finite State Machine. At any given time, the player has what we called a "knowledge nugget" which signifies how much information that player has acrued. Depending on the players current knowledge nugget, the Non-Player Characters (NPCs) will say different things, have different question available for asking, etc.

One of the knowledge nuggets, whether or not the player has the map, also determines if he can open the map in game. It wouldn't make much sense for the player to be able to access the map before he has acquired it in game.

The game uses many animation concepts. We did this to try and bring the NPCs to life. We have two models associated with most NPCs. And idle and a talking model. The idle model is hidden, and the talking model is shown when you click on them. They also turn to face you! It was our hope to get around to modeling more expressive options for our characters. We wanted some basic emotions to work with: Happy, Sad, Angry, Confused, etc. And then, encoded in the dialog structure, would be what expression the NPC should have during the current dialog. This is unimplemented unfortunately.

The dialog is contained in huge lua tables. The NPC and the current knowledge nugget are typically the index into the dialog data structure. What you get back from the dialog structure is yet another table that includes one or more "sequences" and "questions." There is a special kind of a sequence called an intro sequence which basically will start playing when you click on the character, otherwise the question box is displayed first. Each question is then associated with a sequence except for the last question which is effectively a "cancel".

This is basically how the dialog works although I have oversimplified it. There is also an overall "introduction" dialog that will play the first time you talk to a character no matter what you know or don't know. This became essential because we were having situations where the player would advance in knowledge and skip over some really funny/important dialog from some characters.

Also, ordering becomes tricky. Sometimes the player starts talking first, sometimes the NPC does. In most cases, I set a simple flag indicating who speaks first and then toggle the dialog boxes back and forth between the player and NPC character. In the case of Martha Stewart, Abigail Stewart, Bob Cassady, and Raquel Ramirez, you have multiple NPCs taking part in the same conversation. So a simple programming model that toggles between the player talking and the NPC talking breaks down here. Further programming structures were needed to make this work.

The pathing to the paintings are done using a bezier curve that is dynamically created based on a couple factors. There is a curviness variable that is affected by how close you are to the painting. The closer the player is, the less curviness we want in the path. The end points of the bezier curve are dynamically computed taking into consideration the size of the painting. This way, the player ends up with the painting in full view. They do not end a fixed distance from all paintings. This wouldn't make any sense, small paintings would be difficult to see and large ones would be off screen.

The shading on the walls is done with a basic spot light shader combined with a normal/bump map shader. If you look closely you will see the walls are bump mapped. We made the effect minimal because we didn't want the walls looking like they were stucco. The paintings and floors do not have the bump map applied, but are still affected by a spot light shader. Interesting challenges are always present when you are talking about shaders. One area of interest was the translation that needed to take place for the spot light positions/directions. Our paintings were created centered about the origin and then are programmatically moved to their position in the museum. Our walls and floors by contrast are modeled in their actual final world coordinate system. This means that when you send the positions and directions of the spot lights to the shaders you need to know which coordinate system you are in. When applying a spot light position/direction to a paiting, I need to translate them both into the paintings local object space before passing it along to the shader.

GAME AI:

There is really no AI to speak of, other than the extensive dialog structures outlined earlier.