Platform Agnostic Approaches for FPCT Development

Transcription

1 Platform Agnostic Approaches for FPCT Development Ramon Novales, Kyle Marple, Gopal Gupta Department of Computer Science The University of Texas at Dallas {rnovales, kbm072000, Marjorie Zielke Arts and Technology The University of Texas at Dallas Introduction This paper examines different options for platform agnostic development of the First Person Cultural Trainer (FPCT). FPCT is a high-fidelity, game-based simulation, which trains cross-cultural decisionmaking within a 3D representation of a Middle-Eastern society. The current version of FPCT is a computer-based video game built in Unreal Engine 3. The project is currently in its second year, or spiral, of development. FPCT is part of the Hybrid Irregular Warfare Improvised Explosive Device Network Defeat Toolkit (HI2NT), sponsored by TRADOC G2 Intelligence Support Activity. HI2NT is a federation of virtual, constructive, and gaming models, providing a combat training center (CTC)-like experience for individuals through brigade-staff training audiences. The overall HI2NT program is also in its second year of development. FPCT functions as a stand-alone cultural trainer, or as part of the federation. 1 The motivation behind platform agnostic development is twofold. First, such an approach allows the development team to take advantage of new development platforms or devices more easily. If FPCT code is tightly coupled with an engine, considerable effort will be required to move to a new engine or platform; existing code will need to be evaluated for portability, and code that is not portable will need to be redone. This rework has the possibility of introducing bugs into previously working functionality, and creating coupling issues that need to be re-addressed if there is a move to another platform. Additional issues arise if development is to take place on two or more platforms concurrently multiple codebases need to be kept in sync, increasing development and software configuration management overhead. The second motivation for this approach can be viewed as a form of risk management. Should external factors mandate a switch to a different engine or platform, the project will be in a better position to make the switch. Further, the project would not be as locked-in to a particular engine, should the vendor end support or not add desired functionality. The ideal is to write code once, and have it run on multiple platforms. 1 "The Game Engine Space for Virtual Cultural Training: Requirements, Devices, Engines, Porting Strategies and a Future Outlook", Technology White Paper, Marjorie Zielke

2 We present a range of possible approaches for platform agnostic development and portability. These approaches are not mutually exclusive, and can be used alone or together on portions of the project or on the project as a whole. For each option, we present a discussion of the relative difficulty and level of effort, as well as the risks and rewards. Note that the approaches in this paper only cover project code, not other project assets such as art and models. Multi-Platform Capability via Game Engine Certainly the most straightforward approach is to use the game engine itself to provide multi-platform capability. Currently, Unreal Engine 3 officially supports the PC, Playstation 3, and XBox 360 platforms. At the 2010 Game Developers Conference, Epic Games gave a presentation demonstrating Unreal Engine 3 running on an iphone 3GS. Further, the presentation slides 2 showed that, although unsupported, Unreal Engine 3 was running on Linux, Mac, and Tegra2 (mobile system-on-a-chip) platforms. If the anticipated lifespan of FPCT coincides with the lifespan of Unreal Engine 3, and Epic Games commits to supporting the anticipated platforms for FPCT, then this approach is attractive, even more so if budget or schedule constraints preclude the other approaches. A true platform agnostic approach can then be designed and implemented on the successor to FPCT. Advantages Multi-platform capability with no additional cost. Low risk and minimal schedule impact, as developers do not need to learn a new engine and tools. Avoids the disruption of switching to a new approach midstream. Disadvantages This approach is dependent on Epic Games supporting the desired platforms. End-of-life may occur when Unreal Engine 4 is released. There is still the risk of a mandated platform switch away from Unreal Engine 3. This is not a true platform agnostic approach code is still specific to Unreal Engine 3. Libraries and Application Programming Interfaces (APIs) In this approach, FPCT code that can be shared between platforms is identified and packaged into libraries. An API is then created that provides access to library functionality from different platforms. This approach can be viewed as a step towards platform agnostic development libraries provide a means for developing and sharing code between platforms, but application development is done native to the target platform, and functionality that cannot be packaged into a library must be replicated across platforms. Creating Libraries and APIs Developers work to identify existing FPCT code that can be easily decoupled from Unreal Engine 3 and reused on other engines or platforms. This code is then extracted, modified to decouple it from the 2

3 engine, and packaged into a library. Typically, code is segregated into different libraries based on similar functionality; the desired granularity of the libraries will control the number of libraries created. For each library, an associated API is created to provide a uniform method for calling library functionality. New development of shared code would follow a similar process. These libraries and APIs will not be static; they will need to be refined and maintained, both to address any deficiencies in the original design and to adapt to use with a new engine or platform. Typically, it is not feasible to extract all project code into libraries; some code will need to be rewritten for each new platform. Figure 1 shows an example of FPCT code being refactored into libraries. Libraries 1 and 3 contain FPCT code that could be decoupled from Unreal Engine 3. Library 2 contains FPCT code as well as modifications to Unreal Engine 3 that could be converted into stand-alone code. Note that in this example, some FPCT code cannot be extracted to libraries, and no engine code is packaged into libraries. FPCT Unreal Engine 3 API 1 API 2 API 3 Library 1 Library 2 Library 3 Platform-specific FPCT code, unable to decouple Game engine code Modified game code, able to decouple Figure 1: Extracting FPCT code to libraries. Using the Libraries and APIs In the Unreal Engine 3 version of FPCT, code that has been extracted to libraries is replaced with calls to those new libraries. Further development of FPCT on Unreal Engine 3 and subsequent development on different platforms takes place in the native language and using the native tools of those platforms. It is important to remember that any functionality not contained in the libraries will need to be developed and maintained separately for each target platform. Developers will make calls to library functionality

4 using the mechanisms of that particular platform. The libraries themselves, however, will be maintained using a generic, non-platform-specific set of tools. It is to be expected that these libraries and APIs will evolve over time, as features are added, bugs are eliminated, and interfaces are adapted to new target platforms. Figure 2 shows an example of how the libraries created in Figure 1 would be used with Unreal Engine 3 and with a new engine, Engine B. API calls for library 1, 2, and 3 replace the original code in the Unreal Engine 3 version of FPCT. For each new engine, it is possible that existing library APIs will need to be modified. It is also possible that libraries will be incompatible with the new engine (perhaps due to language or architecture differences), and will need to be either rewritten or modified. In this example, the API for library 3 was modified to work with Engine B, and moved to version 3.1. Similarly, library 1 was incompatible with Engine B, and the functionality needed to be redone in a completely new library, library 4. FPCT FPCT Unreal Engine 3 Engine B API 1 API 2 API 3.1 API 4 Library 1 Library 2 Library 3 Library 4 Unreal Engine 3-specific FPCT code Engine B-specific FPCT code New library, Engine B unable to use Library 1 Figure 2: Calling libraries from multiple engines. Advantages Creating libraries and APIs is a generally understood approach, with many resources and professional books available. It would not require extensive retraining for program personnel. Library and API development can be done in parallel with main FPCT development, reducing schedule impact. A small period of time for integration and test of the library code back into main FPCT development will be needed.

5 Development is done natively with the target engine, with no layer of abstraction in between. This makes it easier for developers to take advantage of the unique features and strengths of each platform. Developers can use the native tools and IDE of the target platforms, which are presumably robust. With proper maintenance, the libraries and APIs can be reused across multiple engines and platforms. Any updates or new functionality will be available anywhere the libraries are used. Disadvantages This approach addresses the portability of discrete portions of code, not FPCT as a whole. Each move to a new platform can be viewed as a porting effort, barring the code that has been packaged into libraries. Integration and test activities must be repeated for each engine. If development is done for multiple platforms at once, having multiple implementations of the same functionality could lead to increased software configuration management (SCM) effort, as any fixes or features added to one version may need to be mirrored back across all implementations. There is the risk of significant integration effort with future unknown engines and platforms. While there are guidelines to follow for creating libraries and APIs, this is to some extent an educated guess with respect to future technologies. Language or architecture incompatibilities may reduce or eliminate the gains hoped for by creating libraries and APIs. Middleware FPCT API In this approach, a middleware API (say, FPCTAPI) is created which acts as a layer of abstraction between the developers and the target platform or engine. Instead of writing code directly for the target engine or platform, developers write code for FPCTAPI. Developers working on FPCT proper are shielded from platform details, and rely on an interface layer (written by other project developers) to implement their FPCTAPI calls on the target platform(s). Creating FPCT API Developers first identify the objects, operations, and functionality required in order to create FPCT essentially the kinds of things that need to be done, and the types of operations that FPCTAPI needs to support. From this, the interface exposed to the developers is designed. Design of the API itself is very important the research challenge is to create an interface that is generic enough for use across multiple platforms or engines, yet expressive enough to allow for complex functionality in FPCT. This will likely take place across several iterations, incorporating feedback from FPCT developers. The API itself may be implemented in one or more languages, depending upon compatibility with target platforms. Code in the current implementation of FPCT that can be reused across platforms is identified and packaged into libraries as described in the previous section. For each target platform, an interface layer is created which resides between FPCTAPI and the target engine. These interface layers take the

6 FPCTAPI calls, and make the appropriate target platform calls to achieve the desired result. Care must be taken during the design and implementation of the interface layers to ensure not only correctness, but also adequate run-time performance. Using FPCT API In the library/api approach detailed in the previous section, developers write code in the native language of the target platform that interacts directly with the API of the target platform. Switching engines meant familiarizing themselves with a new API (and possibly language), and then rewriting the old code using the API and language of the new engine. The FPCTAPI, however, insulates developers from engine API details. In this approach, FPCT development is done using the language and functions of the FPCTAPI. If the FPCTAPI is expressive and powerful enough, developers on FPCT proper will not need to interact with the engine APIs at all. If a new target platform is desired, a new interface layer for that engine is designed and implemented; since all interface layers are required to support the same interface and functions, existing FPCT code will run on the new platform without modification. It should be expected that FPCTAPI and the interface layers will evolve and require maintenance (particularly when adding a new target platform) during the course of FPCT development. Figure 3 shows a block diagram of how FPCTAPI would be used across multiple platforms. FPCT code is written to the FPCTAPI (which also contains portable library code), while the interface layers connect it to their respective engines. Figure 3: Using FPCTAPI across multiple engines.

7 Advantages This approach fully addresses platform agnostic development. If FPCTAPI is sufficiently comprehensive, FPCT developers make no platform or dependent API calls. Switching from one engine to another means switching interface layers, without needing to change any FPCT code. FPCT developers are shielded from the implementation details of particular platforms; the same code will be able to run unmodified on future platforms and engines, provided an equivalent interface layer can be created. When preparing to add or switch to another platform/engine, a separate team can work on creating the new interface layer, while development on FPCT proper can continue uninterrupted. The majority of program developers only need to learn how to use FPCTAPI. Only a subset of program personnel (those working on the interface layers) need to be trained for a particular engine or platform. For concurrent development on multiple platforms, SCM will be greatly simplified. There is only one version of FPCT proper under development, which means that different versions for different platforms will not need to be kept in sync with each other. Interface layers can also be developed independently from each other. Disadvantages Development of FPCTAPI is a technical challenge and would add technical, schedule, and budget risk to the project. If current development is switched to FPCTAPI, it would need to be recoded and retested. A complete set of tools will need to be developed for use with FPCTAPI, as the tools provided with a particular platform are typically only useful with that platform. It may be a significant effort to create development tools on par with the tools provided by engines. Run-time performance of a generic solution such as FPCTAPI may not be as good as something that has been hand-coded and optimized for a particular platform or engine. Similarly, a more generic approach may make it more difficult to take advantage of the strengths of one platform versus another. Creating functionally equivalent interface layers for different platforms requires that the target platforms be roughly equivalent in terms of adaptability and capability. The interface layer needs to be able to direct the target engine to perform certain tasks, whether through its API, the ability to access and modify engine source code, or the ability to run scripts or external code. Similarly, the interface layer cannot give a target platform functionality that it simply does not have. Creation of a Domain Specific Language The use of FPCTAPI would also open up other options for making multi-platform games easier to design. One of these options is the creation of a domain specific language (DSL). Traditional programming languages, such as C++ and Java, are designed to allow users to solve a wide range of problems. In addition to their general approach, such languages typically require significant expertise, which a subject

8 matter expert may not possess. DSLs, however, are constructed at a higher level of abstraction and are focused on solving a problem in a specific domain. This allows a developer to focus on what they want done as opposed to how it is to be done. Such a DSL could be developed for multi-platform game design using FPCTAPI. A developer would write code in the DSL, and it would be translated into code which accessed FPCTAPI to create either portable games or their components. UnrealScript, currently used in FPCT development, is a DSL. It is tailored to solve problems typically found in first-person-shooter game types. Unfortunately, it is specific to the Unreal engine, and cannot be used directly for other engines, such as Unity. In order to support the platform agnostic goals of the project, another DSL would need to be developed. Different usage scenarios may involve different degrees of DSL adoption. One case would be the development of a more general DSL for developing FPCT using FPCTAPI. Another option would be the use of multiple DSLs for different portions of the project. In this case, DSLs that are more specialized could be used for specific aspects of development. This could include allowing subject matter experts to input cultural data or design scenarios without the need to worry about other components of FPCT. Other potential targets for separate DSLs are the emotion and conversation components of the software. Moreover, these cases are not mutually exclusive. A more general DSL could be developed for overall game design using FPCTAPI, along with more specific DSLs for use by domain experts. In any of the above cases, the DSL or DSLs would almost certainly require significant maintenance in addition to the initial design and implementation efforts. This could be due to a future desire for additional features, deficiencies in the original design, or any number of other reasons. Full adoption of a DSL-based solution would be a large-scale project, with significant potential impact to schedule and manpower requirements. DSL adoption is by no means a trivial activity. Additionally, these increases would be directly affected number and scope of the DSLs used. Figure 4 contains a block diagram showing how FPCTDSL would be used in conjunction with FPCTAPI across multiple engines. FPCT code is written in FPCTDSL, which in turn calls the FPCTAPI described in the previous section. Andre Furtado, a Ph.D. student at the Federal University of Pernambuco in Brazil, has developed a visual domain specific language and toolset called SharpLudus 3 that can be used to create two-dimensional games of moderate complexity. While the games created by this framework are clearly orders of magnitude simpler than FPCT, it can be viewed as a sort of proof of concept. SharpLudus uses the FlatRedBall game engine, along with Visual Studio and Microsoft's XNA framework. The latter two show that this approach can make use of widely used production-level tools, as opposed to custom-built academic research software. While DSL(s) developed for the FPCT project would be designed to interface with FPCTAPI rather than a specific target platform, the SharpLudus case demonstrates that such integration is indeed feasible. 3

9 Figure 4: Using FPCTDSL in conjunction with FPCTAPI across multiple engines. Advantages DSLs allow for rapid prototyping. Furtado's results show that, once implemented, he was able to use SharpLudus to produce fully working game prototypes in a fraction of the time and lines of code that it would take doing it manually. This could allow FPCT to both react quickly to customer changes, as well as present more choices to the customer up front. The DSL approach allows flexibility, as tasks that are not easily done in a DSL can still be done by using FPCTAPI directly. Software configuration management tasks will be simplified, as developers will not need to keep code changes consistent across different versions of the project. Only one codebase will need to be maintained. DSLs also provide a lower barrier for developer entry. A sufficiently high level of abstraction would allow developers and subject matter experts not fluent in C++ or UnrealScript to contribute directly to the code. DSLs could also be used to aid in the development of graphic tools for working with the API. Development tools target the DSL, or target the API directly, to simplify development. In particular, tools for more specialized DSLs could be developed to allow domain experts to add content more easily.

10 Disadvantages Development of one or more DSLs and the associated framework would require a significant commitment of project resources, and would be a research challenge. Program personnel would need to learn to develop in FPCTDSL, and DSLs would need to be maintained. Additionally, a degree of uncertainty would be introduced into the project. A DSL would need tools designed or modified for use with it, which would add to the resources necessary for development. Conclusion In this paper we have presented a variety of approaches that can be used to move FPCT towards platform agnostic development. Each approach has advantages and disadvantages which must be considered in conjunction with project priorities. A short project lifespan with few projected engine changes may dictate using the library approach. A longer project lifespan targeting many platforms might be better served with the middleware API approach, due to the ability to amortize the significant development costs across several platforms. A desire for an enterprise-level solution may result in the development of a middleware API as well as an associated domain specific language. An incremental approach may also be adopted. For example, the library/api approach could be used for current development of FPCT proper, a DSL solution adopted for tools used to import cultural data, and a middleware API developed for future FPCT development. The need for cultural training is ongoing, and is certain to outlast the current generation of engines and platforms. Given the current assumptions, the recommendation is to create a middleware API as part of a long-term cultural trainer strategy. This will facilitate the adoption of new technologies, engines, and platforms without sacrificing FPCT work-in-progress. The use of FPCT-centric domain specific languages would complement the middleware API, increasing productivity and allowing subject matter experts to participate more directly in development.