Search the Community

The Goal: To be able to open a world of game functionality to non programmers, and to allow programmers to create this functionality. To give drop and drag with configurable functionality without restricting possibilities in any way. The Design: This approach uses the component design along with an attribute design. The attributes represent the data a component wants to expose. A component is a smaller behavior piece that is attached to a game object. Components expose events. Events drive everything in this design. It's the cornerstone for component communication with other components. Components themselves are completely isolated from each other. Inside a component it only knows about itself. The exception to this rule would be a factory type component that creates things dynamically. This type of component would store the game objects it creates dynamically. F.A.Q. ===== Q. If a component doesn't know about any other component, how can we create game functionality with these components? A. Components are made up of 3 pieces. Attributes, Events, & Exposed Methods. Attributes are data that the component wants to expose to other components giving them the ability to change. Events are fired by components when certain things happen. Components have a set of default events, but the component author creates event relavent to their component also. In the component code, they define what causes an event to fire. For example a health component might fire an OnDead event when it's health attribute reaches 0. Exposed Methods are the functions that work on that given component and are exposed for other components to call. So let's say we have a spot light component. We might give an exposed method called TurnOff, which basically turns off the LE spotlight entity that's created from this component. So the functionality is created by linking events of one component with methods of another (or itself). Since Attributes, Events, and Exposed Methods are all accessed via their string name, this makes it really easy to create a UI to make this very easy. The results are stored in xml files. Q. How can I handle game objects that persist through scenes? A. This is a good question and something that bothers me with some other engines. Game objects in other engines seem to be focused in the scene only. The solution with this design is to only change 1 thing. The scope at which persitent objects are created. Everything else stays the same. I call these global game objects and they are created at startup and stay in scope until the end. Game objects in scenes are loaded and unloaded with the scene, but global game objects stick around. Global game objects are also usable in every scene in the game. Nothing about global games objects change between scenes. Q. How do I program a component? A. You use C# to create a dll. Derive from a base component class that provides some basic functionality like creating events, attributes, & exposed methods. What this component is and does is 100% up to you. There will be a fine art of making components. You don't want to go to low level or high level with components. Finding a nice middle is preferred. A component ideally is some kind of general behavior that can be reused. Examples might be: MousePickComponent - A component that is looking for being picked by the mouse and fires events when it is. You could attach this to any game object that you want to be mouse picked. LoadLevelComponent - A component that loads a new scene. GUIButtonComponent - A component that looks for the mouse being pressed down and within a certain area on the screen and fires an OnClick event when that happens. A very primitive setup of this has been create to validate it. I will be working on getting the editor up and looking more professional.