MASARYK UNIVERSITY FACULTY}w¡¢£¤¥¦§¨  OF I !"#$%&'()+,-./012345

Level Design

BACHELOR’S THESIS

Pavel Ugwitz

Brno, summer 2011 Declaration

Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.

Advisor: Mgr. Jirˇ´ı Chmel´ık

ii Acknowledgement

I would like to thank my supervisor, Mgr. Jirˇ´ı Chmel´ık, for his help and advice.

iii Abstract

This thesis explores the workflow of level design in current-generation ren- dering engines. Having described the techniques of level design and the workflow methods of creating a level, the thesis also brings in an example level to demonstrate the aforementioned techniques.

iv Keywords level design, game design, rendering engine, game engine, unreal engine, UDK, level design workflow, level optimization, CSG, static meshes

v Contents

1 Introduction ...... 3 2 Choosing the Rendering Engine ...... 5 2.1 Technical dispositions — the engine ...... 5 2.2 Team dispositions — design approaches ...... 7 2.3 Comparison of engines ...... 8 3 The process of Level Design ...... 12 3.1 Conceptual phase ...... 13 3.1.1 Determining the core gameplay concepts ...... 14 3.1.2 Collecting references ...... 14 3.1.3 The floorplan ...... 15 3.1.4 Moving on to the production phase ...... 19 3.2 Geometry ...... 20 3.2.1 Primitive geometry ...... 20 3.2.2 Terrain ...... 21 3.2.3 Zoning and Volumes ...... 22 3.3 Materials ...... 22 3.3.1 Material Editor ...... 23 3.3.2 Applying the materials ...... 23 3.3.3 Material optimization ...... 24 3.4 Static Meshes ...... 24 3.4.1 Placing the Static Meshes ...... 25 3.4.2 Pros and Cons of Static Mesh usage ...... 25 3.4.3 Static Mesh colissions ...... 26 3.4.4 Static Mesh details ...... 28 3.5 Lighting and environment ...... 28 3.5.1 Light types ...... 28 3.5.2 Other environmental settings ...... 30 3.6 Objects, interactivity, level flow ...... 30 3.6.1 Game logics ...... 31 3.6.2 Interactivity ...... 32 3.7 Optimization and finalization ...... 33 3.7.1 Revising the details ...... 33

1 3.7.2 Optimization techniques ...... 35 3.7.3 Finalizing the level ...... 36 4 An example of Level Design ...... 37 4.1 Designing the environment ...... 37 4.2 Illustrating the process ...... 37 5 Conclusion ...... 39 A The process of creating a level ...... 43 B The content of the DVD ...... 53

2 Chapter 1 Introduction

Level design is a subject that has to do with the creation of environments. These environments in question, usually three-dimension ones, are then used in architecture, simulations, and, most notably, in video games. Level design tends to be interactive (in every game, there is a player interacting with the environment), therefore the environments are rendered in real time, using a middleware rendering engine (or game engine). In this regard, level design finds its place in the context of 3D applications. Real-time rendering engines have been around for about 20 years, al- ways being limited by the possibilities of the current hardware. As hard- ware evolved, so did the engines. And with an increasing number of possi- bilities of engines at hand, even level design evolved [20] [21] from simple, intuitive procedures into a complex field of its own. Production techniques and procedures are just a mere part of level de- sign, though. Design has always been a field rooting in both technological and artistic background. Therefore, a lot of approaches of level design aim for a certain artistic expression, even though they are backed down and de- fined by technology (a specific environment should ideally reflect specific impressions). It is also crucial to mention that the technological evolution of engines has facilitated an increased number of possibilities regarding the artistic styles in level design. Level design usually does not stand on its own. It is adopted by the game industry (or some other big companies related to graphics) and in- tegrated into a production, where it interacts with other developer teams (programmers, concept artists, modelers, etc.). A level designer has their own specific role in a wholesome team of developers. All the techniques, concepts and procedures of level design, be it the technological or the artis- tic ones, are therefore dependent on the interaction among the teams and the production strategy of the company in question. The focus of this thesis is to analyze, describe and illustrate the possibil- ities of level design using current technology and methodology in the game industry. In the following chapters, the reader will be presented with the-

3 1. INTRODUCTION oretical workflow and concepts used in level design; this workflow will be then applied on a specific example level.

4 Chapter 2 Choosing the Rendering Engine

Before any serious production can even begin, it is necessary to know what kind of technology is to be used. This is because technology always brigs limitations — and not even rendering engines are exceptions in this regard. A specific rendering engine has its strong and weak aspects — it is therefore strategic to take its traits into consideration and use them effectively in the forthcoming production. On a similar note, even a pre-production phase (i.e. the phase of planning and concepts) can prove futile, if the possibilities of a rendering engine are not taken into consideration from the very be- ginning of a project — a core game concept may include ideas, that simply cannot be realized due to the limited possibilities a specific engine. There are many rendering engines available [29], which may prove con- fusing. This chapter is therefore intended to pinpoint the crucial features a high-quality engine should have. The chapter will conclude with a compar- ison of the ablest engines to date.

2.1 Technical dispositions — the engine

A specific engine determines the limits of visuals of the title in production. Some features of an engine, such as material processing of textures and ad- vanced lighting functions, are taken as industry standards, expected by the consumers (games), and therefore practically required (i.e. a certain “gener- ation” of games, of a certain graphical and gameplay standard [27]). Some supplementary functions of an engine (such as destructible environment) are certainly a plus, yet they are not critical — at least not in this genera- tion. A solid engine should be optimized for maximum performance regard- less the hardware configuration of the system it is currently running on. If not done automatically, the engine should at least offer the designer the pos- sibilities to somewhat optimize the performance of a level manually. Such an engine should also be easily scalable and customizable in detail.

5 2. CHOOSINGTHE RENDERING ENGINE

It is also important to take into consideration what was the engine built for, specifically. Optimizations in an engine are certain programming tech- niques that are best utilized in certain situations, while not so effectively in different scenarios. While some engines can be labeled as “general”, be- ing somewhat effective to render the vast majority of all kinds of levels, some other engines have their own significant pros and cons — such as idTech4 [28], programmed to render detailed interiors, or Reality engine [22], coded to display spacious exterior levels. Therefore, using idTech4 to ren- der vast spaces of forests or Reality engine indoors would not land optimal results in either case. If one wants to create a project with a specific kind of levels to render, they should research whether an engine is optimized for such environments. Openness to third-party software and the ability to import other formats are also important features of an engine. If an engine is particularly “un- friendly” in this regard, it could hurt and slow down the efficiency of a pro- duction cycle in the company. The engine (with its own interfaces) is a core application in the development of any game or interactive 3D application, yet there are also some other applications used — 3D modeling programs, textures, animations, physics, etc. Incompatibility means either abandon- ing the (rather costly) supplementary programs for some other, supported ones, or a complicated and possibly buggy workflow while converting the incompatible formats into compatible ones. Talking about efficiency, the creators of the engine should also provide the designers with an effective, user friendly and ergonomic interface (a frontend editor). If it is uneasy and/or time consuming to access certain widely used functions in the editor, this will also have a negative impact on the production. The architecture an engine was built on should also be taken into con- sideration. A robust engine allows the programmers to add certain features, remove some other unused and/or inadequate features and edit/update the obsolete parts. Engine scalability (engine potential, engine evolution) is a key factor for every programmer who wants to change or update the engine to suit his team’s needs. Not everyone is a programmer, though. An ideal engine allows even the non-programmers to do some scalability (within the boundaries of the engine’s own hardcoded limits, of course) — it provides feature-rich WYSIWYG interfaces for level design, material and shader composition, etc. This side of scalability could also be referred to as “user friendliness.” An engine written in a widespread programming language without the use of any platform-specific libraries and without strict fixation to any platform-

6 2. CHOOSINGTHE RENDERING ENGINE specific hardware ensures portability. An application that is intended to be released for multiple platforms (Windows, Mac, Linux, Consoles, Mobile devices, etc.) can be ported from one platform to another with ease only if the differences between the platform related engine modifications are not of a severe amount. If, on the other hand, two different platform implemen- tations of an engine have little in common, porting an application from one platform to another is not a simple task and such porting process may take up as much time as actually producing a brand new application. A reliable engine is well tested, reliable and being actively maintained by a group of developers. Engine support comes in many forms: detailed documentation, developer feedback, test and trial (an engine proved by previous, released applications). Once a company purchases an engine li- cense from another company (as engines are often sold, as a middleware) to develop an application, it is not uncommon for the development team of the buying company to encounter some issues while learning the engine technology. Any unresolved issue of this sort creates a drawback in devel- opment of an application; support can prevent, or at least resolve such sit- uations.

2.2 Team dispositions — design approaches

The times of level design as an independent sub-field in game industry [12] [31] are inevitably over. While back in the early 1990’s, a single person in the development team could focus on “game design” (level design, textur- ing, modeling, etc.), such an approach is certainly not possible nowadays, with the plethora of work on current-generation of games that needs to be taken into account. Engines are increasingly more complex and facilitate a lot of features, requiring many more man-hours to create a high quality standard, therefore a “game designer” of the 1990’s was inevitably divided into texture artists, level designers, modelers, concept artists, etc. Even a field as level design is being divided into sub-fields such as environment design and gameplay optimization in the last few years. In other words, while a game development company twenty years ago could function with five employees, some of the serious companies of today employ possibly even five hundred employees. Therefore, in today’s game design, a need for optimized interactions between adjacent occupations arises. It would be the ideal if such a possibility of interaction among adjacent occupations would be facilitated (or at least detracted) by the engine in- terface itself. I.e. if, for example, a 3D model created by a modeler can be

7 2. CHOOSINGTHE RENDERING ENGINE directly imported into the engine and used by the level designer without delay, it is an effective approach. Such an approach, where finished prefabs are delivered to the level designer to work with, is called modular level de- sign [19] [23]. This is a core approach in effective level design by today’s standards. While choosing an optimal engine for a company to base their prod- ucts on, economic criteria should also be considered. What is the licensing fee of a certain engine? Does the engine licensing support small teams of developers? What is the cost of technical support? Is the engine provided strictly closed-source or made available as source codes? These questions are crucial, as in the end, every company strives to make their products into a success on the commercial market.

2.3 Comparison of engines

The demands described in the two previous sub-chapters (2.1 and 2.2) could help narrowing down the number of possible engines to choose from. User expectations for quality in an engine are quite high and a robust engine is not created overnight either. In fact, development of an engine according to today’s standards takes months to years and dozens of talented individuals (as can be illustrated on the example of developers notes on Unreal Engine 3 [1]). This also explains why the smaller teams of developers usually adopt third-party engines to be used in their games instead of coding an engine on their own from scratch — that is because they do not have the resources to create a whole new engine. A comparison of the most promising engines as of 2011 follows. These engines were chosen for further comparison: CryEngine, HeroEngine, Un- realEngine, Source. They will be evaluated based on the criteria stated in the previous sub-chapters (2.1 and 2.2). CryEngine ( [3]) The first iteration of the engine was seen in the 2004’s FPS game Far Cry. Since then, the creator, CryTek, released a second gener- ation of the engine and not so long ago (early 2011) came the third genera- tion.

• Optimization: first generation clearly optimized for rendering of vast outdoor areas. Second and third geneartion can also do interiors.

• 3D party software support: basic support (such as 3dsMax), extended features are to be coded in the engine itself.

• Interface: SandBox, the editor GUI.

8 2. CHOOSINGTHE RENDERING ENGINE

• Scalability: PC and consoles.

• Portability: unknown (the developer did not state).

• Support: not so many tittles were released using this engine. CryTek wants to release a free version of the editor to the general public in the near future.

• Licensing: for game industry only. HeroEngine ( [4]) A fairly new engine, included in this listing for its fresh concept of networked level design. • Optimization: this is a MMO (massive multiplayer online game) en- gine, therefore quite simple graphics.

• 3D party software support: unknown (the developer did not state).

• Interface: the innovative concept of the HeroBlade editor is the possi- bility of networked design (or as the developers call it, real-time col- laborative world building). This approach can surely bring some in- teresting results [30], and is yet to be explored in the context of game development.

• Scalability: unknown (the developer did not state).

• Portability: unknown (the developer did not state).

• Support: just one game based on this engine was released as of yet.

• Licensing: game industry and indie developers. UnrealEngine ( [11]) This is the oldest and the most proven engine of this selection. The first tech demos of Unreal Engine surfaced in 1995, fol- lowed by the release of the flagship game Unreal in 1998. Since then, Epic Games’s own Unreal Engine (abbr. UE) has progressed into its second and third generation. UE 3, first introduced in 2004 and maintained since then has established itself as industry standard. Even the fourth instance of UE, intended for the next generation of consoles that are supposed to come in about 2015, is being developed, with an early spark. • Optimization: real time lighting, scalable level of detail, a general- usage engine.

• 3D party software support: a wide range of supported software (i.e. SpeedTree, PhysX, etc.)

9 2. CHOOSINGTHE RENDERING ENGINE

• Interface: the Unreal Editor is tailored in the style of 3dsMax interface, therefore being effective.

• Scalability: one of the greatest strengths of Unreal Engine — Material Editor, Matinee, Kismet — these are the WYSIWG interfaces that help the developers produce their own games without the need of any ac- tual programmers to adjust the engine source code.

• Portability: PC, Xbox360, PS3, even mobile platforms lately.

• Support: in fact, the majority of shipped titles nowadays use the Un- real Engine. Monthly builds of the engine (Unreal Development Kit, or UDK in short) are being released to the general public and can be used as a base platform to develop new games. A documentation site [8] of the engine specifications exists and it’s actively maintained.

• Licensing: both game industry and a royalty-based licensing model for the indie developers. Free of charge for educational and non-commercial usage.

Source ( [25]) Based on the Quake I engine, and seen in the release of Half-Life, 1997, the original Source engine by Valve corporation was re- worked and reintroduced in 2004. It is now developed in an iteration-based cycles, therefore being ongoing and modular, i.e. not spanned into engine “generations” with radical technology leaps.

• Optimization: solid optimization, proven by the games released. 3D party software support: possible, some specific third-party support also easily implementable.

• 3D party software support: a wide range of supported software (i.e. SpeedTree, PhysX, etc.)

• Interface: Source SDK and the Hammer level editor are obsolete and ineffective.

• Scalability: the modularity of the engine provides a lot of possibilities on a programming level.

• Portability: PC, Xbox360, PS3

• Support: a few titles (and a lot of mods) were shipped using the source engine. Source SDK is available for indie developers.

10 2. CHOOSINGTHE RENDERING ENGINE

• Licensing: game industry, mod community.

Conclusion: all four of the selected engines are lacking in some areas, except the Unreal Engine. Therefore, as of 2011, Unreal Engine is the ideal choice for the majority of possible game projects or even isolated level de- sign attempts. The engine is well grounded, universal and has a quality support.

11 Chapter 3 The process of Level Design

This whole chapter is all about illustrating the most common method used in level design — procedural level design [5] [13]. The procedural approach begins with a conceptual phase, where the basic ideas and drafts for the up- coming level are prepared as a proposition. This proposition is then taken into CGI programs (a level editor and supplementary 3D modelers) and transferred into basic geometry. After that, the rough geometry undergoes texturization, more geometric details are added and lighting gets intro- duced into the level. After optimizing the gameplay and a final revision of the previous step, a level is pronounced finished. The whole procedural method is quite failsafe and effective if done right; it has one crucial flaw, though — the absence of a preview (the designer does not know how the level would look like unless they are in the finishing stages of the process). An important thing to understand is that while being the most effective approach for the majority of game developers and their internal produc- tion strategies, the procedural approach in level design is not the only way to get the job done. A good alternative to this approach is iterative level de- sign [17]. In the iterative method, a fully designed reference environment is created first. This reference environment may (or may not) be a part of the final level. While being quite small in size (a fraction of what the fully completed level would take), the reference environment serves as a real- time preview of the concepts and visuals a finished level should resemble. In a full iteration-based leveldesign, an upcoming level is divided into seg- ments and those segments are worked on start to finish, one at a time. The challenge here is to maintain the same look and build styles of the seg- ments, and this does not come as easy as in the procedural approach (in the procedural design, the designer focuses on one phase at the time (be it the geometry, the lighting, etc.), wraps up the phase and moves on the next phase without distractions; in the iterated approach, the designer needs to be aware of all the phases at all times — mishaps and errors are more prob- able here, and the designer may spend a significant amount of time just recalling what he did (or how he did it) the other day).

12 3. THEPROCESSOF LEVEL DESIGN

Another method used to create levels would be a chaotic level design method (or call it no method at all). Such a method is not recommended — the environment of a level editor behaves according its own technol- ogy and is therefore not as forgiving to a level designer as a blank piece of canvas would be to an artist. Any level that is designed also needs to un- dergo all the phases the procedural methodology accents (i.e. from concept to geometry, then to textures and lighting). It would therefore be unwise to ignore those phases, for the phases are tied to one another (one cannot light the level before creating the geometry the lights would reflect on; if the geometry is not optimal and needs reworking, then so does the light- ing, the textures, and possibly some other aspects). In the end, the chaotic approach may be effectively applicable on just a few aspects of level design that are easily scalable and not severely tied to the other areas (for example terrain editing tools or particle generators — it may produce a few ”lucky accidents” in design here); elsewhere, the chaotic level design is just a waste of resources. The technical aspects of the procedural design approach in the follow- ing sub-chapters will be using unreal engine-related terminology and ap- proaches. Even though the vast majority of the techniques to be demon- strated are general concepts that are applicable to many engines (as listed in 2.3), there will be a few situations, that are not standardized and/or gen- erally widespread (the other engines may be taking different routes to attain similar outcomes or simply lacking the features).

3.1 Conceptual phase

The conceptual phase is the preproduction phase of level design. No actual work is done during this time period; the work ahead is however being carefully assessed so as not to let it come to vain. One could think of the con- ceptual phase of level design as of a micro-cycle, rooted into a macro-cycle (product — usually game — development). Once a game gets into the stage of development, where it needs its own levels designed, it is usually deep inside its production phase (the mandatory preproduction questions of the game, i.e. the core concepts, have all been determined by now). Knowing the concepts and themes of the game in making is a good starting point (and an absolute necessity) for the level designer. The game (or virtually any application) can be seen as an interface from the perspective of a level designer; and it is the duty of the level designer to put this interface to a good use, to present all its possibilities, to make it come alive.

13 3. THEPROCESSOF LEVEL DESIGN

3.1.1 Determining the core gameplay concepts

The game in making is aimed to appeal to a certain target group (deter- mined by a platform — be it a console or a PC), using a certain game type/genre (an action game, a strategy game, an adventure, etc.) and pre- senting itself in a certain style (a fast paced or a precisely coordinated game). All those concepts can be summarized into a single word: gameplay. A good level design facilitates good gameplay. Here are but a few loosely defined examples of gameplay concepts:

• Individual competition (Shooter games — UT3 deathmatch) — to let the players test their skills in a struggle against each other, using a variety of tools to defeat the enemy.

• Team Competition (Shooters and Strategies — UT3 CTF, or Warcraft) — usually a symmetric area designed to test the skills of two compet- ing teams.

• Exploration (RPGs, MMORPGs — Fallout, WoW) — to immerse into a complex word of its own, to participate in an alternate reality.

• Environmental (Portal, The Ball) — the accent is aimed at the envi- ronment and the immediate actions the player can do in such envi- ronments.

A specific game has it’s own set of specific skills; a good gameplay can be defined by a player honing those skills and/or competing with other players using those skills. Those skills can be unique for any game in ques- tion — therefore instead of trying to list them here (which would only lead to generalizations), it is advised to explore the specific mechanics of any game that comes to question — and the most straightforward way to do that is either to observe the gameplay elements in other, existing levels of the game or to experiment with those elements on one’s own.

3.1.2 Collecting references

The concept phase should also explore the visual possibilities of the future level. Having acquired some kind of a reference (be it paintings, concept art, photos or written stories) to drive the concept phase forwards and inspire the designer gives a clear idea of what the future level should be about — the possibilities of geometry, the range of textures, the theme and at- mosphere of the level. A reference is a vital aid for the future phases of

14 3. THEPROCESSOF LEVEL DESIGN level design; even though it won’t be a part of the future level, the reference serves as a backup model whenever one of the advanced design phases encounters an obstacle. Having not provided any reference may also mis- lead the outcome of the design into something it wasn’t intended to be. In other words, gathering the references means getting to know the environ- ment and exploring it on many different levels (or perspectives). A designer who knows well the environment he/she is then supposed to portray elim- inates the majority of environmental design flaws, that could otherwise oc- cur in his work. A designer who does not know the environment well is susceptible to introducing many flaws into his work. Environmental de- sign mishaps include (yet are not limited to): indistinctive, confusing and unmemorable environments, inconsistent features of the environment (bro- ken architectural flow), eye-striking and violently unrelated environmental features, boring and unimaginative environment.

3.1.3 The floorplan

A floorplan is a simplified plan (or a sketch) of how would a projected level look like. Floorplans are typically portrayed in 2D, providing aerial view on a level (and thus leaving out the height coordinate). They are drawn up in simple lines (boxes, symbols); no need to steer into detail while creating floorplans, as floorplans are just rough references.

Figure 3.1: This is the finalized wireframe/floorplan of the DM-Deck16 level (Unreal Tournament, Deathmatch gametype).

15 3. THEPROCESSOF LEVEL DESIGN

A quality floorplan is basis for any upcoming level that is expected to deliver good gameplay; there are some do’s and don’ts to abide while cre- ating a floorplan. This sub-chapter strives to explore and explain such de- sign principles, as seen in all the standard multiplayer levels of first-person shooter games1

Figure 3.2: Limited (left) and imaginative (right) floorplan connection.

Giving the players options to choose from is a key concept of gameplay. On the left image, there is only one option for a player located in the ”A” room to get into the ”B” room. On the contrary, the image on the right pro- vides a lot more choices. Now imagine two competing players, one located in the room ”A”, the second placed in the room ”B”. There are not many options or strategies for the players in the left diagram. Besides no strat- egy, there is also no element of surprise, since both the players, who appear in the middle of the respective rooms, have a clear sight on each other. The floorplan on the right allows for a wide variety of strategies (direct, indirect, evasive ,etc.)

1. Even though the principles that are about to be mentioned are quite widespread (being taken into account while designing the majority of 3D competitive games), these principles are certainly not universal — a specific game with unique gameplay conceps unlike any other game can, understandably, defy these principles and still deliver quality gameplay.

16 3. THEPROCESSOF LEVEL DESIGN

Figure 3.3: Meaningless (left) and imaginative (right) paths.

This couple of images brings up the question: what is the meaning of the architectonic elements in a level? On the left image, the long corridor in the north has no meaning. It only gives the player a long, uninteresting experience of a long walk through a corridor. That part of the map should therefore be designed in some other way. The northern corridors of the right image is in place, as it leads to the room ”C.”

Figure 3.4: Floorplan game flow analysis.

This is a simplified floorplan example of a level made of nine adjacent rooms, forming a 3x3 cube. As the image suggests, there are only two ways of getting into the corner rooms, turning those rooms into rather infrequent places for the players to encounter each other. And there is the middle room. It is of no doubt, that this room is the most probable place of player encounters. Knowing the ”hot” and ”cold” spots of the level does, also, help the designer to refine the gameplay. A good idea would be balancing the dangers of the middle room by placing the most powerful items in here,

17 3. THEPROCESSOF LEVEL DESIGN for the players to acquire (see the sub-chapter 3.6.1 for more information).

Figure 3.5: Vertical gameplay.

Even though floorplans are usually lacking the vertical element, experi- menting with this dimension can bring a whole new perspective to a level. A player located on the second floor has a good overview of what is go- ing on below him. If such player chooses to compete with another player, located either on the first floor or on the ground, the player on the sec- ond floor has a significant advantage. The movement potential of a player in higher grounds is also better, as this player may either stay on his/her height level or decide to jump down a floor at any time (unless the height difference of two floors is high enough to actually harm the player). Vertical gameplay also introduces lifts, elevators, jump pads, all interesting game- play elements.

18 3. THEPROCESSOF LEVEL DESIGN

Figure 3.6: Routing the floorplan paths in a level (DM-Deck16 example).

After the floorplan of the wholesome level is put together (into one con- sistent image), a revision is in place. A good way to do this is to analyze the routes, i.e. to see which rooms, corridors, archways and other passages form a route. A good level should have a few of these routes — putting it- self together in a consistent flow and providing some interlacions between the routes.

3.1.4 Moving on to the production phase

As illustrated in the chapter 2.2 (team dispositions), level design is not an isolated vocation; in order for the level designer to build the level, resources (i.e. textures, models, etc.) should be prepared to be available at hand. Hav- ing gathered the references and prepared a floorplan, the designer (or a su- pervisor of the level designer) is now eligible to make a list of requirements (textures, models, etc.) for the level based on this information. A certain time gap may occur in between the request, the work of the supporting vo- cations (i.e. the texture artists, modelers, etc.) and the continuation of the level design — but this is up to the company work organization to handle. Once the requested resources are delivered, the designer can also create a tiny, unstructured piece of a level (as explained at the beginning of the third chapter — iterative level design), to build up further reference and test how the visuals of the level would look like.

19 3. THEPROCESSOF LEVEL DESIGN

3.2 Geometry

The majority of all the applied design ahead takes place in the UDK’s Un- real Editor. It is beyond the scope of this thesis to provide a thorough in- troduction to all the aspects of the Unreal Editor. Such introduction can, however, be found on the Unreal Development Network [10] (the official documentation source for Unreal Engine), among other Internet sources.

3.2.1 Primitive geometry First steps with the actual editor start with lining up the rough geometry. It is good to start with the conceptual floorplan as a guide to build the primitive, constructive solid shape-based geometry (CSG) [26] and work from there on to see if the floorplan is constructible; if the creation of the in-editor floorplan proves difficult (on the paper, it is all too easy to draw things without seeing the limitations that come with the perspective of the three-dimensional space of the editor), the new floorplan may need some adjustments. The key idea to take into account while creating the primitive geometry is to create good proportions (in correlation with the floorplan), in a good scale [24]. Good scaling estimations can be derived from the mea- sures of in-game characters and character moves (to avoid unpleasantries such as the ”in giant’s playground” effect, where the whole scale of the level is way too big).

Figure 3.7: Essential player scales (height, width, height of stairs, jump-over height), in Unreal Units (1 Unreal Unit equals circa 2cm).

The geometry build-up phase involves a lot of testing — as a lot of issues

20 3. THEPROCESSOF LEVEL DESIGN can emerge here (either from the floorplan conversion or from the scaling and proportions). It is therefore advised to keep this CSG phase of con- structing geometry plain and simplistic, so that all possible errors can be easily corrected and also because using a lot of CSG is not optimal. Prediction of the shapes and limitations of the forthcoming, more de- tailed geometry, that follows and extends the CSG shapes later on (i.e. Static Meshes — chapter 3.4) should also be taken into account while placing the CSG. The translation from CSG to the detailed geometry should be facili- tated to be made as easy and seamless as possible.

3.2.2 Terrain

Along the rough CSG solid, a terrain can also be put into the use at this time, provided a part of the level is based on an organic/varible surface. Terrains in the Unreal Editor (UE) are created using texturized heightmaps; the monochrome pixels in a heightmap represent a grid and the lightness of a specific pixel refers to the height of the node (the Y coordinate). The limitations with terrain using this approach (invariable X and Z axes on the nodes ) renders this kind of terrain unsuitable for complex environment modeling, such as steep mountains. In such cases, using a premodeled ter- rain created in a third-party 3D software is advised. An imported terrain- model is, however, less flexible when it comes to tweaks and changes.

Figure 3.8: Terrain heightmaps (left) don’t have adjustable X and Z coordi- nates — they cannot form complex three-dimensional shapes (right).

21 3. THEPROCESSOF LEVEL DESIGN

3.2.3 Zoning and Volumes

It would also be suitable to adjust the distinctions of the environments at this time. Using the same CSG shapes as in actual geometry building, one can define specific environments (water volumes of all sorts of water clarity, other liquid volumes, etc.). Some other volumes can be specified to generate certain particles (i.e. rain volumes, fog volumes, etc.), but let’s leave that up for the 3.5 chapter. The process of dividing a level into certain areas is called zoning. This process is generally used to break down a level into a group of independent segments. Every zone and volume can be adjusted to hold certain proper- ties (lighting, physics, etc.), dissimilar to the rest of the zones/volumes (a ZoneInfo property, a Volume property — water volume is actually an ex- ample of a highly specific area). Aside the zone-specific properties, zoning is also used to achieve level optimization [2]. The engine renders only the zones (and the content of the zones) that the player entity inside the level sees with their own field of view (FoV). Therefore, the best approach here is to divide the level into individual zones in a way that the player sees mul- tiple zones as infrequently as possible and/or sees as least of the content outside of their own FoV as possible. Another kind of volumes are blocking volumes. These volumes function as collision (i.e. they don’t allow the player to pass through them), even though they are being invisible. More about the problematics of collision in the 3.4.3 subchapter (that subchapter deals with Static Mesh collisions, but Static Mesh collisions themselves are nothing more than CSG blocking volumes, internally associated to certain Static Meshes).

3.3 Materials

This chapter mentions strategies regarding applying materials to the level (i.e. texturing; strictly speaking though, these two terms are not interchange- able, as materials are made from a combination of textures; only materials, not textures, can be applied to surfaces in the level). Having modeled the rough conception of the level, one can move on to applying specific materi- als to the surfaces of the basic level geometry. There is little to be said about working with materials, as the majority of material editing and creating relates to the job description of a 2D/texture artist, not a level designer (to actually create the textures or materials from scratch an ability to operate applications such as photoshop and/or illus- trator is required); Static Meshes, i.e. the detailed geometry described in the

22 3. THEPROCESSOF LEVEL DESIGN chapter 3.4, also come with a default material attached to them. Unreal En- gine, however, includes a detailed material editor interface, which allows extensive manipulation of the materials and a certain amount of possibili- ties with creating new materials (using the available textures and material editor effects/passes) even to the level designer. And then there are a few techniques concerning applying the materials to the surfaces properly.

3.3.1 Material Editor

The Unreal Editor includes a powerful WYSIYG interface for constructing materials [7], which can be used to create a wide variety of materials us- ing the available textures and a great deal of filters. Every existing material can be analyzed, disassembled and adjusted here, transforming itself into another, perhaps more fitting material.

3.3.2 Applying the materials

In the Unreal Editor, a material is applied to a surface by simply dragging the material out of the content browser and dropping it on the specified sur- face in the editor viewport. But the key aspect here is knowing how to align, scale and group the materials together. Any surface can be edited, with cer- tain limitations, so as the material on the surface scales, pans and rotates. Adjusting the proportions of a material on a surface has two means: to por- tray a certain level of detail and to effectively cover the area defined by the surface. If the material is too underscaled, the texture underneath repeats itself and becomes quite repetitive (unless the texture is crafted skillfully by the 2D artist; the tradeoff of a well-repeating texture, however, is its vague- ness (such texture can not bear any distinctive marks, as the repetitiveness of such marks would strike the viewer)). The material on the surface should also not be too overscaled, because an overscaled texture means a loss of de- tail (which comes apparent especially when the other materials are scaled in conservative numbers — i.e. this breaks the consistency in overall level of detail). Overstretching a texture is similar to overscaling it; only with over- stretching, the original impression of the texture is also being lost (over- stretching a texture too much creates an illusion of smudging it). Therefore, if a spacious surface area (with specific proportions) needs to be covered by a material, an adequate resolution of the material texture(s) should be applied in such cases.

23 3. THEPROCESSOF LEVEL DESIGN

Figure 3.9: An underscaled (left), overscaled (center) and overstetched (right) material — none of them looks plausible.

All the materials in the level must maintain a certain amount of coher- ence. A good designer knows how to pick a certain texturing tone and stick with it, how to align materials, how to properly group different materi- als (seams) together, etc. A good overview of these matters is located at Hourences’ site [14]. Terrain painting is a workflow similar to texturing; the only difference being that during the terrain painting, different textures can be layered on top of each other.

3.3.3 Material optimization The amounts and resolutions of materials applied to a level must simply be taken into account. Using way too many materials and/or overdetailed resolutions of the textures underneath the materials does have a negative impact on the performance of the level. Level loading time and/or overall performance (in case of dynamically loaded textures) are both dependent on the overall size of the textures in use; graphics cards can also fit only a limited amount of textures into their memory. A material can also contain dynamic transformations that prove to be too complex for the graphics card to compute in real time. In such cases, a significant drop in frame rate is imminent. It is therefore advised to avoid such material complexities.

3.4 Static Meshes

Static Meshes represent the second (i.e. the detailed and the last) geometric pass, following the CSG geometry pass. After fleshing out the geometric

24 3. THEPROCESSOF LEVEL DESIGN details by placing all the Static Meshes, no more static polygonal detail is added to the level and only lighting with gameplay optimizations remain.

3.4.1 Placing the Static Meshes

How to place Static Meshes properly? First of all, a designer should be aware of the proportions of the Static Meshes even before placing them into the level (the content browser of the Unreal Editor allows one to check the proportions of the Static Meshes quickly and without the need of placing them). Unlike CSG geometry, Static Meshes are complex 3D objects made in external applications (3Ds Max, Maya, etc.) and thus can not be modified inside the Unreal Editor. Stretching and scaling of Static Meshes is possi- ble, but the shapes (and limitations) of the Static Meshes that are about to be placed into the level should be taken into account as soon as possible (during the CSG geometry phase, i.e. chapter 3.2). For an effective approach to level design, there should be an order in which the Static Meshes are placed. As Static Meshes come in many shapes and proportions, a strategic approach would involve placing the large and significant Static Meshes first, then proceed further by building up the vi- suals with detail Static Meshes. As the details are built on the basis of the rough elements, detailing certain areas without establishing the basic Static Meshes could prove futile. A slightly different, yet effective approach in Static Mesh placement is be building the Static Meshes from bottom up: to start with terrain, ground and floor, to continue from there on the walls and other vertical slopes, and to finish with detailing the ceilings and the sky.

3.4.2 Pros and Cons of Static Mesh usage

Static Meshes are in many ways superior to the CSG geometry, but they too may have some negative aspect on the level, if not used properly. A Static Mesh is a detailed geometric prefab. The amount of detailed attained in one Static Mesh can not be matched by the primitive shapes of CSG ge- ometry and a smart usage of Static Meshes can help to create a detailed environment in a fair amount of time. To create a complete shape — be it a building, as an example — it is much easier to pick a few Static Meshes to start with (as for the example of a building, it would be a Static Mesh of a door, a window, perhaps a few stone bricks) and assemble the intended object using those Static Meshes than trying to model such detail either in the CSG shapes (nearly impossible and badly optimized for such complete shapes) or in an external 3D application (possible, but time consuming).

25 3. THEPROCESSOF LEVEL DESIGN

Figure 3.10: Combining a few simple meshes (left), one can create a wide variety of shapes (right).

When the Static Meshes are, however, used extensively in a level with little variety, many locations in the level end up looking very similar to each other, which is not an ideal approach to level design (unless one specifically intends to portray a mindless, Orwellian, uniformed environment). A cer- tain amount of variety in Static Mesh usage should be ensured; if there is a specific place in the level that is intended to give a unique impression, the level designer may not be able to attain such impression using the same, recycled Static Meshes and may use a unique piece of geometry (either pick a Static Mesh not used before from the editor’s content browser or ask a 3D modeler to create a special Static Mesh for that occasion).

3.4.3 Static Mesh colissions What is a collision? It’s a state of two objects touching each other. In the terms of game engine, collisions set the boundaries to the player as which areas are accessible and which are not. If, for example, a player entity in a level with normal gravity did not properly collide with the ground, the player would fall through the ground. A similar situation would occur with non-colliding vertical objects — such situation would enable the player to walk through the walls, etc. In order to deliver a believable experience, it is therefore crucial to design a level with collisions working as they should — as we’d expect them to, according to the basic laws of physics.

26 3. THEPROCESSOF LEVEL DESIGN

Collisions are no issue for the CSG geometry (as all CSG objects inherit collision spaces equal to their own shapes), but as for Static Meshes, colli- sions should be dealt with separately. Since Static Meshes are the most com- plex geometry in a level (thousands, tens of thousands or even hundreds of thousands of polygons per individual Static Mesh), computing collisions based on the actual wireframes of Static Meshes would usually constitute quite a difficult and menial task (even though such setting is in Unreal En- gine possible). Stopping a single entity (the player, a single projectile) does not define a complex problem, but calculating an area-based collision (an explosion, a large quantity of game physics objects rolling over the colli- sion mesh) could create a computational task too complex for the processor to maintain a stable frame rate.

Figure 3.11: A simple box substitutes the colission model of this axe.

For every Static Mesh that is intended to have a collision, an extra col- lision brush is generated. A collision brush follows roughly the shape of the Static Mesh it approximates. For a complex Static Mesh totaling tens of thousands polygons, an invisible collision brush of a few hundred poly- gons is created. The approximation won’t ever be following the shape of original perfectly, but it is intended to be ”good enough” — which is a sub- jective quality, a matter of optimization for a specific placement/location in a level. The techniques for creating Static Mesh collisions are mentioned here [16]. Similarly as with no collisions at all (nonsensical falling through floor), inaccurate collision models can also hurt the gameplay. If the geometry of Static Meshes communicates one thing (”the corridor is clear”, for exam- ple) and the geometry of the collisions communicates a different thing (i.e. ”impassable”), this creates confusion, and perhaps frustration in the player. Therefore, for an optimized level, ”impassable” must look impassable with-

27 3. THEPROCESSOF LEVEL DESIGN out a shatter of a doubt, and vice versa.

3.4.4 Static Mesh details

Every extra polygon on screen for the graphics card to draw is an extra de- mand for the hardware. Programmers of 3D engines are not only aware of these limits, they try to implement techniques that simplify the com- plexity of the screen without sacrificing too much visual quality. One of those techniques involves adjusting Static Mesh level of detail. Unreal En- gine has two levels of detail for Static Meshes — a high one and a low one. A Static Mesh in high detail is the actual mesh, as seen in the content browser. A low version of that Static Mesh consists of simplified geometry (i.e. about one tenth of the polygons of the high version) and is drawn only on a certain distance from the player onwards (this being not very notice- able, since the low-resolution model occupies only a small portion on the screen). This may seem like an engine optimization, the distance settings for the high/low version of the Static Mesh can, however, be adjusted by the level designer in the editor. Apart from the Static Mesh level of detail optimization, the designer should review the detailing of the whole level. Do some parts of the level look more/less detailed than the others? Are there some critical spots in the level with extensive amount of Static Meshes and/or polygon count? If that is the case, the areas in question should be revised, the level balanced.

3.5 Lighting and environment

Lighting brings any level to life. Static Meshes, materials and CSG geometry on their own form only an inexpressive view. It is the purpose of lighting to highlight some areas, bring the focus to them, while pushing some other areas to the background. Having a certain amount of interdependent lights, blending their colors together and casting all sorts of shadows, creates a distinctive atmosphere of the level.

3.5.1 Light types

There are four types of lights available, each one of them fit for certain use.

• Point lights are the most common lights, as they are placed in the level and illuminate the scene in all the directions, up to their lighting reach. They can be though of as light bulbs.

28 3. THEPROCESSOF LEVEL DESIGN

• Spotlights radiate cones of light into area-focused segments. As a metaphor, these lights are like flashlights.

• Directional Lights are most like the sun — they fill the entire scene with light coming from a uniform direction.

• Sky Lights are like the uniform gray lighting on a cloudy day — if applied to the level, their purpose is to bring up the overall lightness of a level (used to brighten up the way too dark levels).

Figure 3.12: A point light (left) and a spot light (right).

There is a wide variety of settings that can be applied to lights; let’s leave that to the Unreal Development Network lighting reference [6]. As for the purpose of this thesis, it is important to know how to use lights and in what amount. As far as lighting the level surfaces goes, bright surfaces are easy to be lit — a light of almost any color can illuminate such surface. Dark surfaces have limitations here, as when lit by clear, white-ish lights, the lighting effect is not so visible (this constitutes quite a problem if there is a scene, in which both bright and dark materials need to be lit). Where to put one’s lights? Best if the lighting of the level provides clues about the key locations of a level — putting a special emphasis on lighting the most frequent and/or the most significant areas of the level. On a further note, it is important to know that any light can be turned into a dynamic light. Dynamic lights, unlike the static lights, cast real time stencil shadows on the level. This is useful while trying to bring to life any moving objects on the scene (player characters, physics, moving objects), but when used

29 3. THEPROCESSOF LEVEL DESIGN extensively, this can hurt the performance of such level dramatically. This is because any dynamic light needs to be computated in real time, whilst the static lights have all the lighting pre-comuputated and baked-in into the level. A lightmap created by rebuilding the static lights within the editor is basically an overlay to materials/textures. And even the resolution of lightmaps can be adjusted. A word of caution here: using a high-resolution lightmap in a spacious level leads to the level file taking up a significant amount of space (the lightmap textures need to be stored somewhere — that is, by default, the level file). High-res lightmaps can also have the same adverse effect on performance as any other high-res textures.

3.5.2 Other environmental settings

Postprocessing volumes are engine-specified areas (just like any other CSG brushes) that can adjust the overall feel of lighting in a level. All the lights within such volume can be globally adjusted by the settings of the postpro- cessing volume — to tone down the lighting, to put more emphasis on a certain lighting color gradient, do decolorize the scene a bit, etc. And then there are fog volumes. These can adjust the draw distance of a level (which is, by default, set to infinitive). A fog volume has a cer- tain critical distance, after which all the objects in the scene blend to foggy unknown. Even though an extensive usage of fog in every level would be uncommon as not every day is a foggy day, there are occasions and op- portunities to use it (for example underwater); and when used, it can help to save up some performance (the objects beyond the fog distance are not drawn by the engine). Depth of Field settings, which blur the scene on a distance, are in principle very similar to fog volumes; the scene must be drawn as a whole, though. Sounds can also be added to the level, further enhancing the atmo- sphere. As with materials or lights, even sounds have a rich palette of op- tions and tweaks. Hourences’ tutorial site, once again, provides a good overview of sound settings [15]. Optimization-wise, sounds are not an is- sue; therefore, they will not be analyzed to further detail in this thesis.

3.6 Objects, interactivity, level flow

This is the phase of getting the gameplay to place. Level flow is achieved by placing the game logics (i.e. the spawn points, the path nodes, the pickups) and perhaps some interactive elements into the level in a way it accents the gameplay. All this is only an extension of the previous level design steps,

30 3. THEPROCESSOF LEVEL DESIGN though — the gameplay possibilities are grounded in the geometry (and visibility), a good game logics strives for the best utilization of the former.

3.6.1 Game logics

A level is supposed to be functioning in a certain way. A player entity can enter the level in specific places (i.e. spawn points), enter specific places, pick up specific items, etc. Spawn points are the locations, where the players can appear after load- ing the level. If there are any challenges in the level (be it puzzles, physics, or other players competing against each other in a deathmatch gametype), the spawn point is generally placed in a safe area, far-out from the areas of conflicts and challenges. A spawn point is an ”introduction” to the level for the player, therefore the location and direction of the spawn point should drag the player in — an opposite of confusing them. An important part of any level that counts on artificial intelligence sup- port (i.e. bots) is a pathing system. Both the common path nodes and the uncommon ones (triggers, jump spots, defend spots, etc.) tell the computer controlled player entities how to behave. It is best if the pathing routes copy the intended routes of the map logics and utilize the specific locations of the level as a real player would. Any artificial intelligence controlled player entity should, at its best, approximate the behaviour of a real player as au- thenticly as possible. Moving on to the pickups, and their placement: such entities are most frequently seen in competitive gameplay, where a set of players competes against their own kin and/or another gaming team. In such cases, those pickups represent all sorts of weapons, shields, health boosters, etc. The conflict between the players, the flow of the map and the possibilities of the pickups are melted together to create a strong definer of such a game. The question of proper pickup placement can be, from the most generalized point of view, interpreted as gaming theory [18] — a level can offer a wide variety of spaces (close quarters, medium range spaces, wide ranges, ver- tical spaces, etc.), each kind of a pickup requires a certain amount of skill for the player to handle and is best fit to be used in a certain space; fur- thermore, placing the powerful pickups into dangerous places balances the possible reward of acquiring such a pickup with the dangers of being ex- posed (and losing) to the other players. All in all, a good pickup placement accents strategy, conflict, game flow and player creativity — all of which are adding to the gameplay experience.

31 3. THEPROCESSOF LEVEL DESIGN

Figure 3.13: A standard pickup in a common, low-risk route (left) presents mild risk for the player to acquire. On the other hand, a powerful pickup placed in a deadlock (right) is of high risk for the player (a risk balanced only by the power of the pickup); even though deadlocks should not gen- erally be used in any arena-type level (as they trap the players, offering only one way out), designing a deadlock including a powerful pickup is an exception.

Some special pickups/items can also be a part of the gameplay. A good example of this is the Capture the Flag (CTF) game, where two teams of players compete against each other, trying to possess the other team’s flag and bring it back to their own base. A CTF level is usually designed like this: on the two ends of the level are two fortresses, while the area in the middle serves as a battleground for the two teams trying to infiltrate the enemy’s fortress. Intuitively, the flag (the most important object of the level) is placed in a relatively safe place inside the fortress, giving the defending team a room to protect it. Besides CTF, there are also some other game types using a special pickup/item. In such cases, the gameplay usually revolves around those special elements in some way.

3.6.2 Interactivity Some kind of interactivity with the level may add to the gameplay experi- ence (unless the interactivity gets repetitive and frustrating for the player). Pickups, as weapons in first-person shooter games are but a weak exam- ple of interactivity. There are, however first-person games that expect the player to interact with the environment around (The Ball or Portal are good examples of such games). An interactive game usually contains puzzles, movable geometry, extensive usage of physics and destructive environment. Exploring and seizing these possibilities can alter the gameplay experience a lot, constructing such a levels is a challenging task, often requiring an-

32 3. THEPROCESSOF LEVEL DESIGN other look at the concept of the level.

3.7 Optimization and finalization

At this point of level development workflow, all the major steps of the cre- ation phase should be established, fully developed and in place. Optimiza- tion is just a review and analysis of those previous steps — to evaluate the former constructs, to add and/or adjust a few overlooked details and to remove the unnecessary things.

3.7.1 Revising the details

Every level should be constructed with a specific set of hardware limita- tions in mind (this applies most importantly to the graphical details, i.e. Static Meshes and lighting, or generally, to virtually everything). If a spe- cific level is being constructed for a console, that specific level must be playable there, i.e. perform smoothly on that certain console - running such level on the console must maintain a decent frame rate (i.e. at least 30 frames per second), with no severe performance drops. Same principle goes for a PC level (just instead of the console specifications, the level must perform well on a ”recommended system” here), or any other hardware. The pro- cess of optimization starts with testing the designed levels on the adequate hardware and see, how the level performs. There are basically two kinds of elements in a level: the needless and the useful ones. Both reduce the performance, driving it to the limits of the tested hardware, but both are not the same. A needless element adds little to none value to the level, while hurting the performance considerably. On the other hand, the added value/lost performance ratio of a useful element is a more balanced one. An example of a needless element may be a Static Mesh that is 99% hidden under a collection of some other Static Meshes and is thus neither visible nor relevant to the end-user, who is exploring the level. Such a Static Mesh adds no visual value to the level, while still forcing the engine to take it into account, render its full geometry and store its textures in the memory. Another example would be a partially visible terrain mesh (again, the invisible parts of the terrain only hurt performance and don’t need to be rendered at all). That is why optimization process needs to scan for these needless elements and remove them all. As for the useful elements, the situation is a bit more complex here. If the performance testing shows that the level is over-detailed and not running well enough on the reference hardware, the amount of detail in the useful

33 3. THEPROCESSOF LEVEL DESIGN elements must be reduced. The question is how. All the over-detailed scenes should be scanned for the elements that hurt the performance most considerably. Removing those elements (or re- placing them with less demanding alternatives) is the way to go. One thing to keep in mind is that a level of detail of a good level is always balanced and uniformed over the whole space of the level: it was added to reach similar intensity on the whole, and if some amount of detail is removed, it should also be removed consistently. There are situations, however, when a weak point is detected. A weak point is a segment of a level that suffers a significant performance loss considering the rest of the locations in a level.

Figure 3.14: Weak point. Standing on the ”A” position and facing to the north, the engine must draw all the detail of the three corridors/rooms ahead for the viewer in question.

If the weak point is simply an overdetailed location, reducing the details is an easy way to fix the performance loss. It is not always so easy with the weak points, though. A weak point may simply be a poorly designed location, situated in an unfortunate field of view, that forces the engine to draw an unexpectedly high amount of detail. If this is the case, the floorplan of the level should be revised to avoid further occurences of weak points. And there are also the situations, when a level performs generally better than expected on the reference hardware. A solution here is to add more detail, if there is enough time for producing the level — once again, to attain the best looks/hardware demands ratio.

34 3. THEPROCESSOF LEVEL DESIGN

3.7.2 Optimization techniques

This sub-chapter strives to point out a few practical strategies regarding optimizing the level. CSG geometry is not fit for creating complex shapes. Leave out any de- tailed shapes to Static Meshes, as the Static Meshes are intended for such usage. CSG geometry generally does not impact the performance of a level significantly; keeping one’s CSG shapes convex, clean and simple helps constructing a precise level, though. As explained in the 3.2.3 subchapter, CSG zones and volumes help determing the engine what is visible to the player and what is not. Use these as much as possible to save some perfor- mance on the level. Optimizing the terrain is simple: do not let the engine render the seg- ments of the terrain that are not visible (i.e. covered under a Static Mesh or CSG geometry). Choosing a reasonable terrain resolution also helps — no need creating a terrain containing 1024x1024 polygons, if that terrain cov- ers only a rather tiny area, where a 128x128 would do. Lastly, some rather inclined slopes may show the polygonal edges of the terrain; rotating the terrain vertices on such slopes may help smoothing up the terrain a bit. Static Meshes play a major role in optimization issues. If there is a ne- cessity to cover a huge area with a lot of detail, the best thing to do is to use one Static Mesh repetitively - as long as the scene visuals do not drastically decline because of this (for example, a whole cliffside can be assembled by a clever, repetitive usage of three to five Static Meshes). What is the reason for this? A single Static Mesh used in the scene multiple times occupies less system memory in contrast to an extensive usage of unique Static Meshes. If a Static Mesh is way too detailed, it may need to be taken back to the 3D modeling application and reduced on polycount. Tweaking the Static Mesh low/high resolution display range in the Unreal Editor may also help. Being aware of the amount and the resolution of the materials/textures used in a level is also important. Same goes for the resolution of lightmaps. Steering away from overly complex material shaders does improve the per- formance as well. About revising the map flow: all the routes in the level should be tested to ensure their proper functionality and accessibility. The geometry and placement of items all over the level should suggest clues about the seg- ments and overall directions of the level — to do the exact opposite of dis- orienting the players. Collisions should also be revised during the optimization phase. A prim- itive, box-like collision model may suffice for a Static Mesh placed in an

35 3. THEPROCESSOF LEVEL DESIGN improbable location. On the other hand, highly frequented locations in the level should be carefully checked and tested for collision models working as intended (a player stuck in the middle of the level is no good). A completely inaccessible place should be blocked out by a collision volume, whilst the Static Meshes behind such volume do not, hypothetically, need to have any collision model at all. Lastly, but not leastly, the collision models should always follow the shapes of the actual geometry. Moving on to level lighting and visibility. The lights in the level, be- sides being atmospheric, should always illuminate (and accent) the signif- icant gameplay areas. I.e. an overly dark, frequented area of an otherwise brightly lit map is not a good implementation of lighting. Performance- wise, the static lights are not much of a problem (unless the lightmap is of an unbearably high resolution). The real problem can be a dynamic light — if there are many complex shapes that reflex that light and cast its shadow (a dynamic light of a wide lighting radius); the complexity of such situation can only be exxagerated by using multiple dynamic lights. All dynamically lit areas should, therefore, be properly tested. Contravise, properly adjusted visibility options can free up a lot of system resources. A level situated in a deep fog or a thunderstorm has a visibility radius; all the objects beyond such a visibility radius (i.e. a fog bank) don’t need to be rendered at all. The engine should be able to scale the details of a level on its own. The designer usually works with visuals that would turn out to be the ”high”gameplay level of detail. It is the designer who should, however, try to maintain a balanced level of detail through the whole level. For ex- ample, a material with an underlying texture of 1024x1024 pixel resolution may look plausible along other surfaces of 4096x4096 pixels, but once scaled down to a lower level of detail, any texture of 256x256 looks significantly underdetailed in comparison to 1024x1024 ones.

3.7.3 Finalizing the level As of now, the outcome of the previous efforts is a (nearly) finished level. Having done all the production and post-production optimization, the de- signer did all he could. To get feedback (and perhaps discover some pre- viously unresolved issues), the designer may (or must) choose to send the level to a betatest. If any significant issues emerge during the betatest, the level should be taken back to the optimization phase until the issues are resolved. Once a level passes the betatest, it is finished and/or ready to be released.

36 Chapter 4 An example of Level Design

This chapter (along with the appendix A) illustrates the process of creating a sample level.

4.1 Designing the environment

The level will be built using the August 2010 version of UDK [9], created on a standard PC computer and intended for the PC platform; this level will be a CTF (capture the flag) map, utilizing the sample resources (Static Meshes, materials) of Unreal Tournament 3 demo — a standard first-person 3D shooter game demo integrated with the UDK. As for the conceptual phase, the theme of the level would be an aban- doned industrial complex. An original inspiration for this theme was the old complex of Zbrojovka, located in Brno, Zideniceˇ (see appendix figure A.1). Since the process of creating Static Meshes and materials from such a source would be way too demanding for one person only, i was able to utilize the Static Meshes and materials used in the DM-Deck level, bun- dled with the UDK. As can be seen from figure A.2, the theme of DM-Deck doesn’t stray too far away from the concepts in the figure A.1. Moving on to the floorplan: figure A.3 shows a basic floorplan sketch of the upcoming level, figure A.4 adds an overview of intended path routing and the estimated intensity of certain locations.

4.2 Illustrating the process

The illustrated progress of images refered to from this subchapter should reflect the stages of level development, as described in the third chapter. The floorplan of the CTF map in creation is a symmetric one (as CTF maps usually are, to give equal chances to both of the competing teams). Having a symmetric layout can also save up some work efforts - only a

37 4. ANEXAMPLEOF LEVEL DESIGN half of the level needs to be developed and tested, the other half can then be copied, pasted and mirrored. Figure A.5 shows the level in the stage of finishing up adding the rough CSG geometry. In the figure A.6 is the primitive geometry, texturized. Moving on to the Static Mesh phase: a pass of Static Meshes is shown in the figure A.7. At this point in the development, the level can be lit. Figure A.8 shows the level with some lighting applied to it. The process of designing this level slowly draws to the end. The figure A.9 shows some basic bot pathing with pickups added on strategic places. Finalizing touches are adding some optimizations (i.e. blocking volumes), as may be seen from the wireframe overview of the finished scene in the figure A.10. The work is done and the scene is now finalized.

However, during this practical design stage, only a portion of the level was created (as in the iterative method — to serve as a reference if, perhaps the whole level is to be finalized). The other, untouched areas of the sample level can be finalized using the same workflow as described and shown. The approach is repetitive, i.e. more or less the same, only the amount of hours needed to devote to such efforts rises. Developing a level of today’s standards in detail is time consuming.

38 Chapter 5 Conclusion

The purpose of this thesis was to describe and then to demonstrate the most common leveldesign approaches as of 2011. Following a brief analysis of the engines available on the market, one engine implementation (UDK) was chosen for further exploration. After describing the whole leveldesign life- cycle from preproduction all the way to postproduction within the means of UDK, the leveldesign process was demonstrated on a specific level using the UDK, illustrated and commented. On more abstract terms, it is important to note that even though tech- nologies evolve, and with technologies evolving, game development com- panies need to adapt to new workflows, create new vocations by dividing the old ones into segments and restructure the approaches and techniques, the core idea behind level design still remains the same: to create the best- looking, best-playing levels most effectively and with as little hardware re- quirements as possible. Understanding this core idea of level design is a lot more important nowadays than it was some ten years ago. The field of level design did evolve from its early days to the complex forms of today; it is also certain, that with new hardware, new rendering possibilities and more computa- tional power in general, the field of level design will be still growing into even more complicated forms. Since a lot of resources need to be invested into level design in a way that does not equal wasting those resources, keep- ing a clear and transparent workflow of some sorts (as described in this thesis) is no longer just a good habit, it becomes a necessity.

39 Bibliography

[1] Michael Capps. Developing gears of war in unreal engine 3. http: //pipux.net/data/content/72/xfest-gfx.pdf, 2006. [On- line; accessed 22-May-2011].

[2] Rachel Cordone. Map optimization. http://www.angelmapper. com/gamedev/tutorials/optimization1.htm, 2004. [Online; accessed 22-May-2011].

[3] Crytek. Cryengine specifications. http://mycryengine.com/ ?conid=2, 2011. [Online; accessed 22-May-2011].

[4] Idea Fabrik. Heroengine specifications. http://www.heroengine.com/features/ heroblade-all-in-one-development-environment/, 2010. [Online; accessed 22-May-2011].

[5] Alex Galuzin. 11 Day Level Design. Self-published, 2009.

[6] Epic Games. Lighting reference. http://udn.epicgames.com/ Three/LightingReference.html, 2010. [Online; accessed 22- May-2011].

[7] Epic Games. Materials tutorial. http://udn.epicgames.com/ Three/MaterialsTutorial.html, 2010. [Online; accessed 22- May-2011].

[8] Epic Games. Unreal developer network. http://udn.epicgames. com, 2011. [Online; accessed 22-May-2011].

[9] Epic Games. Unreal development kit. http://www.udk.com/ download, 2011. [Online; accessed 22-May-2011].

[10] Epic Games. Unreal editor user guide. http://udn.epicgames. com/Three/UnrealEdUserGuide.html, 2011. [Online; accessed 22-May-2011].

40 5. CONCLUSION

[11] Epic Games. Unreal engine 3. http://www.unrealengine.com/ features, 2011. [Online; accessed 22-May-2011].

[12] Sjoerd De John. The Hows And Whys Of Game Industry. Lulu, 2007.

[13] Sjoerd De John. The Hows And Whys Of Level Design. Lulu, 2008.

[14] Sjoerd De Jong. Texturing. http://www.hourences.com/ tutorials-texturing, 2004. [Online; accessed 22-May-2011].

[15] Sjoerd De Jong. Ue3 sound. http://www.hourences.com/ tutorials-ue3-sound, 2006. [Online; accessed 22-May-2011].

[16] Celeste Masinter. Ue3 static mesh colission. http://www. moddb.com/engines/unreal-engine-3/downloads/ ue3-tutorial-03-static-mesh-collision-detection, 2004. [Online; accessed 22-May-2011].

[17] 3D Motive. Modular building workflow. http://www.3dmotive. com/product-modular-building-udk, 2010. [Online; accessed 22-May-2011].

[18] Kevin Oxland. Gameplay and design. Addison Wesley, 2004.

[19] Lee Perry. Modular level and componenent design. Game developer, 11:10, 2002.

[20] Sam Shahrani. Educational feature: A history and analy- sis of level design in 3d computer games - pt. 1. http: //www.gamasutra.com/view/feature/2674/educational_ feature_a_history_and_.php, 2006. [Online; accessed 22-May- 2011].

[21] Sam Shahrani. Educational feature: A history and analy- sis of level design in 3d computer games - pt. 2. http: //www.gamasutra.com/view/feature/2682/educational_ feature_a_history_and_.php, 2006. [Online; accessed 22-May- 2011].

[22] Artificial Studios. Reality engine. http://www. artificialstudios.com/features.php, 2005. [Online; ac- cessed 22-May-2011].

[23] Pavel Ugwitz. Modular leveldesign. http://pipux.net/index. php?id=72, 2009. [Online; accessed 22-May-2011].

41 5. CONCLUSION

[24] Beyound Unreal. General scale and dimensions. http: //wiki.beyondunreal.com/Legacy:General_Scale_And_ Dimensions, 2007. [Online; accessed 22-May-2011].

[25] Valve. Source engine. http://source.valvesoftware.com/, 2007. [Online; accessed 22-May-2011].

[26] Wikipedia. Constructive solid geometry. http://en.wikipedia. org/wiki/Constructive_solid_geometry, 2011. [Online; ac- cessed 22-May-2011].

[27] Wikipedia. History of video game consoles (seventh generation). http://en.wikipedia.org/w/index.php?title=History_ of_video_game_consoles_(seventh_generation)&oldid= 430285921, 2011. [Online; accessed 22-May-2011].

[28] Wikipedia. Id tech 4. http://en.wikipedia.org/w/index.php? title=Id_Tech_4&oldid=427697182, 2011. [Online; accessed 22- May-2011].

[29] Wikipedia. List of game engines. http://en.wikipedia. org/w/index.php?title=List_of_game_engines&oldid= 430143927, 2011. [Online; accessed 22-May-2011].

[30] Wikipedia. Social facilitation. http://en.wikipedia.org/wiki/ Social_facilitation, 2011. [Online; accessed 22-May-2011].

[31] Wikipedia. Video game industry. http://en.wikipedia. org/w/index.php?title=Video_game_industry&oldid= 429837177, 2011. [Online; accessed 22-May-2011].

42 Appendix A The process of creating a level

Figure A.1: The environment that inspired the theme of the sample map.

43 A.THEPROCESSOFCREATINGALEVEL

Figure A.2: Existing 3D environment with premade resources (Static Meshes, materials), similar to the scenery in A.1 — thus usable.

44 A.THEPROCESSOFCREATINGALEVEL

Figure A.3: The floorplan sketch of the sample level.

45 A.THEPROCESSOFCREATINGALEVEL

Figure A.4: Further analysis of the sketch from A.3 — path routing and a prediction of critical areas.

46 A.THEPROCESSOFCREATINGALEVEL

Figure A.5: The sample level in the phase of finishing up the CSG geometry.

47 A.THEPROCESSOFCREATINGALEVEL

Figure A.6: CSG geometry, covered by some basic materials.

48 A.THEPROCESSOFCREATINGALEVEL

Figure A.7: Detailing the scene with Static Meshes.

49 A.THEPROCESSOFCREATINGALEVEL

Figure A.8: Lighting is introduced into the level.

50 A.THEPROCESSOFCREATINGALEVEL

Figure A.9: Map logics.

51 A.THEPROCESSOFCREATINGALEVEL

Figure A.10: Wireframe view of the finalized sample.

52 Appendix B The content of the DVD

There is also a DVD encosed to this thesis, containing

• the source document of this thesis in the TEX format

• this thesis in the PDF format

• august 2010 version of UDK

• the sample level

53