Trailer created by Bryan O'Hara and Keith Tatarczuk

Download the Game
(414 MB installer exe)
Craig Ellsworth
Steven Beaulieu
Evan Burrill
Chris Cheng
Cory Livingston
Corey Moore
Eric Nardo
Bryan O'Hara
Alison Seffels
Keith Tatarczuk
Thomas Triplet

Buzz Ambroseno
Logan Dwight
William David John
Justin Loomis
Karl Markis
Level Designer
Lead Programmer
Level Designer
QA Manager
Lead Designer
Producer, Narrative Designer
Lead Artist
Level Designer

Voices, Sounds
Audio Lead
VO Lead
QA Lead


Carnero is a first-person shooter developed in UDK, with level design that favors puzzle-solving, atypical navigation, and strategy over blunt force.

You play as Kurt, a space salvager looking for the infamous ship Carnero, a sci-fi El Dorado. With your trusty AI pal E.L.I., you make your way through the ship to power it up and drive it home. Onboard, you must fight your way through an onslaught of robots that have infested the ship.

Your main weapon is a salvage gun which does minimal damage, but pushes enemies away from you. To get through areas with enemies, you often must push them off ledges or under breakable objects to crush them.

Through the course of the game, you also gain access to the spaceship's environmental controls, enabling you to magnetize the floors, and raise or lower the temperature. Magnetizing floors sends cargo crates and catwalks crashing down, freezing the ship makes some objects brittle, and heating the ship causes explosions. You must use all of these controls, along with your pushback beam and decoy grenades to destroy your enemies.

I served as level designer for Carnero. I was responsible for designing and building Level 2, a tutorial on magnetism and your gun's alternate fire; and Level 6, the final boss fight.


What Went Right

1. Enthusiasm and Buy-In

Coming onto the project after pre-production, our Lead Designer decided the best way to build some team spirit was to take us all rock-climbing. It was this sort of thing that kept us motivated and happy to work. During weekend jams, our Producer bought us pizza, and our Lead Artist brought in coffee and donuts. The friendly atmosphere was a huge boost to morale and made us all excited and eager to come to work each day.

On top of that, each Level Designer was given full responsibility for his levels, giving each of us a sense of control and full buy-in to the project. We were given our requirements, and beyond that, do our best and make great levels. We ended up with a game that feels cohesive but has a distinct feel and flavor to each level.

2. Team Vision

The design paradigm was a brilliant stroke by our Leads which separates Carnero from other shooters. Focusing on atypical navigation allowed us to come up with intriguing paths through the ship that look constantly unique, yet use modular assets over and over. A focus on strategic battles allowed us, the Level Designers, to stretch our brains and come up with innovative encounter areas.

The design also changed as new members joined the team. We had many meetings where every team member gave their thoughts on the design, the art, the AI, and the story. When a great idea was hit, no matter who it came from, it was immediately favored and people got excited. This led to a team vision that made us all feel valued and important to the design process.

3. Leadership

Having full team meetings five times a week gave us plenty of face-time with our Leads and Producer. I was sitting next to my Lead Designer and Producer nearly everyday. Our Leads were friendly, happy, and always on the ball. They weren't just management; they were peers. We could go to them whenever we had a problem and they always had their ear open.

It was this sort of atmosphere in the workplace that made me happy to come to work on a Friday night or Saturday morning when crunch time gets out the whip. Spending so much time together also allowed us to help each other out the moment there was a problem. We came up with design solutions for each other's levels, taught each other software tricks, and made sure our levels flowed smoothly from one to the next.

What Went Wrong

1. QA Structure

Quality Assurance is a much under-valued role in game development. It is the place where you learn if all your hard work turns out to actually be fun. You learn where the game is broken, where it is solid, what needs to be fixed or tweaked, and what needs to be completely redesigned.

We had a dedicated team of QA leads and managers directing dozens of testers with four games. No one can quite be sure where the ball was dropped, but I think the failure might have been on multiple levels, since there were so many steps between the tester and the level designer.

This was the QA structure: the Level Designers tell the Lead Designer what they want to know about their levels, the Lead tells the Producer, the Producer tells the QA Lead, the QA Lead tells the testers, the testers test, the testers and QA Lead make reports, the Producer sees them and disseminates them to the Level Designers. Way too many steps! By the time we got the feedback, it was out-of-date, incorrect, or useless.

After a lot of this, I decided to cut out the middlemen and see what was going on. I went down to testing and took notes. I got more useful feedback from five minutes watching them than I got in months previous.

2. Sound

The sound team was originally composed of only two members, eventually becoming three, but which had to split their time between four projects.

The voiceover people did a great job in the end, but communication issues weighed them down in the beginning. Because the sound team was separate from the core team of Designers, Artists, and Programmers on Carnero, the audio team often wasn't at our meetings, and we had to relay the information later. Similar to the QA problems, our lack of communication (or perhaps, layers of communication) prevented us from clearly explaining what we wanted, and the audio team couldn't clearly explain their process and what they were capable of.

The battle with audio lessened as the script was finished for the voiceover guys to record, and we found alternate ways of getting our music and sound effects, but we worried for a long time about getting our placeholder sounds out of the game.

Lessons Learned

1. Core Team, Schmore Team

The QA and Sound fiascos made us realize that our "core" team of eleven people should have cast a wider net. The Audio team should have been present during our meetings, at least any where we specifically talked audio needs, and the QA team needed a more direct line of communication.

By the end of production, my fellow Designers, Artists, and Programmers felt like brothers, but the Audio and QA teams felt like strangers, even if we were all friends in our social lives. Audio and QA may seem like specialized fields at times, but they should not be looked over and always need more involvement in the production process to make a better game.

2. Do It Right - Do It Yourself

When things need to get done, you sometimes can't expect others to do them, or do them well. Again, our problems with sound effects and QA feedback had us scrambling and thinking that there had to be a better way. When I took the initiative and went down to QA myself, I discovered a lot of directly applicable problems that had never before been discovered. When the sound effects wouldn't come in, our Lead Designer spent hours pouring through a foley library to get the assets we needed, and the rest of us improvised by editing the standard UDK sound assets.

In the past, I've learned to do the work of two people, learning the skills of Design and Programming. From Carnero, I've learned to do the work of a third, discovering the process of QA and what works best.

On big projects, I prefer to specialize in my field of choice - Design - but when push comes to shove, and problems arise in other areas, I know how to fix them myself.

Gameplay footage of Level 2. You may want to fullscreen it.

The Player's view of the final boss upon entering the bridge. Click for a larger image.

A cargo bay. The Player enters from the lower-left. The Player must shoot and destroy the glowing green support, then magnetize the floor to make the catwalk come crashing down, killing the bots below. Click for a larger image.

A kismet sequence for the puzzle shown above. Click for a larger image.

Original blueprints for Level 2. Click for a larger image.

3/29/11 Level 2 in-editor. Similar to the drawing above, but the second room became a "between the walls" corridor, shown in the perspective view. Click for a larger image.

The boss battle is a multi-storied assault on the bridge/security center of the ship. Click for a larger image.

A kismet sub-sequence on how the robot arm attacks when the player comes too close. Click for a larger image.

3. It's not a Workplace, It's a Home

Game development should never be treated like a job. While much work needs to be done, game development requires so much cohesion that everybody needs to be on board, on the same page, and get along better than best friends. After all, you'll be spending eight or more hours a day with your coworkers, so they need to be closer than kin.

When personal problems arise, it's best to get everything out in the open, aired, and dried. Not everyone needs to know, but the major parties need to deal with problems efficiently, but with great care and empathy. Most of the personal problems that came up in Carnero were dealt with quickly, before they were allowed to boil.

In game development, the goal is that everyone is so comfortable with each other that they act in concert as one giant hive mind that know exactly what to do. This is best accomplished through both nature and nurture -- what personalities people walk in with, and the relationships they cultivate.

All written content copyright Craig Ellsworth. All screenshots of UDK are copyright Epic Games, Inc. (probably) and the levels displayed copyright Craig Ellsworth. Something like that. My legal department will have to doublecheck.