• Portfolio
• Resume
• About

O2 - Survival-Themed First-Person Shooter

November-December 2008

Role: Modeler/Texturer, Technical Art Lead

Engine: Unity

Awards: Best Adaptation of Theme (Survive)

In O2 you play a grunt worker who's stuck with the rest of the lower class on a space colony that's running out of oxygen while the upper class has evacuated. Knowing that the evac ships aren't coming back, you resolve to fix the oxygen problem--but you must fight your way through the panicking masses to do it, with only a half a tank of oxygen and your trusty plasma riveter to see you through.

Key Features:

• Ragdoll physics on enemy death
• Normal Maps--Tower pipes and player character hands
• Large game world
• Accurate aiming
• Moral ambiguity

Fun Fact!

On so many projects we'd resolved to make multiple genders for NPCs but invariably the time crunch gets us and we only ended up making the male NPCs. This time we decided to make the female ones first--but invariably the time crunch got us and we only ended up making the female NPCs. No, this game isn't a statement against women.

Postmortem

I unfortunately had very little role in this as a game designer. The fact of the matter is that I was the second best artist in my class, and even if design was my greatest interest and biggest strength I was still so much better at doing artwork than most of my classmates that we really couldn't afford for me to not focus on it completely. So, I focused on it completely and ended up taking a "technical artist" lead on this, helping the other two modelers identify and solve their problems and doing everything I could to insure that the many, many ingame assets here at least ran efficiently.

The models I was responsible for included the gun & arms, the tower at the town's center, the oxygen tanks, the dome, all the pipes, an unused box, a pair of unused trees, and an unused catwalk. I also did a last-second texture for the overturned truck, which had the world's worst UVs.

I attempted to work normal and specular mapping into this in order to achieve higher visual quality but sadly Unity's support of them is very limited and an object that will appear to have rub-your-skin-off roughness in Maya or any XNA-based game will look almost smooth in Unity. Additionally Unity won't support specular maps at all. All of this is a real shame because I worked a lot of normal maps in to conserve on the tower's number of faces and they hardly showed up at all, only appearing on the surface of the pipes and still failing to display the texture apart from the lines cut into them.

Things I Learned on this Project

Designers who don't know how to do anything practical at all will not have a good workflow for between themselves and artists. This was by far the most art-heavy game I ever worked on, so the communication issues became very apparent.

• First, Unity seems to reference the same texture once each time a model is used as opposed to just once, period, for each copy of the same model. The designers' insistence on using the terrain editor, which I regretted endorsing so strongly at the semester's beginning, made it impossible to set up the town in Maya in such a way that it would recycle textures efficiently. The resulting framerate issues caused us to drop the majority of my normal maps when they shouldn't have been an issue.
• Second, the designers seemed to think we were psychic. I made my tower and the dome and the pipes quickly, but I had no idea that they had planned on taking the player under the pipes and had absolutely nothing to do with the terrain the object was being set in, so I didn't put a face on the bottom of the concrete blocks that I'd originally put on the outer walls of the dome where the pipes went into them. I'd thought I had fixed the issue and put a face on the bottom, but it turned out the normals were facing the wrong way and no one bothered to tell me about it, so it got turned in with these concrete blocks with conspicuous holes in their bottoms looming over every area transition. Being that I never received a playable build of the game up until this one I retrieved from the bowls of the asset server I was never able to ascertain this myself.
• Third, the level designers would refuse to work on making their levels until the artists made the resources to go in them. This considerably limited the amount and quality of relevant assets we were all able to produce and incorporate into the game. We had to focus more on getting things done quickly instead of getting things done well. This also meant that not a whole lot of thought ended up being put into the level design. If they'd created a basic representation of their level and ideated and re-ideated on it while the rest of us really focused on the common assets we knew were going to be using, then let us polish up the in-betweens they'd made I bet we'd have come up with something a lot more imaginative and satisfying. Certainly there would be more visual polish.

This proved to me what I'd suspected coming into the game design specialization in the first place: that as a designer some practical experience in art or programming is invaluable, if only because you understand how the pipeline can get gummed up and how to avoid making unreasonable demands. This game wasn't stellar, but it gave me a really, really clear idea of how not to work as a project manager or a designer on any project. I'd argue against the methods we were using, saying real artists never work the way they were having us work, but the only thing the designers could tell me in response was that we weren't real artists. They seemed to think that my perception of a good art pipeline was some kind of fantasy that didn't apply to the classroom or most of all to them. I find I run into this problem of being taken seriously when I raise an objection very frequently. Personally I think they're just trying to find the path of least resistance and don't want some maverick ruining their strategy of academic survivalism by forcing them to put forth more effort where they know that they can get by with less.