BOOKS FOR PROFESSIONALS BY PROFESSIONALS® B e r i n s t e i n A d v a n c e d G a m e D e v e l o p m e n t T o o l E s s e n t i a l s ISBN 978-1-4302-6700-3 55999 Shelve in: Programming Languages/General User Level: 9781430267003 Advanced www.apress.com www.it-ebooks.info For your convenience Apress has placed some of the front matter material after the index. Please use the Bookmarks and Contents at a Glance links to access them. www.it-ebooks.info Contents at a Glance About the Authors ���������������������������������������������������������������������������������������������������������������xv About the Technical Reviewers �����������������������������������������������������������������������������������������xix Acknowledgments �������������������������������������������������������������������������������������������������������������xxi Introduction ���������������������������������������������������������������������������������������������������������������������xxiii ■ Part 1: Asset and Data Management ������������������������������������������������������������1 ■ Chapter 1: Plug-in–based Asset Compiler Architecture ����������������������������������������������������3 ■ Chapter 2: GFX Asset Data Management ���������������������������������������������������������������������������7 ■ Part 2: Geometry and Models ���������������������������������������������������������������������17 ■ Chapter 3: Geometry and Models: 3D Format Conversion (FBX, COLLADA) ���������������������19 ■ Chapter 4: Building Procedural Geometry Using MAXScript (Voronoi Polygons) ������������39 ■ Chapter 5: A Uniform Geometry Workflow for Cutscenes and Animated Feature Films �������������������������������������������������������������������������������������������������������������������55 ■ Chapter 6: Building a Rock-Solid Content Pipeline with the COLLADA Conformance Test Suite ���������������������������������������������������������������������������������������������������67 ■ Chapter 7: Rendering COLLADA Assets on Mac OS X with Scene Kit ������������������������������87 ■ Chapter 8: COLLADA Exporter for Unity Developers in the Unity Asset Store ������������������95 ■ Part 3: Web Tools ��������������������������������������������������������������������������������������103 ■ Chapter 9: Introduction to Utilizing HTML, CSS, and JavaScript to Create Rich Debugging Information ��������������������������������������������������������������������������������������������������105 ■ Chapter 10: Moving Tools to the Cloud: Control, Configure, Monitor, and View Your Game with WebSocket �������������������������������������������������������������������������������������������117 v www.it-ebooks.info ■ Contents at a GlanCe ■ Part 4: Programming ��������������������������������������������������������������������������������129 ■ Chapter 11: Programming: Decoupling Game Tool GUIs from Core Editing Operations �131 ■ Chapter 12: Building A Game Prototyping Tool for Android Mobile Devices �����������������149 ■ Chapter 13: Engineering Domain-Specific Languages for Games ���������������������������������173 Index ���������������������������������������������������������������������������������������������������������������������������������189 vi www.it-ebooks.info Introduction The computer game industry isn’t what it used to be. Early on, which wasn’t all that long ago, developers focused on bringing the magic of arcade games to microcomputers, which was fun, but suffered from a computing environment that was technically and artistically limiting. However, as computing power exploded, so did developers’ technical options and creativity, culminating in the sophisticated AAA titles that became so popular in the aughts. These marvels required large development teams, with complex and proprietary platforms that themselves required dedicated teams of programmers, and game development grew up; boy, did it. In the last few years there has been a massive explosion in the growth of mobile and casual gaming, which has dramatically changed the nature of game development. Many successful products are now developed by small teams that do not have the resources to build the kind of complex tool chains AAA teams use. These developers cannot afford the luxury of specializing in one small part of a complex system. To build a modern game, typically in a web or mobile environment, you must be familiar with a wide range of technologies and techniques, and you must be able to turn your hand to meet the immediate need, which may be just about anything: one day asset management, the next capturing usage statistics, the day after passing conformance tests. This book was written with the needs of the new developer in mind. We offer strategies for solving a variety of technical problems, both well-known and unusual ones, that our experts have encountered. There’s quite a lot about COLLADA, as well as techniques for using the Web and the cloud in your pipeline, rapid prototyping, managing your files and assets, and optimizing your GUIs. We think there’s something for everyone here and hope you agree. Code samples are written in Java, MAXScript, Objective-C, Python, HTML, JavaScript, JSON, C, C++, C#, AngelScript, Xtext, and domain-specific languages. We’ve divided the book into four parts: • Asset and Data Management • Geometry and Models • Web Tools • Programming Asset and Data Management covers the critical issue of managing your assets in the game development pipeline. Two different aspects are described; both will help developers reduce their workload in the always daunting process of not only organizing original assets, but also tracking changes and versions. For example, Chris Ronchi’s “Where Is It” chapter explains why it’s important to follow a consistent and thought-through naming strategy and demonstrates how to create one. This basic but useful chapter attacks an area that involves no programming and no expenditure, but can help you save time and money just by using a basic “convention over configuration” approach. The second section, Geometry and Models, focuses heavily on the COLLADA document format, describing how it can be used to bridge the gap between proprietary high-end tools and the requirements of small developers. The Web Tools section offers hints on moving game development tools to the cloud as well as some particularly interesting ways in which readily available open source web development tools may be used. By adopting software like Django, for example, it’s possible to build a comprehensive web-based gameplay monitoring and tracking system. Finally, the Programming section offers help for developers who want to create their own flexible workflows. The emphasis here is on employing programming techniques that were originally developed to solve more general problems, such as the Command Pattern and the use of domain-specific languages (DSLs), to simplify the xxiii www.it-ebooks.info ■ IntroduCtIon programming task. Each programming chapter describes not only the use, but the concepts behind the particular technique, so you can identify a variety of use cases and build up your armory of skills. Just a quick word about the development of this book. Unlike almost every game development volume out there, this one was originally published independently by a group of experimenters—people with something to say who came together to try something new; it was titled Game Tool Gems. We self-published the book in both hard copy and ebook formats and sold it through Amazon. But it was a bit bare bones: no index, tech reviewed only by each other, laid out by editor Paula B. rather than by a fancy designer. But people liked it, including Apress’s editors, and that’s how this book with its new title, Game Development Tool Essentials, was born. Apress took the basic material, tech reviewed it six ways from Sunday, added that missing index, and expanded and updated all the chapters. And for that, we are most grateful. We feel that it’s critical to share information about the tools we use to create games. The better our knowledge, the faster and more efficiently we can work, and the more cool things we can do. That’s why we wrote this book pooling the knowledge and experience of working developers. That fragile pipeline has plagued us long enough. Let’s show it who’s boss. xxiv www.it-ebooks.info Part 1 Asset and Data Management www.it-ebooks.info Chapter 1 Plug-in–based Asset Compiler Architecture Nicus¸or Nedelcu From the beginning of the game creation process to the end, developers have two things to worry about: code and data (game art and other type of assets). In the past, data was formatted specifically for the one platform the game was about to run on. Now we have to format the same data for many different platforms. In order to satisfy this new requirement, we need access to source assets that can be compiled into a variety of targets. We also have more work to do, since special care has to be taken for each format. However, there are ways to reduce the pain involved in this more complex pipeline. To make this process as streamlined as possible, I propose a plug-in–based asset compiler that can load converter plug-ins for the given asset types. The plug-in–based nature of the compiler can also help developers create their own plug-ins for any other special asset types they need. In this chapter, I describe how to set up and code such a compiler using an example of a texture converter/compiler plug-in. The platform you are going to use is Windows and the language is C++; with few modifications regarding the OS specifics, the code should work on other environments and can even be adapted to other languages. Design The underlying plug-in loading system can be a “traditional” dynamic-link library (DLL1) loading and querying for the proper interfaces. You will be using the Windows DLL API, but the code is almost the same for other operating systems. The DLL can export a special function that will return an instance of the converter interface (see Listing 1-1). The same goes for other platforms (OS/X, Linux), using their specific dynamic link library API implementations. Listing 1-1. Creating the Asset Converter Instance Using the Exported DLL Function DLL_EXPORT AssetConverter* createAssetConverter(); The interface of the asset converter looks like Listing 1-2. 1Wikipedia. “Dynamic Link Library.” http://en.wikipedia.org/wiki/Dynamic-link_library. 3 www.it-ebooks.info Chapter 1 ■ plug-in–based asset Compiler arChiteCture Listing 1-2. The Asset Converter Interface class AssetConverter { public: enum EType { eType_Unknown = 0, eType_Compiler = 0>>1, eType_Importer = 1>>1, eType_ImporterCompiler = (eType_Compiler | eType_Importer) }; AssetConverter(){} virtual ~AssetConverter(){}; virtual bool convert(const char* pSrcFilename, const char* pDestPath, const Args& rArgs) = 0; // Args class is a command line argument parser, not shown here. Basically holds a list of arguments and their values virtual const char* supportedExtensions() const = 0; virtual EType type() const = 0; }; The asset converter has a type that represents what the converter does with the given input file: compiles or converts. You make this distinction between compilers and converters because you would like to use compilers to compile data from your intermediate format to the final platform-optimized format, and converters to convert from third party formats to your intermediate format. An example of a compiler is cube.json (the intermediate format) to cube.mesh (final optimized format); of a converter, cube.fbx to cube.json. You can also have a compiler and a converter in one implementation (flag eType_ImporterCompiler) that can handle third party and intermediate formats (for example, a TextureConverter that converts third party JPG/PNGs and compiles to a custom format like .TEX). The convert method is the one called by the asset compiler executable when the given command-line arguments are passed to it, and they match the file extensions returned by the supportedExtensions() method. This function should return something like a file mask such as *.jpg, *.tga, *.png, or *.texture, so even a simple substring matching test can select the right converter(s). The command line arguments are shared for all the converters; each one can pick up its own arguments and their values. By convention, the converters will be called first on the given assets, and after that you will call the compilers. Since you (probably) generated/converted assets from the previous step, now you can compile those intermediate formats into final binary optimized ones for specific platforms. The main asset compiler executable will load all plug-in DLLs from either a specific folder or the same folder as the executable. You can use any kind of plug-in loading scheme. For example, you can have those DLLs with their extensions named .plugin, .converter, etc. In this way, you dynamically load only the eligible ones, skipping the unsupported/unknown DLLs. Once a plug-in is loaded, you retrieve the address of the DLL exported createAssetConverter() function and instantiate the converter. Then, with all plug-ins loaded, you match each input asset filename with the return string of the supportedExtensions() of each converter. If the match is true, then you call the converter to take care of that file type. After that, you can continue to pass the filename to be handled by other matching converters, or you could come up with a stop Boolean return value so the file will be handled only once by a single converter and not by further matching converters if the return value is false. Even further, you could have some sort of dependency tree dictating when converters would be called after others have finished converting assets. 4 www.it-ebooks.info Chapter 1 ■ plug-in–based asset Compiler arChiteCture Obviously, another thing that speeds up the compilation/conversion process is multithreading.2 In a first phase, you can schedule groups of files to be converted on separate threads. Then, when you convert a few files, the converters could spawn several threads to take care of a single asset. You must be sure, however, that the available cores are used/spread evenly, whether on a CPU or GPU. Multithreading asset compilation can be a little tricky when dependencies are involved, so for this process to be safe, and to avoid problems arising from two threads concurrently modifying the same resource, you should build a dependency tree and put each main branch and its sub-branches and/or leaves on their own thread. Various methods for thread synchronization can be used, like mutexes and semaphores, each operating system having its own API for that. The main compiler class would look like Listing 1-3. Listing 1-3. The Asset Compiler Class class AssetCompiler { public: AssetCompiler(); virtual ~AssetCompiler(); bool compile(const Args& rArgs); void compileFolder( AssetConverter::EType aConverterType, const char* pMask, const char* pExcludeMask, const char* pCompileFolder, const char* pDestFolder); protected: vector<AssetCompilerWorker> m_workerThreads; ....................... }; The main asset compiler class has the compile(...) method (synchronous call; it will wait until every asset compile thread finishes), which will take the actual command-line arguments. The compileFolder(...) method (asynchronous call; it will just start the threads) will process a given folder for a specific converter type, with a filename mask, an excluding mask, the actual compile folder, and destination folder for the output files. The class also has some worker threads for multithreaded processing of the input assets. Example The code in Listing 1-4 shows an example—a texture converter/compiler plug-in. Listing 1-4. The Texture Converter and Compiler class TextureConverter : public AssetConverter { public: TextureConverter(); ~TextureConverter(); 2“Multithreading.” http://en.wikipedia.org/wiki/Multithreading_(computer_architecture). 5 www.it-ebooks.info