Remote Shepherd is the capstone project for Long Shot Games, a group of five graduate students in RIT's Game Design and Development masters program. The game allows the player to step into the shoes of a group of vigilantes who have decided to put their skills gained as Marine Scout Snipers to use in cleaning their city of criminal organizations. This blog will track both the ongoing design and development of the project.

Wednesday, May 11, 2011

Dave McKean Should Be Flattered, Right? Right?

So, what do you do when your game is a week from the final deadline and you realize you want some cool promotional art, splash screens and loading screens? Why, you task it to your AI engineer! Wait, why doesn't that sound right? Anyways, when I thought about what these images should look like, my mind immediately went to one of my favorite artists, who has done album covers and comic covers: Dave McKean. I had three images in particular of his in my mind when creating the images for our game:

The Sandman Vol. 7 Cover

The Last Temptation album cover, also the cover of Book I of The Last Temptation Comic

Cover of Book III of The Last Temptation comic

The middle image hangs on my wall as a large print. With those images in mind I created:

Remote Shepherd comic book cover

Remote Shepherd splash screen

Remote Shepherd loading screen

Thursday, April 21, 2011

Havok, Vertex Buffers, Maya 2011

So, it's been a while since I posted. We ran into an interesting situation where we learned that Havok was exporting our referenced meshes as unique meshes within our level. This led to each mesh having its own unique vertex and index buffers. Now, with trees, paths, POIs, and other content, this led up to having 5600 unique vertex and index buffers.

That, for lack of any better words, is a lot of content. That's also a lot of state changes between graphics calls. So, how did we fix this?

Well, we first attempted to export our files using the Havok exporter in Maya 2011, using the "Find Mesh Instances" filter. This filter is supposed to remove duplicate meshes from the scene, but does not detail how it does so.

We at first assumed that any file that was referenced in would be considered a duplicate mesh. Then, when that didn't work, and we had a 50 MB level, we tried doing reference copies. That didn't work either. Well, I then systematically attempted to figure out how "Find Mesh Instances" worked. Turns out, I couldn't find a way for it to work (at least not using the filter).

But, after talking with Eric, I found a nice way around this.

So, the solution was instead to do this:

  1. Reference in the object / model you want to use from the file of your choice.
  2. After placing your reference, select the object in the Viewer or Outliner.
  3. Go to Edit->Duplicate Special (click the square next to it to set it up)
  4. Select Geometry Type as Instance and Group Under as World.
  5. Click Duplicate Special.

What this does is creates an instance of the reference that was loaded, which has its own transforms separate of its parent. However, because it is an instance of the reference, its materials, vertex data, etc will be changed when the reference is updated. Likewise, when you execute the shortcut now, these parameters will already be set up.

When you export using the Havok Content Tools exporter for Maya 2011, "Find Mesh Instances" will report not finding any duplicate meshes. However, only a single instance of the mesh will be loaded and referenced in the scene. For us, this insures we only create one index and vertex buffer per referenced mesh, greatly reducing the size of our level files and increasing run-time performance for the game.

Saturday, April 16, 2011


I spent the last week or so working on all the pieces I need to get set up in order to have the data needed to create a heatmap. I first had to log out the data from our game engine, which I achieved by writing all the gameplay metrics to text files. The next step was to organize all the metrics from the log files into a database. The proper way to do this is to use an SQL database, but this was going to take me too long to learn and implement. So I decided to keep using a text file to store the organized gameplay metrics.

Tuesday, April 12, 2011

Animation State Engine and Expressive AI

Now that we have some animations the AI can start to look more interesting. No longer do they merely stop at the goal and wait to move to the next goal; they actually do something at their goal now! To further that end I developed an animation state engine. This is basically a finite state engine with each state representing an animation, and the edges representing transitional animations. It allows the AI and animation systems to be separate, and the AI system to merely tell the animation system which animation state it should be in next, and the ASE will handle picking the appropriate transitional animation and determining when to play and when to stop animations. Each agent also has a map of animation categories to specific animations, meaning different agents can easily have different "Walk" or "Idle" animations without the ASE or the AI system caring at all.

This Is Why We Can't Have Nice Things, Delta

A little photoshop magic on the city map shows just how well our detective takes care of his things.

Two Paths Diverged in the Park (With Apologies to Robert Frost)

We've had the nav mesh and path finding in for a while, I just haven't had time to make a post about it. Here's what our nav mesh looks like currently:
Right now it's only the actual dirt/concrete/DG/whatever paths in the park, it doesn't include grassy areas yet. There are plans in the future to mesherize the grassy areas as well, but we need some way to assign terrain modifiers to polygons so that AI knows what kind of terrain it is walking on. The other thing you will notice about the nav mesh is that it is all triangles, instead of n-gons. This is unfortunately a shortcoming of Havok, it refuses to read anything but triangles. This means more polygons than strictly necessary, and also it means that our centroids kind of make a wobbly line. That being said, it works pretty well, and the local avoidance gets the AI to alter it's path and keeps them from looking like they are in one big line.

Tuesday, March 29, 2011

Scout Mode

As I mentioned in an earlier post we created a new game mode called Scout where the player views through a camera and has a directional microphone. The first thing to notice the HUD is designed to match what the player would see while looking through the viewfinder on high end digital camera. The squares and circle have no bearing in our game, but are there to simply match what would be seen through a real camera's viewfinder.

Scout HUD

Making Comic Book UIs

One of my jobs on this project is as UI design which has been challenging because of the comic book look of the game. All of the Menus and HUDs have to look like something a reader might find in a comic book. As such I have to find some reference material on panel layout, lettering and art styles. If anyone is interested in any of these topics here are a few places to look at.

Sniper Map

One of the new features that came out of the redesign of the missions is that there are now more sniper nests than snipers. This means that the player will be able to reposition the snipers around the mission area. So we had to come up with a system to allow the player to control the position of the snipers and luckily one of the games we looked at during the research phase of the game had such a system. It had stuck with me as it seemed to be a simple solution that added a new menu page and keep the controls simple.

The Strangers

Saturday, March 26, 2011

Game Modes / HUDs

This past week we established two play modes for our game, Shooter and Scout. The Shooter mode is the original mechanic of the game where the player uses a rifle and a scope to locate their target and kill them for lethal conclusions. Below is the first version of the HUD for this game mode. In the center is what the sniper sees looking through the scope of their rifle. Around the scope the player can see their current setting for the scope's magnification, elevation adjustment, windage adjustment and a compass to show where they are facing. Then in each corner of the screen there is a designated area for each of the snipers (Alpha, Foxtrot and Whiskey) and the police detective (Delta) to talk.
Shooter Mode

The new game mode is Scout where the player uses a directional mic attached to a high power camera. The player will use the mic as another method of locating their target and the camera to gather evidence for non-lethal conclusions. In this mode dialogue picked up by the mic is displayed in radio bubbles around in the blacked area of the HUD. Due to how the dialogue is displayed, we removed everything but the compass form the Shooter mode HUD.
Scout Mode

Repurpose Not Rebuild

As a follow up to my earlier post about scraping our designed levels and building a new one it is important to mention that for the mission redesign we first designed the mission situation and then placed that situation into an environment. This let us build a gameplay experience that would be fun and engaging for our player, which was why we scrapped the first missions in the first place. It also allowed us to make the environment be something that we could use as much of the art assets we had gotten for our art team as we could. As well as keeping old art assets and making the game more fun it was equally important that we redesign the narrative. Mainly because at the time we were unsure how many artists we still had on our art team and Dan and myself would not be able to make enough of the assets we needed. It was also important because all the art we had worked well and there was no need to scrap any of it.

Building a Terrain

One new problem with the redesign of the game's narrative path is that the park is not a flat plane like the market was. This meant we would have to generate a terrain in Maya, which is something difficult for myself to do as the level designer. After a week's worth of searching for plug-ins or external software that would let me design the terrain of the park I decided on the program that would best allow me to generate a terrain and export it into Maya: Nem's Mega 3D Terrain Generator.

After experimenting with all the other solutions I had found, I settled on Nem's Mega 3D Terrain Generator for several reasons. The most important was that it allowed the level designer to quickly generate a terrain using some built-in generation techniques and hand-sculpting tools. This program also allows us to export our terrain as an .OBJ files that we can then import into our Maya scenes, a feature I felt was important to have. The designer also has control of the size and number of triangles of the terrain, which is important for us to make sure we keep our poly count down. Lastly with Nem's Terrain Generator the designer can hand paint each face with a texture which is nicer than Maya's process for applying a face with a particular texture.
Nem's Mega 3D Terrain Generator