MASARYK UNIVERSITY FACULTY}w¡¢£¤¥¦§¨ OF I !"#$%&'()+,-./012345<yA|NFORMATICS 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. CHOOSING THE 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. CHOOSING THE 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.