DOCSLIB.ORG

Level Design

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Level Design 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.
Load more

Recommended publications
  • Game Level Layout from Design Specification
    EUROGRAPHICS 2014 / B. Lévy and J. Kautz Volume 33 (2014), Number 2 (Guest Editors) Game Level Layout from Design Specification Chongyang Ma∗z Nicholas Vining∗ Sylvain Lefebvrey Alla Sheffer∗ ∗ University of British Columbia y ALICE/INRIA z University of Southern California Abstract The design of video game environments, or levels, aims to control gameplay by steering the player through a sequence of designer-controlled steps, while simultaneously providing a visually engaging experience. Traditionally these levels are painstakingly designed by hand, often from pre-existing building blocks, or space templates. In this paper, we propose an algorithmic approach for automatically laying out game levels from user-specified blocks. Our method allows designers to retain control of the gameplay flow via user-specified level connectivity graphs, while relieving them from the tedious task of manually assembling the building blocks into a valid, plausible layout. Our method produces sequences of diverse layouts for the same input connectivity, allowing for repeated replay of a given level within a visually different, new environment. We support complex graph connectivities and various building block shapes, and are able to compute complex layouts in seconds. The two key components of our algorithm are the use of configuration spaces defining feasible relative positions of building blocks within a layout and a graph-decomposition based layout strategy that leverages graph connectivity to speed up convergence and avoid local minima. Together these two tools quickly steer the solution toward feasible layouts. We demonstrate our method on a variety of real-life inputs, and generate appealing layouts conforming to user specifications. Categories and Subject Descriptors (according to ACM CCS): I.3.5 [Computer Graphics]: Computational Geometry and Object Modeling—Curve, surface, solid, and object representations 1.
    [Show full text]
  • Persistent Realtim E Building Interior Generation
    Persistent Realtime Building Interior G eneration By Evan Hahn A thesis submitted to the Faculty of Graduate Studies and Research in partial fulfilment of the requirements for the degree of Master of Computer Science Ottawa-Carleton Institute for Computer Science School of Computer Science Carleton University Ottawa, Ontario September 2006 © Copyright 2006, Evan Hahn Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Library and Bibliotheque et Archives Canada Archives Canada Published Heritage Direction du Branch Patrimoine de I'edition 395 Wellington Street 395, rue Wellington Ottawa ON K1A 0N4 Ottawa ON K1A 0N4 Canada Canada Your file Votre reference ISBN: 978-0-494-18353-3 Our file Notre reference ISBN: 978-0-494-18353-3 NOTICE: AVIS: The author has granted a non­ L'auteur a accorde une licence non exclusive exclusive license allowing Library permettant a la Bibliotheque et Archives and Archives Canada to reproduce,Canada de reproduire, publier, archiver, publish, archive, preserve, conserve,sauvegarder, conserver, transmettre au public communicate to the public by par telecommunication ou par I'lnternet, preter, telecommunication or on the Internet,distribuer et vendre des theses partout dans loan, distribute and sell theses le monde, a des fins commerciales ou autres, worldwide, for commercial or non­ sur support microforme, papier, electronique commercial purposes, in microform,et/ou autres formats. paper, electronic and/or any other formats. The author retains copyright L'auteur conserve la propriete du droit d'auteur ownership and moral rights in et des droits moraux qui protege cette these. this thesis. Neither the thesis Ni la these ni des extraits substantiels de nor substantial extracts from it celle-ci ne doivent etre imprimes ou autrement may be printed or otherwise reproduits sans son autorisation.
    [Show full text]
  • Master Thesis
    Faculty of Computer Science and Management Field of study: COMPUTER SCIENCE Specialty: Information Systems Design Master Thesis Multithreaded game engine architecture Adrian Szczerbiński keywords: game engine multithreading DirectX 12 short summary: Project, implementation and research of a multithreaded 3D game engine architecture using DirectX 12. The goal is to create a layered architecture, parallelize it and compare the results in order to state the usefulness of multithreading in game engines. Supervisor ...................................................... ............................ ……………………. Title/ degree/ name and surname grade signature The final evaluation of the thesis Przewodniczący Komisji egzaminu ...................................................... ............................ ……………………. dyplomowego Title/ degree/ name and surname grade signature For the purposes of archival thesis qualified to: * a) Category A (perpetual files) b) Category BE 50 (subject to expertise after 50 years) * Delete as appropriate stamp of the faculty Wrocław 2019 1 Streszczenie W dzisiejszych czasach, gdy społeczność graczy staje się coraz większa i stawia coraz większe wymagania, jak lepsza grafika, czy ogólnie wydajność gry, pojawia się potrzeba szybszych i lepszych silników gier, ponieważ większość z obecnych jest albo stara, albo korzysta ze starych rozwiązań. Wielowątkowość jest postrzegana jako trudne zadanie do wdrożenia i nie jest w pełni rozwinięta. Programiści często unikają jej, ponieważ do prawidłowego wdrożenia wymaga wiele pracy. Według mnie wynikający z tego wzrost wydajności jest warty tych kosztów. Ponieważ nie ma wielu silników gier, które w pełni wykorzystują wielowątkowość, celem tej pracy jest zaprojektowanie i zaproponowanie wielowątkowej architektury silnika gry 3D, a także przedstawienie głównych systemów używanych do stworzenia takiego silnika gry 3D. Praca skupia się na technologii i architekturze silnika gry i jego podsystemach wraz ze strukturami danych i algorytmami wykorzystywanymi do ich stworzenia.
    [Show full text]
  • Textile & Fashion Careers Level 2
    Textile & Fashion Careers Level 2 Apparel Construction Demonstrate measurement skills, standard and metric. Select patterns. Follow written pattern directions. Demonstrate pattern layout and material cutout. Demonstrate pattern making. Operate machines, equipment and attachments in a safe and efficient manner. Use tools for construction, alteration and repairs. Demonstrate basic construction and alteration skills and techniques. Computer Technology in Textile/Fashion Industry Set up Computer Aided Design (CAD) tables. Grade and digitize patterns. Create models. Design and plot markers. Produce embroidery motif. Interior Design Research and use information to assess product needs. Determine solutions to design problems. Select fabric, considering patterns and textures, for visual effect. Demonstrate basic construction skills needed in product development. Demonstrate basic installation of window treatments. Apply basic techniques to strip and rebuild furniture. Use standard methods of upholstery for furniture and automobiles. Design and construct slipcover products. Fashion Merchandising and Retail Describe the dynamics of the fashion industry. Explain economic concepts. Explain apparel production, business strategy, sales and distribution. Analyze retail business fundamentals. Compare strategies for retail success. Evaluate principles and methods of advertising. Analyze the global perspectives of the textile/fashion industry. Entrepreneurial Skills Describe types of small business. Analyze components of success in business. Evaluate methods for meeting customer needs. Evaluate regulations and laws related to self-employment. Utilize handcraft and entrepreneurial skills to meet business objectives. PERSONAL QUALITIES Work Effort Safety Habits Work Area Organization On Task Behavior Responsibility Initiative Team Work Respect Interpersonal Skills .
    [Show full text]
  • Inside the Video Game Industry
    Inside the Video Game Industry GameDevelopersTalkAbout theBusinessofPlay Judd Ethan Ruggill, Ken S. McAllister, Randy Nichols, and Ryan Kaufman Downloaded by [Pennsylvania State University] at 11:09 14 September 2017 First published by Routledge Th ird Avenue, New York, NY and by Routledge Park Square, Milton Park, Abingdon, Oxon OX RN Routledge is an imprint of the Taylor & Francis Group, an Informa business © Taylor & Francis Th e right of Judd Ethan Ruggill, Ken S. McAllister, Randy Nichols, and Ryan Kaufman to be identifi ed as authors of this work has been asserted by them in accordance with sections and of the Copyright, Designs and Patents Act . All rights reserved. No part of this book may be reprinted or reproduced or utilised in any form or by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying and recording, or in any information storage or retrieval system, without permission in writing from the publishers. Trademark notice : Product or corporate names may be trademarks or registered trademarks, and are used only for identifi cation and explanation without intent to infringe. Library of Congress Cataloging in Publication Data Names: Ruggill, Judd Ethan, editor. | McAllister, Ken S., – editor. | Nichols, Randall K., editor. | Kaufman, Ryan, editor. Title: Inside the video game industry : game developers talk about the business of play / edited by Judd Ethan Ruggill, Ken S. McAllister, Randy Nichols, and Ryan Kaufman. Description: New York : Routledge is an imprint of the Taylor & Francis Group, an Informa Business, [] | Includes index. Identifi ers: LCCN | ISBN (hardback) | ISBN (pbk.) | ISBN (ebk) Subjects: LCSH: Video games industry.
    [Show full text]
  • Defend the City
    COMPUTER GAMES LABORATORY DOCUMENTATION Defend the City By ToBeUmbenannt Prepared By: Last Updated: Josef Stumpfegger 11/01/2020 Sergey Mitchenko Winfried Baumann Defend the City Documentation TABLE OF CONTENTS GAME IDEA PROPOSAL 4 GAME DESCRIPTION 4 TECHNICAL ACHIEVEMENT 8 "BIG IDEA" BULLSEYE 8 SCHEDULE & TASKS 8 LAYERED TASK BREAKDOWN 8 TIMELINE 9 ASSESSMENT 10 PROTOTYPE REPORT 11 PROTOTYPING GOALS 11 MODELED GAME 11 GENERAL RULES 11 ACTORS 11 ENEMY BEHAVIOR 12 BUILDINGS AND THEIR PURPOSE 14 TRAPS 15 LEVEL DESIGN 15 WHAT WE’VE LEARNED 17 INFLUENCES ON THE GAME 18 INTERIM REPORT 18 PROGRESS REPORT 19 CHARACTER 19 TRAPS 20 AI 20 DESTRUCTIBLE ENVIRONMENT 21 LEVEL DESIGN 21 GENERAL GAMEPLAY 22 CHALLENGES AND PROBLEMS 22 TODOS FOR NEXT MILESTONE 23 ALPHA RELEASE REPORT 23 PROGRESS REPORT 23 TRAPS 23 22222 2 Page 2 of 42 Defend the City Documentation UI 25 AI 26 DESTRUCTIBLE ENVIRONMENT 27 CHALLENGES AND PROBLEMS 27 TODOS FOR NEXT MILESTONE 27 PLAYTESTING 28 CHANGES BEFORE PLAYTESTING 28 PLAYTESTING REPORT 30 SETTING 30 QUESTIONS 30 OBSERVATIONS 31 RESULTS AND CHANGES 33 ADDITIONAL FEEDBACK 35 CONCLUSION 36 THE FINAL PRODUCT 36 EXPERIENCE 38 COURSE PERSONAL IMPRESSION 38 33333 3 Page 3 of 42 Defend the City Documentation Game Idea Proposal Game Description Our game takes place in medieval times setting combined with some fantasy aspects. You control in a standard 3rd person fashion a hero, whose task is to protect the kingdom from a series of attacks on different cities of bloodthirsty creatures. The attack is continuous but sometimes offers some time where the soldiers of the city can defend on their own while you prepare some additional defenses to assist you when the attacks intensify again.
    [Show full text]
  • Development of a 2D Lateral Action Videogame for Android Platforms
    Escola Politècnica Superior Universitat de Girona Development of a 2D lateral action videogame for Android platforms. Desenvolupament d’un videojoc d’acció lateral per a plataformes Android. Projecte/Treball Fi de Carrera GEINF. Pla 2016 Document: Memòria Autor: Robert Bosch Director: Gustavo Patow Departament: Informàtica, Matemàtica Aplicada i Estadística Àrea: LSI Convocatoria: JUNY/2016 Contents 1 Introduction6 1.1 Introduction . .6 1.2 Personal motivations . .7 1.3 Project motivations . .7 1.4 Project purposes . .7 1.5 Objectives . .7 1.6 Structure of this memory . .8 2 Feasibility study9 2.1 Resources needed to develop this project . .9 2.1.1 Developer requirements . .9 2.1.2 Player requirements . .9 2.2 Initial budget . 10 2.3 Human resources . 10 2.4 Technological viability . 11 2.4.1 Economic viability . 11 2.4.2 Human costs . 11 2.4.3 Equipment costs . 11 2.4.4 Total costs . 11 3 Methodology 12 4 Planning 14 4.1 Working plan . 14 4.2 Planned tasks . 14 4.2.1 Planning . 14 4.2.2 Learning . 14 4.2.3 Implementation . 14 4.2.4 Verification . 15 4.2.5 Documentation . 15 4.3 Estimated scheduling . 16 4.4 Expected results of every task . 17 4.4.1 Planning . 17 4.4.2 Learning . 17 4.4.3 Implementation . 17 4.4.4 Verification . 17 4.4.5 Documentation . 17 5 Framework 18 5.1 Videogame engines . 18 5.2 Examples of videogame engines . 18 5.2.1 Unreal Engine . 18 2 Contents Contents 5.2.2 CryEngine . 19 5.2.3 GameMaker .
    [Show full text]
  • Gourmet Typography Training
    presents GOURMET TYPOGRAPHY TRAINING Take control of your type instead of letting it control you! Gourmet Typography Training teaches and demonstrates the expert-level typographic skills and aesthetics that are rarely taught in schools or fully understood by professionals. Fill in the gaps in your typographic know-how and learn how to “see” type like you’ve never seen it before. Why Gourmet Typography Training? Every creative professional, regardless of specialty, can benefit from learning to communicate more effectively with type. Whether you are a beginner or seasoned pro, Gourmet Typography Training will sharpen your eye and give you practical, usable skills that will visibly improve the beauty, clarity and effectiveness of all your typographic projects. Subjects covered include: Who will benefit? What makes a good typeface Visual communicators of all kinds, including: OpenType demystified Graphic designers Type crimes: Are you a type criminal? Art directors Fine-tuning type, including alignment, Creative directors hyphenation, hung punctuation, etc. Creative services directors Tracking, kerning, and word spacing Web designers Tips for more professional typography Package designers Type on the Web, Web fonts Production specialists Type in motion Typographers Keyboard shortcuts and time-saving tips Web programmers and developers Every creative professional regardless of specialty can learn to communicate more effectively with type! For more information, call The Type Studio at 203.227.5929 or email us at [email protected]. www.thetypestudio.com (page 1 of 2) What they are saying about Ilene’s Gourmet Typography Training... “Your course was great! Since taking it, “I recently attended your Gourmet “As a working professional in the advertis- I can’t help but look at every book title, Typography workshop and wanted to ing industry with 10 years of creative magazine headline, and even company thank you again for an amazing day.
    [Show full text]
  • Multiplayer Online Games Insecurity (Neverfeelsafewhileplayingonline)
    MULTIPLAYER ONLINE GAMES INSECURITY (NEVER FEEL SAFE WHILE PLAYING ONLINE) Luigi Auriemma1 and Donato Ferrante2 ReVuln http://revuln.com [email protected] http://twitter.com/revuln 25 January 2013 Abstract Multiplayer online games security is an underestimated field, with an insane amount of players playing online games and companies push- ing out new games at an incredible rate. In this ecosystem finding vulnera- bilities in games turns to be a really attractive work. 1W HY ATTACKING GAMES? There are two main entities in multiplayer games: players and companies. Players play games for fun, companies make games for money. For each of these two entities there are different possible subsets of attackers. Let’s start by considering players. 1.1A TTACKING PLAYERS Some of the people who may be interested in attacking players systems while they play online games include: Script kiddies - people without any technical knowledge. They browse the • internet looking for ready-to-use attacking tools, and then they use such tools to attack players. Primarily, their final goal is to generate Denial Of Service (DoS) conditions against players systems. Others - this category is composed by several entities. We may find people • testing exploits, or people trying to build a games-based malware botnet. Others also include people interested in deploying "applications" on remote systems. 1.2A TTACKING COMPANIES As stated previously, companies make games for money. This is their business. Because of this possible attackers for game companies include: Script kiddies - this category of attackers makes no distinction between play- • ers or companies. They attack both for fun.
    [Show full text]
  • PROCEDURAL CONTENT GENERATION for GAME DESIGNERS a Dissertation
    UNIVERSITY OF CALIFORNIA SANTA CRUZ EXPRESSIVE DESIGN TOOLS: PROCEDURAL CONTENT GENERATION FOR GAME DESIGNERS A dissertation submitted in partial satisfaction of the requirements for the degree of DOCTOR OF PHILOSOPHY in COMPUTER SCIENCE by Gillian Margaret Smith June 2012 The Dissertation of Gillian Margaret Smith is approved: ________________________________ Professor Jim Whitehead, Chair ________________________________ Associate Professor Michael Mateas ________________________________ Associate Professor Noah Wardrip-Fruin ________________________________ Professor R. Michael Young ________________________________ Tyrus Miller Vice Provost and Dean of Graduate Studies Copyright © by Gillian Margaret Smith 2012 TABLE OF CONTENTS List of Figures .................................................................................................................. ix List of Tables ................................................................................................................ xvii Abstract ...................................................................................................................... xviii Acknowledgments ......................................................................................................... xx Chapter 1: Introduction ....................................................................................................1 1 Procedural Content Generation ................................................................................. 6 1.1 Game Design...................................................................................................
    [Show full text]
  • Level Design Histories and Futures”
    Level Design in a Day: “Level Design Histories and Futures” Robert Yang @radiatoryang About this talk ● Concepts and language to help you be critical about “level design” ● Not about “how to do level design” ● Heavy bias toward 3D character-based games (like everyone else) (The PERFECT level designer?) (one can dream...) Four (4) possible dimensions of contemporary level design ● as a material, as data ● as industrial process ● as architectural space ● as community politics 1:1: LevelLevel designdesign asas MATERIALS,MATERIALS, CONSTRUCTION,CONSTRUCTION, andand DATADATA “LEVEL” = a bunch of data (asset) that references a bunch of other data (other assets) “LEVEL EDITOR” = software that enables human visualization and modification of this data LEVEL EDITOR HISTORY: text editor as level editor LEVEL EDITOR HISTORY: studying tool interfaces / workflow LEVEL EDITOR HISTORY: one 2D floorplan pane AutoCAD (1982) DoomEd (~1992?) LEVEL EDITOR HISTORY: the asset browser Hammer (2004) Hammer (2006?) LEVEL EDITOR HISTORY: 3 pane, 3D preview + floorplan + elevation QuakeEd (1996) (great ancestor of “Radiant” level editors) LEVEL EDITOR HISTORY: mouse-look / WASD more emphasis on 3D camera view, more emphasis on “wandering” as workflow LEVEL EDITOR HISTORY: 4 pane, 3D preview + 2D ortho views 3D Studio (1990) Worldcraft (Hammer) (1996-2012?) Unreal Dev Kit (UE3, 2009) LEVEL EDITOR HISTORY: (from left to right:) - Unity one big interactive 3D view - Unreal 4 - SketchUp to rule them all and in the darkness bind them - Trenchbroom (Quake 1) - CryEngine3
    [Show full text]
  • A Doom-Based AI Research Platform for Visual Reinforcement Learning
    ViZDoom: A Doom-based AI Research Platform for Visual Reinforcement Learning Michał Kempka, Marek Wydmuch, Grzegorz Runc, Jakub Toczek & Wojciech Jaskowski´ Institute of Computing Science, Poznan University of Technology, Poznan,´ Poland [email protected] Abstract—The recent advances in deep neural networks have are third-person perspective games, which does not match a led to effective vision-based reinforcement learning methods that real-world mobile-robot scenario. Last but not least, although, have been employed to obtain human-level controllers in Atari for some Atari 2600 games, human players are still ahead of 2600 games from pixel data. Atari 2600 games, however, do not resemble real-world tasks since they involve non-realistic bots trained from scratch, the best deep reinforcement learning 2D environments and the third-person perspective. Here, we algorithms are already ahead on average. Therefore, there is propose a novel test-bed platform for reinforcement learning a need for more challenging reinforcement learning problems research from raw visual information which employs the first- involving first-person-perspective and realistic 3D worlds. person perspective in a semi-realistic 3D world. The software, In this paper, we propose a software platform, ViZDoom1, called ViZDoom, is based on the classical first-person shooter video game, Doom. It allows developing bots that play the game for the machine (reinforcement) learning research from raw using the screen buffer. ViZDoom is lightweight, fast, and highly visual information. The environment is based on Doom, the customizable via a convenient mechanism of user scenarios. In famous first-person shooter (FPS) video game. It allows de- the experimental part, we test the environment by trying to veloping bots that play Doom using only the screen buffer.
    [Show full text]