MFA Thesis

Background

This project was done as my thesis for my Masters of Fine Arts in Game Design which concentrated in Environment Art. I came to Game Design via the Architecture field. When I studied architecture in undergraduate used 3D tools a lot, to the chagrin of my teachers. Upon graduating this lead me into working with game engines to create tools for biotech research and at architectural firms.

The initial idea was to create a portion of a futuristic city based off of Woken Furies by Richard K. Morgan. It was intended to contain 5 distinct district, modeled, textured, light, at FPS quality. Initial, I wanted it to be a large collaborative project. Where I would work in part as an Art Director along with make assets for the game.

As with anything in art and design the journey of this project took many turns to get to its end. Midway through production I re-pitched the project. The re-pitched focused on one exterior and one interior area with limited game play. This time I did not plan for any collaboration. The entire project was to be model, texture, light, and make sure it worked in the Unreal Developers Kit (UDK).

After an intense learning process my project was completed and ran at 30-45fps with working mechanics. Below are some of the trials and tribulations I had during the process.

First Attempt

During pre-production I was in the Animation and Visual Effects Departments. So my advisers did not have vast knowledge about the game field. This caused some misdirection, a later conclusion of mine, but it was by no means a waste.

In pre-production my adviser focused me on the narrative. I loved developing the idea of the game, coming up with characters, enemy NPC's, places to visit, figuring out weapons/equipment/power ups ect. At the end I knew the feeling for the game play, different levels, when level/quests would activate, the upgrade process, abilities of PCs/NPC, and much more. At my midpoint presentation I spoke for about 50mins regarding all the ideas and we only had 10 minutes for question and answer; which was enough time due to the amount of information I had given.

The narrative was extremely strong, but the imagery and designs were not fully expressed. While I had a strong mental image of the world; translating it to 3D was slow. Without proper pre‐production I did a lot of "design as you go." Additionally, I kept lean towards Art Deco form with minimalist ques. This was problematic for two reasons; 1) I had pitched a where Mass Effect meets Blade Runner 2) minimalist design is hard and I learned it is even harder in games.

The first issue was compounded by not reviewing my reference enough. I had folder and folders of material, but I did not look at it daily. This is something that was later drilled into me, thankfully, and has become a staple of my process. With the "design as you go" approach my modeling and designing was slow too.

Additionally, my background caused me to continually think in real world terms, "steel spans should never go over X length," "concrete is only best in Y situations," or "the wall could be built like this." While this is great for architecture and could be helpful contemporary settings it was not my original vision. If I had used proportions as a meter and not numbers the sci-fi feel could have been easier and quicker to achieve.

During this process I learned that some architectural ideas/theories, like minimalism, do not have the same impact or application when applied to game environments. Architecture has to transmit feelings/function while games need to transmit story/direction. While there are similarities techniques to do this they are also very divergent. After creating some spaces that, Luis Barragan, Todao Ando, or Mies Van Der Rohe would enjoy, I found Gamers felt the spaces were cold, boring, and static. I received comments like: "it all feels the same," "where is the detail," "what's the story," "where is the drama?" The real world spaces have an amazing unique quality, but you have to physically be in them to experience it. I was missing that those same feeling do not come though in such a subtle way in games and that the spaces transmit back different feelings and experiences.

Reboot

In early 2011 Pryce Jones and I discussed the semester goals and I said to not sugar coat any critiques. That leading to a discussion about project scope and visuals. He said the narrative and ideas were great, but the visual expression was poor; which I agreed with.

So we started to prune the project into two areas. The pruning helped but with the baggage I had form developing such a large narrative the project needed to be lighted more. This brought me to a pivotal decision; consider starting over. Doing so would put aside 8 months of work that included; development/research, modeling, texturing, and ideas. It was an incredible hard decision to make, but it was the right one. The following weeks were was spent redeveloping parts of the narrative, but mainly it concentrated on the the visual expression and embracing the Art Deco leaning.

Pryce reiterated to focus on the visual narrative and not the written. This got me to shift from thinking of "creating space" to "creating images." In architecture I though about how spaces express ideas like: compress/release, heavy/light, open/closed, ect. The error I had been making was thinking about it as a "real space." I needed to think of it as 3D space conveyed in a 2D format. The questions are similar in games but the representation and execution are different.

Additionally, my thesis started in the middle of a large game idea. Since the narrative had elements explained in earlier levels I made decision based on what was not visually apparent in my project. Since I knew what would happen I did not consider this as an issue. Figuring out those earlier levels was a great paper exercise. I concentrated on how events connected, the overall feel of the game, and the variety of experiences but I was blind to the confusion people were having.

I received comments like, "the building and gas tell me "this," but "that" something else." In part this was because the player did not experience earlier levels that explained the "raison d'etre" of some assets. Had they experienced that the misunderstandings may have been diminished. Still this is not a viable explination or solution, because of these comments the project under went a couple of rounds of vicious editing. Some which had a large investment of time. Later I concluded projects of this size needs a short and simple narrative.

Having edited so much out after I had designed, modeled, and textured the asset I learned an all important leasson, distilled by my teacher Matt Abbot very well, "Get it in engine even if it's crap." His point was if its in engine early you know if it is working for the composition or not. If isn't working there isn't a lot of time of wasted time. Once the composition is pinned down then the asset can be optimized, made modular, and made to look awesome. I regret knowing that I told others to do this but did not follow it myself; something I have since changed.

Production/Techniques/Solutions

Creating all the assets was an ever changing experience. Initially, my pipeline was Max based and I planned on using the Virtools or Cryengine 3. In the primary tools of my pipeline were Maya, Zbrush, and UDK. My pipeline mainly changed because of the school curriculum not because one was "better" than another. For engines Unity was an option but I felt UDK's GUI shader system would be easier and its is by far more robust.

Shortly after starting my work with UDK I learned how robust the shader engine was. I found that for small changes it allowed me to fine tune materials and textures without constantly going back and forth to Photoshop. I also learned how powerful small mask textures are to fine tune specific parts of a texture. One advantage this gave was being able to put different specular powers on different parts of an asset. A similar technique used masks to additional variation to tiling areas beyond vertex texture blending. Finally, master material let me cut the memory budget by creating material instances that could swap maps and changing parameters. This was very useful in making blinking lights with different timing, brightness, or re skinning an asset quickly.

An early decision of placing the main building at a 45 degree angle caused a number of headaches. UDK does not allow for all the translating and snapping that most modeling packages do. Had I started to work in-engine sooner I would have learned this and changed my process. Since I aligning object precisely was nearly impossible I investigated reworking the assets/scene to be more UDK friendly. My tests showed it would take longer to do that that get creative with work arounds. Eventually, this resulted in the objects being divided more and built to overlap. This had an unintended positive benefit by decreasing light map sizes.

Other issues were more technical. For example, when baking light in my exterior scene the May 2011 UDK would crash instantly. At first I thought it was a RAM issue, but discounted this after doing a distributed render across 10 computers with 12gb of RAM each. After researching and checking log files I discovered that there was a bug in that release. The bug would crash UDK if there was a "Landscaper Actor" and lighting was calculated in a 64‐bit environment. Luckily, this bug was not in the 32-bit environment. With the RAM limit in the 32-bit environment I would also get crashes. This resulted in developing a multi-step process to get the lighting. The process boiled down to deleting the landscape, baking the lighting in 64-bit, bringing back the landscape, then doing the lighting on the landscape in 32-bit. This was a laborious and dangerous, but it worked.

The other main of issue involved the gun. Rob Howell helped me a lot with solving this. We had based the code off the Shock Rifle from UT3 and for the most part it worked perfectly fine. The first struggle was getting the gun to destroy the toxic gas tanks. The hit scan/ray cast would leave a decal, but the tank never "knew" it had taken damage. We eventually discovered Kismet would respond to "projectiles fire." This caused us to rewrite more code to get the primary fire to be a small projectiles. Then we did some basic weapon balancing to work on the time between shooting and hitting.

Firing the gun had problems too. Some how we would get had unlimited ammo occasinally. This was solved by removing code in the weapon class and relying on a high script in UDK to call the reload function. It was a simple fix, but one took a while to discover. It was also a "hack" but we did not find an elegant solutions, and in the end it worked so we did not question it.

This "hack" might have caused the gun to get stuck on reload at times though. That happened more often if a player was sighted in and tried to reload, but this that was not a fool proof way to trigger the bug. The gun could be "unstuck" if the player sighted in and out a few times. Rob and I both felt this was caused more by "hacking" the reload function than anything else.

Final Thoughts

My thesis took a lot of twists and turns, but overall I am glad I had the experience. My original pitched was too ambitious, expansive, hinged on other people, and not investigated thoroughly. There were times when I knew I was in over my head but I pushed forward. Sometimes this meant making a decisions that made the pipeline trickier. Other times the decision felt like taking steps backwards but were ultimately steps forward.

I am happy with how far I came with this project. There was a ton of researching, experimenting, and self teaching. At the time it was very stressful. Now, looking back, I remember it as being fun. Going through the program when it was brand new awesome and frustrating all at once. With some of the growing pains gone I cannot wait to see what future students create. I hope the suggestions I made to the School of Game design post graduating have had a positive impact.

Finally, this post-mortem is not all encompassing by far. Had it been there would be a lengthy book to read. I hope it was helpful in someway. Feel free to contact me if you have questions. I will do my best to respond.

Thanks to all those who supported and helped me through my thesis.

Thanks to all those who supported and helped me through my thesis.