Rick

Not that it's a huge deal, but that seems kind of hacky. Would seem better if we could just check the Mesh object against null.

I like something like Entity.Children["name"]. I think that's nice syntax.

Does LE even allow displacement maps? I'm still fighting for maps to be able to make 3D geometry on the fly. I think that would be very cool and the displacement map seems to always do that to some extent.

Well, it is a level editor, but not really for LE. I use 3DWS to make the basic level shape like floors, walls. Then I convert the file to the gmf model format (LE's model format). At that point it's just a model that I can include in the LE editor. I do this because I don't know how to model, and 3DWS is much easier to make these basic shapes than using a true modeling program. The shell/meat/whatever you want to call it, of a level can be created with a tool like 3WDS. Then in the LE editor you would include other prop models and functionality in Lua if you like.

Doesn't .NET 4.0 get installed on XP or Vista in some Windows updates?

I tend to agree with Laurens. I feel the future is where near everything is virtual. Brick and mortar just can't survive the future, and really it shouldn't. By not having physical locations we are reducing our footprint on earth, which is a good thing. A good chunk of what we do today is just because there were no other choices available at the time, but that's not the case today. There are better choices now, but when we change it everything feels like it's wrong or won't work. When someone says library buildings need to go away, people get sad. Why? There are better ways to do a library these days. Less intrusive on the earth and more convenient for us ways. When someone says paper books should go away people think it's a bad thing. Why? We have better ways to present the knowledge than cutting down trees and printing on them now. Let's use those ways. The pricing model of games is the same thought. If this method becomes a better method to distribute games, then we should use it, even if that means things change. There is no doubt in my mind that publishers hate this new method because it doesn't really include them in the capacity that they once were needed.

Has anyone done the basic camera look functionality within this control? I can't get it to work. Something like the FPS lua file where it lets you look around with the mouse. Since it's in a control some things like GraphicsWidth/Height() and MoveMouse() won't work. --Camera look gx=Round(GraphicsWidth()/2) gy=Round(GraphicsHeight()/2) dx=Curve((MouseX()-gx)/4.0,dx,3.0/AppSpeed()) dy=Curve((MouseY()-gy)/4.0,dy,3.0/AppSpeed()) MoveMouse(gx,gy) camerapitch=camerapitch+dy camerayaw=camerayaw-dx camerapitch=math.min(camerapitch,90) camerapitch=math.max(camerapitch,-90) fw.main.camera:SetRotationf(camerapitch,camerayaw,0,1)

I can only assume that it's the game companies who wouldn't allow the $50/mo play everything idea. Most likely old school executives reluctant to move away from their model of needing to get $50 per copy. I just read that we needed to purchase the game on top of the monthly fee. Screw that. There is no point in me doing that. I can run new games with the graphics turned down on a 5 year old PC. $5/mo with this in 5 years is $300. I can buy a kick bum new graphics card for that, which will last another 5 years. Sounds like another case of technology moving faster than executives. That sucks. It also seems like from what I gather you are in a pretty populated place with fast internet speed and you even noticed some lag. Me living 45 miles from a major city probably means I'm screwed.

Keep in mind that programmers will be creating components so it's not just for artists.

Yeah, that's kind of the cool part about this is that components can really be anything

@Pancakes, yep. The way you would make a basic character game object is by starting with an empty game object. Then add all those components. Then you right click that basic game object and click "Make Prefab", and from now on you can add your "Basic Character Game Object" by just a menu option of Make Prefab->Basic Character (if that's what you named it). I also introduce global game objects, so not everything has to be part of a scene. One of the issues with LE's editor is that everything is at the scene level. Most every game has global (non scene) level objects as well. For example the player object would most likely be across scenes, so instead of having to add the player object in every scene and worrying about what they had in their inventory and such things, you just make the player object a global game object, and now it'll maintain all it's data between scenes. A component would then be created that could set the position of the player game object and that's what would be added to each scene and on it's OnInitialize() event it would set the player's position to where you want it for that scene, but the player object would be the same as it was last scene so you don't have to worry about inventory items they had or any other data between scenes. Nice and simple. My first test scene/situation that I'm making is a global player object that has a controller component, fpscamera component, & health component. A scene that has a trigger component attached to a game object named death_trigger (will create a physics body). I'll set this trigger attribute of what it cares about to fire it's events to the player. Then assign the OnEnter event to link to the players health component's Kill() method, which will set it's health attribute to 0. Then link the players health component even OnDead to the fpsCamera component's Dead() function which will fall the camera to the ground and tip it sideways. Will also link OnDead to the controllers Disable() method so the player can't move anymore, and link OnDead to a timer component, which will set a chain of restarting the scene. This shows that one event can be linked to many different methods to create a complex interaction of events. I'm excited

Not so much per entity, but per bahavior. One could also have multiple behavior classes in 1 dll if they wanted to maybe make a package of behaviors.

You act like this is the first time you've talked to Lumooja

So I was able to get prefabs working with the component design. It's really easy too! A prefab is just an xml file that describes the different components and their attributes that make a game object. For example, in the editor I added an empty game object to my scene, then attached a spotlight component to it. This provides spotlight functionality. It creates an LE spotlight and exposes some attributes to control the spotlight. I then right click the game object and choose Save As Prefab. I provide it a name (SpotLight) and it saves an xml file named SpotLight which has the components required for that game object and saves the attributes that were set. Now when I go to add a game object I have another menu option named Prefabs, which lists all available prefabs. SpotLight shows up! I select it and it adds a game object to the scene and automatically attaches the spotlight component to it and sets the default settings. It's that easy. Distribute your prefab xml file and any component dll's that depend on it and people can add your game objects to their scene with a click of a button. The editor will also validate if a dependent component is missing or not and inform you of the missing component. This is getting exciting More to come!

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.

Yeah, but VS 2005 and above has what I would consider a "normal" foreach. One that doesn't require a function. One that is inline. I didn't know that before.

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.

I assume these towers are created dynamically by the player?

What type of functionality are your towers doing? Just want to make sure that the component method is able to handle all sorts of requirements. So if you wouldn't mind the idea behind your towers and the interaction they have that might help me validate that my design will work in various needs.

This is the reason I'm making this component based system. Like you pointed out above: "To far in to make such a big change now though", this is often the case with hierarchy systems. It can take a good deal of work to rework a hierarchy. With the component design I have you would create components that describe the behavior of your towers via a class. This would expose events, functions, & attributes. Then the communication between each other would be by linking events to functions between game objects. So in your case you would create in an editor x tower game objects. Then assign your tower component class to them. Now those game objects have events and methods. Let's say in the Update() method of your tower component, it's looking for a distance between it and another game object (let's say the "player"). When the distance is < x that tower fires off an event called OnFoundPlayer. Let's also say your tower behavior has a function called ShootAt() with an attribute of what to shoot at. In the editor you would link all your towers OnFoundPlayer event to each other towers ShootAt method. You would then set each towers shoot at attribute to the "player" game object. Now when 1 tower see's the player it's telling all the other towers that registered to that towers event, and the other towers can act accordingly. This is just an example, I don't really know how your towers are working, but this is the main idea behind my component design.

Oh for the love of god

Yeah, that's the way it works with pointers. The viable solution is to use pointers. If you do that you are not letting C++ determine when it gets called either. You control it with new and delete. Pointers solve your problem Lumooja. You should just accept them. They give you the control you are asking for Come on Lumooja, that is just insane. It doesn't become unreadable just because you have to use ->

?? I'm guessing it's not calling it at random times. I didn't test this but try storing pointers to your class in the vector. My guess would be that when adding via push_back() it's creating a copy of the class instead of the pointer to the class. I think it's kind of like passing any non pointer/reference to a function. Copies are created of the variable. If you use pointers I'm thinking it'll work. [EDIT] Yes, this seems to be the case. push_back() is creating a copy of your object, so once push_back() is finished that copy goes out of scope and so the destructor gets called, which makes sense. You can use pointers to solve this. That way push_back() is taking a pointer to your class, and no temp object will be created which means no destructor gets called.

Yeah, I was just questioning if VS actually used boost or not.

hmm, could you just have the Tower class hold a list of Towers that are linked instead of having the graph, edge, vertex classes?