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.

Our Work This Week

This week we met 3 times to continue work on the game. Gordon and Branan have continued working to implement mesh skinning on the GPU. Having finished implementing it on the CPU which caused major framerate issues, we knew that running it on the GPU was the only possibility. They are currently struggling to sort out the BVH files which appears t0 be missing joints, which is a problem on the GPU, as the joints must match perfectly.

Mack and I have began to collect Foley sounds for our game. We spent the day recording sounds in forest behind campus. We recorded our footsteps through the leaves, breaking branches, and a large stick hitting a tree, to simulate a sword hitting wood. We also recorded water running from the pond behind south village. We recorded a number of other random sounds to use as we need them.

Gary has been devoting his time to creating gameplay elements. Currently we are able to move and jump in 3D space. He has spent the week working on adding proper collision detection, as well as adding shadows. He has also been working on adding the combat system to the game. He has also been working with Gordon to ensure proper file parsing, and assisting with the problems Gordon and Branan have been experiencing.

Branan, Rachel and I have continued to produce Art Assets for our game. Branan and I have been doing all of the modelling, while Rachel puts the finishing touches on the assets, and paints the textures onto them in Mudbox. I have been producing all of the minor art assets, as well as working on level designs. Branan has been working on our main characters model, as well as rigging any models which require animation.

Overall our production is coming along nicely, and if we keep up our current pace we should have a quality game prepared for the Game Con in April.