Rick

There is 1 phy file per model. If you have 5 instances of a model that you've scaled to 5 different scales, how would the 1 phy file represent all 5 instances?

I think visually, if you have physics debug on, it looks like it's scaled, but collisions don't act correctly to what it visually looks like.

Even if that rescales the body of the model, you might want to stress test collisions as I believe it'll look like the body is rescaled but doesn't act correctly. Again I'm not interested in testing this currently, just letting you know to take caution because I seem to remember scaling and newton bodies not working nicely together even if it looks like the body is scaled.

So you add this functionality to every object that you need scaling on? I assume you handle scaling the model when you load a scene then too not just when you set the property? Sounds like physics bodies in Newton can't be resized so this could cause issues around that and collisions.

They have some system where people vote for features and if it gets enough votes or whatever, they will look at implementing the feature. I know at one point the flowgraph was pretty close to having enough votes. You have said yourself that Lua won't store all your code for all aspects to a game. Given that, it would seem that we would then still need a good structure to use C++ libraries that the community creates from inside Lua. Do you plan on supporting such a structure? If not then community libraries, which we need so bad, probably won't be created that work from inside Lua and with you putting all your chips on Lua that's not good. I think you have to look at the entire picture of making a game from start to finish and if that still includes C++, then give the community something to work with as far as integration between C++ and Lua.

Oh OK, I guess I was still stuck on the game programming side instead of graphic techniques. I don't think there is much question about the graphics direction LE is going and how everyone loves it. Looks like the majority of this thread was about the game structure direction.

Around that line, copying existing entities and created other instances that have all the same scripts attached for dynamic creation via code.

What route would that be and how is it different?

What Pixel just said sums it all up. You have to promote integration and the way you do that is by defining a basic structure for others to follow first. This has to come from the creator. At that point it doesn't matter what language you use. Once you have this structure your tools can be built around it to help aid people in following that structure. This is exactly what Unity does and it works. This is the successful strategy for any game engine and it can't be ignored. The issue with Josh putting all that structure on the Lua side is that if we can't create the entire game in Lua, then you still leave this big open non structured path with C/C++. The structure has to be consistent between any language used to make the game.

I believe Josh's argument to this is the physics file that gets created and how you can't scale bodies. There are work arounds however but I think he mentioned that he would make this available in LE 3.

Unity does define a structure though. You are to derive your classes from a behavior base class which defines methods you can override and they are called by the game engine. It also gives you a way to piece things together. From a programmers point of view giving us a predefined structure might not be require but he's looking at the masses here. Because Unity has defined this structure programmers feel comfortable to make libraries that they know can easily be integrated into other peoples projects. You and I probably don't want a structure forced on us but you have to admit that without that common structure it makes it difficult to share code without the user of the code making modifications to it to fit their structure. Now if a person newer has to do this they probably won't succeed and gives up or worse learns about this before even buying the engine. Josh is trying to make money by appealing to the masses.

I think that looks good. I wouldn't call the scripts that can be attached "actors" though. I would simply call them what they are, scripts. That seems like a very common task so would be better if it was enclosed in some kind of global helper function somehow like CallMethod("Hurt", dmg) or FindMethod("Hurt")(dmg) or something like that. I think each "actor" or script should have a default name that gets assigned by the engine and it's the script name minus the extension, and then we should be able to FindScript("name") on any entity. FindEntity("name"):FindScript("name"):Hurt() or something like that. The ideal way for doing this I think would be to have "actors" have exposed variables that we can set via the editor and it would do something like: self.myentity = FindEntity("name")

Well, Josh had to go get all serious on us

If your goal is to attract non programmers who have money then I think you have to do flowgraph for coding the entire game. It might end up crappy and limiting (to us programmers) but those non programmers will eat that stuff up and fork over the cash, because it'll make them feel like they can make the next Crysis. FPSCreator may have more games created last year, but I promise you 99% of them all "suck", but hey, they are all paying customers so who cares right. I'd still venture to say they had more games created because they define a game structure to follow. Be it a programming structure or a non programming structure they had something to go off of and people could make libraries that would fit and be reusable because there was this common interface defined for them already.

I agree with this, but interestingly enough you are putting your chips on Lua being the way to help solve this. I don't know where you got that idea that another language will make this change, but I'd venture to say it won't. People want a structure to follow and they don't really care what language they do it in (well some do). You have to provide a basic structure for how games will be written in LE to get games made (at a general level as there will be exceptions). All these other engines provide this, which leads to programmers wanting to invest their time in making libraries that support this structure and so people who have the determination to finish a game use these libraries to actually make a game. An indie person just can't be expected to write all the pieces that go into a game from scratch (again, the majority of indie ppl). Every game engine has a well defined game structure defined for people to use and extend. That's what makes it a game engine and not just a graphics library. Your fear might be that you don't want to make a FPS Creator but the fact of the matter is if you want to be seen as a game engine and not just a graphics library you are going to have to define some kind of structure that people use and not just a language. He's right about the community being the one to help, but gamelib is a complete unorganized mess because you, Josh, haven't defined any kind of structure for the programmers to follow. So that's what you end up with. Everyone does their own thing and nobody wants to share because they know it only works in their structure they've created. I don't know if you've done a poll around this, but instead of making your best educated guess about why you think games aren't being made with LE, you might want to poll the people who are actually trying to make them.

Now that's a quotable line right there. Love it!

Oh man Paul, low blow, but funny.

The command doesn't even make sense. It should take a parameter with the game type you want ie. MakeGame("FPS"), MakeGame("RTS"). That would allow it to be much more flexible. Better yet if should be able to take an actual game title and a clone of that game will be made: MakeGame("Crysis"). He should make it return a string that picks from some random smartass comment.

http://dl.dropbox.com/u/1293842/hud.jpg Let's say there are 2 images at work. One image is the circle the other is the rectangle. Now even the circle image is really rectangle but it has transparency in the middle on at the corners. I want to draw the rectangle first, then lay the circle on top BUT I want the corners of the circle to somehow mask the rectangle image that was drawn first so you don't see those, but I want the middle of the circle image to show the rectangle behind it. This is all in 2D land, not as a texture that will go on a model. How would I do this inside LE? I assume I have to use some OpenGL drawing? What's this technique even called?

Check out GetEntityTarget

And you are only doing art assets at first right? I think you mentioned that before just confirming. This also doesn't include actual games I assume?

What a random comment to make that game lol. I have a multiplayer stratego game drawn up. Letting it sit for a week to see if I'm still excited about it. Trying to finally put together everything I've learned so far to finish a product and I think that has a good mixture of easy and hard and fun to complete. Of course it wouldn't be anything amazing graphics wise that showcases LE's abilities.

That screenshot is a classic piece of history that will be shown 20 years down the line when LE is a billion dollar company

I would almost prefer that so it's more explicit to what you are doing. Like you pointed out this leads to issues when Hurt() is defined in 3 different scripts attached. Prefixing the script name of 'player' removes that issue. If you want to have a way to call multiple functions with the same name in different scripts I would keep your SendMessage() method of the entity and instead of firing a ReceiveMessage() it fires the actual method name. That would still give the ability to call all similar named methods if needed because that could be valuable if you need to inform every script attached. You would just make it not return a value, and I think Lua can handle the dynamic parameter count. Why only some? You would be able to interact with every script attached to the entity.

Right, I assume the programmers kind of have to pull the artists back some and make them realize this is all to run real-time and so shortcuts have to be made. Well, I wouldn't say "just" as it's a pretty big deal in games still and LE doesn't have this functionality yet. That seems strange to me. You are essentially making keyframes from entirely different models (even though it's basically the same model with verts moved around it's still a different model in your example). Why not just allow vert manipulation and take a snapshot? You would save disk space by just storing the different verts from keyframe to keyframe.