The Engine Agnostic Interface design can be reviewed on the Google Patents site. This was my second major design project after Mission Control. The EAI was created to build a foundational platform for all our simulation and training tools. It acts as a hub for all entity and interaction data available for the simulation. This allowed ACI to build tools for network protocols, hardware interfaces, artificial intelligence, and user interfaces. The philosophy behind the project is leveraging the ever changing world of game engines with established simulation tools. The EAI's goal was to allow development of these tools without a large overhead each time a game engine generation lapsed. Originally the EAI was built around the concept of a single process. This introduced many challenges as our controlling application, Mission Control, would need to load an EAI core in order to communicate with the game engine. In this paradigm we were forced to recompile engines as DLLs and load them into the same space as managed applications, as well as mixed assemblies. A few problems sprouted out of this approach. We couldn't control global data from the engine interfering with memory within the mixed assemblies. Additionally, we realized that this approach required us to have access to full engine source code, which isn't always the case in government contracts. Finally, the extension system designed to allow ACI to develop simulation tools outside of the game engine where requiring more and more middle-ware which conflicted with libraries loaded with the game engine in the same process. With some clever use of Mission Control's management capabilities and hours hunting memory addresses from engine globals (who knew game engines weren't designed to be loaded as a DLL!) we were able to circumvent most of these problems, but we knew there was a better way. After working around this issues for quite some time, the second major version of the EAI was conceived. In this revision we moved away from the same process design and implemented Inter-process Communication through Remote Procedure Calls. The solved many of our problems with memory and management, while allowing us to mirror the Service Oriented Architecture of Mission Control. The EAI and its library of extensions are still growing today to meet the needs of various customer requirements. |