Josh

That looks right. Then in the editor you would drag the desired entity into the "target" parameter to set it. Alternatively, you could do this in C++: int i = entity->AttachScript("Scripts/actors/pointat.lua"); entity->SetObject("target",targetentity,i);

You must be running the evaluation kit. The real thing is located in "C:\Leadwerks Engine SDK".

Here's an example of a script that will make the entity's color oscillate over time: function actor:Start() self.speed = 1 self.color = Vec4(1) end function actor:Draw() local luminance = (math.sin(Millisecs()*self.speed) / 2 + 0.5) self.entity:SetColor(self.color * luminance) end Basically, I am thinking in terms of what Michael Betke could use. Not to pick on him, but programming is not his area of discipline, nor should it be. With scripts he can attach behaviors to entities and watch it go. Add a couple of these scripts with different speeds set, and you get a random but smooth change in brightness.

i don't believe they have a flow graph, which is where the whole design plan for le3 comes together, imo. I also am a big believer in Lua

Tessellation, multisampled deferred rendering, CSG editor, etc.

There's ExecuteFile(). LoadScript / RunScript is a little weird, because that is not at all the way Lua works. For the attachments, that should be no problem. As far as getting a copy of all the values set in Lua, that might be problematic, because some things you would want shared, and some things you would want copies made. I see this working out as you create prefabs, like in 3D World Studio. A prefab is an entity + whatever scripts are attached to it. Then you can call LoadPrefab() or maybe LoadEntity() to load the fully decked-out object, ready for use. So like if you had a flickering streetlight, you would just load the prefab, and have everything working immediately.

Here's a simple example that's working: function actor:Start() self.movespeed=Vec3(0) self.turnspeed=Vec3(0) self.global = false end function actor:Update() if self.movespeed~=Vec3(0) then self.entity:Move(self.movespeed,self.global) end if self.turnspeed~=Vec3(0) then self.entity:Turn(self.turnspeed,self.global) end end It's quite nice how easy it was to add support for the ~= operator overloading.

Your order has been processed. Thank you.

That argument is so bad it looks like a fake argument to make Unity look better. I respect the work David and Joachim have done. I've know them since before they came to the U.S. They've made some good contributions to the user-friendliness of engine art pipelines. We're going a different route than Unity, but it's still important to recognize the design decisions they got right.

I don't know anything about Unity's scripting system, but multiple scripts were suggested a few months back and after thinking about it a while it seemed like a good idea.

Especially because I might have an actor.script table, in which shared variables for each script file would be stored. actor.script.whatever=3 --shared across all actors of this type

Ah, but you can have more than one script of the same type attached. It could handle multiple scripts of the same name if it creates tables on the entity and stores them like this: entity.mover[0] = {} entity.mover[1] = {} entity.door[0] = {} I don't know if calling the attached game object a "script" is accurate, because each one can have its own values, so it doesn't really correspond to a global file.

I am leaning towards making each script attachment an "actor" that is self-contained. Actors perform game actions, and turn ordinary entities into interactive game objects. Actors do not share variables or functions. Entities themselves can have Lua functions and values attached to them, but this practice would be an exception. So an entity can have two "mover" actors, three "animation" actors, and one "cow" actor, and none of them interfere with one another. To display it visually, the hierarchy in Lua would look like this: entity={} entity.actor[0]={} entity.actor[0].health=100 entity.actor[0].name="Dave" entity.actor[1]={} entity.actor[1].speed=10 entity.actor[1].mood="Angry" entity.actor[2]={} entity.actor[2].openstate = true If you have an entity and want to call an Open() function on all its actors, you would do this: for actor in entity.actor do if actor.Open~=nil then actor:Open() end end Some of these functions don't exist yet, but this code demonstrates how actor classes would work with a rocket 'actor': self.damage = 25 self.speed = 10 self.force = 100 --Use physics to set body velocity function actor:UpdatePhysics() local v = self.entity:GetVelocity() self.entity:AddForce((Vec3(0,0,self.speed)-v)/60) end --Explode on impact function actor:Collision(collisionentity,position,normal,force) self:Explode() end function actor:Explode() local entity, aabb, list, actor, effect --Create an AABB for the explosion volume aabb = AABB() aabb.min = self.entity.position - self.blastradius aabb.max = self.entity.position + self.blastradius aabb:Update() --Get all entities in the explosion volume list = GatherEntities(aabb) --For each entity in the explosion volume, lets add some physics force and call the Hurt() function, if it exists for entity in list do -- Calculate strength of effect based on distance from blast center effect = (1.0 - self.entity:GetDistance(entity,true)) / self.blastradius --Add force to the entity entity:AddForce(self.force * effect) --Now check all entity actors for a Hurt() function and call it, if present for actor in entity.actor do if actor.Hurt~=nil then actor:Hurt(self.damage * effect) end end end --And delete the entity Delete(entity) end --Heck, lets add a Hurt() function --If the rocket receives any damage at all, it will explode function actor:Hurt(damage) self:Explode() end

I am not talking so much about our current users, but the total potential market. Because of the emphasis on programming we tend to attract programmers, but for every one of you guys there are twenty people who don't know how to download visual studio, but still have money to spend.

So you are saying the tire velocity is making the car move again? What language are you using?

The reason I don't do that is because if someone needs a C++ example to do that, the probability of them expanding on that is nearly zero. Then every bit of code I release gets treated as if it were the ten commandments, and if a game feature is missing, I am expected to add it. And expert programmers already have their own ideas how things should be done, and don't need my code. Any game examples I provide are going to be in Lua, because there's at least a chance beginners will be able to expand on it.

The fact that there have been zero commercial games with Leadwerks so far indicates we are doing something drastically wrong. To solve a problem, you have to first admit it exists. The brutal reality is that people are generally making beautiful walkthroughs with left-handed guns, and very little else.

I like that you did GameLib, but it's not enough on its own. If that approach worked, it would have happened already.

I completely missed this topic. Regarding navigation meshes vs. A*, I don't really see what difference it makes. If one works, and the programmer is familiar with it and can produce actual results, that is infinitely better than a theoretical alternative that might or might not have any real advantage. Thanks for posting this.

Gamelib, yes, but it's a framework you add components to. You cannot interchange C++ components. You have to include headers and files, and there's a compiling step, and one code file might rely on a library that conflicts with something else...technically, it's possible to share C++ code, but it's just such a pain in the bum no one bothers. Can you drop the code for someone else's groundhog AI into your C++ project? Not without so much work, it makes you seriously question whether you ought to bother. With Lua, you download the code, press F5, and it works immediately, across all supported platforms.

Haha, ToLua works! The code below will print out "No Name, Joe, Joe", as it should. Thanks Mika for investigating this months ago, but the issue with Luabind is so obscure I can't blame you for not finding that. Its documentation and presentation really does appear better, but I think ToLua wins. for i=0,self:CountChildren()-1 do child = self:GetChild(i) if child.name==nil then Print("No Name") child.name="Joe" Print(child.name) else Print(child.name) end end for i=0,self:CountChildren()-1 do child = self:GetChild(i) if child.name==nil then print("No Name") else Print(child.name) end end

There I go, breaking my own design parameters. You're probably right about that.

Well, who put out more games in 2010? The FPSCreator community, or the Leadwerks community? I don't think doing away with programming is the answer, but I do think that providing a framework within which we can code together is critical. Okay, so your main program should be in C++, C#, or whatever, and that's fine. But I believe very strongly in the power of Lua for game interactions. When you write code in C++, you are branching development away from the rest of the community, because from then on, your code and their code can't be combined. Not easily. Therefore, every C++ programmer is an island. With Lua, code can be readily shared. We now need a standard way to code interactions so that the shared code can be more interesting than self-contained game objects.

Ah okay, you can just add this in the .pkg file: $using namespace le3;

I have it working, but ToLua's namespace system is really obnoxious. By default, the command namespace is included, so all functions are like this in the Lua state: le3.LoadModel() Why is everything I didn't write so badly designed?