[LE3] : detect entity in bounding box centered on goblin

[YouGroove]

Attach this script to a goblin you place in the level.

Any entity entering the bouding box deifned in the code will turn in red color.

 

function Callback(entity,extra)

--We only want to execute this on models.
--If we don't check the class we will change the color of the light, too.
if (entity:GetClass()==Object.ModelClass) then

local v = Vec3()
v = extra
entity:SetColor(v.r,v.g,v.B)
end
end

function Script:UpdatePhysics()

...

      --Create an axis-aligned bounding box for testing.
      --This will occupy an area 10x10x10 centered around the position -5,0,0.
      --So it will intersect all entities on the left
      local position = self.entity:GetPosition()
       local aabb = AABB(position.x-2,position.y+1,position.z-2,position.x+2,position.y+1,position.z+2)

        --We're going to pass a Vec3 to the callback in the extra parameter
         local v = Vec3(1,0,0)

         --Execute the callback for all entities that intersect the bounding box.
         --The intersected entities will turn red.
        App.world:ForEachEntityInAABBDo(aabb,"Callback",v)

....

end

 

 

You can use that to detect any entity entering the volume.

Can be used to call some attack or pursue function, nad like Goblin.AI , it should be called not all frames fro detection but each 2 seconds would be enought (optimisation).

[Rick]

Would be cool if you fired an output so it could be used in flowgraph

[YouGroove]

For now i prefer to saty simple with Lua templates than FlowGraphs.

I will have to test them, but i'm really not sure how it will help in game development ?

For non programmers perhaps ?

Actually Lua scripts and exposed variables are just great to any non programmer adjsut values could it be camera, player attributes etc ..

 

But ok i'll try to look at Flowgraph and how to do it.

[Rick]

I'm really getting tired of the, flowgraphs are for non programmers, idea (this isn't just you saying this). Flowgraphs speed up development and make it easier for you to get/test interactions in your level and reuse these components for multiple levels and games. Programmer or not, the "negatives" I hear are often from people who haven't even used them, which is just insane. I'm a programmer and I'm making these nodes for anyone who wants to get complex interactions that would otherwise just be silly to sit and code all together. You'd end up copying and pasting all sorts of different code together to get the same thing you can do with a flowgraph much faster. If at any point you find yourself copying and pasting code all over the place, you're doing it wrong

 

Josh's switch script is a perfect (but small) example of why generic flowgraph components are ideal. He hardcoded sound files into that script, making that switch require manual changing to be reusable. That's a waste or time and resources to do for every game you have. Multiply that by every script/functionality you need for an entire game and all the different level interactions you will need and you've just wasted a bunch of dev time. A switch in itself shouldn't have sound files hardcoded in it at all. A switch should just be a switch. It should turn something on or toggle something. That doesn't always require a sound, but if it does, then just insert a sound node and you're good to go in seconds.

 

Insert a toolbox of flowgraph components and you can get all these interactions up and running and combine things in an easy way and get complex behavior in seconds. You can easily mix and match these components to get really cool effects and functionality in much faster than coding each interaction specifically.

 

The only thing I want to know is how far can we push it with flowgraphs. I think we can push it pretty far myself, but we'll see in time. I'm pretty certain I can create a fairly basic FPS game 100% with flowgraphs. I plan on making GUI elements to be exposed via the flowgraph. Some AI commands via flowgraphs. You name it. I'm not seeing anything at this point yet that suggests this can't be done.

[YouGroove]

Good points Rick.

I would just want little details on how it's done behind the scene ? Josh saying it was for doing a complete game.

I'm just curious ? is it less optimized than pure script ? or anything else ?

 

Perhas the best way is to test ourselves making a real game with Flowgraphs only