Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: ACE Team's Zeno Clash
View All     RSS
December 18, 2018
arrowPress Releases
December 18, 2018
Games Press
View All     RSS






If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

Postmortem: ACE Team's Zeno Clash


October 8, 2009 Article Start Previous Page 3 of 4 Next
 

What Went Wrong

1. Spitting out tons of art with little time to prototype.

The biggest problem we encountered with the development of the game was creating a lot of content without really knowing if it would work.

We had a very unbalanced team (with a single programmer and many artists) so the speed at which we created content was much faster than the speed at which we could see that content functional in the game.

For this reason we had to do a lot of work, and design it for code that would be implemented later on. I do applaud the results of the team in terms of anticipating things well, since a lot more work could have been wasted if our vision wasn't clear.

However, many animations needed to be redone once the game started working, and many environments needed to change in proportions after they had been properly lit and finalized. This was mainly because many of the attacks that the player could execute did not exist in the game until very deep into the development of the project. The same happened with several attacks for the enemies.

2. Lighting, again and again...

In regards to the lighting process, we had enormous problems with getting the world to light properly, because of how we decided to use the Source Engine. Source is specialized for building geometry with brushes (box shaped primitives) which are very efficient for creating most types of environments, but for Zeno Clash we needed something much more organic.

This meant we needed to work around brushes and use static geometry exported from 3D Studio Max. But our problem was that Source was optimized for proper brush lighting, not static props. We would have to elaborate a system where we created a new type of model that accepted two UV layers where we would bake lighting rendered from 3D Studio Max scenes.

But since the game is lit in Hammer (the world editing tool of Source) we had to match the lighting of the 3D engine with our 3D Studio Max scenes, which was a huge task. If an artist decided to move the main light source in the world this meant all the baked lighting of the static meshes would be incorrect and need to be re-done, which ended up being one of the most time consuming processes of the game.

At certain moments I can remember how people would hesitate to re-light a scene that was poorly lighted only because of the consequences this would have on the lighting of a level. By not generating a more efficient pipeline to approach this problem we took much longer than expected with the lighting of the world.

3. The unpredictability of the iterative design process.

Zeno Clash was built upon a very iterative design process with no main game design document, but a sheaf of very disorganized and messy papers. The main reason behind this was that the project had been born after another failed project and we were not completely certain of the direction of many things in the game until we were very deep in the development of it.

While the iterative nature of this style of design allowed us a great amount of freedom in changing things on the fly so we could make the game better, too many times we suggested ideas that were mainly hunches, and these suggestions caused David (our programmer) to spend invaluable time in wasted code.

4. No competitive feature until near the end... and no multiplayer.

As a small team we knew that we couldn't make a multiplayer feature for Zeno Clash, mainly because of time. So we decided the game would only focus on the single player campaign and nothing else. But as we neared completion of the game we realized many people were requesting ways in which they could fight against adversaries -- some sort of challenge mode.

A few months before release we faced the dilemma of either leaving the game the way it was, or implementing a challenge mode. The team clearly underestimated the complexity of creating a challenge mode and the impact this would have on the game.

We tackled the problem way too late, and this meant the first iterations of the tower levels were poorly balanced in difficulty and almost an insignificant percentage of players were actually capable of beating the final challenges, which in my opinion were way too hard. This meant we had to balance the levels via updates which were released after the game had been out for some time. This obviously affected leaderboards, and was not something we were happy with.

The most successful update the game has received was a new challenge mode, and it is a clear sign that we underestimated the value of this type of content. The game can be beaten in a relatively short time and without the challenges a lot of people would have stopped playing the game very quickly.


Article Start Previous Page 3 of 4 Next

Related Jobs

Disruptor Beam, Inc.
Disruptor Beam, Inc. — Framingham, Massachusetts, United States
[12.18.18]

Senior Producer
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States
[12.18.18]

Associate Producer (Temporary)
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States
[12.18.18]

Animator (Temporary)
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States
[12.18.18]

Viewmodel Animator





Loading Comments

loader image