Rick

Banished from your home town, dropped in the middle of the woods left for dead. Use your skill and cunning you attempt to survive the elements; hunt, and keep safe. Environment: The environment can be your best friend or worst enemy. You must use it's resources to help you survive Weather: The weather is constantly changing. Protect yourself from the elements by building shelter. Crafting: Whether it be a creating a tool, or a log cabin. Items you collect can be mixed together to create something new. Tools: Increase your productivity with tools or make a previously impossible job possible. Once made you will need them to work the land. Vitals: The woods are unforgiving you must make sure you take steps not to freeze, starve or injured. Food: Refine your hunter/gatherer instincts by finding food in the forest and fill your stomach. Darkness: Beware the darkness. Terror lurks in the shadow of night. Controls: LMB clear area = Walk LMB Click on object i.e. foliage = Use LMB (Inventory Item) = Drag RMB (Hold) = Rotate camera RMB (Inventory Item) = Use/Equip MW = Zoom In/Out Open Inventory Window = I Open Crafting Window = C Settings Popup = O

Banished from your home town, dropped in the middle of the woods left for dead. Use your skill and cunning you attempt to survive the elements; hunt, and keep safe. Environment: The environment can be your best friend or worst enemy. You must use it's resources to help you survive Weather: The weather is constantly changing. Protect yourself from the elements by building shelter. Crafting: Whether it be a creating a tool, or a log cabin. Items you collect can be mixed together to create something new. Tools: Increase your productivity with tools or make a previously impossible job possible. Once made you will need them to work the land. Vitals: The woods are unforgiving you must make sure you take steps not to freeze, starve or injured. Food: Refine your hunter/gatherer instincts by finding food in the forest and fill your stomach. Darkness: Beware the darkness. Terror lurks in the shadow of night. Controls: LMB clear area = Walk LMB Click on object i.e. foliage = Use LMB (Inventory Item) = Drag RMB (Hold) = Rotate camera RMB (Inventory Item) = Use/Equip MW = Zoom In/Out Open Inventory Window = I Open Crafting Window = C Settings Popup = O View full game

Will this be available through Lua in LE 4.6?

That's why I'm confused as to why you said generated script. No lua script needs to be generated for visual coding really. That's all just configuration of what hooks to what. Code generation adds another layer into the mix.

I'm not following why you want to programmatically generate a script to do this specific game requirement. With the idea of connecting functions to 'events' that's just configuration information between generic/reusable user created scripts that is ran when the starting 'event' is triggered. If you're thinking about a per-entity flowgraph, all you need is the information of the entity, attached scripts, and the connecting information. After all that is loaded, read a text file that stores the config of what hooks to what and since lua is so flexible that string information in the text file should be able to be setup since everything in lua can be accessed with it's string name. So let's imagine entity1 has a health script, sound script, postprocessing script attached to it. The per entity flowgraph could just be a text file config file I would think. When saving you're saving the 'event' variable name and what script it belongs to and the called function and what script that belongs to. All that information can be stored as a string and read back as a string and then you can get all the actual lua objects from their string names. So not following the idea of generating a script to do this functionality.

Because that script has properties like the current noise does. So you need a way to capture those and combine it with the functionality. The noise script can emit events as well like onFinishedPlaying, onHalfWayThrough whatever. A script is just a class to hold all that information, then you make instances of it by attaching it to entities. It's not engine commands. We have our own scripts that do a lot of gameplay specific events and functions that we would want to hook up as well. OnScorePoint, OnFoundTreasure, etc etc. Stuff that you can't make common commands for but are useful for our games scripts. Now, once you've attached a bunch of scripts to an entity then yes you need a place to connect everything between those scripts and a per entity flowgraph is a good idea on how to do that actually. One could do another script that is specific to that entity and do it all by typing the code if they wanted to do that but a flowgraph for each entity would be a really cool way to do that. If you could save the entity as a prefab and it has all that information (scripts, flowgraph, model, etc) that would be cool too!

You would never have/want health information inside a sound script. That script has stopped being generic enough for reuse at that point and it's now very "leaky". Other responsibility is leaking into that script. If you want 3 instances of that script all playing sound on different events you either bloat the 1 script to handle all use cases (which no reuseable script will know all possible use cases) or you create 3 different scripts. Both are bad options. There are all sorts of different events that you want to play a sound and trying to build in common functions or sharing information directly inside another script is just a mess waiting to happen and again kills reuse. Being able to link the event to a function in the editor is the way to go. Those other ways you're showing can't really be done via the editor unless you start doing code generation inside the scripts themselves which leads to a whole other mess. I think your StartThePain()/StopThePain() is the right idea as long as the idea is that I can connect (in another script or via editor) my sound scripts Play() and Stop() function to those functions (events). That way the 2 scripts are unaware of each other on the inside of themselves. The sound script has no knowledge internally of the health script and vice versa. A much cleaner and reusable situation.

Just to put a more concrete example with this. Let's say the goal is to have a heartbeat sound play when health is < 25% and to also add pulsing red post process effect around the edges of the screen. A reusable way to do something like this so that others can modify it to their needs would be to: Create a Noise.lua script. This would have a property of what sound to play and a function Play() (some other properties as well). Create a HurtPostProcessing.lua script. It will do the pulsating red boarder when you call it's TurnOn() function and you can turn it off by calling it's TurnOff(). It can have properties as well to control certain aspects like how fast the pulsating is. Create a Health.lua script that has a Hurt() function and an onHealthBelowTwentyFivePercent event. It also has properties like max health and such. All 3 of these scripts are separate and were created by 3 different people and put in the shop. I come along and add all 3 scripts to my player entity. I set the noise.lua wav file property to some heavy breathing sound and I connect it's Play() function to the Health scripts onHealthBelowTwentyFivePercent. I do the same for the HurtPostProcessing script. I now have 3 scripts that knew nothing about each other working together help me reach my goal effect. This is the benefit of "events" and event programming. If we used the polling and shared variable way of doing things this wouldn't be ideal. My reusable Noise script should never know or care about a Health script. Inside it's Update() method it shouldn't be checking if self.health is < 25% because self.health has nothing to do with Noises. It couldn't possible know all the use cases for playing noises. The main benefit of attaching multiple scripts is the reusability and cleanliness of code. Put a nice user interface on top of hooking all this up and you have a very friendly system to make complex functionality without much coding by the user. This gives the coders a framework to create reusable scripts, and down the line a revenue stream by selling those scripts.

You do that for the reason my blog post talks about. When making reusable scripts for others to use, you create events for things that happen inside that script. Users connect whatever they want to that scripts events (I wouldn't know what they want to do at the time of writing my reusable script) and when I fire them inside my reusable script their custom code is called. If a health script wanted to tell the outside world when the health dropped below 50% then inside it's Hurt() function when health is < 50% is would raise or call an event. Since these are functions in your example it can just call the function onHealthBelowFiftyPercent() I guess but internally that function would be empty and only exists for others to connect to it so they can call their functions. So in that regard it acts more like an event since it's sole purpose is for others to just connect to it and it's body is empty.

So :Connect() is an entity function. Can we have our own event? In the example above "Collision" can be thought of as an event. When it's called/raised you call the connected functions. Can we have our own lua defined event that we can call and it'll call all the connected functions? -- treating this more as an event that I can call and it'll in turn raise all the connected functions function Script:MyScriptsEvent() end self:Connect("MyScriptsEvent", target, "Foo") So when inside self I "raise" or call MyScriptsEvent function it'll call Foo() from target? Why do you do the AddArg()? Is that for the C++ side of things? Lua can do variable number of arguments so you could capture all arguments after the 3rd one and pack them off in a table and then unpack them when you make the call and they'll fall in the right order.

Update is the "event". In all the stuff you're saying you are linking functions to "events". Then when that "event" is fired/called it's actually calling the function we assigned to it. Being able to assign multiple functions would be nice. In your example your 2nd param is basically a script in itself as it's getting executed, but before you were assigning things to straight functions to be called and so I was wondering if you could assign to multiple functions and when Update is called it'll loop through and make the call to all functions attached. If you changed the name of Update to onUpdate then it becomes clearer that it's basically an event that the engine is raising every frame. There are other events like onCollision. Same idea. You're simply allowing users to have their functions called when these events are raised (when those engine functions are called). That's the premise of my blog post. Raising and event is just like calling a function, except the event can have N number of functions that the user assigned to be called when the event was raised. It allows one to make events when they don't know what a user wants to do with said event. It gives them the flexibility to do whatever they want when an event is raised. It's easier to think about a GUI button. When it's pressed the UI library "should" raise and event and the user would have attached a function (or more than 1) to that event that gets called. This is opposed to the polling that you use in your GUI system. So you either poll or use events.

Do you have it so we can connect multiple functions to an "event"?

I just want to note that the high level concept you are doing in that example is basically connecting event(s) to functions. A great way to program :). I have multiple blogs on that from Roland and me back a year or so ago. It handles arguments and other things like criteria to call the function or not (returns a boolean to call or not. comes in handy).

I'm well aware of the benefits of adding multiple scripts to entities. Some have been asking for it and simulating it in LE for a long time :). That's not the question. The question really is the best way to do it. Giving the ability while not pigeonholing you into a style is generally what I think is best/safest for the core part of the engine. Then you can add something like this on top of that. The value attaching thing is a great idea for sure!

I hope my post didn't come off as it was a bad idea. I said there are pluses to doing it this way and just needs to be promoted and supported by Josh (he can't just tell people to name their functions this way he needs to built them into entity scripts just like UpdateWorld() and others are). I mentioned that this is completely different from what Josh has wanted in the past. Josh was always more of a library vs framework guy. LE was always a library. it gave you generic ways to create games and/or multimedia apps. What he's saying now is way more specific and funnels people towards a common way of creating these apps/games. A library is more like a bunch of baking tools and ingredients. You have everything you need to bake something but it's 100% up to you on how to use those tools and ingredients to do it. A framework is more like following directions on how to bake something. It gives detailed guidelines on how to do it, but still has a little room for you to add your own special mix to set it apart. Josh was always a library guy with LE and with this blog we can see the shift which is surprising to us who have been around awhile.