Relay

[Josh]

I actually have this working in an example. This is just a relay that accepts an input and sends it after a pause:

function actor:Start()
self.delay = 3000
self.queuedevents = {}
end

function actor:Activate()
self:AddEvent("Activate")
end

function actor:Deactivate()
self:AddEvent("Deactivate")
end

function actor:Enable()
self:AddEvent("Enable")
end

function actor:Disable()
self:AddEvent("Disable")
end

function actor:AddEvent(name)
local event = {}
event.name = name
event.time = AppTime() + self.delay
table.insert(self.queuedevents,event)
end

function actor:Update()
local n,event,t
t=AppTime()
for n,event in pairs(self.queuedevents) do
	if t>event.time then
		self:CallOutputs(event.name)
		self.queuedevents[n]=nil
	end
end
end

[Josh]

Here's a C++ example that makes a button open a door after a delay. I don't recommend setting these relationships up in code, but it does show what's going on under the hood:

	//Create the button
Model* buttonmodel = LoadModel("button.mdl");
Actor* button = LoadActor("button.lua",buttonmodel);

//Create a relay.  Since no entity is defined, it will just create a pivot
Actor* relay = LoadActor("relay.lua");

//Create the door
Model* doormodel = LoadModel("door.mdl");
Actor* door = LoadActor("door.lua",doormodel);

//Set outputs
new Output(button,"Activate",relay,"Activate");
new Output(relay,"Activate",door,"Open");

//Set the delay
relay->SetInt("delay",5000);

//And now to set off the sequence:
button->CallOutputs("Activate");

[Josh]

And here's what a flowgraph for the above sequence would look like:

[Josh]

Ladies and gentlemen, here's the money shot. Arguments can be added to the link between actors. In the example below, activating the button will call the platform's MoveTo() function, passing the Marker's property member and the Constant's value member to it. The platform script will then use that position as the target it is moving towards, and move to it until it reaches that point, at the given speed.

 

 

And that is my idea for how gameplay will be made in Leadwerks Engine 3.

 

The code side of this is actually working. I can set up outputs, arguments, and actor scripts can provide either members or functions that return a value for the arguments. This is only possible because of the flexibility of Lua. It is very adaptable with differing numbers of function parameters and return values, so you can adjust these nodes without worrying about perfectly matching argument types and count.

[wailingmonkey]

if I read your last 2 sentences correctly then, the actual order of placement of arguments (marker and constant) along the node links

makes no difference to 'Platform' in how it interprets the value? (I'm thinking of this as a variation to the way a render tree in XSI

works...there, you have open slots to plug your nodes into, like diffuse/specular/transparency etc.---with what you're showing above,

all available 'slots' that can be plugged into 'Button' lie on the link between it and it's target node, 'Platform'. Same basic concept,

just different means to send values/properties, yes?)

[Admin]

The arguments are marked on the line connecting Button0 and Platform, in the order they will be supplied to the function. There will be a visual representation of the available arguments, even when nothing is connected to them.

 

Lua allows a fair degree of flexibility without crashing, which is probably why the Crysis flowgraph editor works pretty well.

[flachdrache]

Hmmm, so i could add actions to "dead" physical objects in the scene ?! A chain of commands for a big explosion of some fuel tank would be :

 

while object.health > 0 do
 if object.health is decreased then
   object.health = object.health - object.decrease
 end
else
 object:Destroy()
end

function object:Destroy()

 ... blabla

 GetEntityPosition(self);

 self.spawn_explosion;
 self.spawn_shakeCamera;
 self.spawn_explosionEmmiter;

 ... blabla
end

 

How complicated would the flowgraph get - i mean, its just one object but several events and

would such flowgraph_eventbehavior be saved to file for being used again and again ( x times the same fuelTank = sameExplosion behavior ) ?

 

thx

[L B]

So... this is basically delegates?

[TylerH]

It's basically a fully-featured input/output system with per-actor delegates and events. I like the idea of having the arguements linked on the actual line linking the nodes as opposed to the target flowgraph node Josh.

 

So from my understanding:

 

A line links one actor's output to another actor''s input.

The arguments you can pass to the actor's input are fed into this visual line representation.

 

Makes perfect sense.

[Josh]

So... this is basically delegates?

Visually, with arguments, yes. Then you have a bunch of abstract game logic scripts that move platforms around, open and close doors, perform logic, turn lights on and off, etc.

 

So to make something like a Mario 64 level, you drop in some pre-coded AI , make some moving platforms with the flowgraph, and execute a script that makes a little guy run around. There's your game. Select the File>Publish menu item, package it up, and submit to Steam, the App store, or upload it here. And if you need to modify code at any time, you can always drill down to the script level or even C++ code. So it's super easy and visual without crippling it.

 

flachdrache, your example could be done in script like this:

function actor:Update()
if onfire==true then
	health = health - 1
	if health < 1 then
		self:Explode()
	end
end
end

function actor:Explode()
local emitter = CreateEmitter()
--do stuff to make an explosion
delete self
end

I don't know if you would want to make flowgraphs for reusable behavior like that. I see it as a per-scene visual script that controls gameplay logic.

 

Remember in the original Unreal Tournament, there is one map that has a room with a weapon inside, and there's a button outside the door that will seal the room and incinerate anyone in it? That's a good example of what I have in mind.

[Josh]

Here's an "If.lua" logical script:

function actor:Evaluate(condition)
if condition==true then
	self:CallOutputs("IsTrue")
else
	self:CallOutputs("IsFalse")
end
end

[Rick]

Ladies and gentlemen, here's the money shot. Arguments can be added to the link between actors. In the example below, activating the button will call the platform's MoveTo() function, passing the Marker's property member and the Constant's value member to it. The platform script will then use that position as the target it is moving towards, and move to it until it reaches that point, at the given speed.

 

Generally those would be parameters to the MoveTo node and not something that sits on the connector. What most flowgraphs do is have parameters and return values at the bottom of the node that the node can take. You can hardcode them via a grid that shows the same values or you can assign them from variables like you have, but connecting them to the connectors doesn't look all that great or clean.

 

This is only possible because of the flexibility of Lua.

 

Actually C# can do the same thing. Just saying.

[Josh]

Generally those would be parameters to the MoveTo node and not something that sits on the connector.

If you did it that way, it would be a value you can set in the properties editor. If the Platform has a member "targetentitytomoveto" this would appear in the properties dialog, and you could drag an entity onto it. The flowgraph controls actions, not values.

 

I supposed you could have a "targetentitytomoveto" member in the Platform script that can be edited in the properties dialog, and then the optional argument in the flowgraph could be used to change this.

 

The possibilities are endless. It's just a matter of laying out a foundation of scripts that works consistently and predictably.

[Rick]

I supposed you could have a "targetentitytomoveto" member in the Platform script that can be edited in the properties dialog, and then the optional argument in the flowgraph could be used to change this.

 

Yeah, this would be exactly what you would do. This is the general workings of most flowgraphs anyway. You have specific nodes that do specific tasks against some data and can return data and continue flow. Eventually you'll get into basic math nodes that will say add 2 values together and the returned value will be used in another node, etc.

 

The interesting part I think about all of this is that it looks like you can have multiple inputs to 1 output at which point the flowgraph could get confusing to read because those nodes can then have outputs and so the question might be what order are the outputs being called because that could be important to know if those outputs need to use data between them.

[Josh]

They would get called in the order the script calls them in:

function actor:Activate()
CallOutputs("DoSomething")
CallOutputs("DoSomethingElse")
CallOutputs("MakeMeACake")
end

[Rick]

So in a flowgraph situation it would be the order of how you setup the connectors? In that situation you may want to place a number on the connector which shows what order they are in or else coming back to a flowgraph after 2 months you wouldn't know as you'd just have 3 lines coming out from 1 output and going to 3 different inputs without knowing anything about the order they were originally connected.

 

The confusing thing about having this ability is visually it will look as if they are all running at the same time.

[Josh]

You can't display an order, because the outputs can be called from different place in the script, in a different order:

function actor:Activate()
       CallOutputs("DoSomething")
       CallOutputs("DoSomethingElse")
       CallOutputs("MakeMeACake")
end

function actor:Whatever()
       CallOutputs("MakeMeACake")
       CallOutputs("DoSomethingElse")
end

I am guessing if the flowgraph gets too complicated to understand, you are probably using it to do stuff that should be handled in script code. The flowgraph is for the interaction of objects, not really for coding a single object's behavior.

[Rick]

You can't display an order, because the outputs can be called from different place in the script, in a different order:

 

Correct me if I'm wrong but in the flowgraph you are making the connections between inputs and outputs of specific nodes. So I would assume that when making that connection for that instance of that node you know what outputs and when they were connected. Knowing that would mean per each node instance you could know the order they were connected?

 

 

I am guessing if the flowgraph gets too complicated to understand, you are probably using it to do stuff that should be handled in script code. The flowgraph is for the interaction of objects, not really for coding a single object's behavior.

 

Well, I think you have to be prepared to handle anything your system can. Over at UDK they aren't telling people "we didn't mean for you to do that with our flowgraphs". Because I am going to push this thing to the limits and so will others

[achrystie]

Ok, some questions.

 

1) Is the LUA code for your relay attached to/reside within the specific node in the flowgraph called relay, so I can just double click that and it opens up my code IDE so I can edit it?

2) You have a second set of code that shows creating the relay and making it an actor, where does this code reside? Is it automatically created if I make an object (probably a null) in the scene editor called relay and assign some parameter to it to make it an actor, or is it created when I decide to add it as a node in the flowgraph, or am I writing a separate code file somewhere to create this thing and make it an actor?

3) Along similar lines, where does the code to create the button and the door reside, in a separate file, in/attached to each node that is made, or is it just a parameter I can flag for those object inside the Leadwerks scene editor for the physical models I've loaded that are a "door" and a "button" in that given scene?

4) Are there event functions inside the button.lua file and the door.lua file that is attached to the button node as well, like actor.Start(), etc.?

5) Is each node shareable as a file type, so we have some sort of flowgraph node repository on the site here that people can tap into?

6) Can I package the whole flowgraph up into a node of its own and reuse it, or share it?

7) Can I track and adjust the variable changes in the flowgraph and can I at least temporarily tweak constant values somewhere while the game is running?

To put it more simply, can I expose the delay on the relay to the editor and change the value based on my observation as the game runs and I click the button in game?

 

In general I think this is a good idea, and if you read other forums, how objects communicate with each other/pass variables, has been a sticking point for people in the past who are just starting out trying to make a game.

[ChrisV]

Sorry for bringing this back to life, but I was wondering, how is the progress on this, Josh? Is this still been worked on for LE3? ?

I really like the idea of a visual programming flowgraph editor. This might have been discussed before, and I'm sure some people will be against the idea, but there are an equal (or maybe greater) amount of people that would like this feature in the Leadwerks engine.

All the major game engines have such a feature, and it increases the interest for game developers (people with less programming skills) and also for the amount of games being brought on the market.

It would also help getting basic demos or concept ideas done faster. And, for the programmers out there, it wouldn't make much a difference, because having a visual programming flowgraph editor in the engine, doesn't mean you have to use it. And...such an editor would still have its limits aswell, so there would always be room for advanced programmers do add their code.

Anyways, I'm hoping this is still a feature being worked on, and hopefully easy enough to use for game developers who have good understanding of game logic, but less of programming languages.

 

Cheers

[Josh]

I'm not interested in making a visual programming language. If that's what people wanted, they would be using the C4 Engine:

 

Once you start writing a real program with such a system, it quickly becomes unmanageable. People might say they want this, but that is because they have no idea how complex the actual result would be. You end up with something neither artists nor programmers understand.

 

Instead, I am interested in a system to connect objects to control interactions using predefined functions. The code that makes things happen is in script, and the visual tool lets the level designer control sequences of events.

[Benton]

YES! We don't need visual scripting, if you want that get Gamemaker. This makes sending events easy Right?

[Josh]

YES! We don't need visual scripting, if you want that get Gamemaker. This makes sending events easy Right?

It's a way to let designers access script functions in a visual manner. Script programmers can write in their functionality, then have it available for everyone to use in a standard framework.

[Benton]

So say I have a door. I want it to open when someone goes near it. So I create code to open the door, and then use blocks to say: if "player" near door run dooropen.lua?

[ChrisV]

I'm not interested in making a visual programming language.

Well, that's not what I want either. But, more like a visual editor to set up game logic.

 

We don't need visual scripting, if you want that get Gamemaker.

What's Gamemaker? Never used that.