New class in Lua?

[MatejZajacik]

Hello, folks.

So far, I've been impressed with the fusion of the Worldcraft-style editor and the general style of work, and Lua. But, of course, I have some questions.

Is it possible to create a new class / game object entirely in Lua? For instance, I want to create an item that, when picked up, reduces incoming damage by 50% for 10 seconds. Is this possible without touching C++?

[Carsten]

Hi MatejZajacik,
welcome to the Cafu forums!

Is it possible to create a new class / game object entirely in Lua? For instance, I want to create an item that, when picked up, reduces incoming damage by 50% for 10 seconds. Is this possible without touching C++?

This is not possible at this time -- but we're actively working on it!

Currently, although we have a sound basis for map/entity scripting, feature additions still require hacking and adding to the C++ code in virtually all instances.

However, we're currently switching from an inheritance-based entity hierarchy to a "component system". For more details, see

• the original suggestion and discussion in this thread, and
• a summary in this news posting.

Since then, I've completed the implementation of a component system for our GUI system. This was a great success, and I'll make another news posting with the latest results soon (I'm working on updating the documentation right now).

Immediately after that, I'll start implementing the component system for map entities, too. This will re-use all the basic work (and in fact use 90% of the same code) that went into the component system for the GUI windows, and thus will proceed much quicker than before.

As one of the results of this work, adding new behavior to game objects without having to resort to C++ programming will become possible.

[MatejZajacik]

You have to be kidding me... That's exactly what I've been dreaming of - component system in an FPS engine with a solid level editor. Wow. I'm really looking forward to it, man, like... really!

So if I understand it correctly, one will be able to create components in Lua and define objects (consisting of components) in Lua, too, right? So an item as I described above will be easy to implement without touching C++. If yes, man, I'm happy.

Yo and thank you for a quick response. I will read those posts later when I get some free time.

[Carsten]

You have to be kidding me... That's exactly what I've been dreaming of - component system in an FPS engine with a solid level editor. Wow. I'm really looking forward to it, man, like... really!

It's great to hear that, thanks!

So if I understand it correctly, one will be able to create components in Lua and define objects (consisting of components) in Lua, too, right? So an item as I described above will be easy to implement without touching C++. If yes, man, I'm happy.

Yes, that hits the mark.

Usually though, you'd use the graphical editor to create new objects (e.g. the windows in the GUI system, or later the entities in the game maps) and to assign components to them, and to set the properties of the components.
You can however dynamically instantiate objects and the components they are composed of, and do all of their configuration etc., in Lua, too.

In both cases, Lua scripts would be used for implementing the "behaviour", e.g. handling event callbacks, etc.

(For our windows in the GUI system, all this is implemented and working already.)

For contrast, as an example of what is not possible is adding new components in Lua that no one has ever thought of. For example, today we don't have windows (or in fact, window components) that can make sounds. If we wanted to have window components that can do that, implementing a new component in C++ is required. But this kind of feature additions is really the only place where there is a natural limit for what can be done via scripting.

But in summary, yes, when the component system has been ported to game entities, you can do as you described entirely in Lua.

[MatejZajacik]

Wonderful news!

So you're basically shooting for a system very similar to Unity, where you compose game objects in the editor (in Cafu, I believe this will be the level editor): create an empty game object, add components, play with the components' variables, etc., play test, and when happy with the results, save the game object as a prefab that can be later on easily placed in any map.

One great feature of Unity is that they have archetypes (just another name for a prefab), but they work a bit differently from what we know as a prefab from the Hammer editor. When you place an instance of an archetype into a map, and then you make changes to the archetype itself (not the instance), the changes will be propagated to all instances of the archetype. However, variables already fiddled with in an instance will not be changed.

Example. An archetype for the item I spoke about....
A.effectDuration = 10
A.reductionModifier = 0.5

Now you place an instance (I) of A into a map and you change I.reductionModifier to 0.25. After some time, you go back to A and change A.effectDuration to 5. Now when you load up your map, the resulting I will have:
I.effectDuration = 5
I.reductionModifier = 0.25

If we changed A.reductionModifier to, say, 0.75, it would have had no effect on the instance I, because that variable has been marked as changed on instance level.

This behaviour is very neat and useful in Unity. Basically, all changes on archetype level are propagated to all instances (when the map loads or whatever) unless previously changed from default values on instance level.

[Carsten]

So you're basically shooting for a system very similar to Unity, where you compose game objects in the editor (in Cafu, I believe this will be the level editor): create an empty game object, add components, play with the components' variables, etc., play test, and when happy with the results, save the game object as a prefab that can be later on easily placed in any map.

I don't know much about Unity, but yes, that summarizes the envisioned goal very well.

For example, we would no longer have one C++ class per monster type, but instead each monster type would simply be a prefab. (Which of course requires that we provide proper and suitable components beforehand.)

One great feature of Unity is that they have archetypes (just another name for a prefab), but they work a bit differently from what we know as a prefab from the Hammer editor. When you place an instance of an archetype into a map, and then you make changes to the archetype itself (not the instance), the changes will be propagated to all instances of the archetype. However, variables already fiddled with in an instance will not be changed.

Yes! This is exactly how I wanted to do this!

(This is also the only big part that I can think of that, in our GUI component-system, is not yet implemented. It's not particularly difficult, but a lot of time consuming work, and in fact I've not yet planned when this would best be done: Either now, before the work on map entities is begun (delaying this further), or only later, when the component-system is used with map entities already.)

[MatejZajacik]

Great. Seems we are on the very same wave length on this.

If it was up to my naive myself to decide, I'd definitely start working on "componenting" entities, because I can't wait for it.

[deamonpog]

Pardon me, because i am not a big SE
So, what you mean by a Component system ?
is it something like,
When creating a character type,
1.) Create a base object.( it has an array(or a list) of components)
2.) Add components such as Mesh and Animations to it. (using some function like AddComponent() )

That is how things go in UDK.

[Carsten]

Hi deamonpog,

Pardon me, because i am not a big SE
So, what you mean by a Component system ?
is it something like,
When creating a character type,
1.) Create a base object.( it has an array(or a list) of components)
2.) Add components such as Mesh and Animations to it. (using some function like AddComponent() )

Yes, exactly like this!

Please see my first post above, where I've also linked to other posts with additional details.

I realize that I should post some "official" summary information about this at our News page, which until now is only delayed because I'm very busy with actually implementing all this (see the repository at https://bitbucket.org/cafu/cafu for details), but also because I hoped to come up with at least basic documentation about the GUI component system and some details at the Feature List beforehand.

But I've taken plenty of notes already, and will fill in all the missing prose as soon as I can -- promised!

[deamonpog]

thanks Carsten That is awesome and I wish you best of luck with that too.