Level Design Report

I began the level design process by determining the general feel for our game. We discussed as a team what style our game would take, as well as what environments we felt would be fitting to our game. We decided the game would be a 3^rd person Action-Adventure, with platforming elements. We also decided on a number of environments, from a forest to a desert. I began work on the forest level, as we knew it would be our main locale.

I began by designing a couple of concepts on paper, from a top down perspective. While this approach worked for determining the general layout of the level, I quickly found that attempting to design a 3D environment from a 2D perspective could not encapsulate the actually design of the environment. Knowing this I began using a tool for 3D rapid prototyping, Google SketchUp. Using Google SketchUp I was able to quickly produce a number of simple level designs in a 3D environment. After selecting an appropriate design for the forest, I moved into Maya.

Figure 1 Google SketchUp Level Prototype

I began modeling the design I had made in SketchUp into real geometry in Maya. While doing this I noticed a rapidly growing problem. The design I had laid out in SketchUp, which my team had liked the concept of was proving to be far too much geometry. The design called for the level walls to be made from trees, so as to improve the look and feel of the level, while preventing players from feeling trapped by illogical walls.

This is when we encountered a new obstacle. We would only be able to perform axis aligned bounding box collision detection. This meant that everything in the level must now be square or rectangular. Any curves would cause large areas of impassable terrain. This meant that all elements of the level must be either rectangular or make sense colliding in a rectangle.

Figure 2 Scrapped due to losing the ability to make curves.

Knowing this I decided to change my approach and design the level as blocks, fitting the constraints perfectly. After showing my group what that looked like we decided that we would have to meet in the middle. A level made out of blocks might be fun to play in, but it’s extremely uninteresting to look at.

Figure 3 Technically Perfect – Functionally Lacking

We decided that we would have a prop based level, with collision boxes created around the geometry in order to handle the collisions. At this point I stopped working on the level itself, and began creating all the individual models that would make up the level. The other members of the art team also participated in this process. Branan created the platforms we would use, and Rachel created a very nice looking tree, which used impostered leaves to reduce the poly count. I created chests for collecting, rocks, a well, pieces of ruins, and a large gemstone, among other things.

Figure 4 A number of our props.

After we had finished prop construction I began assembling the level. My designs went through many iterations, but all focused on the same concepts. A linear start focused on forcing a player to learn the controls was followed by a small platforming section in order to reinforce the controls. After the platforming there is an open world segment which players can explore and look for the game items. There is a large boss enemy in this area which players must fight. Afterwards the player must climb a mountainous area to find the level finish. While working on the level it was constantly redesigned and retested. Bugs were found and fixed, and a few were implemented as secret paths a skilled player can take.

One of the main causes for the many redesigns was the constraint on the number of polygons. When the first design was finished the level was 30,000 Polygons. This was causing our engine to drop frames, which in turn caused collisions to malfunction. In order to overcome this I redesigned a number of props in order to lower the number of polygons in them, as well as trimmed unnecessary props from the level. By doing this I was able to bring the number of polygons down to just over 10,000, a third of the original number.  This reduced strain on the engine, allowing us to lock the framerate at 30 frames a second. This issue has since been fixed, and we are able to use considerably more geometry. However having lower polycounts is still very desirable, and restricting them while designing was a valuable learning experience.

I was also able to overcome the problem of having level boundaries, without resorting to invisible walls. I created a highly detailed mountain scape, which was approximately 300,000 polygons. This was necessary in order to achieve a smooth texture resembling worn rock. I then rendered a view of these mountains and applied them to the level boundaries, giving the level the appearance of being in an enclosed valley, explaining why it is impossible to leave the level.

Figure 5 High Resolution Mountains

At the end of the design process, the level came together nicely, and it suited our game well.  Despite many setbacks, and redesigns we were able to complete the level and the game before our ship date. This was both a result of following good design procedure, and through constant testing and co-operation with Gary who was designing the gameplay elements.  I enjoyed working on the level design, and look forward to doing more in the future.

Figure 6 Our Finished Level Design

Thanks for reading.

Lead Level Designer, Alex Best.