Rick

But games have been and continue to be made this way, so it is being used in practice today in the industry. Some of those articles talk about a few games that have been made with this design. When a person starts getting into a medium to large game things become unmanageable very quickly. That's what this design tries to solve. It breaks things down to very small isolated (to some extent) components that become easier to maintain/create. I have done the very simple designs in the past, but when your code base grows to thousands of lines (and it will most likely), it gets harder to make changes without major hacking and/or just giving up because it's to much of a pain. I haven't implemented this system yet, but I do agree with the reason for it because I've ran into the same issues in the past. That being said this isn't really for anything like a tetris or breakout clone although you could, it's probably overkill for that type of game. I am excited to try and implement this with my zombie game, but I haven't had much time for programming it lately. No doubt it's a different way of thinking and will be hard at first to get right, but will be fun and interesting to try. I do think this system would be best supported in C# where specific components are in their own DLL's. Then you just reference what component dll you need to build a game object. Could be done in C++ that way also, but C# just makes it easier to make and use dll's.

I worked on water patches some but never go to much into it. I just made a plane that you could size in the editor. My idea for the underwater effect was more to use a body in the shape of a cube and when the camera is inside the AABB of the body it would trigger the underwater effect.

I'm a fan of this structure, but it might be more useful for 3.0 if it ends up being object oriented. http://www.truevision3d.com/tvdna/

From my understanding the C# implementation of LE is slightly different than anything else. It would be more like LEO, but I think it's even different than that.

Yeah, back when I was looking into DX everything about it was kind of a pain. It's like Win32 API programming. So many damn structures that have 30 fields that you need to fill out and pass to a function along with 12 other parameters.

Are you sure it's the actual boost library in VS 2010? If I google VS 2010 and boost it seems people are still trying to build boost for it. Why would one have to do that if it was already in there?

It seems VS already has this. I wasn't aware as I never used it and never looked into it before.

wow, nevermind.

PointEntity (I think is the name) can do this also over time.

I can't seem to get that working. The .pak file reads in fine without a password, but with a password I get Zip data error with that syntax. I place it right after the Graphics() call. The way I make the password is right click the .zip file and select explore. Then from the file menu there is a set password command. Not sure if there is another way or that's wrong or something. SetZipStreamPassword("Swat.pak", "password");

Or Josh could try to see if it works and if it doesn't he could fix it OK, OK, I'll do that and report a bug if I can't get it working.

I thought that also, but that seems to have been fixed. Another post I had Josh said it was fixed and if I zip the lua files along with the model and don't give it a password everything works fine.

I only have 1 pak file at the moment for testing purposes. I just zipped up 1 model and it's scripts, textures, & materials and gave it a password then renamed it to pak, but I get Zip data error on the console when loading them.

Still looking for someone who has done this before to lend a hand. Would love to get a game demo out but need to know how I can do this.

What's the idea with how game objects communicate with each other?

I assume the DX support is for XBox.

I use a "portal" object in each map. When the player touches this invisible portal (trigger) it tells the main code the name of the next map to load. This portal object is placed in the map via the Editor and has a property for next map name. The code for loading a new map is in my main exe and not Lua. Kind of like HL did it. Z is 4 Zombies uses this and a criteria system to open a door that leads to the portal. When all victims/hostages are saved, if triggers a door to open automatically. Behind the door is the portal trigger to load the next map.

The problem is the AAA game industry has put all their chips on C++ and so it becomes the "standard". Any other language (not just BMax) will have a hard time breaking into "mainstream" for games, or anything else for that matter. The fact that BMax2 will run on anything won't really matter much. Linux is a pretty good example of this. Linux runs everything from wrist watches to massive servers, yet it sits back seat to other OS's. If it does it all and can run on anything why would that be? Maybe if BMax had more promotion it could take off? Agreed that at a functional level it would be the same as it is for us. I think Josh mentioned something about these other hardware devices that he's aiming for use C++ and so if the engine was in C++ it would be "easier" for him to get LE working on a wider array of hardware since C++ is a very standard and popular language. Sounds like BMax 2 will be able to run on a wide array of hardware also, but it doesn't seem to be complete, so putting eggs into that basket wouldn't be wise. All that and I think investors are probably saying what is BMax? Which may suck but it's reality, and money makes the world go round sadly.

Yeah, I could add an attribute in the component class in the ctor for enabled or not. That way each component will by default have this attribute. Then the Update() method can first check if that attribute is enabled or not for the children and not call Update() if it's not enabled. That should give the result.

I'll 2nd that. Never heard of it until LE.

Would depend if the component is just swapped for another that is the same name (or has the same interface) because at that point the components shouldn't care and everything should just continue working. I wouldn't suspect components would be removed completely at run-time but instead just swapped for other like components.

Yeah that's good. The problem I have with that is that community people come and go. C# is a good example because Tyler left for some time. If the people updating these languages doesn't have a deep invested interest, to me it's just not official because they can walk at anytime for whatever reason. Not that Josh can't walk either but he clearly has a deep invested interest since money is involved. My assumption is that (not much) money really is involved with these other languages being updated.

Ah ok, cool. I just remember them being out of sync which didn't seem official to me. It's my biggest fear with C# currently.

Yeah, from the way I see it not many components would truly be standalone. So you are right. However, how you expose these dependent components becomes the topic at hand then. 1) Directly place a child component pointer into the component that depends on it. Very straight forward and easy, but requires you to pass these dependent components directly to this component somewhere. Then this component has the actual class name of dependent component so if you wanted to try a different component you'd have to alter the containing component which isn't good. You could store pointers to just the base component class. You still have to pass in the pointer to that component somewhere. This would put the dependency checks on the person assembling the game object instead of the components checking while they run. I can see both good & bad there. 2) You can do the way I did it, where every component can query for every other component that share the same game object they are attached to and either use a message function or events. 3) You can use "interfaces" to determine the interface that a component is expecting from it's dependent components. This seems like a mix of 1 and 2. You could store pointers to that interface and shouldn't be that big of a deal. I'll play around with that once. That might be a cool option. C++ doesn't have interfaces. You can kind of simulate them by making pure virtual classes where the derived class needs to provide the body of a method though.

From my understanding LEO usually lagged behind in API updates because someone from the community updating it (much like C#). To me that's not "official". If these languages were official every one of them would be updated with each API change. MS doesn't release a new version of .NET and only give the new features to C# and say VB.NET will come later by a couple guys who update it for us with the changes we made. Each languages MS officially supports is updated with the changes before release BY MS. That's where I'm coming from with all this anyway. So really BMax and the C interface would be official.