DROD

2. DROD Koifman Eran Egri Ozi Supervisor: Alexander Arlievsky

3. The Problem • Open source projects developed by independent developers tend to be “Spaghetti” projects. • Traditional games define a closed set of features and object. In order to add a feature or a new object the “traditional” game’s source code must be altered.

4. Project Goals • Creating a new .NET platform for the game. • Creating a generic platform which will enable the users to assimilate new code into the platform without changing the source code. • Develop a platform which will not be game specific.

5. Solution Overview • Creating a base infrastructure which will provide common features and services for external objects. • Creating objects which will be assimilated into the infrastructure at run-time. The assimilation does not require changing the infrastructure source code. • Creating a simple interface which will enable the user to add new features and objects to the infrastructure.

6. Solution Overview • Implementing DROD object and features in order to demonstrate the infrastructures capabilities. • Creating the DROD 2D world in which the DROD game will be played.

7. Creating a new unknown type of object and assimilating it into the infrastructure. Factory object. Using the .NET reflection. Inheritance from a basic object known to the infrastructure (BaseObject). Problems And Solutions

8. Communicating between the infrastructure and the unknown objects. Communicating between the unknown objects. Message based communication. Each objects will contain a mailbox. Creating an engine which will supervise the flow of messages. Intercommunication

9. Generically creating and assimilating different 2D worlds into the infrastructure without changing the infrastructure’s source code. Screen Creator object. Screen Sequence object. Map Manager object. Screen Manager object. Creating The 2D World

10. Creating new feature and behaviors and ascribe a certain behavior to an object. Dynamically changing objects’ behaviors at run-time. Handlers associated to messages. Handler Manager object. Associating preliminary behavior to objects using a simple text interface. Object Behavior

11. Searching an unknown object in the infrastructure at run-time. Searching according to features. Searching according to object type. Yellow Pages object. Unique ID given at creation. Categorization according to implemented interfaces. Finding Unknown Objects

12. Saving the current state of the infrastructure and the unknown objects within. Restoring the state and the objects at a latter time. Serialization mechanism. Multiple file usage. Clearing the current state and restoring the saved state. Saving And Restoring States

13. Creating a multi-threaded infrastructure. Protecting critical sections. Threads for players, decoration, monsters, and engine. Mutex protection on the infrastructure critical data such as Map Manager object. Multi Threading

14. Creating object priorities. Creating Message priorities. Manager and supervise the timing in the infrastructure. Message priorities in the mailbox. Object priorities according to implemented interfaces such as “IPlayer”, “IDecor”. Timing using the Engine object. Timing And Priorities

15. Future Development • 3D Engine. • Network support. • Input devices support such as joystick. • Editor environment which will create new worlds.

16. Older Development Environments Versus .NET • Reflection mechanism in .NET. • Portability in .NET. • Extensive GUI support in .NET versus MFC. • Extensive object collections in .NET versus STL. • Problems with the serialization mechanism.