General
Q: What is FederationX?
A: FederationX is HLA-based architecture for the construction of large-scale distributed agent-based applications. It is the product of a multi-year Magnetar Games Corporation's research project into large scale agent systems and includes not only the core architecture but also a variety of demonstration, visualization and management components to simplify the development of complex, distributed applications.
Q: What are the uses for FederationX?
A: FederationX primary use is for the development of Distributed Simulation Systems and massive multiplayer online games. This architecture has multiple uses, however, and it can be applied to a range of different problems. Here are some of the domains that FederationX directly applies to:
- Military HLA-based Distributed Simulations
- Online Multiplayer Games
- Web-based Simulations
- Collaborative Development Tools
- Education and E-Learning Systems
- Information Repositories
- Extensible Runtime Engines
Magnetar Games has created four different project concepts, each of which can be implemented using FederationX. They are:
- ExForce - a role-playing strategy game
- Nebula - game network for board games and puzzles
- Pulsar - an online stock tracking and trading system
- Fortuna - a live casino embedded in a virtual world
Q: What is FederationX comprised of?
A: FederationX is comprised of four different layers that together form a complete system. The layers are:
Infrastructure (Super Peer Network)
- Nexus
- Guild
- Spire (optional)
Platform (end user)
- Tryst - a lobby client
- Chronos - a fully IEEE 1516.2-compliant HLA Runtime Infrastructure (RTI) network engine
- Mirage - a fully-functional 3D engine
- Realm - a distributed digital asset repository and directory engine
Tools
- Forge - a unique editor with advanced collaborative services that include chat, video chat, and instant messaging, and a special mode that lets the user test the changes immediately after editing (by running them in the product).
- Model Editor - a new editor that supports visual creation of IEEE 1516.2-compatible object models as well as MORPH models; used for military simulations as well as games.
Components
- FX Visuals - a set of Delphi-based components that provide for RAD of DirectDraw applications. These components will soon be .NET compatible.
- FX Frameworks
Q: What does FederationX stand for?
A: FederationX is combines terminology from the US military simulation and Microsoft PC gaming communities by merging the core "Federation" concept of High Level Architecture (HLA) with "X" from the DirectX family of game enhancement technologies.
Q: What is the history of FederationX?
A: FederationX is an implementation of MAGNETAR, itself an implementation of Collaborative Metaprogramming Framework (CMF) paradigm. MAGNETAR is being developed as an open standard by Magnetar Games, while FederationX is a proprietary implementation of it. In the long term, the management envisions the proliferation of third party components, implementing the open-standard MAGNETAR interfaces, which would be directly pluggable into the FederationX framework.
Q: How can I get involved in MAGNETAR?
A: We have an open forum on www.magnetar.org for general questions and specific technical discussion on MAGNETAR technology. Separate threads for FederationX-specific questions can be started.
Q: How can I add to or correct this FAQ?
A: Please send email to info@magnetargames.com.
High-level Technical FAQ
Q: What is an Agent?
A: FederationX Agent is a software entity that performs domain specific task. It is a pluggable unit to a FederationX engine. FederationX agent can be viewed as a 'knowledge source' that participates in a Blackboard system. It could also be viewed as a 'Federate' that participate in a single process Federation in HLA. Additional information on agent-based computing can be found at http://www.multiagent.com and http://agents.umbc.edu
Q: What is an Engine?
A: An engine in Magnetar architecture is a component module that performs a specific task in the system. For example, Mirage engine is responsible for implementing the 2D and 3D functionality in a system. An engine is essentially made up of a blackboard and a number of agents that act on the blackboard.
Q: What is a Blackboard?
A: A blackboard is a central component of an architectural pattern called the Blackboard Pattern. This pattern is highly applicable to systems that address problems with non-deterministic solutions. Non-determinism means that there is at least some amount of unpredictability associated with solutions for such problems. Blackboard architecture provides a modular solution approach to this class of problems. The main components of the architecture are: knowledge source, blackboard, and control. Knowledge sources are subsystems that could solve parts of the problem. KSs are modeled as independent agents. The blackboard is a shared memory repository that provides a central data store regarding to the solution space for all knowledge sources. The control component acts like a scheduler monitoring the state of the blackboard and dispatching the required knowledge sources to solve the problem.
A blackboard can be implemented as a Multi-Agent System (MAS) with agents as knowledge sources and control as a scheduler. The agents communicate solely through the blackboard by publishing data to the blackboard and getting notified of changes. In addition, MAGNETAR blackboard encapsulates MORPH information model and provides 'Model Service API' for agents to access the blackboard content. MAGNETAR architects the Blackboard system as a Multi-Agent System (MAS) that mirrors a single process federation in HLA. It transforms knowledge sources to federates, and blackboard to data store for MORPH information model which is parallel to OMT of HLA.
Q: What is MAGNETAR?
A: MAGNETAR (Meta-programmable AGent NETwork ARchitecture) is open reference architecture for building large-scale collaborative multi-agent systems. The highlights of this architecture include:
- Compliance with High-Level Architecture (HLA) specification developed and promoted by the Department of Defence (DoD)
- Use of meta-programming with XML scripts
- Use of the MORPH paradigm for information modeling
- Use of the blackboard problem-solving model
- Component-based design of modules
Q: What is Collaborative Metaprogramming Framework?
A: Collaborative Metaprogramming Framework (CMF) is a framework that lets users collaboratively create software products using templates for the corresponding product families. There are many abstract terms in this definition:
- Product families: Families of products are characterized by some commonality in their capabilities and/or design/implementation and/or the set of components they use. More generally, they target the same domain. For example, games like Chess, Go and Chinese Checkers can be considered a family of games called "board games."
- Templates for product families: A template for a product family implements just the commonality among the products in the family. Typically, it consists of several software modules that are parameterized. The parameters to the modules represent the variance among the products. For example, a template for board games may have parameters that may have different values for different games - for example, the board, the pieces and the games rules - while implementing common behaviour (such as the code for moving a piece from one position to another and checking if a move keeps a piece within the bounds of the board).
- Create software products: In FederationX, creating an actual software product from a product family is just the process of supplying the requisite parameters to the product family template. The process also involves supplying product specific digital assets such as graphics, sound and video, which are used by the product.
- Collaboratively: A team of users can cooperate over a network in the creation of a software product from the product family template. Collaboration allows people to combine their likes, dislikes, knowledge, and expectations for a system when creating a new software product.
Q: What is MORPH?
A: This is an acronym for "Metanode Organized Prototype Hierarchy." The idea behind MORPH is to specify a template for the organization of Information Models of computer systems. It is intended to provide a standard way for developers to produce domain models utilizing two powerful concepts - Meta-node and the Prototype pattern. One can think of MORPH as a meta-modeling language that can describe the models in the classic four-layer architecture propounded by OMG.
Q: What is Metaprogramming?
A: Metaprogramming is the process of specifying generic software templates from which new software components can be automatically instantiated by providing the requisite configuration parameters. Meta-programming greatly facilitates software reuse by producing "families" of software systems rather than a single system. A developer, therefore, writes a framework that can create varying software systems when supplied with different parameters. The meta-programs supply these parameters to the framework and instantiate a specific product from the generic framework. They are called meta-programs because they are little programs about programs.
Q: What is a System?
A: In Magnetar architecture, a System is a collection of Engines. A system offers domain-specific functionality to its users by assembling a group of related engine components and configuring their object models for the target domain.
Q: What is the difference between MAGNETAR and FederationX?
A: MAGNETAR refers to the Engine/Agent Interface Standards whereas FederationX contains a specific component architecture implementing MAGNETAR. MAGNETAR is a MORPH specification with language bindings, FederationX contains actual implementations.
Q: What is HLA?
A: The High Level Architecture (HLA) forms the technical foundation of FederationX. This definition is taken directly from the US Defence Modeling and Simulations Office (DMSO) website: "The High Level Architecture (HLA) is a general purpose architecture for simulation reuse and interoperability. The HLA was developed under the leadership of the Defence Modeling and Simulation Office (DMSO) to support reuse and interoperability across the large numbers of different types of simulations developed and maintained by the DoD. It was approved by as the standard technical architecture for all DoD simulations on September 10, 1996. The HLA was adopted as the Facility for Distributed Simulation Systems 1.0 by the Object Management Group (OMG) in November 1998. The HLA was approved as an open standard through the Institute of Electrical and Electronic Engineers (IEEE) - IEEE Standard 1516 - in September 2000." FederationX extends and pervasively uses HLA.
FederationX and other Technologies
Q: How is FederationX different than other Agent / P2P technologies?
A: FederationX is a highly configurable architecture with many capabilities, which makes it difficult to sum up. Here are some characteristics that we find unique: The FederationX Component Model allows a FederationX agent to be tailored from minimal single-host embedded applications to highly distributed heavy-weight applications. The service-based framework allows developers to add new components without altering the architecture APIs. The FederationX architecture is built with scalability in mind. FederationX adds the concept of agent-local blackboards, which abstracts the message transport from the application developer.
Q: What are the future plans for FederationX?
A: Magnetar Games is currently in the process of finalizing the architecture for the engines that will comprise the FederationX. The first engine to be completed is Chronos, slated to be ready for certification in August 2003. The other components will be completed sequentially after Chronos, with the final one ready by the 2ndQ 2004.
Q: How does FederationX compare with Grid Computing?
A: Grid Computing is a branch of peer-to-peer computing that utilizes spare cycles on distributed machines (i.e. "computer farms"). A classic example is the SETI@Home project . There are many grid architectures (Sun, IBM, OGSA, etc) that offer vastly different capabilities, from lightweight number-crunching engines to enterprise solutions. FederationX, as a flexible peer-to-peer architecture, could be used as a grid engine. The primary difference between FederationX and most grid engines is that FederationX developers often write autonomous, heterogeneous agents instead of anonymous computing clients.
Getting Started
Q: Can I develop proprietary products using FederationX?
A: Yes. Third-party products that replace components of FederationX are allowed, and in fact encouraged. The products will be subject to the terms of the FederationX license.
Q: What are the system requirements to run FederationX?
A: FederationX is still in the development stage, so the system requirements for running it will vary. The requirements will be updated as new information becomes available. Right now, FederationX will be running on Microsoft Windows platforms.
|