Trailer created by Bryan O'Hara and Keith Tatarczuk
Download the Game
(414 MB installer exe)
Bernard "Buzz" Ambroseno
William David John
Producer, Narrative Designer
Carnero is a first-person shooter developed in the Unreal Development Kit, 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.
The Player's view of the final boss upon entering the bridge. The Player looks up to see the boss, and in frame are two pipes hanging from the ceiling. The red valve to the left glows green, indicating it can be shot. After being shot, it will cause an explosion when the Heat power is used. The purple-lit pipe to the right glows blue, indicating it can be destroyed when the Cold power is used. When the player destroys the brittle parts of the pipes, they come crashing down and create ramps to climb the boss. Click for a larger image.
Gameplay footage of Level 2.
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, rather than standard waist-high walls, etc.
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.
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 co-workers. 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 spy on each other's work, and 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
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.
The basic structure of QA was this: 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! So much can go wrong during each step, so by the time we got the feedback, either it was out-of-date 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 a couple of times, and just sat back and watched the testers play my levels, and took notes. I got more useful feedback from five minutes watching them than I got in months previous. In fact, I took notes on the other levels too, and gave them to my co-workers. Gigantic design flaws were discovered, and some of them needed a major redesign, but we learned about them too late to do much but quickly hack patches onto them.
Computers suck. When they aren't crashing, freezing, or blue-screening, they're busy corrupting files or just making them disappear altogether. We had many problems during production involving the mysterious disappearance of art assets, programmed features, and hours of work lost from crashes. Even autosaves failed to recover!
Some of these problems, like crashes, were clearly no one's fault, and we could only rage against the machines. Other problems, however, such as mysteriously missing art assets, had us getting our pitchforks for a manhunt. The messengers were often shot, and everyone put on shifty-eyed glasses.
That is, until the discovery of UDK Gnomes. Not to say we were hallucinating or going crazy or anything. We just decided to shift the blame to Gnomes to keep our sanity. When a file went missing, the UDK Gnomes took it. It stopped us from passing the blame, and made us unite against them, rather than split us up.
It's difficult to explain without sounding like a nutcase, but in some sense, the UDK Gnomes acted like gremlins to aircraft on us. It gave us something to vent our frustration at without demoralizing anyone further than necessary.
The sound team was originally composed of only two members, eventually becoming three, but which had to split their time between four projects.
Because of this, we had to use many stock sound effects found in UDK, and outsource our music needs.
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.
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 newer projects, I am slowly improving my art skills.
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.
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.
A cargo bay. The Player enters from the lower-left. The Player must destroy the glowing green support by shooting it, then magnetize the floor to make the catwalk come crashing down, killing the bots below. This also prevents the player from reaching the exit (upper left) via the original catwalk, so when the Player gets up to the catwalk (from the upper-right), the Player must jump along crates (behind the catwalk in this image) to reach the exit. Click for a larger image.
A kismet sequence for the puzzle shown above. This causes the catwalk to come crashing down and kill all below it as long as the support has been destroyed and Magnetism is turned on. Click for a larger image.
Original blueprints for Level 2. The Player begins at the AI Core and ends at Life Support. Click for a larger image.
3/29/11 in-editor blueprints of Level 2. Similar to the drawing above, but the second puzzle 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. The Player loses all of their environmental control at the beginning of the fight and must find the switches to give them their powers back. The Player must climb back and forth between the tower (left) and the floors wrapping around the wall (right), while facing both a horde of standard bots and the boss robot which has giant arms smashing through ceilings and walls to hurt you. Click for a larger image.
A kismet sub-sequence on how the robot arm attacks when the player comes too close. I discovered that the robot arms could not rotate at all times and slam down when triggered (two matinees would not play at once properly), so I jury-rigged an invisible mesh that handled the slamming matinee, while the actual drill was given rotation physics and was attached to the invisible mesh. Click for a larger image.
|All written content copyright Craig Ellsworth. All screenshots are of UDK, copyright Epic Games, Inc. and the levels displayed copyright Craig Ellsworth.|