However you want to look at it, that's how I intend on doing things at the moment (extending through Lua).XianForce wrote:The fact that you said it would "execute the appropriate lua function", shows that it IS a behavior, by the way you've defined your system...? (I was using component/behavior interchangeably)EddieRingle wrote:In my system, there would never be a "collision response" component. Whatever behavior is checking for collisions (if I have the behaviors doing that all, that might even be handled elsewhere), should fix the entity's position (if the entity collided with a solid object), and execute the appropriate lua function (if it exists).
Wrapping My Head Around a Component-Based Architecture
Moderator: PC Supremacists
-
- Chaos Rift Cool Newbie
- Posts: 69
- Joined: Sun Apr 10, 2011 5:58 pm
- Programming Language of Choice: C
- Location: Detroit, MI
Re: Wrapping My Head Around a Component-Based Architecture
- EccentricDuck
- Chaos Rift Junior
- Posts: 305
- Joined: Sun Feb 21, 2010 11:18 pm
- Current Project: Isometric "2.5D" Airship Game
- Favorite Gaming Platforms: PS2, SNES, GBA, PC
- Programming Language of Choice: C#, Python, JScript
- Location: Edmonton, Alberta
Re: Wrapping My Head Around a Component-Based Architecture
Wait, I'm confused. I thought you were going to implement your behaviors via function pointers now - hence a behavior is simply defining an entity as having access to some function that will "do stuff". What you're telling me is that the behavior will instead be implemented inside the Lua script rather than in the engine, so I'm not sure where a function pointer would fit in with that.EddieRingle wrote:However you want to look at it, that's how I intend on doing things at the moment (extending through Lua).XianForce wrote:The fact that you said it would "execute the appropriate lua function", shows that it IS a behavior, by the way you've defined your system...? (I was using component/behavior interchangeably)EddieRingle wrote:In my system, there would never be a "collision response" component. Whatever behavior is checking for collisions (if I have the behaviors doing that all, that might even be handled elsewhere), should fix the entity's position (if the entity collided with a solid object), and execute the appropriate lua function (if it exists).
Re: Wrapping My Head Around a Component-Based Architecture
Which was kind of what I was getting atEccentricDuck wrote:Wait, I'm confused. I thought you were going to implement your behaviors via function pointers now - hence a behavior is simply defining an entity as having access to some function that will "do stuff". What you're telling me is that the behavior will instead be implemented inside the Lua script rather than in the engine, so I'm not sure where a function pointer would fit in with that.EddieRingle wrote:However you want to look at it, that's how I intend on doing things at the moment (extending through Lua).XianForce wrote:The fact that you said it would "execute the appropriate lua function", shows that it IS a behavior, by the way you've defined your system...? (I was using component/behavior interchangeably)EddieRingle wrote:In my system, there would never be a "collision response" component. Whatever behavior is checking for collisions (if I have the behaviors doing that all, that might even be handled elsewhere), should fix the entity's position (if the entity collided with a solid object), and execute the appropriate lua function (if it exists).
-
- Chaos Rift Cool Newbie
- Posts: 69
- Joined: Sun Apr 10, 2011 5:58 pm
- Programming Language of Choice: C
- Location: Detroit, MI
Re: Wrapping My Head Around a Component-Based Architecture
No no. The behaviors are implemented via function pointers and do their job in C/C++. Lua comes into play when I want to execute logic specific to that entity (e.g., what it does when it's used).EccentricDuck wrote:Wait, I'm confused. I thought you were going to implement your behaviors via function pointers now - hence a behavior is simply defining an entity as having access to some function that will "do stuff". What you're telling me is that the behavior will instead be implemented inside the Lua script rather than in the engine, so I'm not sure where a function pointer would fit in with that.EddieRingle wrote:However you want to look at it, that's how I intend on doing things at the moment (extending through Lua).
Example:
behaviors.cpp
Code: Select all
void behavior_usable(Entity *_entity, float _delta) {
// ... Check requirements for use ...
if ( /* can be used */ ) {
g_scripting->ExecuteHook(_entity, "onUse");
}
// ... Remove object from the scene/inventory/whatever, since it's been used ...
}
Code: Select all
...
behaviors = {
...,
"usable"
}
function onUse()
health = entity:GetProperty("health")
if health ~= nil then
health = health + 100
entity:SetProperty("health", health)
end
end
- EccentricDuck
- Chaos Rift Junior
- Posts: 305
- Joined: Sun Feb 21, 2010 11:18 pm
- Current Project: Isometric "2.5D" Airship Game
- Favorite Gaming Platforms: PS2, SNES, GBA, PC
- Programming Language of Choice: C#, Python, JScript
- Location: Edmonton, Alberta
Re: Wrapping My Head Around a Component-Based Architecture
Got it - you call the lua script (if there's one available), then let the engine do its thing, both inside the scope of the function you have the pointer to.