Multiple scripts lobby

[Rick]

I don't know if it'll do any good but I'll lobby once to get back multiple script attaching to entities.

 

 

1) The functionality was already there.

2) If you keep the functionality and someone doesn't want to use it they aren't forced to. They can still just use 1 script.

3) Having the ability to attach multiple scripts gives us more freedom in picking the programming model we want as it lets the people who want to do component design do it.

4) Other engines allow this already so people coming from those engines to LE will be used to it and might even expect it. It might have been confusing to people who aren't used to it, but then again they didn't HAVE to use multiple scripts if they didn't want to.

 

I would like to hear any arguments people have against having this functionality in LE (not the component design pattern itself but just having the functionality we already had). I'm open and interested to hear these other arguments to get a better understanding of the other side.

 

Thank you.

[AggrorJorn]

I stand with Rick on this as well.

 

Another downside to one script is that we get cluttered and messy scripts that are more difficult to understand. They are also not suitable for re-using.

 

lets say you have 3 functionalities for entities:

• Rotating
  
• Moving
  
• PlayingMusic
  

 

Lets say you need to combine scripts together to get the desired result, you will get the following scripts:

• Rotating
  
• Rotating-Moving
  
• Rotating-PlayingMusic
  
• Rotating-Moving-PlayingMusic
  
• PlayingMusic
  
• PlayingMusic-Rotating
  
• PlayingMusic-Moving
  
• Moving
  
• Moving-PlayingMusic
  

That means (nⁿ) (3³ in the example above) different scripts have to be made. This is a serious drawback.

[YouGroove]

I also second Rick.

 

Why ?

Because it was modular and as good as done in some others 3D engines.Anyone can design modular scripts and combine them.

Take some bad *** NPC , just attach these scripts :

- GeneralStateManager (this script would switch messages like Walk, run , hide) in some vairable

- AnimateNPCBiped (this would manage animation of bipeds NPC) using the variable Message from previous script

- HeadMoving script (custom script that would manage Head looking direction for some NPC

 

You have some 4 foots alien NPC : attach that scripts

- GeneralStateManager

- AnimateNPCQuadriPed

 

I think that new orietations, just back down Lua script, to force people going C++.

But lot of 3D artists and other scripters that never gonna C++, won't go simply.

 

 

LE 3 Beta was great , with Darkness and scripts to make some entire game and fast. It was real indie easy game making.

Now it's more for core programmers, what means lot more less 3D artists and game makers , but lot more for coders, what means lot of time , not super grahics.

[Josh]

Basically, if you want more support and examples in Lua, we had to do this, because not having a 1:1 script:entity ratio makes things impossible to code for.

[Rick]

I think that's fine. You can still give official LE examples with 1 script even if you allow multiple scripts to be attach. However some of us want to be more component oriented and the multiple scripts allowed this where the 1 script approach does not. The component model isn't impossible to to code, and in fact is easier to code the components because they are so isolated. It's just the glue code then that someone has to do for the specific game where you attach things together. Basically going back to the 1 script really hurts the versatility of the scripting system.

[beo6]

I was at first also not sure about the loss of the multiple scripts per entity.

But now i still can not see a real advantage of it.

 

for the rotating/moving and music playing example:

You will most likely play the music globally so you can have a music playing script in the world to do that and in the future when we got logical entities for the flowgraph we can do it with these.

So you stay with the rotate/move script which in my opinion should stay together to be really reusable.

 

 

I have two ideas i am not sure if they are really useful or would solve the issues for everyone.

1. we could just include scripts into the entity scripts in code (dofile, loadfile maybe?)

 

2. naming the different scripts or giving them ids:

currently you can use the following:

entity.script.TakeDamage(10)"

 

but maybe it could work when we can name the different scripts like this:

entity.scripts.damageScript.TakeDamage(10)

entity.scripts.animationScript.DoDamageAnimation()

[YouGroove]

Are several scripts attached to some entity less efficient ?

If it isn't some performance problem, just keep multiple scripts attaching possible.

 

It is so great to have lot of scripts to choose and you just pick up and attach the ones you need sometimes.

[Rick]

But now i still can not see a real advantage of it.

 

I'll explain in my vision the advantage and how I feel the procedural way of programming doesn't work with multiple scripts BUT event programming does.

 

This requires thinking about problems differently. Instead of directly doing something when it happens yourself, when things happen inside a script you fire an event that the script defines. Other scripts attach to these events to control the flow of the program. Setting up these relationships of events to functions is done in a script of it's own and really drives the flow of the game.

 

So with component programming it's all about starting with a blank entity (or you could have a visual model be the starting point if you wanted). Then you attach components (scripts that give specific functionality). Each of these components really only do 1 task and do it well. They have ZERO dependencies to any other component inside of it. Because of this the chance for errors drops a ton! It also becomes VERY easy to have a big programming team and give them each components to work on. The components will have events to interact with the outside work (other components) and functions to attach to other component events to be interacted with. The components are also highly reusable so once your toolbox of components becomes large enough you can actually start pluging and playing scripts.

 

 

Small example:

Health component/script

==================

Properties

-------------

Max Health

Current Health

Functionality

-----------------

ReduceHealth(value)

Events

----------

OnHealthReduced(remainingHealth)

OnDead

 

HUD component/script

================

Functionality

-----------------

UpdateHealth(value)

 

Drop in a player model and call it "player" and attach the health script to it. Drop a pivot in and call it "hud" and attach the HUD script to it.

 

In App.lua OR another script that's just used and called AFTER all entities have been loaded is where you make the link. This becomes the real game specific file. It would look something like:

 

-- get the entities
player = FindEntity("player")
hud = FindEntity("hud")

[size=4]-- make the connection between the HUD and the player[/size]
player.HealthScript.OnHealthReduced.Bind(hud.HUDScript.UpdateHealth)

 

So what happens here is when the player takes damage (which is other scripts with enemies and such) those will fire healths ReduceHealth() function which will reduce the current health variable inside the script AND then fire OnHealthReduced event, which the Bind() will trigger the huds UpdateHealth() and the current health is passed to it. Now the HUD updates it's display to update the health.

 

So you see that you never actually program the flow directly sequentially, but instead do so by linking events to functions. With a little up front thinking about components expose themselves to the world this has MASSIVE benefits.

 

I hope that helps show the different style of programming. We were able to do this before but you weren't forced too if you didn't want to. You could still use 1 script if you wanted. I see no sense in taking away functionality like this when it doesn't hurt the 1 script people.

 

I really want to play around with the component design now that I have a little time :/

[beo6]

what you describe sounds just like what the flowgraph is for.

 

You have a function in your script. For example

function Script:ReduceHealth(amount)--in
   self.Health = self.Health - amount
   self.component:CallOutputs("OnHealthReduced")
end
function Script:OnHealthReduced()--out
   App.displayedHealth = self.Health
   if self.Health <= 0 then
       self.component:CallOutputs("OnDead")
   end
end
function Script:OnDead()--out
end

(untested code)

 

 

i tried in my own Project to have a HUD script but for some reason i could not draw to the context so i did it in the App:Loop of the App.lua script but i think that is another issue

[Rick]

I don't think this would work the best in the flowgraph but it could work there. Better when logical nodes are added but I still think it's more ideal to have these attached to the one entity they belong too instead of pivots.

 

A player would have the model, health script, maybe faction script (so things can tell which other things they should be attacking), weapon script, FPS script maybe (this could be broken out to keyboard/mouse possibly), etc. All these scripts would be attached to the player model. I don't think setting up all the interactions in the flowgraph would be the best, but it could work.

 

The flowgraph is a little less dynamic as well so it might run into problems with setting up the connections for say enemies that spawn during run-time where the code piece of it could handle this.

 

Again, there are multiple ways to code things, and when we had multiple scripts on entities we had more options than we do now. I just don't get why limit those options when we already had them.

[YouGroove]

but I still think it's more ideal to have these attached to the one entity they belong too instead of pivots.

I agree and having to make pivots, just makes the workflow less simple , more annoying.

[YouGroove]

So the question could be : Will multiple scripts per entity return ?

Is Lua reliable enought ? (just seen some memory problem reported on forums)

Hopefully there is no big team Lua project, caus i can't imagine people having to recode all their Lua scripts to be compatible to new system.

Important changes like that in the future when LE3 will become mature with big game projects, should be submitted on forums before make the changes and just say :"Here is the new changes, you must do like that"