Compositions of Game Objects

[matej_zajacik]

Hello, guys.

 

 

I'm coming from Unity and having played around with the Steam demo of Leadwerks 3, I'm very curious about how you normally go about composing your game objects. In Unity, you create components (scripts) where each component adds some kind of functionality to any game object you add it to. I read on a blog about how the devs of Leadwerks want to compatrmentalize logic in small chunks (much like Unity does it I guess), but in the example maps I see no such thing. You have an object (say, a CSG primitive) and you can add a single Lua script to it.

 

 

So how do I add multiple scripts to a single object where each script adds some functionality?

 

 

From what I've seen, both FPSPlayer and AIMonster had their own movement, health, and damage handling implementations. A lot of the same (or very similar) code copied over. I find this worrying. Is there a modular way to do this?

 

 

Note: I'd prefer to work in Lua. Coz Lua rocks!

[Rick]

So how do I add multiple scripts to a single object where each script adds some functionality?

 

You don't. This was a debate some time ago and some still would want it, but the engine dev decided against it as he thought it didn't add much benefit as he deemed those scripts needed some kind of connection to make them specific and less generic which is the main benefit of multiple scripts. Some don't agree with that still, but attaching 1 script only does simplify things. What you can do is make your own lua "classes" that have functionality you want and add those to the script of an object. This is probably the best workaround to this.

 

The best advice is that this isn't Unity and so even though that's your background it's best to not come in with that mentality to save yourself any frustration. The Leadwerks API is great and so easy to work with. Very little math is required to make a game which is nice and speeds development up. Focus on the good and note the bad and see which has more pros

[matej_zajacik]

Thank you, Rick. Now it's a lot clearer to me, although the blog post is confusing.

 

For me, Leadwerks 3 is an interesting and attractive alternative to Unity 5 and Unreal 4 (both of which utilize component-based design). The main draw is Lua, of course. And the fact that you can actually alter the main loop.

[Josh]

After using a multiple-script approach I found it was a nice idea that didn't work in real life. It is very rare to find a situation where you have two scripts that behave independently that you would want to use on the same object. You can do things like make a box that spins AND changes colors, but when you get into real gameplay scripts the paradigm falls apart. You start adding "managers" for every little thing you can compartmentalize, and it ends up requiring a bunch of different scripts to just set up simple things.

 

I found the one to one script:entity approach to be much easier and more efficient. Because you can just call TakeDamage() and things like it is much easier for the users to create reusable scripts, because we only have to agree on one function name ("TakeDamage"). Whereas if we used multiple scripts, we would have to agree on a function name, and a prefix on what the script name should be ("HealthManager.TakeDamage()")...and then some people would make another system for health with a different name, and then I would want to change something I did a long time ago because I want some different behavior, but now I can't because it would break a lot of things. It was a nightmare trying to figure out which parts should be separated out into different scripts, and then realizing I needed to do something else and couldn't without creating yet another separate script for the others to both access.

 

The fact is that code that controls an entity in game is not easily compartmentalized into separate subcategories. It's just a programming fad that was going around five years ago. There's a thread on GameDev.net where a coder announces he is implementing a system like that to make his life easier, with much applause and fanfare, and then he slowly realizes he is now struggling against the system he built and all his effort is being spent fulfilling a paradigm instead of producing output, and he finally scraps the whole thing. I went through the same process and quickly killed it once I realized what it meant for end users. There's no way I can stand up and tell users they have to attach a bunch of different scripts to make an enemy behave, and pretend that is easy.

 

I am confident that using a one-to-one script / entity paradigm is a major advantage Leadwerks has, after having worked with both approaches.

[beo6]

i would agree, but it would still be nice to also use flowgraph scripts without first attaching it to a pivot.

Why would i need to have for example a timer needing to be attached to an entity?

[Rick]

I find multiple scripts to basically be just like designing any other system. In C++ I create many classes to do various things and link them together. Right now basically I make Lua "classes" for various functionality and add them into the 1 script and hook them up. This isn't any different than multiple scripts though. This just makes me have to create a container scripts to attach to the entity that holds my other Lua classes that actually have the functionality manually. In a sense LE sort of does this with the AnimationManager script and that's good because it's good to logically break up the code for readability and maintainability.

[Einlander]

i would agree, but it would still be nice to also use flowgraph scripts without first attaching it to a pivot.

Why would i need to have for example a timer needing to be attached to an entity?

 

I was going to add this to the is request forum and still am after I do some prototyping. This would allow people to build MASSIVE libraries of code and allow a person to hook up nodes and never have to program. Imagine: You drop an entity and attach a node that exposes the default script functions. You then link a fps node to it, an inventory node to the fps node and a use item node to the inventory one. Now you have a fps player with an inventory where you can uses items. Add a ui node to the inventory, now you have a backpack that you can open.

[Josh]

I have actually considered the additional of "virtual" entities, entities that only consist of a script in the flowgraph and nothing in the 3D world. Thanks for the feedback.