Rick

OK, sounds good.

Well I guess I wasn't considering this a competition but I can see how it could be seen that way. I don't plan on hitting any sort of strict timeline or anything like that as this is my spare time that I'm working on this, so the time spent isn't very constant. For me this is more about trying to find a new way to allow non programmers to create games with functionality without typing any code and without being restrictive like a FPS creator would be. The bad thing about this design is that it really requires editor support that the current LE editor can't provide. So I'll be creating an editor around this design to aid in the creation of the game object components visually instead of directly via code or xml files. The editor basically will generate the xml files from visual feedback from the users. That in itself presents a ton of challenges.

@ZioRed Each gui element would be it's own game object component. So you would have 3 game object components in your example. Then attach the correct component to each one. So you would have a panel game object, and 2 different button game objects. Then attach the PanelComponent/Behavior to the panel game object, and etc for the buttons. To me that is actually a simple example of how this would work. I don't really know what you other example really means. Could you provide a specific idea around it? Maybe that'll help me understand that example if there was more specifics around it.

I haven't. This is structure around how a game is to be made. It isn't a restrictive structure, since components can do anything you can imagine and anyone can code a component, but it does provide rules that need to be followed to provide common interfaces between components. This however in no way restricts any functionality ability though, so I'm happy with it. I agree that you can accomplish this easier with a class hierarchy. This approach is more about maintenance, flexibility, reuse, and code sharing. For me it's also about creating a framework for non programmers to be able to use components visually to create logic without programming. Plus an ability for programmers to create components for others to use. These components would be as plug and play that one can get. For me, this is a game engine design using LE as the graphics/input library.

It can be at whatever level you like it to be. Well, at whatever level the component writer wants it to be. Personally I wouldn't go to the level of arm component, leg component although you could if you like. The company that did the Prototype game (I think) used the class name Behavior instead of component. That name might better describe what a component is. These components are really behaviors. So that company listed a few behaviors they had. For example they had a HitReaction behavior component.The general idea I think is to separate out these different behaviors as components. As far as models go, one approach (the one I'll use) is to just have a 3DVisual component that has an attribute that stores the actual model. So if a game object needs a visual model you can attach this to it. That's important to see because that means game object components don't always have to be models in the game. They can be logical game objects also. @ZioRed, I think I need more convincing that a game object component would want more than 1 of the same component. I don't know if I'm sold on 1 game object component wanting 2 or more 3D model components attached to it. I'm just thinking of Unity in this situation and to me it seems like if you wanted that you would create a separate game object component, and then parent that to the first game object component. Can you think of any other situations where multiple of the same components could be used? The reason I'm hesitant on this is because currently with the 1 component type per game object you don't have to worry about giving anything a name. The way I'll have it setup is that you could give a name to a component but that was more stored for the game object components so you could have something like "player" and then be able to query that game object component via it's name only. Do you have a few other ideas of wanting the same component attached multiple times to the same game object component?

Yeah good call. Yeah I'll do this also. I think the way I had it was left over from one of the iterations of this design I did. That's the Type property. It's a virtual property that other components override. Components aren't given unique names like button1. They are stored per game object component as "Component.GUIButton". Per game object you would only ever have 1 of the same component type. Thanks for the plugin class. I'll put that in and use that directly. Very nice. So here is with the changes what it would look like to do this via code: // build the player from components. the player itself is just a component player = new Component.Component(); // create the components setting it's parent to the player component ComponentGUIButton.ComponentGUIButton button = new ComponentGUIButton.ComponentGUIButton(player); ComponentLoadLevel.ComponentLoadLevel loadLevel = new ComponentLoadLevel.ComponentLoadLevel(player); // make the link between when the button is clicked and the load level method being called player.Components["Component.GUIButton"].Events["OnClick"].Add(player.Components["Component.LoadLevel"].ExposedMethods["LoadLevel"]); player.OnUpdate(); Now, I'll come up with an xml file that describes the above game object and use that to create it. At that point the editor becomes a visual tool for build the xml file that describes all the game object components in a project. So basically a config file would end up describing ones entire game. This is really looking like a very nice system. A true separation of components that programmers can create and distribute easily for others to use easily. I'll have to create a few more complex components to see if I'm missing any vital issues, but so far so good.

So I've put my events & exposed methods to the test and it works!! This gives great ability to link events exposed via string name and methods via string name that the component creator exposes to be called. Component events are a dictionary with a key of string and the value is a list of a specific delegate sig. Component writers add the events they want to expose and in the OnUpdate() method would be where those events are fired. I'm finding this communication between components to be very slick. It really allows visual programming when put into an editor. Since everything is string based it's very easy to do in an editor without any need for components to need to know about each other. Here is an example of the button and load level working together. // build the player from components. the player itself is just a component player = new Component.Component(null); // create the components setting it's parent to the player component ComponentGUIButton.ComponentGUIButton button = new ComponentGUIButton.ComponentGUIButton(player); ComponentLoadLevel.ComponentLoadLevel loadLevel = new ComponentLoadLevel.ComponentLoadLevel(player); // add these components to the players list of components player.Components.Add(button.Type, button); player.Components.Add(loadLevel.Type, loadLevel); // make the link between when the button is clicked and the load level method being called player.Components["Component.GUIButton"].Events["OnClick"].Add(player.Components["Component.LoadLevel"].ExposedMethods["LoadLevel"]); So the last line is the magic. You can see that via strings I'm able to link a components function (that the component creator specifically exposed) to another components event. Since it's a list it can also be chained. So in the above example, when the GUIButton component reads that it's been clicked (which the component handles in it's update method) it's fire off the OnClick event. Since the LoadLevel component linked one of it's functions to that event, that function will get called. The result is that when the button is clicked the LoadLevel() method of the other component will get called. All this and the development of these 2 components know 100% nothing about each other. This information that describes game objects and their components and the links can all be in config files since it's all just string names. Each component will be it's own .NET DLL so in order to create them via strings I'll probably have to use some reflection. This is exciting stuff!

Holy cow. I've been using pointers for 10 years now and have never had my computer destroyed Smart pointers could be used. The whole Create(CREATENOW) thing is just an ugly design. I'll take an ugly operator over an ugly design

If Josh allows us to link statically then I would think that might help. Not sure how it works in BMax.

You could if it was return a pointer to the object and not a const, but probably wouldn't want to do that. I just hope the whole Create() thing from LEO goes away. I was never a fan of that. In any C++ library I have never seen anything like that. If you want to create something after a certain part of code runs you either place it after that code OR use pointers. There is nothing confusing about: Cube* cube; ... cube = new Cube(...); That's how it should work. Not this: Cube cube; cube.Create(...); or any kind of weird CREATENOW thing in the ctor. That's my vote anyway.

Well at this point for NA, it's a road block because he has to do this translation step. Really if he would have just used Phyre to start with he could avoid all that. It seems like it would be better to find the right tool for the job instead of a tool that doesn't really do the job but you like working with it. Like if I have to nail something but I don't like using a hammer but I like using a screwdriver it's like me modifying the screwdriver to be like a hammer so I can hammer the nail in. We all knew what LE was going in. We knew where it is heading but it's not there yet. So would seem to me that if you had a specific goal in mind that a tool you like using didn't support, then you would find another tool that did.

I think I also need a messaging system. The more I look at this in being in an editor the more I see that I need the ability to send messages when events happen. Since components & attributes are accessed via string this should be pretty easy to be dynamic in an editor. The idea will be to have a list of messages per event for a component. So when said event is fired it will loop through the list of messages and send them out to the given component. The message structure will be made up of the component name to send the message to, the message string, and any extra message data as a string. This would be interesting as the connectors between your objects and ultimately your game flow would be all preconfigured in the setup of your game objects and their components. A simple example of this in action would be when you press a button to load a scene. You create en empty game object. Attach the GUIButton component to it. Then attach a LoadScene component also. Then you provide a message to the GUIButton component OnClick event that'll send a "load" message to any "LoadScene" component attached to the game object. The GUIButton's OnUpdate() looks for the button area to be clicked. When it does it fires it's OnClick event. The GUIButton's local OnClick event has this message that says call "LoadScene" game objects OnMessage() method passing to it the message of "load", with extra data as the scene to load. I think this will be my first "real world" test with this.

Make sense. Yeah, I guess it would be easier to just write LE commands on top of Phyre since your game is mostly finished. This is where it would be nice if all game logic could be separated from engine specific commands somehow.

I agree. So why not just program in it and skip the LE part NA? I can't figure out why you are using LE then.

Was anyone working on the LE control? The control that let's us have an LE "window" in a control? Last I checked it was kind of bugged with the framework right? Does anyone know the status of this thing?

Well that sucks.

hmm the wiki says "PhyreEngine (also known as Phyre Engine) is a free to use, cross platform " So it says "free to use". So couldn't you use it for free?

Ah ok. So the lines of what is really LE vs Phyre are pretty blurred. You basically implement LE's command set with Phyre. Then you can code with LE commands but really the code underneath is Phyre. I've never used Phyre Engine but it kind of just seems like you could use it instead of LE, no? It seems to support all the major platforms.

Yeah, that is one of my concerns. Adding that on top of using C# and speed will take a hit, but I wonder how much. Per component object it's probably best to keep the attributes/properties to a minimum and the data that's just needed internally to do the stuff for the component that doesn't need to be exposed to be normal variables.

The more I look at your code above the more it looks like the Lua implementation that Josh did with the new LE version. You are using BMax instead of Lua though. Was that the idea behind what you were trying for or are you allowing multiple scripts per game object?

I really really would prefer to use C++ but .NET just makes things to convenient.

I'm actually looking at implementing mine in C# now. It would work great for an editor. Each component is a dll. Drop the dll in a folder the editor reads. It dynamically loads the dll without even closing the editor. Now the component is available to use to build game objects. That'll be the general idea anyway. Doing that with C++ would be ugly. If you build you components generic enough you will have a nice library to pick from for other games. If you build an editor of sorts like I was describing above making different kinds of games quickly would be possible. The component method is all about easier maintenance and flexibility. That's really all it is. People who have used the OOP way have found when plans change and/or projects get massive things get out of control. You either hack changes in or end up reorging things all the time. Most of the time a nice hierarchy design just ends up getting ugly. Objects end up with a ton of stuff they don't require leading to bugs and such. That's why this method was created. To avoid that. That's not me talking, that's me explaining what the articles are saying. I'll let you know if that's true as soon as I get my system up and running.

Very cool. How is this working though? What is really happening under the hood with this?

Actually I was more thinking a library of components could be written which make it easier to make a game by plugging in components that people have created. Like someone could create a first person movement/camera component and someone else could make a third person etc. Then people could plug in what one they wish to use for their player game object. People could create weapon components that we could plug into game objects etc. I know, it sounds like a fairly land with rainbows and such, but oh well.

It might be a fun project to have some community members create components. Since the idea of this design is separation it should be possible and pretty easy to do this without people having to know much, if anything, about the other components. Plus most components shouldn't be that hard or long to write since they should be smaller. I'll put the component class in a library and write some basic components and see if anyone else wants to give it a go.