Trees, Glorious Trees!

As I’ve mentioned before, Tombeaux has a main narrator character who we hear reading journal entries throughout the game experience. But there is a group that I would argue upstages our narrator, and that (as you probably guessed by the title) is the trees. Before the St. Croix was a river of recreation for fishing, canoeing, and speedboating like it is now, it was a river of pine, acting as one of the nation’s busiest highways for timber in the mid to late 1800’s. During this time, non-logging boats were lucky to get up the river at all, due to the waterway being clogged full of floating logs (or even worse, a logjam that stopped everything in its path). Since the St. Croix directly connects with the Mississippi, and it had what seemed to be an unlimited supply of tall and straight trees growing along its edges, it was a resource ripe for the picking (or chopping…sorry).

Pinus_strobus_trees

L: group of Pinus strobus, R: distribution map of tree (images via wikipedia)

While Tombeaux is not entirely about the logging industry, it definitely does take the player on a journey to see what it might have been like both before and after the timber harvest. Because of this, I wanted to set the stage by creating an old growth forest, with the main silvan feature being that of Pinus strobus, or the eastern white pine. These old growth forests of white pines are nearly impossible to find now, as only 1% remain in North America due to logging in the late 19th and early 20th centuries. This type of pine is the tallest tree found in the eastern (and northeastern/midwest) United States and Canada. With a mature white pine living well past 200 years old, reaching heights of well over 150 feet (while keeping a very straight trunk), and a diameter of 3-4 feet, they were particularly attractive to lumber barons.

pinus_strobus_moodboard

Mood Board for reference

After doing some visual research, both online and in person (last post I wrote about my trip to northern Wisconsin, in which I did some bark texture reconnaissance), it was time to dive in to creating this giant beast of the forest, including the many iterations that it might take, such as sawed-off stumps, beaver-chewed stubs, and dead (needle-less) versions (both standing and downed).  Additionally, I wanted to make sure I was creating an environment that felt both native and diverse, filled with other types of trees such as oak and birch. At a later date, I plan to return to the detail meshes and plants, to create native species such as wild celery (an underwater type of river weed/grass), wild rice, ferns, and wildflowers.

speedtree_whitepine

One iteration of an eastern white pine, inside SpeedTree

Once I compiled a small mood board, I set out to learn and use a new program that I had been itching to try, called SpeedTree. It is an industry standard tree and foliage creator for both movies and games, and now that it is naturally integrated into Unity 5 and Unreal 4, we will most likely continue to see a great deal of high quality natural environments in the coming years from both indies and AAA companies. One way to use their tech is by paying and downloading high-quality, pre-made tree assets from their store (but what’s the fun in that?!). Another, more creative way is by paying a $19 per month subscription fee to use their modeling/creation software. As a point of reference, two months of paying for the software is actually cheaper than the $39 price tag for a single tree from their store!). Since it is my goal to create as much in my game as possible from scratch, I decided to download the software and start making assets myself.

stumps

2 Stumps and 1 Gnawed Beaver Tree in SpeedTree

bare_tree

Bare (Dead) White Pine in Speedtree w/ Bark Detail

Simply put, SpeedTree is my new favorite software. One can quickly and easily create natural assets for a game, using an intuitive, node-based interface that tries to mimic how a tree is naturally constructed. Starting with a trunk, and then adding elements such as roots, branches, and leaves provides for a very smooth workflow. Everything is highly customizable as well, with integrated wind effects, collision capsules, seamless branching, randomizers, break points for branches or trunks, and automatic billboard and LOD (level of detail) creation upon export to Unity.  Once I created a base white pine tree, I was quickly able to create many iterations by simply removing leaves (bare tree) and breaking and capping trees (stumps).  I didn’t even use many of their features, and hope to dive deeper into the program when I use it to create plants and other detail foliage.  Again, I can’t say enough about how much this program has helped my environment-heavy project achieve a great look.

LOD_unity

LOD transition feature in Unity (LOD 0 on left w/ 9K tris, LOD 2 on right w/ 2K tris)

Once you bring a SpeedTree asset into the Unity engine, it offers other great options for you to tweak. With the LOD’s that were auto-created/exported by SpeedTree, you can adjust them to your liking in the engine, so that it seamlessly transfers to a billboard at the distance you set. I really like the fact that you can also drag and drop the trees into the scene as objects or prefabs. Since these also have the LOD settings, you could put a hero tree (a hi-poly, hi-detailed tree) in your scene without having to worry about relying on Unity’s finnicky terrain.  With that said, I painted most of my trees on the terrain, as it makes it much easier when you have a large amount of assets to place and randomize.

tombeaux_5

Here there be beavers…and downed trees…the perfect natural barrier!

Due to my game being on a river, it is important that I have some invisible walls that will stop the player from continuing up and down the river at their leisure. Implementing barriers correctly is tricky, as you don’t want the barrier to scream “HEY, I’M AN INVISIBLE WALL PUT THERE BY A GAME DESIGNER WHO DIDN’T REALLY CARE ABOUT YOUR IMMERSIVE EXPERIENCE THAT MUCH!” (sorry, it is one of my biggest pet-peeves in games). While natural-looking barriers are great, you also don’t want it to be mistaken for just another stick or bush in the game that one thinks they can walk over.  I try to put some purpose behind the walls when possible, which is where things like downed trees, beaver dams, and beaver-gnawed stubs come in to play (plus, it’s always a great way to show off some of your hard work in a more up-close view!).

tombeaux_2

The view from directly outside the cabin door

While the exterior river scene is hardly complete, I’m happy with the progress I’ve made in the past few days on the tree elements.  So far, I’ve created and placed four iterations of the white pine, three of the birch, and two of the oak. Additionally, I have three white pine stumps, three gnawed-beaver stubs, and three downed trees.  Once I give the same attention to the plants and detail rocks (they are all currently the low-quality placeholder plants that Unity provides), spend some time on the lighting (it is just a single real-time directional light w/ default skybox at the moment), and add some environmental effects like haze and fog, the river will hopefully start to look more like it did 200 years ago.

tombeaux_3

Looking up to the cabin from the river (underneath a couple towering pinus strobus)

Advertisements

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.

cabin_maya

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

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).

20150603_203203

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.

Untitled-1

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.

3_rocks_cliffs_ideaboard

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.

8_rock_textures

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)

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.

gdd_overall

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.

tumblr_myjjeliP4j1sum3xmo1_500

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.

cabin_map

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.

river_map

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!).

greyboxed

Grey …err… Colored Boxing

Playtesting

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.

kids

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? 😉

and so it begins (albeit a year late)

My name is Dave Beck, and I’m an artist and professor living and working in Wisconsin. I’m writing this blog for you. I hope this peek into my development process will give you a better understanding of my project (which I’ll introduce below), and possibly inspire you to follow and learn along with me on this journey.  I’ve got a lot of lost time to make up for, so before I dive into the “now”, I’ll start with the “then”, much of which happened over this past year.

On that note, I really should have started this devblog a year ago, when I first began the project.  But then again, I had no idea that it would grow to such the monstrous behemoth that it has, filled with so many design doc pages, polygons, pixels, sounds, and lines of code!  The project I’m talking about is Tombeaux. 

tombeaux

Tombeaux Blog Header

Tombeaux is a video game that I am creating.  It is an interactive experience that explores the convergence between cultures and the environment across a few hundred years of midwestern American history, taking place on a small section of the St. Croix River (which serves as part of the natural border between Minnesota and Wisconsin).  Through exploration, the player discovers new objects, environments, and narratives, all of which cause reflection upon our history and our future.

Map of St. Croix River, by Kmusser, based on USGS data, via Wikimedia Commons

As an artist, I see the medium of games as having a fantastic future in contemporary art and new media. It’s a wonderful way to educate, entice, and entertain an audience in ways I’ve always wanted to do with other media, but just couldn’t fully accomplish. I’m making Tombeaux for a variety of reasons, many of which I’ll expand on in future posts. I’ll talk about my inspirations behind the game, the development process, the factual research fueling its content, the collaborations supporting its creation, and other things that provide interesting angles about Tombeaux.

It’s already been a heck of a ride, and it’s only halfway there.  I hope you’ll consider joining me for this last leg of the journey.