1 script per object?

[Admin]

To explain further:

 

You do get some utility (usefulness) out of having multiple scripts per entity. However, you also lose utility because it makes the script programming side very messy. With one script object : entity it's easy to call different functions and build a more abstract and flexible system.

 

For example, Lua allows us to check if a scripted entity has a "TakeDamage" function, and if it does, we can call it. We can do the same thing with multiple scripts, but they make it harder:

• Since there can be multiple definitions of the function, functions that return a value are ambiguous.
  
• Each function call requires looping through a table.
  

 

The worst problem is that multiple scripts effectively require an extra namespace in front of everything. It's fairly easy for us to all agree on common generic functions and values:

• teamid
  
• health
  
• Kill()
  
• GetScore()
  
• Alert(enemy)
  

 

However, if an extra namespace is required, we get less sharable behavior. One person will create a script called "HealthManager" to store the health value in. Another person will mix that with an AI script. As a result, the system becomes less modular and less shareable, which was the main goal of our script system in Leadwerks 3.

 

Like all engineering, there is a tradeoff, and this is the choice I made after seeing both approaches in action.

[Rick]

One person will create a script called "HealthManager" to store the health value in. Another person will mix that with an AI script. As a result, the system becomes less modular

 

I've accepted the fact that we won't have multiple scripts again, but the example you gave is more modular than a person making 1 script that does both health and ai. Why would you call it less modular? With multiple scripts I can plug and play 5 different ai scripts to use the same health manager script. That's the entire point of being modular. Building the whole with smaller parts. It also makes the scripts more shareable because zero code has to be copied or moved around. The point it to pick the scripts you want and piece them together. The scripts themselves define their interface which if you want to hook into as another script writer you can because of the defined interface. This is exactly what beo did with my collision script and his level changing script. That's the exact benefit multiple scripts has and it happened organically within the community in a matter of a month of release. Something LE2 really never had.

 

So although I'm done hoping they'll come back, I, and some others, truly don't understand your reasoning.

[beo6]

i can understand both arguments.

 

however i think the example about a HealthManager is not great because i think managing health is not so complicated that it would require an additional complex script.

 

And for situations like the levelchange script i think a way to add scripts to the flowgraph without requiring an entity where it is attached to would help a lot.

 

That way the only entity with an attached script would be the collision script.

And the Level change script would be directly added in the flowgraph without requiring it to be attached to any entity.

[Rick]

however i think the example about a HealthManager is not great because i think managing health is not so complicated that it would require an additional complex script.

 

I'm not so sure about that myself. There are a few different ways to handle health in games. On top of this though is health scripts that draw and represent that health in many different ways as well because there are hundreds of ways to do that. This is about being able to pick components that can play nice together to build the overall game. You're entire game won't be built this way, but you could benefit from this in many ways. It's about making game development more efficient so we can actually get games finished. That's my view on it anyway. Almost everything can be a script. I do agree logical scripts (no entity needed) is also needed though.

[panz3r]

having one script only means pretty much killing the asset store.

usually in unity when you buy some code from asset store it attaches as a script to the object.

[Josh]

We're not trying to be Unity. Our flowgraph and programming support is what we do uniquely well, and that's what I want to focus on.

[Rick]

Your advantage over unity is the entity programming. That's really where LE shines when compared to Unity in my book. You can use other things from them without being them.

[panz3r]

i am fine with whatever honestly, as i plan to do an mmo i plan to have everything in c++ (so is harder to do complex bots/hacks).

[YouGroove]

panz3r : space mmo you mean ?

The amount of work is reduced, caus characters (design,sculpt,textures, aimations, classes ...) are what can take ages to finish, like terrain levels and buildings (decorative and functionnals).

[ZioRed]

@Josh: the fact that you're not comfortable with component based programming does not mean that it's a mess or less modular (lol I wonder how such a system that is created for modularity is lesser modular, it sounds like the old LE2 API style against the OOP, but now you see that OOP is much more effective so I'm pretty sure you'll see that components is better than singular). It mostly depends on how you (the engine) design it and how the devs use it

 

About single/multiple script management, I was a little disappointed at first like most of you, but since a while I decided to completely drop the LUA things and work only in C++, so I've built my own component based system in C++ and it works well and exactly as I love, so I'm fine now

 

Live example, a component to handle animations, another to handle input for my player gameObject:

Player::Player(string name, Entity* playerModel) : GameObject(name, playerModel)
{
  input = AddComponent<PlayerInput>();
  animation = AddComponent<CharacterAnimation>();
  SetupAnimations();
}

void Player::SetupAnimations()
{
  animation->AddAnimation("idle", 1, 0.05, 200, true);
}

void PlayerInput::LateUpdate()
{
  player->GetComponent<CharacterAnimation>()->PlayAnimation("idle");
}

[YouGroove]

I target casual game on Leadwerks 3.

No need of mage complex scenes, or mage speed, just good, enought fluid game with simple but good graphics.

So even if i touched C++, i stay Lua and components.

 

And yes components are missing with scripting, even if LE3 changed for one script, and to avoid problems on raodmap,

would it be not possible to return to some similar system as multiple scripts ?

[panz3r]

ok let me give an example. i make a "radar" package for my space game. i develop and test it separately and it works like you attach a script to what you need to "blip" in the radar. You attach the display script to the object that will display the radar.

Easy and simple, no copy paste, no side effects to other code ....

[YouGroove]

Let's forget scripts, it will stay one script , let's do like that.

No need to insist anymore.