LE3 Lua

[Josh]

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

[Josh]

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

[Benton]

The only way I think we could get away from only one script per entity is to be able to modify scripts on the entity an have it save the changes just for the entity. That way we could add blocks of code to our enities

, but this can get really really messy. Only one script per entity is an option, but you/we need to find a way to add generic functionality to our entities in a clean logical way.

[Josh]

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

[Rick]

Is that actually working or is that just pseudo?

[Josh]

Is that actually working or is that just pseudo?

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");

[Rick]

That all looks really clean. I'm trying to think really hard about the downside of this design but not really seeing it yet. Could you describe how the connectivity between entities would work.

 

Let's say I have a volume that I would like to attach some collision functionality to where if the collision is the player it turns on a light and plays a sound on that light. Then maybe shoots off some fireworks (emitter). How would we hook those together in your vision?

[Josh]

Let's say I have a volume that I would like to attach some collision functionality to where if the collision is the player it turns on a light and plays a sound on that light. Then maybe shoots off some fireworks (emitter). How would we hook those together in your vision?

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.

[Rick]

OK, so we would link each of those entity script functions to this volume trigger's script "Trigger" output. The collision gets called, it's the player, we fire our 3 "Trigger" outputs which will be those 3 functions from those 3 different scripts tied to those entities.

 

So, I see in the scripts how we define variables, and make functions (which are basically inputs). How do we expose/define outputs for a script? How is "Trigger" defined in your example so that the editor can tie things to it?

 

 

What I do not like about this is you can't set a per-entity value like "CausesTrigger" to the player entity

 

Do you mean that inside this script you can't do something like: entity.components.Player.CausesTrigger = "me"? That would make sense that you can't do that with this because it would become to specific. I think to aid in stuff like this you could make a volume trigger script that exposes variables that describe what entity you want to trigger it. That way you have a generic trigger script that won't specifically look for the "Player" component like you have, but looks for the script name (stored as a public variable) of their choosing by them dragging their player entity script (whatever that may be for that person) to that exposed variable.

 

CollisionTrigger.triggerComponent = nil -- Component
-- not sure if I mentioned that I really like the idea of public variables being assigned like this. the question I have is would private variables just not prefix CollisionTrigger and still work? that might be a nice distinction between exposed/public and private.

function CollisionTrigger:Collision(entity,normal,speed)
	if entity.components:Contains(self.triggerComponent) then
			self:CallOutputs("Trigger")
	end
end

 

The interesting, and cool thing about Lua, is that you can create table variables on the fly. So if a component really wanted to it could just create a variable and give it a value to another component. When using another component it should be known what variables it will assign so you know what to read if you need too. Or perhaps use a SendMessage() feature. Unity does something like this where you call SendMessage() passing in the function name you want to call and some data (sort of like LE's) on the other components to get your message. You would do this at a components level in your case and any component attached to the entity that defines that function will get that function called. Just throwing around ideas, but it would be cool to know that after a CollisionTrigger script gets called that I'll have some extra data that it added to my Light object, for example, that can now be consumed by components attached to the light. Can data be stored at the entity level instead of only at the component level? That data should be usable by all components attached to that entity.

 

Things start getting deep and heavy when talking about data though because it has to be very flexible and the users given the right to pass it around to all sorts of different things. So far we've only been talking about chaining functions together and exposing data used by scripts and that does give nice functionality easily, but when we start talking about scripts changing/assigning data to other scripts things get more complicated to keep things generic.

 

Chaining input/output is one thing, but not sure how far you plan on going with data exchanging between components.

[Josh]

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!

[achrystie]

Well, I would think that having one script per entity wouldn't be such a bad thing if there is a way to hierarchically parent one entity to another entity. Is that possible? Also, it seems as though you are trying to tackle one of the big problems Unity presents to new users which is, "how do my components talk to each other", with the flow graph? Which is good, but I don't know if that is worthwhile if there is some major tradeoff associated with it that makes everything else more difficult to create/understand.

 

Parsing the code examples you've posted has helped, but is there a way that you can create a higher level schematic diagram and description of how things will "work" at the entity level and from entity to entity, and how things run in the game loop with some sort of update, fixed update, startup, onload functions? In other words, I'd like some idea of how I'm going to piece everything together in a understandable way, while still having my entity scripts (components) as compartmentalized and specific as possible, and how those things will actually run in the engine.

 

For instance, if I have something that has a set of animations on the 3d model, and should interact with the in built physics, and needs to be controlled by the player with keyboard/controller input, and needs to do some sort of raycasting, and has to track or change data (health bar or something), is that all written in one script, with it's own load/create/game loop functions, and just the outputs and inputs are fed through the flow graph to whatever is external to that entity and needs to see the changes? What does that even look like from a flow/functionality standpoint?

[Guest Red Ocktober]

after some initial hesitations, this approach doesn't look too bad... not too bad at all...

 

nice one Josh...

 

--Mike

[Rick]

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!

 

Yeah, I agree. It opens up a nasty can of worms. If people want their custom data for an entity they'll just have to create an empty component/script and make the variables, and then tie that to the entity and it'll just be a specific script for their game. Seems good.

 

Some other things I'm curious about is data living across scenes. Do you plan on doing anything for that or leaving that up to the user? If I created all these scripts and made a prefab (assuming you are allowing prefabs) of my main character using these scripts, and I have a script where I made variables like level, xp, name, etc. Are we able to keep this data between scenes? Is it up to us to save out our data when a scene is unloaded, and read it back in when a new scene is loaded? If so we'll need some way in our scripts to know when this is happening so we can write our save code. If you want to make a way to specify this automatically somehow then even better

[Josh]

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!

 

[Rick]

Whoa. Interesting. Going to have to soak that in. Do you have a specific use case you can think of for that?

[Josh]

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.

[Josh]

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

[Rick]

Not sure if you are just showing the editor with this but a few things jump out at me.

 

The entities in the scene are both named box. How does it know which is which? You seem to have 2 of the same scripts attached (Door). I thought you concluded you could only have 1 of the same script attached to entities with the ability to have multiple unique scripts?

 

1) Are you thinking we'd have 1 logical space for each entire scene?

2) How do you get a node in the logical editor? From the scene editor and some sort of right click on an object, or from the logical editor where you right click and get a selection of entities?

3) Would be cool if in the 3D space we can somehow get a hint that this entity is used in the logical editor.

 

I like it. It's looking very promising!

[Josh]

The entities in the scene are both named box. How does it know which is which? You seem to have 2 of the same scripts attached (Door). I thought you concluded you could only have 1 of the same script attached to entities with the ability to have multiple unique scripts?

They are both named box, but should not have multiple door components.

 

1) Are you thinking we'd have 1 logical space for each entire scene?

At first I thought there would be tabs and multiple flowgraphs, but it seemed confusing for the end user.

 

2) How do you get a node in the logical editor? From the scene editor and some sort of right click on an object, or from the logical editor where you right click and get a selection of entities?

Drag an entity from the scene tree on the right into the logic editor window.

 

3) Would be cool if in the 3D space we can somehow get a hint that this entity is used in the logical editor.

I am experimenting to see if I can make selecting the logic nodes select an entity, so you can easily see what is what.

[Rick]

I don't know if this would complicate things, but I think it would be nice if we could create folders/filters in the scene tree view so we can group things. Much like Visual Studio. In Visual Studio I know if you just have a wall of source files it's a pain to look at and find things, but with folders/filters it let's a user group things however they see fit. Of course these are purely visual to the tree view and have no functionality. Looking at the scene tree view you have this just came to mind. With 2 it's not bad but a scene could have hundreds and what better way to organize things than letting the user give their own structure.

[Pancakes]

take my money now don't fight it

 

Btw, is there going to be a beta for this? And can I sign up for it please? I ain't too proud to beg.

[Benton]

I'm right next to Pancakes. On the floor. Begging.

[dennis]

Owh my gawd! this is so freaking awesome! the good part is... I will be 3 weeks on camp. I will earn loads of money, I can't spent my money when I'm there, in the forest. after 3 weeks I have loads of money then I'm said.. cold in the forest and such, probably bad weather hugging my weapon is the only thing I can hug. and then the almighty JOSH is there, to show LE3. which I can buy then then I'm feeling way better, start coding LUA again. and only can do that using weekends so stays really fun So Josh win, win situation for u and me

 

take my moneys

Ps. really sweet the logic editor.

[Josh]

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.

[Benton]

Nice. You will need to write up some really good docs for this however, because powerful it is, simple it's not.