[Insert Game Title Here]

Many artists struggle with the seemingly simple task of assigning a title to their artwork. I’ve often been guilty of giving something an “Untitled” moniker, so as to leave the interpretation ambiguous and allow the viewer to decipher the work, stripped of any hints or labels.  With a video game, this is a bit trickier, as the title serves a larger purpose than just simply occupying a placard on the wall next to the hanging work.  It is the name of the app, the anchor for the game’s opening menu screen, the name of the website (and/or blog), and much more. It serves as a unique representation of the work across the vast internet, in both game spaces and not-game spaces.  It is one of the most crucial aspects of the game’s identity.

Select Game Title Screens from “A Brief History of Video Game Title Design

So to say that I struggled with this task is an understatement.  I’ve been through multiple iterations and ideas, with a final title that (luckily) works wonderfully on multiple levels.  I want to speak about the background to giving my game the title of “Tombeaux“, to once again offer a peek into my process.

First off, it wasn’t always Tombeaux.  Originally, I had another very fitting name to my game, courtesy of a suggestion from an early playtester and good friend, Mitch Ogden.  He suggested the title “Depth“, as it spoke to the focus I’m giving to both the literal (water) and the figurative (cultures, histories, characters, etc) elements in my game.  It was a wonderful title, and the only problem was that another game dev team also thought the same thing, and was waaaaay different than me on their game and scope.  Unless I wanted to contend in the Google search-a-verse with an underwater multiplayer shark hunting game (and their blend of “tension and visceral action…in heart pounding combat”), I knew I had to move on to another title.


Depth, a FPS about hunting sharks underwater…definitely not room for Tombeaux here…

In my research about the St. Croix River, I found an interesting reference to Father Louis Hennepin‘s travels up the St. Croix.  The 17th century French Catholic missionary had explored the Mississippi, and spent some time on the St. Croix as well.  His was one of the first attempts by a European to name the river in a publication, giving it the title of “Riviere du Tombeau“, translated as “River of the Grave” (he had witnessed a Dakota buried on the banks of the river after dying from a snakebite, so the story goes). As one can gather, the name did not stick, for both the event and name did not seem fitting for an entire river full of such life and energy (the origins of the real name of the river – St. Croix – is actually up for debate as well, with stories such as the shape of the river resembling a cross, people dying at the mouth of the river, and other tales that all lead back it most obviously being named by a missionary).

While “Riviere du Tombeau” did not fit as the official name for the St. Croix, it did catch my attention enough to research the name and words further, as my game does deal with death in a more conceptual sense. When I looked up the word tombeau, I was pleasantly surprised to find that while the original french word does in fact mean tomb (or tombstone), another definition exists, derived from this original word.  It turns out that tombeau (or the plural, tombeaux) can also be a musical composition commemorating the death of a notable person. Most popular in the 17th century, the musical genre tended to take the dance-like form of either a pavane or an allemande.

Through further research, I came across a number of composers and works that I found inspiring and very fitting to some of the same time periods as I was recreating in my game, namely the late 19th century. Some of the works by Gabriel Faure and Maurice Ravel seemed particularly pertinent to what I was looking for as a connection to my game. Faure’s Pavane in F-Sharp Minor, Op. 50 gave me the feeling of navigating a smooth-flowing river and contemplating the majesty of one’s surroundings.

Pavane in F-Sharp Minor, Op. 50 by Gabriel Faure

Additionally, I found both a pavane and a tombeau that piqued my interest by Ravel, including his Pavane pour une infante défunte (Pavane for a dead princess). While not penned for a specific princess, it served to express “a nostalgic enthusiasm for Spanish customs and sensibilities”[1]. He also composed a much more upbeat, lively memorial to a number of his friends who passed in World War I, titled Le Tombeau de Couperin.

Pavane pour une infante défunte (Pavane for a dead princess) by Maurice Ravel

These types of works were wonderful finds, both as a stronger foundation for my title and as inspiration for the music of the game. I am trying to integrate a strong element of music into Tombeaux, through collaborating with a local composer on the soundtrack (more on him and his work for Tombeaux in a future post!). While I have always had a great appreciation for music (on its own and in games), I have no training whatsoever in composition or playing, so this discovery was a great way to offer the composer a direction for the music that fit very well into what I was trying to get the player to feel throughout the game.

When I think about it, the game really is somewhat of a dance – the player finds themselves being led by the main narrator through a series of rhythmic steps which move back and forth between two distinct positions/locations, while also traversing through a number of different time periods. This movement urges the player to contemplate what they saw in previous levels as possibly now being no longer among the living, bringing in themes of death and feelings of remorse. So in essence, my game is comprised of a number of smaller movements that investigate and memorialize life, making each level their own type of tombeau. These experiences build on one another, resulting in the game that is officially titled: Tombeaux.


Le Tombeau de Couperin, by Ravel

At the Homestead

By now, it is probably somewhat obvious that Tombeaux is not a typical video game.  With me possessing a background in fine art and a career rooted in academia, I’m taking a slightly different approach to my project than many fellow peers in the indie game world. One example of this is how (and where) I’ve spent the last three weeks.  I’ve been the artist in residence at the National Park Service’s Homestead National Monument of America, in Beatrice, Nebraska.

2015-05-26 16.44.32

The Palmer-Epard Cabin, and original homestead cabin (and inspiration for the cabin in Tombeaux)

An artist’s residency is what I like to call a “work-cation” (I know, that phrase doesn’t make sense, unless you’re a workaholic…), in which I’m away from my family, home and university job, and focusing on nothing but making the game for literally 14 hours a day, 7 days a week (but I don’t recommend being away from your family for this long, as it is very difficult (on me, but especially on my wife Emily, who is a saint and superhuman/mom!)). Residencies are quite common for artists to pursue in the contemporary art world, as it provides the solace one might need to dive deep in to the “creative zone”. The idea is that an organization, institution, or foundation will award an artist (who has been selected through an application process) with the time and space to support their creative practice. Some residencies actually even provide outfitted studios, full-time chefs, and living stipends. Some have dozens of artists living and working at the residency at once (think “grown-up art camp”), while others have a single artist visiting with them (I prefer this – the hermit-like, no-frills approach).


The National Park Service has supported artist residency programs for some time, and it has always been a goal of mine to take part in one of these programs. I was fortunate enough to be selected by the Homestead National Monument of America as one of their 2015 Artist’s in Residence. I’ve spent the last three weeks researching, making, photographing, and talking in an environment that is the perfect fit for making a historically based game like Tombeaux.

The Homestead Monument of America site is dedicated to both preserving and teaching visitors about the Homestead Act of 1862, which granted 160 acres of free land to nearly any man or woman who applied. This act, signed in to law by Abraham Lincoln, was a major reason for the rapid westward expansion in the 19th century. Since part of Tombeaux takes place in the 1800’s and incorporates themes of homesteading history, working here has probably been the closest I’ll get to finding a “field laboratory” for conducting my game research.


The restored prairie and Heritage Center at Homestead National Monument of America

As one can probably gather by now, my time here has been wonderful.  While I have hunkered down in my living quarters and art studio making the game for the majority of the three weeks, it’s given me the escape that I needed after such a busy and stressful year of working in higher education (in a state that has seen better days, in that regard). I’ve been able to consult archives and exhibits, photograph authentic objects, documents, and structures, and interact with visitors to talk with and receive feedback about my game.

At work in the studio, making Tombeaux (image courtesy of Beatrice Daily Sun)

Today is my last day at the Homestead Monument of America, and while it will be wonderful to return to my family who I’ve missed so much, I know I will look back and remember this place for the time, space, and resources it provided me. Frankly, without the National Park Service’s help, Tombeaux would not be nearly as far along as it is today (in the ballpark of 300 hours less developed, to be exact!).

Art Update

I thought I’d put up a post showing some of what I’ve been up to, in regards to modeling and texturing over the past few days. Note: nearly all of this is WIP, so certain textures and details are yet to come!

I’ll start with the cabin, where the player will frequently be returning to throughout the game. I modeled it in Maya and wanted to keep the exterior under 1,000 tris, all while trying to recreate a cabin similar to an authentic homesteader’s cabin. As you can see, most of the detail work is handled by the texture maps, since it has flat walls that don’t demand a high-detail geometry profile. Also, the player will not be able to walk around the entire cabin, so my focus was mainly on the front and sides of the structure. Soon, I plan to add a handle and hinges to the door, a stove-pipe on the roof and wooden boards nailed over the windows.


Base for Cabin Exterior in Maya (835 tris). Inset: reference image

Albedo & Normal Map for Cabin Exterior

Albedo & Normal Map for Cabin Exterior

I have also modeled a few outbuildings/objects for the cabin.  The outhouse will sit in proximity to the main structure, and the lean-to will be found behind the cabin, as if it was a later addition to the home. I’ve created some barbed wire fencing as well, using albedo, normal, and transparency maps. Its design is based on the 1874 version by Joseph Glidden from DeKalb, IA (itwas the first barbed-wire patent awarded in the United States).


Outhouse in Maya (188 tris)

Lean To

Lean-to in Maya (166 tris)

Barbed Wire Fencing. (L: Glidden's 1874 Patent, Top Right: Model in Maya, and Bottom Right: Transparency Map for wires.

Barbed Wire Fencing. (lef: Glidden’s 1874 Patent, top right: Model showing textured and untextured versions in Maya, bottom right: Transparency map used for wires (black makes it invisible, white makes it visible).

Cabin, Outhouse, Lean-to, and Fencing (NOT scene from game, just set-up for showing models)

Cabin, Outhouse, Lean-to, and Fencing in Unity (NOT scene from game, just set-up for showing models)

I’ve also steadily continued to create the rocks and cliffs that will be found in the game.  As I talked about extensively before, the environment in which my game is set demands a great amount of focus on these geological creations. At this point, I’ve created one giant cliff (2K tris), two medium cliffs (1K tris each), and two large rocks (500 tris each).  My goal is to have about double that regarding assets to choose from, in order to dress the river scene’s set so that it is both believable and not redundant.

Cliff in Zbrush (top) & Maya (bottom)

Medium Cliff in Zbrush (top) & again selected amongst the other rocks/cliffs Maya (bottom)

5 Rocks/Cliffs, separated for demonstration (in-game)

5 Rocks/Cliffs, separated for demonstration in Unity

As seen above, to create objects with unique silhouettes (that can stand on their own as interesting pieces) is one challenge, but to also design it so that they work as a “team” in a modular fashion is a bit trickier.  Below, I’ve duplicated and arranged the five rock/cliff models into a grouping to show what I mean. I will need to eventually line both sides of my river level with rock and cliff formations that have unique nooks and crannies, so as to create memorable images and moments for the player to stumble-upon during their experience. I’ve thrown in some trees from Speedtree as well, to provide scale and reference.

Shot of assets (NOT scene from game, just set-up for showing models)

Modular cliff set-up (using 5 unique, instanced assets) (NOT scene from game, just set-up for showing models)

Shot of assets (NOT scene from game, just set-up for showing models)

Modular cliff set-up (using 5 unique, instanced assets) (NOT scene from game, just set-up for showing models)

While I’m content with the modeling pipeline I’ve established for these rocks and cliffs, I still need to give a lot of attention to their texture maps.  Currently, all of the geological forms share the same non-native, generic albedo texture, and while that is helpful for continuity, it becomes a bit boring when the player gets closer to the forms. In the coming months, I plan to return to the St. Croix River to shoot reference photography of the sandstone for the base rock textures.  I’m also planning to add lichen and moss into the secondary albedo detail maps, in order to give more interest for close-up inspection. Finally, I plan to turn the specular highlight way down (unless the rocks are wet, of course, which some of them will be!), as I’ve cranked it up only to show the secondary normal detail map. When it comes time for set-dressing, I’ll also be interspersing natural growth throughout the cliffs, such as grasses, flowers, weeds, and even trees.

Cliff Detail (NOT scene from game, just set-up for showing models)

Cliff Detail – albedo and spec maps will be changing (NOT scene from game, just set-up for showing models)

Cliff Detail (NOT scene from game, just set-up for showing models)

Cliff Detail – albedo & spec maps will be changing (NOT scene from game, just set-up for showing models)

So, hopefully this helps you envision the world of Tombeaux just a bit more, as the objects (both natural and human-made) are beginning to take shape and make their way into the game engine! As always, I’d love any comments, questions, or constructive feedback in the comments section.

Shot of assets (NOT scene from game, just set-up for showing models)

Shot of some assets from Tombeaux (NOT scene from game, just set-up for showing models)

Saving, SVN’s, and Schedules

Yesterday was not a very good day.  I spent about 12 hours trying to fix my project, due to a myriad of issues surrounding file versioning and back-ups.  Because of this situation, I thought the timing was perfect to talk about something that every indie game developer cringes at the mention of – PROJECT MANAGEMENT! So, on top of actually making the game, you also need to remember and find time to: back up all of your work, work with versioning/repository software, put together schedules and to-do lists, back-up all of your work, and constantly and relentlessly promote your game (and then back-up all of your work). For this blog post, I’m going to talk about all of this except for PR (it definitely deserves its own post, due to the amount of time it takes to do it correctly).


Okay, maybe I’m a *little* paranoid…

So, back to yesterday. I woke up yesterday morning to find roughly 3/4’s of my entire game project corrupted (ie: files wouldn’t open, some assets missing, Unity spitting out errors, etc. – pick your poison, as they all happened at some point).  I honestly can’t say how it happened, as things were fine the night before.  Luckily, just as I tell my students to do, I had backed the project up in a couple different places the night before last (as I do every night), and was able to get most of it back. But it did cost me about 90 minutes of searching, finding, merging, and testing to do so (and even worse, I had to go back to a version from two days before to find a project that didn’t have any errors, so I lost a lot of work!). I’m a big proponent of cloud backup services (I use a combination of Crashplan, Dropbox, and Google Drive, all for different purposes), but due to me currently being somewhere with slower internet speeds, I had to rely on my collection of external hard drives (you can never have enough, as you can see in the picture above). It definitely pays to back-up in multiple places, as when one of them failed, another ended up working.


File Versioning (like Perforce SVN, above)  is important for any game development process that involves teamwork and collaboration

But that wasn’t the end of it. The main issue that took of most of my day was due to me trying to make my project available online for collaboration with other people. Being somewhat new to this approach for my own projects (and wanting to experiment for what to use next year in the classroom with my students), I did some research into both GIT and SVN. A simple search of “GIT vs SVN” brings up over 400,000 hits, making it very hard to make up one’s mind on a clear winner for the best tool in game dev.  While they are definitely two different entities, both accomplish the same goal. They allow people to collaborate on projects simultaneously (if done right) and then allow changes that the developers have made to merge back into the master project, safe and sound (again, if done right).  I won’t go into much more detail about how GIT or SVN works (I’m not sure if I even know!) or which is the better option, because frankly, many others have already explained it better than I ever could.

I feel like the guy on the left.

I decided to go with Github, which proved to be easy enough at first (and worked for a few days), but something must have gone wrong. After crawling back from the dead with my earlier back-up issue yesterday morning, I decided to uploaded it to Github, so as to not lose even more progress.  Upon uploading, Github opened my files in the background, made conflict comments throughout the text version of the file, and put me in the point that I was earlier that morning – the Github-modified files would not open and everything was missing!  After wrestling with that for a few hours, I decided to try using Perforce instead, a SVN client that requires a server. While Github is praised by a louder, more passionate crowd, it seems like SVN (of which Perforce, a for-profit company, is only one of many who use SVN) seems to be a better fit for game development, especially within Unity. But, since I had to upload my entire project to the server before doing anything else, it continued to fail the upload, probably due to the slower internet speed.  After spending nearly all day wrestling with this, I decided to go back to what was working – sticking to my own personal local machine (the old-fashioned way!), and waiting until I get back to a faster internet to try out SVN and GIT options more thoroughly.

Screenshot 2015-06-03 19.43.48

Screenshot of Trello, the online project management app I’m using

Finally, I wanted to talk a bit about project management from the other side of the fence – keeping track of schedules, to-do lists, and milestones.  Software to support this abounds on the internet, due to teams collaborating across the country and globe. Because of this, the presence of some sort of online forum helps to make sure everyone is on the same page. I had a bit of experience with this in the last year, when I served as co-instructor and co-executive producer on a class project that brought together over 40 students to develop a game.  We decided to try using a product called Basecamp to manage our tasks, schedules, and conversations. While it probably works for many projects, it really ended up being a waste of time for us. Instead, we decided to fall back on a combination of Facebook and Google Drive, two platforms that are a bit better at handling communication and large files, respectively (yet there was still a big hole in project management that neither Google or Facebook could fill).  Because of that bad experience, I wanted to find something that would be a better fit for game development, especially since I’ll be instructing and leading a couple large student teams (around 12 per team) next year in my senior game development class.  After a bit of research, I came across Trello, which – so far – has been extremely helpful.  It is essentially set-up like a massive bulletin board – you can create to-do lists, cards, upload files, and manage schedules, all of which reside on the same screen (which is important).  While I haven’t experimented with it on a larger team yet, I’m hopeful that it could be an answer as the alternative to “Facecamp” (which is what we started calling the mess that was our project management situation last year on the Harvey game project!).

Screenshot 2015-06-03 19.44.18

Pulled back view of my entire Trello board for Tombeaux

So, hopefully this post shows that not all game development consists of fun forays into modeling, coding, and design. Some of it is the stuff that not many people like to do (and if you do enjoy it, there are certainly jobs out there for you!).  While the jury is still out about how I’m going to get my project online for collaboration, I hope that this one bad day will be it for a while, and I can get back to the steady and rewarding process of making my game!

P.S. please comment below or contact me if you have some suggestions about SVN or GIT, or (even better) are open to helping a GitNoob figure all of this out!

Like a Rock

The Cliffs of the St. Croix

Some cliffs of the St. Croix

For this post, I thought I’d focus on the pipeline that is involved with making a fairly common asset found in my game – ROCKS.  Due to the outdoor level taking place on the St. Croix River, I’m trying to stay as true as possible to the natural environment one would find on that river.  For anyone who has traveled to the St. Croix, they probably know that the lower St. Croix (as you get closer to Stillwater) is lined with beautiful cliffs that surprise you around each bend in the river.  Sometimes it is a small ledge that creeps up on you, while the heights of other towering cliffs invite – or even dare – you to jump off its ledge into the waters below.  Due to this diversity, I knew I couldn’t just make “one cliff to rule them all”, but instead would need an assortment of fat ones, skinny ones, tall ones, short ones, big ones, small ones, and (more often than not) oddly shaped ones.  People who play my game will be see quite a lot of these rocks, so I knew that giving special attention to these guys was important, even if it did seem counterintuitive to care so much about them 😉

A mirror of the same cliff, found two different times in

A mirror of the same cliff, found two different times in “The Vanishing of Ethan Carter”

Since this was my first round at creating a rock for the game, I decided not to attempt an entire giant cliff, but instead approached it from a modular standpoint. If done right, a game level can have multiple repeated objects in the scene, without the player even realizing it (unless they are really REALLY looking for it).

A game that does this well is The Vanishing of Ethan Carter (above).  Through flipping, rotating, and scaling, they achieved a lot of visual diversity at a low-cost. In fact, when I started looking for it, identical rock formations and textures began showing up throughout the game. If you haven’t yet played this game and are a fan of first-person adventure/exploration titles, it comes highly recommended (ironically, it is supposed to be set in Wisconsin, yet it is made by a European studio!).  The game is actually so gorgeous that as a game artist it depresses me every time I play it (the rocks are so real you’d think you’re looking at a photo (and it turns out that you actually are!)). They didn’t actually do as much modeling as you’d think, but instead took hundreds of pictures of rocks and turned those photos into 3D models and textures (using photogrammetry). I’ve got a friend and fellow game design colleague at UW-Stout, Seth Berrier, who focuses a lot of his research in this field. He’s given a number of really interesting talks that tie this advanced tech into popular uses like game asset creation and archival preservation.


An idea board of St. Croix pictures, created to visualize silhouettes and scale for Tombeaux

To begin, I made out an idea board (above), so that I could start envisioning how these rocks would be put together in the game. For this go around, I aimed to create a medium-sized rock that could be stacked and combined with others to create a larger whole. I also wanted to keep it below 1,000 tris (tessellated triangles created for the game engine render it on-screen), so I was going to depend a lot on the maps I’d be placing on the object.

My preference for a 3D modeling program is Autodesk Maya, which is basically an all-in-one poly and NURBs modeling program that incorporates a great deal of other features like rigging, animation, effects, and rendering (to name just a few!). I knew that to get a believable rock, I’d need to also use Pixologic ZBrush, organic sculpting software that uses a pen tablet, and attempts to simulate working with clay.  To begin, I created a polygon cube in Maya and smoothed it twice, to make a more pillow-like structure (below).  Starting in Maya allows me to establish good topology right away,and sets up my pipeline for going between Maya and ZBrush using .obj files.

Starting out in Maya (top) and then on to ZBrush (bottom)

Starting out in Maya (top) and then starting to form the silhouette in ZBrush (bottom)

Once the mesh was exported from Maya, I imported it into ZBrush and began working.  As with any artwork, I began with broad strokes before diving deeper into detail.  I made deep cuts into the rock, using a brush that simulates cutting butter with a wide knife (almost more like pressing).  I also continually went back over specific areas, building up the digital clay again (see above). Since ZBrush is such an extremely powerful tool in a modeler’s bag of tricks, one can get lost for hours in the little details, so I needed to continually remind myself that this part of the pipeline was specifically focused on silhouette – both due to the number of these that I will need to create and the simple fact I was working on a ROCK and not Michelangelo’s David, I did not need to dive too deep into sculpting the details – that can be shouldered by the textures. I relied mainly on a small collection of 3-5 brushes to make the chiseled and broken effects I was going for.

Near the end of the sculpting phase in ZBrush with a clay polish pass

Near the end of the sculpting phase in ZBrush with a clay polish pass

Once I was happy with the shape and overall rough texture of the object, it was time to bring this high-detail mesh down to a manageable level that could be worked with in the game engine.  As a reminder, I was shooting for <1,000 tris for the object, and the current number in ZBrush was around 630,000 tris (which is actually fairly low for a model in ZBrush).  I lowered the polycount through ZBrush’s Decimation Master plugin, which brought it down to just under 1,000 tris, and I was ready to bring it back in to Maya (below). I held on to the higher resolution model, as I’d use it later on to create the details in the normal map. A normal map is a very important element to any game that is aiming to show high amounts of detail on the surfaces while also keeping the total polycount low. It is an image that catches light in specific angles, tricking the player into thinking that there is surface detail or texture on the mesh, when it is all really just a trick of light and image.

Final Decimated Mesh in ZBrush and lo poly version in Maya

Final Decimated Mesh in ZBrush and lo-poly version in Maya,

Now that I had the silhouette of the rock formed, it was time to work on how the textures would be applied to the mesh. While some people prefer other packages or plugins for this, I’m a Maya traditionalist, so I did it the old school “manual” way.  Essentially, I cut along some of the mesh surfaces, unwrapping the mesh from a 3D object to lay it flat on a 2D plane (below).  This would allow me to take a 2D image (created later) and “wrap” it back up around the mesh the same way I unwrapped it. This UV map data also will tell other programs how to read the mesh’s connections to images, materials, and textures.

Laying out the UVs in Maya

Laying out the UVs in Maya

Once finished with the UV stage, it was time to bring all of what I had worked on to this point (lo-poly 1K mesh in Maya, hi-poly 630K mesh still in ZBrush, and flat 2D UV coordinates from Maya) into the third tool in my pipeline, xNormal.  xNormal is a free piece of (Windows-only) software that does a wonderful job of reading the hi-poly mesh details and projecting them on to the lo-poly mesh, by placing them flat on to the UV coordinates. It creates normals, ambient occlusion (or AO), specular, and many other maps as well, automagically for you. After baking out a normal map and ambient occlusion map, I brought the rock into a fourth program, Marmoset Toolbag 2.  While Maya can display the normals just fine, Toolbag does a great job of simulating closer to how the game engine will present it to the player with HDR lighting, real-time rendering, and skyboxes.

Baking the maps in xNormal and previewing in Maya and Marmoset Toolbag 2

Baking the maps in xNormal and previewing in Maya and Marmoset Toolbag 2

For the purpose of the game, these normals looked good.  I was still going to be adding a few more maps on top of this, which will give color, detail, and specular highlight to the object.  All of these things involved me working in Photoshop with tiled textures.  The first texture I was going to take on was the albedo (formerly referred to as diffuse, before Physically Based Rendering came along), which handles the color properties of the texture.  Using cgtextures.com (a site bookmarked by every texture artists out there), I found a small tiling map of a smooth, worn rock face that I thought might look good on my asset (top left in below pic).  Since I wanted my overall texture size to be 2048 x 2048, I tiled this 8 times and did some image editing to it, resulting in the main tiled albedo texture for my rock (top middle in below pic). Finally, to create my main normal map, I used the map created by xNormal as a base, and then turned my albedo texture into a normal map to overlay on top of it (top right in below pic), using the sixth program in the pipeline, NDO (a Photoshop plugin). NDO (by Quixel) is another automagic program, using presets to turn your images into highly detailed normal maps.


Various Maps that go into the texturing the rock, using xNormal, Photoshop & NDO

In order to achieve the detail I wanted for players to see when they were close to the rock, I needed to also create a secondary normal map, as well as a specular map.  The game engine I’m using supports secondary maps, which go the extra mile in providing realism to a scene.  I went through the same pipeline as above to create this, based on a higher-contrast image I found on cgtextures.com and using NDO to create the normals (bottom midde in above pic).  Since I didn’t want my rock to be too shiny, I toned down the specular map to a dark grey, so only certain areas would catch the light in subtle ways in the engine (bottom right in above pic).

Now that I had the lo-poly mesh and five different texture maps (Albedo, Normal, AO, Spec, and Detail Normal), it was time to bring it in to the seventh and last software program in the pipeline, the Unity 5 engine.  While the procedure of getting the textures on the rock were fairly straightforward, I needed to spend some time tweaking the render settings and lighting for a bit to achieve the results I wanted. I’m still not 100% happy with the lighting, but it will have to do for now. So as you can see, the process for creating assets from scratch (which is unfortunately rare these days) is somewhat tedious at first, but once one gets into the flow, things can go relatively quickly.

Final Rock Asset in Unity 5 (detail normal/spec in corner)

Final Rock Asset in Unity 5 (detail normal/spec in corner)

If you have any tips or tricks (or questions!) for asset creation, feel free to share them in the comments below.  Thanks for reading, and rock on! (sorry)

Cabin Fever

Kate Craig of Fullbright, showing her main reference for Gone Home – a Sear’s Catalog from the 90’s

I had the good fortune of attending an amazing talk at GDC this past March, featuring Fullbright’s Steve Gaynor & Kate Craig. They talked about their meticulous and methodical approach to level design in Gone Home (a game that is one of the many reasons I was inspired to pursue my project in the first place).  Kate Craig talked about how important it is to do your research and focus on what looks both good *and* believable, I immediately connected to her approach as a game artist and designer. Even better, Kate personally sat down with me after the talk and provided some valuable feedback for Tombeaux, much of which has shaped the game’s current state (thanks Kate!).

As I mentioned earlier, I am working on two levels that the player spends time in while playing Tombeaux.  One (larger) level takes place on a small section of something inspired by the St. Croix River, while the other (smaller) level takes place inside a small cabin atop a cliff, overlooking the river.  I’d like to talk a bit about the cabin itself, and how I’ve seen the design transformation of such a key level in my game. Although I’ve grown fond of the below screenshot, there was something that just didn’t seem right about it.  Having learned a lot about level design over this past year, I knew I had to (almost) start over with this scene.

Former cabin interior from Tombeaux

Prototype Screenshot of former cabin interior from Tombeaux

So with that said, I’m going to break my realization down into three distinct nuggets.  They might seem like no brainer’s, but I can honestly say I didn’t think about them nearly as seriously a year ago, and now I’m paying for it with having to do a major amount of cabin remodeling (literally!).

Real Estate Tip #1: Who lives in my cabin?

My game is filled with characters, dialogue, and embedded narrative.  While you don’t necessarily see the characters, you hear their thoughts and read their writings. What this means is that these virtual people need to live somewhere in my game.  Not just in a few lines of code or an audio file, but instead I want the player to feel like the characters were present just moments ago – the campfires are still smoldering and equipment is waiting for its owner’s imminent return. Regarding the cabin, it has a unique owner. While you as the player never meet this person, his presence is felt through the decor in the space and the words he’s left.  In fact, the cabin’s occupant is the main narrator of the game, speaking as if he is standing right next to you.

I’ve been working on bios for all of my characters, but due to his prominence in the game, he’s received a bit more attention than the others at this point. As a character, he is timeless and nameless, acting more as a representative of a collection of ideas rather than a specific person or opinion. Yet his dialogue hints at some elements of formal education and a high society lifestyle, with a longing for something more primitive and simple. I’m using Thoreau’s Walden, William H. H. Murray’s Adventures in the Wilderness, and elements of Teddy Roosevelt as some inspirational jumping-off points for his design.

Books & People who have inspired my narrator character

Books & People who have inspired my narrator character

When I designed the cabin last summer, I wasn’t thinking about characters enough. I was more focused on creating a 3D space than giving it “character”.  Sure, the grey-boxing doesn’t need “character” (or characters), but it still provides a large amount of drive to why objects rest in the space that they do (and why those objects are even there in the first place!). So, while my “2014 Cabin” served its purpose well through providing the player a place to navigate and also helped me to envision the style of the game, it was only surface level about its reason for existence.

For instance, my earlier cabin design didn’t even have a bed, sink, or toilet. Instead, I decided to make a closed-door in the room, that would hint that those things were behind that door.  But what do you think everyone wanted to do when they saw that door (and how frustrated they got when they couldn’t do that thing)? Remember, although you think you’re making this game/level/cabin for yourself (or a fictional character, like above), that is only part of it – the true judge of its merit will be the player.

Screenshot of Old Cabin Interior (Maya)

Screenshot of old empty 2014 cabin interior (in Autodesk Maya). Brown door leads NOWHERE.

Real Estate Tip #2: Who is going to visit my cabin?

While designing your virtual space for a virtual character to inhabit is important, it is also crucial to consider how guests visiting your space will react to the world you’ve created.  I boil this down to two questions to ask: Will the player be able to navigate my world efficiently? Will the player believe in the world I’ve created?

Regarding efficiency, I feel that the design of my cabin was fairly straightforward – in both cases I used simple geometric footprints for my layout (long rectangle in 2014 and large square in 2015). While I would have loved to create a more unique blueprint, I thought about the location and timeless period that this cabin is found in and realized that I needed to forego luxury and spatial design for minimalism and efficiency (I have decided to add some outbuildings to the cabin that the player would see when outside, to add some more complexity to the design in a different way).


2015 (filled) cabin on left, 2014 (empty) cabin on right (Autodesk Maya Screenshot)

While my 2014 cabin was visually interesting due to the objects, textures, and lighting, it didn’t make any sense as a living space.  It was long and narrow, lacking half the things you’d normally find in a cabin, and confused the player with an extra door that never opened. In my 2015 redesign, I’ve attempted to create something that is more open, yet feels extremely compact (borderline claustrophobic), to give the sense to the player that someone had lived here for a long time. There is now a single point of entry/exit to the cabin, and I’ve tried to lay out the objects in a way that feels like someone has been accruing memories across multiple time periods. While half of the objects have yet to be modeled, I already feel better about this space, for both the player and my narrator (half of the objects are already modeled, but I haven’t applied the textures yet, as I need to update all of them for Unity 5’s materials).

New Cabin Interior (Grey-box), 2015

New Cabin Interior (half modeled, half grey-boxed), 2015 (in game screenshot, Unity)

Real Estate Tip #3: How much inspiration does my cabin need?

A trend that I’ve been (happily) noticing in-game design lately is the amount of research – or pre-production – people are doing for their games.  While this has always happened to a certain extent, devs and companies are starting to realize that the more seriously we can take our medium from the beginning, the more likely others will take it seriously as well.  Whether it be the AAA studio who flies their devs to Florence to research Renaissance Italy, the mid-sized game dev company who uses on-site photogrammetry to create the majority of models for their game, or the artist who uses a Sear’s catalog as her style and image reference guide, people are doing solid research these days, and it is paying off ten-fold in the final product.

Objects from the Pine Needles Cabin, Modeled in Maya

Select objects from the Pine Needles Cabin for Tombeaux, Modeled in Maya

As an academic, I take research very seriously. When you add my obsession with details and rule-following to the pot, things can get out of hand really quick.  This actually happened last summer with the cabin, as I decided to recreate the exact cabin I was living in, down to many of the objects in the room. While this was a good exercise in observational modeling (and I had access to great texture references), I simply got too caught up being inspired by my surroundings.  The environment I was creating wasn’t making sense for the player and fictional character, and much of that was being driven by the exact place in which I was eating, sleeping, and working.  While the residency at Pine Needles was a monumental and crucial element to envisioning and starting Tombeaux, it took a lot of of user (play)testing, self reflection, and research to realize that it wasn’t the right fit for my game.

Exterior & Interior View of 2014 Cabin Inspiration

2014 Cabin Inspiration (Exterior & Interior of Pine Needles Cabin)

Now a year later, I’ve realized that – in addition to the lack of connection to the subject I was attempting to recreate – I simply don’t have time to be so exact and anal-retentive about everything.  I’ve got A LOT to model and texture, and while that cabin is very important, I can’t lose sleep over how many inches wide the windows each were (yep, I was approaching it like an engineer instead of a level designer!). So now, I’ve reconfigured the cabin’s exterior shape to be loosely based on a simple pioneer cabin.  The interior seeks out another source of inspiration: I’ve discovered the work of Eastman Johnson, who spent most of 1856 living and making artwork on Lake Superior, among the Ojibwe people and the fur traders. He sketched a few cabin interiors that I’ve found particularly pertinent to the look, feel, and time period that I’m hoping to achieve in Tombeaux’s cabin (and river) environment.  His sketches, combined with a late 19th century cabin exterior is shaping up to be a better fit for the game.

Exterior Interior

2015 Cabin Inspiration (L: Homestead National Monument, R: Eastman Johnson Sketch)

So, just as the mantra has been for the past few posts, a lot can happen in a year.  Although it sometimes feels like I’m taking two steps forward and one step back, I think it will be worth it in the end. It is my hope that the player will walk into the cabin and immediately feel my intentions for the designing the space, through their observation of a strong narrative, thoughtful visual layout, and solid research foundation.

Ideate. Playtest. Repeat.

I’ll be honest, when people ask me what it is I do for a living, I take a small amount of pleasure in seeing their response when I say: “I make video games and teach game design”. Even though it is 2015, I still – more often than not – get the look from someone like my career is akin to what the people in the below video do.  This is most likely due to their lack of understanding behind the process behind game dev, and not necessarily the lack of respect for the medium (although the two can be connected, of course).

Game development is very similar to any other field of design or development – there is a problem or challenge put in front of the designer, and it is their job to solve that issue in the most efficient and interesting (and in my case, aesthetically pleasing) way.  People do it everyday. Product Designers make objects. Architects make spaces. Graphic Designers make images. Engineers make bridges. Game Designers make experiences. Some of those experiences can be profound and life-changing, while others are as shallow as the money it earns is deep.

I frankly don’t know where my game stands on that spectrum I outlined above, but I’d like to think it leans closer to the profound than the profitable. The challenge I gave myself was fairly straightforward: I wanted to design an experience that incorporated my interests in history and the environment into a digital 3D world that could be experienced by nearly anyone (including the 6-year old digital native that is my daughter, the 20-year old twitch-gamer that is my student, and the 70 year old tech-challenged person that is my mother). While it might be straightforward, it isn’t necessarily an easy “I can design that sucker in a day” sort of project.  This was going to take time, and I discovered that it was going to take more and more time the further I dove into the research, ideation, and game engine.

With this in mind, I wanted to outline a few key stages I went through in the beginning (and still am returning to), as a way to explain my process a bit better.  None of these are inventions by myself or new elements to the game dev world – in fact, one would probably be hard pressed to find a single successful game without these elements embedded into its process, so for any experienced game designers out there reading this, I hope you’ll be patient during this primer.


Select Slides from Tombeaux’s Game Design Document

The Game Design Document

Simply put, every game needs some sort of game design document (GDD or design doc for short).  Some take the form of wikis, others a google doc, others a pile of papers, while others are through a slideshow/PDF.  This doc is essentially the “manual” for the developer(s) to reference and use throughout the process. Due to a game being so freakin’ huge and bridging across so many disciplines, this document is literally the 10 (plus a few hundred more) commandments brought down from the mountain (and heaven help the person who decides to stray from those commandments!).  This doc includes objectives, mechanics, narratives, level layout, game flow, playtesting, sound info, and dozens of other things pertinent to the game’s functionality and playability.  To use one more analogy – this document literally is the blueprint for the entire game.  The more you can solidify this document in the beginning, the less likely there will be issues like crunch, communication breakdown, or feature creep, later on.


Trim the fat on that design doc

I decided to go with a powerpoint/google slideshow for my design doc, so that I could rearrange the doc easily, integrate a large amount of media, and have it easily transfer into a pitch doc when speaking with others about my game.  In what started out as a relatively thin manual, my design doc grew into quite a large digital tome.  Perhaps this was due to my academic background of insisting on references and footnotes, or my artistic side wanting to see big, beautiful images throughout the doc.  Regardless, I’ve been able to cull it down to about 70 slides now, which feels like a good number.  While the initial work went into putting it together last summer during my Pine Needles residency, I’ve spent time over this past year refining it, largely based on the research and playtesting I’ve been conducting.


Map from sketchbook of cabin interior level

Map Making & Level Design

If one’s goal is to create an environment for a player to explore, a birds-eye view map to visualize that overall experience is probably a good way to start.  I have two environments to explore in Tombeaux (and the player continually returns to both of them): an outdoor river level and an interior cabin level. While I went through a bunch of different iterations, I decided to move in to 3D with two sketches I had made early in the process.

I was aware that my vision might be larger than what was possible for making this game, so you can see that I immediately sliced off about a quarter of the cabin interior space (above), as I know that virtual spaces always feel larger than they actually are in the engine.  While you can’t necessarily see it in the river map, I also ended up squashing down that entire level too, to make the overall exploration area like that of a square shape, rather than a tall rectangle like it is below.


Map from sketchbook of river level

Grey Boxing

From this point, it was time to jump into the game engine to get a feel for the virtual space I had envisioned.  Using my maps as blueprints, I dropped down various boxes and other primitive 3D shapes, so that I might begin exploring the pixelated, lo-poly beginnings of the world of Tombeaux. Normally, this is called grey-boxing, and while I basically did that, I went a bit further with some shapes, as well as colors and shaders, so that I could begin to envision sillhouettes and color palettes into the game (which quickly became much more muted and less Minecraft-y, after seeing them in engine!).


Grey …err… Colored Boxing


It’s my opinion that one of the biggest mistakes that game developers make is that they push playtesting back too late in the pipeline.  Picture this: near the end of the game development process, your game is like a giant, 15-ft tall snowball careening down a mountain at 250 MPH.  It is a lot easier to stop that snowball and rebuild it when it is near the top of the mountain, before it has gotten too big or started going too fast. Playtesters – people who aren’t associated with your game who could play it and provide you with some feedback – will help you avoid those last-minute snowball messes.

I’m a firm believer in playtesting your game from day one, which means you must have outside people play your game.  From those first playtest sessions, I learned about how to change the levels, tweak controls, reconfigure narrative, and even slightly change the direction of the game’s objective.  Those first two weeks of playtests were crucial to a smoother development pipeline down the road (and a big thanks to Emily, Josh, Simon, Amy, and Mitch for your help!). I’ll return to speak more about playtesting in a later post, in which I’ll dive into my reasoning, inspiration, and approach to the playtesting process.


My kids, playtesting Tombeaux

Hopefully these short summaries about specific elements in my process have helped you grasp a bit more about the game dev process.  Before one can start actually playing the game as it was meant to be played, there is a great deal of research, design, iteration, and testing involved (not to mention all of the coding and art!). If only it was as easy as those guys said earlier, and I could just “tighten up the graphics a little bit” – but what’s the challenge in that? 😉