Josh

To make an entity in Leadwerrks3D behave, you can drag a script from the asset browser to the actors list in the entity properties editor. Each entity can have multiple scripts attached to it. Each script can have different variables exposed, with control for the GUI they are displayed in. For example, you can specify upper and lower limits of a spinner or a list of choices for a drop down box. Each script attached to an entity, along with its set of properties, is called an "actor" because...it acts. To handle the interaction of different actors, a flowgraph is used. You can drag actors from the entity properties editor into the flowgraph editor. Each actor has inputs and outputs defined in its script. You can connect the output of one actor to the input of another. For example, you can connect the "tick" output of a timer script to the "Resume" output of a mover script, to make the mover translate and rotate an entity at regular intervals when the timer ticks: I hope this makes it more clear how entity interactions can be handled in Leadwerrks3D, even without programming. With this system, we're all working on one big game together, and we can share functional objects without any difficulty.

I believe you can do stuff like this so all actors can access a per-entity value: function actor:Update() self.entity.myvalue="Hello" end Normally you would want to keep them in their own separate spaces, within the actor table. Programming the editor to handle the multi-script attachments and properties, when scripts or objects may be reloaded at any time, is really incredibly gnarly, which is why I have never done anything like this before.

An "actor" is a script attached to an entity, with a set of properties. Each actor has it's own set of variables in Lua that don't interfere with each other. You can have multiple actors, even actors of the same type, attached to one entity, and they are each in their own "space". In the flowgraph, you will actually be looking at actors, not entities. To you and me, it's trivial to just write exactly what you want a script to do. To 99% of the potential market, programming is an utter impossibility, but they can attach a few behaviors to an entity and adjust some settings. It allows game development through visual trial and error. Good eyes! On one hand, this seems like a lot of work just to allow designers to do things without code that programmers can easily do. On the other hand, this means you can code a few scripts, give them to a designer, and let them make some game maps for you with interesting variations of the gameplay mechanisms you programmed.

Below you can see the properties editor. When you select a script attached to an entity, the properties for that script appear on the right. Here we have a simple "Pulse" script that changes the color of the entity along a sine curve. This can be used for making lights that pulsate slowly, or continually turn on and off. Here's what the script looks like. The "--in" tag at the end of the Pause and Resume functions indicate that these functions can be activated in the flowgraph editor. (A node can be connected to them to call them.) --float speed 1 --color color0 0,0,0,0 --color color1 1,1,1,1 --bool recursive function actor:Pause()--in self.paused=true end function actor:Resume()--in self.paused=false end function actor:Update() if ~self.paused then local i = math.sin(AppTime()*self.speed*0.01) self.entity:SetColor(i*self.color0+(1-i)*self.color1,self.recursive) end end Here's our "mover" script, which just performs simple movement and rotation without physics: --vec3 translation 0,0,0 --vec3 rotation 0,0,0 --bool global true function actor:Start() self.paused=false end function actor:Pause()--in self.paused=true end function actor:Resume()--in self.paused=false end function actor:SetTranslation(translation)--in self.translation = translation end function actor:SetRotation(rotation)--in self.rotation = rotation end function actor:Update() if ~self.paused then if self.movespeed~=Vec3(0) then self.entity:Move(self.translation[0],self.translation[1],self.translation[2],self.global) end if self.turnspeed~=Vec3(0) then self.entity:Turn(self.rotation[0],self.rotation[1],self.rotation[2],self.global) end end end Want an entity to animate in a loop? Attach this script to the entity: --int sequence --float speed 1 --bool paused false function actor:Start() self.frame=0 end function actor:Pause()--in self.paused=true end function actor:Resume()--in self.paused=false end function actor:Draw() if ~self.paused then self.frame=self.frame+AppSpeed() self.entity:Animate(self.frame,self.sequence) end end What if we wanted a one-shot animation that plays when something triggers it? We can define an "Enable" function, connect another node to it, and some other event can cause the script to play the animation through once. Here's "PlayOnce.lua": --int sequence --float speed 1 --bool enabled false function actor:Start() self.frame=0 self.enabled=true end function actor:Enable()--in self.enabled=true self.frame=0 end function actor:Disable()--in self.enabled=false end function actor:Draw() if self.enabled then local length=self.entity:GetAnimationLength(self.sequence) self.frame=self.frame+AppSpeed() if self.frame>length then self.frame=length self.enabled=false end self.entity:Animate(self.frame,self.sequence) end end By using these general-purpose scripts we can set up game interactions and interesting behaviors, without coding...but if we need to code something new, the tools are a couple clicks away.

I drew some sketches on paper, and I think the proper way to go about complex structures is to have assign a list of entities that break when a particular entity breaks. This would actually let you set up complex structures that collapse, instead of just shooting paint off of walls.

Just call it..."The Leadwerks".

If you want to shoot identical chunks of plaster off of indestructable wooden frames, then Apex is the way to go. I'm not very impressed with the results and the amount of work it takes to set up. A single object is one thing, but to make structures collapse you have to go through and tag debris chunks to make the whole structure spontaneously fall apart.

I think there's a new general-purpose tool out there to do this with any physics lib that someone posted a while back. I forget what it's called. To me, it always comes down to this increases the art pipeline complexity, and if people can't handle the current workload required, there's no way they'll be able to handle even more complexity. I think the current method of "breaking" objects is a fad people will quickly get tired of when they see how limited it is. Some technology is a real step forward, and some is a trick to look like something it's not. I was initially very interested in this idea, and then I saw the pre-made fragments and the necessity to set each fragment as either "breaks away" or "the whole structure crumbles when this is shot". You can see the effect of this in a lot of videos with pieces that remain suspended in the air because someone forgot to set a fragment's break mode. This has been around for a while, you can download "Warmonger" from 2007 here: http://www.nvidia.com/content/graphicsplus/us/download.asp Real breakage is the way to go in my opinion, even if the results are more simple than what pre-made fragments can do. I really think we can make CSG solids you can chip away the structure of in real-time, and have it break a different way each time.

You need to get with the times. "Multimedia" is a term no one uses anymore because it is so vague. Yeah, I agree with that.

Yes, but someone who has never seen the name Leadwerks before will instantly know it has something to do with 3D or games if they see "Leadwerks3D". There is a reason for this, but you won't find out for a few months at least... No we don't, we have "UDK" because Epic's marketing guys figured out that "Engine" sounds too intimidating to a beginner.

Well, according to Brad, they do not sell to individuals in countries with a high risk of fraud, and they have always had this policy. I don't think it's anything against you in particular. http://www.onlinefraudguide.com/risk-countries-fraud I wouldn't do this myself, but it's their decision to make who they want to sell to. Maybe they've had a lot of problems in the past, and just don't want to deal with the risk.

In the BMX code you are just rendering to a simple gbuffer. The C++ code is using the Framework object, which has a lot more effects and uses HDR by default.

That's a definite probably.

The various parts of the new editor are coming together. Today I got the properties list box drag and drop functionality working. I actually had to go back and rewrite some of the list control rendering code because I haven't used it in a while, but it didn't take long. I'm trying to attack known unknowns first, so we're focusing on the flow graph, AI, and game logic, and everything required to build up to support that. I've already written a CSG editor and an engine with great graphics, so I know I can do that. Gameplay support is what I want to focus on now before I cover old familiar ground. In other news, it has occurred to me that an OpenGL 2 renderer is needed to provide a PC/Mac equivalent of what the iPhone and Android renderer looks like. Leadwerks Engine 2 uses OpenGL 2.1, but this OpenGL 2 renderer won't be anywhere near as advanced. I'm just going to derive a bunch of classes from the OpenGLES 2 renderer, so we can get as close a match as possible to the Android / iPhone render.

Well, I sent an email off to Brad, hopefully he'll see that.

He's asking for more examples. I need to get their engineers in a room with a power point presentation.

That's a little easier, due to the lack of gravity. I would just create a fixed joint and delete the joint when the object was shot. That's an easy way to make bits and pieces of ships break off. That's cool, but it's still pretty limited. I'd like to implement something that works on any CSG solids. The breakages probably will not look as good as the pre-broken DMM stuff, but if I had the choice I'd rather have dynamic breakage that is simpler and looks worse than pre-made breakages that look better but require extra work to set up.

Of course you can do that, a variety of ways. The easiest would be fixed joints. The "proper" way would be to use zero for the default mass, and then change the mass of an object when shot. You'd want to add a setting for some pieces to be "base" segments that cause the entire structure to collapse when that piece is broken. With all these types of systems, including PhysX, it takes so much work to set up the art assets that people usually don't bother. You can construct a shack out of individual pieces like that, but it's a lot of effort for something that isn't really worth it. I'm much more interested in real dynamic breakage, but no one has done it yet. I think our CSG solids can be used for this because they can be split and carved in real-time. We'll see how it goes.

Models will be effortless. It will just be done for you. Code will be mostly the same, but don't expect your code to compile without some changes.

The name of the third version of our engine is going to be "Leadwerks3D". Why? "Engine" is a term associated strongly with older FPS engines, and typically describes a system with a more primitive workflow and a programming-centric design. I think the term has negative connotations. Leadwerks Engine was designed to be a programming library. Our new software is a visual game design tool. I want to make that clear to the public. "Leadwerks Engine" is two long words. Trying to promote a product with a two-word name is harder. A lot of people don't know what an "engine" even means, and will think we make cars or something. Having 3D in the name gives people at least an idea of what we do. The company name is being legally changed to "Leadwerks Software" (from Leadwerks Corporation). We can't just call the product plain "Leadwerks", because it is not clear whether the company or the product is being referred to. It also looks funny in the editor titlebar. The "3D" suffix punctuates the name and gives balance to the capital "L" at the beginning. In retrospect, naming the product "Leadwerks Engine" was a good idea, because this whole time we have only had to promote one name. I think a company like Stonetrip (Shiva) has a harder time putting their name out, because they always have to choose which they should promote.

Even LE3 won't have dynamic physics scaling without breaking the simulation, but unless you are making a slow-motion weight gain sim I think it will be okay.

So I talked to the product manager of PhysX today on the phone, and I was telling him about our current vegetation technology, and my desire to go beyond the bounds of 32-bit floating points in the next version. I was told they are currently trying to ramp PhysX 3.0 up to handle tens of thousands of bodies, because in the past it hasn't been able to handle as much. I told him that it's perfectly possible to handle millions of static instances, and they just need to think of vegetation and other static geometry differently than dynamic bodies. We had an interesting conversation, and he's interested in pursuing this, but of course it would be a long time until we actually had some results. At this time, PhysX doesn't come close to being able to handle the number of vegetation instances we are used to using. I have developed the technology, and NVidia is interested in pursuing this in the future, so maybe they will end up licensing our C++ code when I implement it. The actual code is pretty trivial, and the valuable asset I have is the knowledge of how this works together with rendering, and how to optimally manage and store the data. Where does that leave us for the present? I don't know exactly, and I would be reluctant to start with PhysX knowing that it cannot support our vegetation goals. However, I have NVidia's attention now, and if they want to move in this direction, I have the knowledge to help them do that. I am posting this in the private forum since this is a little more sensitive than I would want to post in a blog.

Crytek has their own physics system, so who knows. For individual entities, scaling will be done by internally recreating different physics shapes to the specified scale.

It is. I think Lua may be faster in L3D because the binding with C++ will probably be a lot more efficient than what we are doing now. Don't have any numbers to back that up, but it's just my guess.

The capabilities are about the same as the Source engine, so you use lightmaps together with projected shadows. I've done these in the past, so it's easy for me to do.