Development Blog

I love how my research and recommendation to use LuaBind over many others turns out every day to be more powerful

You have probably exploited LuaBind more than anyone else ever has in a 3D engine, and this will be years ahead of all other engines.

I've got iterators working, so you can do this:

for child in entity.kids do
Print(child.name)
end

Unfortunately, the Entity returned by the iterator does not match the lua object the main program uses, and so you can't set attributes from the main program and detect them elsewhere. This is pretty complex stuff.

Great Josh , really great

When you get into more complex behvior I think script programmers will generally use one script per entity that does what they want.

That is absolutely OK

Perhaps you can give each script a name property which will be the script file name itself and we can access it like:

 

FindScript("characterstats"):AddHealth(5)

 

or somehow be able to prefix the script name directly like characterstats:AddHealth(5)

 

Then require that you can't attach 2 scripts with the same name. This would help reduce confusion for newbies and pros both.

 

I would suggest also a FindEntity("") that can be called from any entity to find another entity in the world. Then FindEntityTag("") to be able to group entity types in the case of dynamic entities.

I considered something like that, but I'm not convinced it's that great::

function door:Open()
self:Turn()--Oh wait, we can not do that, because this is the door...

--What if we say "entity" is a value in "door"?  It would be entity.door.entity:
this.entity:Turn()--Okay, this works alright
end

function door:Update()
this.health --wait, that does not work, unless you want the value contained within "door", in which case GetString("health") would not return it
this.entity.health = 100--okay...
end

It seems like a lot of mess for something that is supposed to be as simple as possible. I really do not like the infinite recursive loop of tables.

 

I suppose you could do something like this in C++:

entity->SetInt("door.openstate","1")

Which doesn't look too bad.

 

Of course, you could simple add a prefix to all your functions and attributes you don't want messed with, and achieve the same exact outcome with a lot less complexity:

function entity:Door_Open()
this:Turn(1,0,0)
this.door_openstate=1
end

I personally don't think the entities should have variables, just the scripts attached to them. Each script should be creating it's own "instance" for that entity. So for example the variables in a script that is attached to 4 different entities would have it's own instance of those variables per entity, essentially making those variables apart of the entity itself, but indirectly via the scripts.

 

In my view entities should basically be dumb. They are just placeholders for scripts and other objects like a model or a sound object, or nothing but a script that runs game logic. You build on these things to an entity to make it smart but it's not the entity that is holding anything but the objects attached to it.

If that were the case, we'd be looking at something like this for the mover script:

function script:Start()
self.movespeed=Vec3(0) end
self.turnspeed=Vec3(0) end
end

function script:UpdateMatrix()
Print(self.entity.position.x..","..self.entity.position.y..","..self.entity.position.z)	
end

function script:Update()
if self.movespeed~=nil then
	self.entity:Move(self.movespeed)
end
if self.turnspeed~=nil then
	self.entity:Turn(self.turnspeed)
end
end

It's not bad, although the extra .entity table is not preferable.

 

Let's say you have a rocket script, and it collides with some entity. If all functions were stored on the entity, you could do this:

function script:Collision(entity,position,normal)
if entity.Hurt~=nil then
	entity:Hurt(5)
end
end

But if all information is stored in script subobjects, you would only be able to interact with some classes:

function script:Collision(entity,position,normal)
if entity.player~=nil then
	entity.player:Hurt(5)
end
end

It's not bad, although the extra .entity table is not preferable.

 

I would almost prefer that so it's more explicit to what you are doing.

 

entity:Hurt(5)

 

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.

 

you would only be able to interact with some classes:

 

Why only some? You would be able to interact with every script attached to the entity.

The idea is we might be writing a rocket script right now, but some time in the future we might come up with an entirely new entity behavior that we want the rocket to interact with, without altering the original rocket script. Maybe I'll want to make a special button you shoot to activate, so it has to detect when a rocket hits it.

 

A good case could also be made for having two scripts attached of the same type. A lot of oscillating and gradual motions might use two or three script attachments of the same type, with various settings adjusted to produce a combined output. For example, my vegetation waver code is the combination of a few different sine curves with different frequencies and amplitudes. You wouldn't want to do that in a script, but that's an example of the idea.

 

Each script could just be appended to the end of an entity.scripts table, in which case you could just do this:

for script in entity.scripts do
if script.Hurt~=nil then
	script:Hurt(5)
end
end

Then you could just call the function for all attached script, without knowing or caring what other scripts are doing.

 

I need to come up with some more usage examples and see how they would work out.