Josh

The point of Leadwerks3D is to make a game engine with a really easy to use editor, a framework for game interactions, and support for mobile. I already know how to do high-end graphics, and they can be added on later, but a good foundation has to be in place first. I don't want to make another high-end renderer only a few people can use.

It doesn't matter how well you know 3ds max. It's still more mouse clicks to do the same thing.

For the record, "hybrid" forward-deferred rendering is not "modern". It's a half-baked technique for slow hardware. For rendering, we're focusing on mobile-level graphics across all platforms for the initial release, since the art pipeline and gameplay features are the real point of the new software. That was something I misunderestimated the importance of in LE2.

Okay, so I think we have established this is going to be a competitive advantage for Leadwerks. I counted 5 smileys in one post. XD

I found a way to make it really obvious which object is which. Selection in the scene tree, viewports, and logic editor is always consistent.

All those calls to glEnableClientState() should have a corresponding call to glDisableClientState after the call to glDrawArrays().

They are both named box, but should not have multiple door components. At first I thought there would be tabs and multiple flowgraphs, but it seemed confusing for the end user. Drag an entity from the scene tree on the right into the logic editor window. I am experimenting to see if I can make selecting the logic nodes select an entity, so you can easily see what is what.

Here's what I've got so far. No arguments in the editor, yet, but I'm almost there:

Sure, the target component is called "MessageBox" and has a function called "Display". The argument component has a function called "GetMessage" that returns a string, which gets passed to the MessageBox:Display() function.

Multi-component script system is done, with connections between components (neurons) AND function arguments on those connections. Function arguments can come from any component, and are a function that returns a single value. Argument functions can even return Lua tables!

No.

You should have already received an email with instructions to download and install the software. Please email support at leadwerks.com with your email address used to order. I cannot find any order to link to your forum account here.

I do not like the idea of per-entity values, because the next step is another interface for editing entity-level values, and the next step after that is per-entity scripts!

I would do this by dragging lines in the flowgraph editor from a "CollisionTrigger" script attached to the volume, to the following inputs: Entity-Script-Function Light-HideShow-Show() Light-AmbientSound-Play() Emitter-EmitterControl-Resume() The trigger script would looks something like this: function CollisionTrigger:Collision(entity,normal,speed) if entity.components.Player then self:CallOutputs("Trigger") end end What I do not like about this is you can't set a per-entity value like "CausesTrigger" to the player entity. Everything has to be written with the expectation of certain other classes. If someone wants to add a "MySuperPlayer" class in, it doesn't work with existing scripts that weren't written to accommodate it.

It works right now. On the C++ side, it looks like this (not that you have to actually deal with this): Entity* box = Model::Box(); Component* component = box->AddComponent("Scripts/MyComponent.lua");

Here's how a multiple script approach could work. This treats scripts as "components" and each entity can only have a component of one class: MyComponent.target=nil--Entity MyComponent.newtarget=nil--Entity --This function gets called when the component is attached to the entity function MyComponent:Attach() --We're going to find the component "MyComponent" on our own entity and call a function with it. --This can be used to find other components on the entity, not just our own. self.entity.components.MyComponent:MyFunc() --Of course normally to call a component's own functions you just do this: self:MyFunc() end function MyComponent:MyFunc() System:Notify("I can't believe it worked.") end

Since "script" is not very accurate, and "component" is long and abstract, I am using the script name as a "class": LookAt.target=nil--Entity LookAt.lookspeed=1--float function LookAt:Update() if self.target then self.entity:Point(self.target,2,self.lookspeed*Time:GetSpeed()) end end

I'm totally fine with text linking but I think flowgraphs will strike a decisive blow at the heart of the unity beast.

Thanks for your input. With this script, you can specify the function to call in the editor. It reminds me of the input/output system in HL2: script.target=nil--Entity script.key=Key.Space--keycode script.functionname="Activate"--choiceedit "Enable","Disable","Activate","Open","Close","ToggleEnabled","ToggleActive" function script:KeyDown(keycode) if keycode==self.key then if self.target then if self.target.script[self.functionname] then self.target.script[self.functionname](self.target.script) end end end end

I have renamed the "SwitchTarget" script to "ToggleTarget". I added a KeyDown script function. This entity is now linked to the space key. When the space key is pressed, the ToggleTarget() function is called. script.target=nil--Entity script.newtarget=nil--Entity function script:ToggleTarget() local temp = self.target.script.target self.target.script.target=self.newtarget self.newtarget=temp end function script:KeyDown(keycode) if keycode==Key.Space then self:ToggleTarget() end end I have a chain of about five entities linked together now so that when I hit a key, they react. The flexibility of Lua works really well here. I'm not even sure a flowgraph mode is needed if you can assign entities in the editor. I'll keep playing around with this.

Here's an example of a single script that looks at an entity. The "target" value is an entity that you drag onto script properties in the editor: script.target=nil--Entity script.lookspeed=0.1--float function script:Update() self.entity:Point(self.target,self.lookspeed) end And then this script can be used to switch the target entity. The two entities are assigned by drag and drop in the editor: script.entitytomodify=nil--Entity script.replacement=nil--Entity function script:SwitchTarget() self.entitytomodify.script.target=replacement end What's nice here is the SwitchTarget script can be used with anything, instead of only working with one type of companion script you decide on ahead of time.

That's a good point for consideration. I can't attach values directly to entities in Lua and be able to access them from C++ (which I absolutely need for the script debugger) so there has to be a script table associated with the entity. Fortunately, I can make it a little cleaner than LE2. If you perform a raycast or something, the resulting entity you get will have a script or scripts table attached to it, only accessible in Lua. This is a way to directly access an entity's script object: pick = CameraPick(camera,x,y) if pick then pick.entity.script:DoSomething() end Here's a comparison of two approaches for script attachments. The top one uses a single script. The bottom one uses multiple scripts. Both are manageable: function script:Collision(entity,normal,speed) if entity.script~=nil then entity.script:AddDamage(5) end end function script:Collision(entity,normal,speed) if entity.scripts~=nil then for index,script in ipairs(entity.scripts) do script:AddDamage(5) end end end The big reason we aren't getting general-purpose scripts written now includes: -No script debugging. -One script file per model file design discourages reuse. -Only models can have scripts. -LE2 scripts include a lot of class stuff that I should have skipped. I'll do some experiments next with multiple scripts, and have outputs linked between entity scripts, instead of entities.

-What if you have the same script attached twice? -My entity:AddDamage() approach allows you to add new scripts with the AddDamage() function, to act in ways that were not originally accounted for. For example, a can of paint might explode and fling paint everywhere when its health reaches zero. Looking at Unity's system, I think they have sacrificed their script system for the purpose of making people think they can simply click on options to make a game. I mean, the multiple script attachments has a benefit to the total non-programmer. Let's say they get 20 "utils" more functionality than if they chose from a library of single pre-made scripts. But the cost when they crack open those scripts is -60 utils. Their scripts are a mess, and are fragmented between three script languages.

In my opinion, you need a project plan and a manager that assigns tasks, verifies outputs, and holds contributors accountable and on schedule. I don't think the project manager should even try to do anything else but manage it.

That's correct. With this approach, the differences are: -Script debugger -Any script can be attached to any entity, instead of having one script per model file. -Entity get/set Lua values directly, instead of string-based keys. This includes drag and drop fields in entity properties for materials, textures, other entities, etc. -Visual logic editor connects entity script functions, instead of entity target/message system. -Much simpler scripts, with no attempt to implement hierarchical OO or control properties through string-based keys. -Script values and functions are attached directly to the entity itself. That's the big question. Multiple scripts need multiple spaces for variables. The variables have to be attached to some kind of Entity-Script attachment object. I have implemented this without a problem, and it works well. The problems arise when you try to access that entity's values from another script, or from C++ code. For example, if you want a bullet to affect a character it hits, you would have to do something like this: function script:Collision(entity,normal,speed) local script local n for n=0 to entity:CountScripts()-1 script=entity:GetScript(n) script:AddDamage(self.damage) end end Okay, we can do some tricks to just call the function for the one entity, and it gets called for all scripts attached to that entity, so then it would look like this: function script:Collision(entity,normal,speed) entity:CallFunction("AddDamage",self.damage) end What if the function needs to return a value? There is no version of this we can do with a simplified per-entity function like we used above: function script:Collision(entity,normal,speed) local script local n for n=0 to entity:CountScripts()-1 script=entity:GetScript(n) if script:GetHealth()>0 then script:AddDamage(self.damage) end end end There's very little you can do within a script itself. Gameplay comes from the interactions between scripts. Without that, you'll add one script to make an object spin around, another to make it blink colors, another to make it emit a noise, and that's pretty much all you can do. With a single script per entity, this becomes very easy: function entity:Collision(entity,normal,speed) if entity:GetHealth()>0 then entity:AddDamage(self.damage) end end I originally started off making the logic editor connect script-entity attachment objects, not entities, but I could quickly see that it was way too abstract, so I just made it connect entities, and merged the list of available functions. However, this causes problems because if an input is called, and multiple scripts have the function, if that function has an output to another entity, it will be called for each script that has the function. I could take stricter control of the flow on the C++ side, but I thought the idea was that when a script function was called, from anywhere, it would trigger any outputs it's connected to. I don't doubt I can implement a system that has a way to control all of this, but it's a question of keeping things simple. I made the LE2 script system complex to try to accommodate the feature requests I was getting (like hierarchical OO script objects). One question is just how frequently will the end user be combining multiple scripts to create emergent behavior? It's a nice idea, but beyond really simple stuff like a blinking spinning light, what can you do with multiple scripts that couldn't be done with one flexible script with some adjustable properties? I bet beginners love it, because it gives them the appearance of controlling behavior without modifying any code, but are we crippling the usability of the system to make easy stuff easier? It seems like we have two kinds of functions. We want engine hooks to have multiple definitions, be called in order, and have unique variable spaces. On the other hand, we want script functions to be attached directly to the Entity object, share variables, and only have one definition. Maybe the former needs some kind of AddScriptHook() mechanism, while conventional script functions would simply be overridden if they exist in two scripts attached to the same entity. It's also worth considering that the Unity script kiddies are the least likely demographic we will attract. They've got brand loyalty like crazy, they tend to be on the low end of the technical proficiency spectrum, and are mostly using free stuff. That's unlikely to be a potential customer. That's the goal, but this needs some more thought on the design.