Jump to content

Rick's Blog

  • entries
    65
  • comments
    96
  • views
    24,768

PiE (Component & Attribute design)


Rick

2,537 views

 Share

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.

 

 

med_gallery_112_32_2199.jpg

 Share

7 Comments


Recommended Comments

Rick this is awsome! Do you think it would be better to lay it out graphically like Kismet or the C4's script editor. I may be wrong, since it seems your really not done with this, you may have even better plans for this btw. Keep up the good work dude!

 

Looks like you've got this covered.

Link to comment

Hey Kevin, yeah I was thinking about that the other day. As I was trying to figure out how to make the UI it hit me like a ton of bricks that this basically is how flowgraphs probably work. A flowgraph UI to support this would be ideal and the final goal, but for now it's easier to just make the links between events and functions with a grid control. Making the UI for flowgraphs will be a little more involved but once I get this worked out I'll take a look at that.

Link to comment

I really like it. this way level designers can add functionality in a much quicker ratio and events can be edit in an easy way.

Good stuff rick.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...