Behavior/Component System discussion
by Jeff Raab · in Torque 3D Professional · 06/02/2013 (6:36 am) · 63 replies
It seemed like a better idea to do proper discussion about what my blog covered in a forum thread, since they're, you know, for discussing.
So this thread is more or less going to be about 2 things. Release plans, and suggestions on what behaviors/components should come with as a starter/example set.
I mentioned in my comment that my personal goal with the Actor class and it's use of components is to pretty much get rid of ShapeBase and most of the need for specialized object classes derived from it by exploiting the behaviors system.
So any suggestions on examples are welcome, even if it's something like 'the ShapeBaseImage state machine as a behavior' or 'the entire player physics/movement code'. Lets just throw ideas at the wall and see which ideas stick as a good starting batch out the door.
Ones that will be released with this, regardless:
Core behaviors:
BaseBehavior - script-only behavior, no engine side work, general purpose for gameplay stuff
RenderBehavior - core render behavior template that other render behaviors would derive from
TickBehavior - hooks with Actor's processTick allowing you to do ticked code with the behaviors
NetworkBehavior - this will be useful as a more direct approach to gameplay/event feedback to the client than having to jump hoops through the commandTo* calls.
Unique Behaviors:
RenderShape - accepts a shape file, and renders it
RenderBillboard - accepts a material and renders a billboard of it
AnimationController - if you have a RenderShape, you can do this, and have the ability to animate the shape. What animations can be used will be entirely script defined. No need for the ActionAnimationList.
ControlObject - this lets a client take control of this object. Allows you to make use of the next behavior...
UpdateMove - this lets you intercept the move updates from a controller object and move the shape around
This is what I've got slated thus far. Please throw out your own suggestions and we can try and hash out a solid list of things people need/want to see when it comes out.
So this thread is more or less going to be about 2 things. Release plans, and suggestions on what behaviors/components should come with as a starter/example set.
I mentioned in my comment that my personal goal with the Actor class and it's use of components is to pretty much get rid of ShapeBase and most of the need for specialized object classes derived from it by exploiting the behaviors system.
So any suggestions on examples are welcome, even if it's something like 'the ShapeBaseImage state machine as a behavior' or 'the entire player physics/movement code'. Lets just throw ideas at the wall and see which ideas stick as a good starting batch out the door.
Ones that will be released with this, regardless:
Core behaviors:
BaseBehavior - script-only behavior, no engine side work, general purpose for gameplay stuff
RenderBehavior - core render behavior template that other render behaviors would derive from
TickBehavior - hooks with Actor's processTick allowing you to do ticked code with the behaviors
NetworkBehavior - this will be useful as a more direct approach to gameplay/event feedback to the client than having to jump hoops through the commandTo* calls.
Unique Behaviors:
RenderShape - accepts a shape file, and renders it
RenderBillboard - accepts a material and renders a billboard of it
AnimationController - if you have a RenderShape, you can do this, and have the ability to animate the shape. What animations can be used will be entirely script defined. No need for the ActionAnimationList.
ControlObject - this lets a client take control of this object. Allows you to make use of the next behavior...
UpdateMove - this lets you intercept the move updates from a controller object and move the shape around
This is what I've got slated thus far. Please throw out your own suggestions and we can try and hash out a solid list of things people need/want to see when it comes out.
#42
am sure there are plenty of us here who are just waiting to get
our hands at it!
08/03/2013 (8:55 am)
great news @Jeff Raabam sure there are plenty of us here who are just waiting to get
our hands at it!
#43
08/03/2013 (9:51 pm)
Can't wait :).
#44
That said, I got that junk working, and have successfully tested the behaviors in a multiplayer setup and it's all neato and stuff.
So at this point, it's workable and I'm going to start pulling a changelog and prepping the campaign to get this thing pushed out there.
Hopefully that'll all be sorted in a few days(gotta record some video of this stuff in action) and we can get it rolling :D
Also, figured I'd mention it here since that's the point of this thread, but Lukas made a mention of the behavior stuffs in his magazine, which is pretty awesome :)
I do want to clarify, that while everything will be git'd out for everyone to use if the campaign is successful, I fully plan to continue heavy development with this as I plan to make use of it for my projects going forward.
I don't plan on dropping this once it's in the wild at all. More to the point, I actually have plans for a multitude of improvements, features, and behaviors.
I've also been mulling out the idea of building rapid-prototype kits using the behavior system as a framework that would probably go through the same community purchase as the behavior system core(though each pack would be quite a bit cheaper).
I'd have workable art, any supporting behaviors, and some example levels to let the user of the given pack drop stuff in and be a sizable portion of the way there already.
I plan to use the planned module system for T3D quite maliciously if I end up going for this RPK's >:D
If you guys think the idea of the Rapid-Prototype Kits(RPK's) sound neat, lemme know. I'd love feedback on ideas for what kits people would want to see!
08/23/2013 (7:04 am)
Alright guys, been lagging behind on the updates, but that's mostly because I was inventing new ways to sacrifice my keyboard to the Elder Gods of Networking.That said, I got that junk working, and have successfully tested the behaviors in a multiplayer setup and it's all neato and stuff.
So at this point, it's workable and I'm going to start pulling a changelog and prepping the campaign to get this thing pushed out there.
Hopefully that'll all be sorted in a few days(gotta record some video of this stuff in action) and we can get it rolling :D
Also, figured I'd mention it here since that's the point of this thread, but Lukas made a mention of the behavior stuffs in his magazine, which is pretty awesome :)
I do want to clarify, that while everything will be git'd out for everyone to use if the campaign is successful, I fully plan to continue heavy development with this as I plan to make use of it for my projects going forward.
I don't plan on dropping this once it's in the wild at all. More to the point, I actually have plans for a multitude of improvements, features, and behaviors.
I've also been mulling out the idea of building rapid-prototype kits using the behavior system as a framework that would probably go through the same community purchase as the behavior system core(though each pack would be quite a bit cheaper).
I'd have workable art, any supporting behaviors, and some example levels to let the user of the given pack drop stuff in and be a sizable portion of the way there already.
I plan to use the planned module system for T3D quite maliciously if I end up going for this RPK's >:D
If you guys think the idea of the Rapid-Prototype Kits(RPK's) sound neat, lemme know. I'd love feedback on ideas for what kits people would want to see!
#45
I believe the idea has been suggested a number of times. I know I've suggested it. I think what people was waiting for is your behavior system and the changes being done for 4.0. Nonetheless, as long as they aren't "TOO" expensive. I think it would be a great idea. Make sure you try to cover as many genres as possible.
08/23/2013 (9:47 am)
JeffI believe the idea has been suggested a number of times. I know I've suggested it. I think what people was waiting for is your behavior system and the changes being done for 4.0. Nonetheless, as long as they aren't "TOO" expensive. I think it would be a great idea. Make sure you try to cover as many genres as possible.
#46
that is actually a great idea with Rapid-Prototype Kits
and yes like Kory mentioned
many of us are just waiting to get our hands at your behaviour system
so stuff like GMK++ can be updated to work with it
and when i say work with it i mean it would be more wise to split it up and connect with your behaviour system
anyways looking forward to the video
and great work Jeff
08/23/2013 (12:22 pm)
@Jeffthat is actually a great idea with Rapid-Prototype Kits
and yes like Kory mentioned
many of us are just waiting to get our hands at your behaviour system
so stuff like GMK++ can be updated to work with it
and when i say work with it i mean it would be more wise to split it up and connect with your behaviour system
anyways looking forward to the video
and great work Jeff
#47
08/24/2013 (3:23 am)
In my projects, I use a lot of components(and signals) but only on the server and gameplay. This project is incredibly useful for Torque3D.
#48
08/24/2013 (4:13 am)
Prototype kits sound great. I'm so looking forward to the amazing flexibility this stuff will provide. Even down to the very simple questions like how do I make an object rotate? You add a rotation behavior to it. POW.
#49
Definitely.
For the whole rotate thing, the rotate behavior's update function would look something like this:
:P
Edit: In fact, it was so easy, I went ahead and just spent a minute and bashed it out. It'll be included in the release ;)
08/24/2013 (6:39 am)
@DanDefinitely.
For the whole rotate thing, the rotate behavior's update function would look something like this:
function ItemRotationBehavior::Update(%this)
{
%this.owner.eulerRotation.z += %this.rotationSpeed;
}:P
Edit: In fact, it was so easy, I went ahead and just spent a minute and bashed it out. It'll be included in the release ;)
#50
08/24/2013 (3:17 pm)
Whooooooah. Is eulerRotation a new thing you've added? That's nutty. Also, I would've done it in C++ so you get interpolation at sub-tick intervals, but hey. This works I guess!
#51
Working with euler is waaaay easier for small stuff like this, or when working with player control type things. The regular AA rotation is still there for fancier stuff, or legacy code.
And yeah, you definitely could rig up an engine behavior that does an even fancier job, but this works pretty well for what it is and would make a good example at how simple it makes small things like that.
I may later add in a advanceTime callback for really granular updates like what you mention, but for like, 90% of cases the processTick Update callback should be sufficient.
08/24/2013 (3:24 pm)
Yup. The Entity class has the regular 'rotation' axis-angle field, and I also added in the eulerRotation, which does What It Says on the Tin.Working with euler is waaaay easier for small stuff like this, or when working with player control type things. The regular AA rotation is still there for fancier stuff, or legacy code.
And yeah, you definitely could rig up an engine behavior that does an even fancier job, but this works pretty well for what it is and would make a good example at how simple it makes small things like that.
I may later add in a advanceTime callback for really granular updates like what you mention, but for like, 90% of cases the processTick Update callback should be sufficient.
#52
Once that's completed, I'll set up the campaign, get another blog post on the main page and get this thing rolling.
08/31/2013 (5:34 pm)
Just an update to this, but I'm editing the demonstration video now.Once that's completed, I'll set up the campaign, get another blog post on the main page and get this thing rolling.
#53
Blog post:
www.garagegames.com/community/blogs/view/22419
The campaign itself:
igg.me/at/T3DComponentSys/x/4589845
09/09/2013 (8:29 am)
The campaign is a gooooo:Blog post:
www.garagegames.com/community/blogs/view/22419
The campaign itself:
igg.me/at/T3DComponentSys/x/4589845
#55
EDIT: Also, you may want to consider posting this to something like /r/gamedev. The T3D channel where I posted before is pretty much dead :P.
09/29/2013 (4:32 pm)
Hey Jeff, just quickly - what does creating Behaviors from scripts look like? Before you went public with this, I was discussing a component/entity system with Frank which I wanted to be able to control from scripts in this sort of way:new Entity(myThing) {
new ShapeComponent() {
shape = "blah.dae";
};
new PhysicsComponent() {
mass = 5;
};
};which could then be used to structure .mis files (or quicksave files). I guess you know from t3d-bones that I'm really into doing stuff with scripts instead of editors ;P.EDIT: Also, you may want to consider posting this to something like /r/gamedev. The T3D channel where I posted before is pretty much dead :P.
#56
It's based off how T2D did it, so currently you don't nest new declarations. Part of the reason for that is non-engine templates can't be treated as a con-object class(the class name of the new declaration) and because behavior fields are currently defined specifically through a function. I'll probably edit that to read off of dynamic fields in the template, since the templates shouldn't ever have dynamic fields, but i'll test that.
So currently, declaring a template would look something like this:
For adding a behavior in script during runtime, it would be something like this:
Loading from a mission file, as said, doesn't use nested news, but specially interprets a _behavior field on the entity and parses the value on the field, like so:
The first part of the behavior delcaration is the template, and after that is field-value pairs, delimited by tabs.
As those are read in, it creates an instance, attaches it, and sets the field data. When writing, it only writes the field-value pair if it's different from the template.
The _behavior fields have a trailing number indicating unique behaviors. So _behavior0, then _behavior1, etc.
If I can figure a workaround for the non-conobject class issue for unique templates based on one of the engine classed ones, then we can implement nested new declarations, which would look a lot cleaner, but the way it handles con classes makes it a bit harder.
If you've got an idea for a workaround, I'd greatly appreciate the input.
09/29/2013 (9:04 pm)
@DanIt's based off how T2D did it, so currently you don't nest new declarations. Part of the reason for that is non-engine templates can't be treated as a con-object class(the class name of the new declaration) and because behavior fields are currently defined specifically through a function. I'll probably edit that to read off of dynamic fields in the template, since the templates shouldn't ever have dynamic fields, but i'll test that.
So currently, declaring a template would look something like this:
singleton BehaviorTemplate(ItemRotateBehavior)
{
friendlyName = "Item Rotation";
behaviorType = "Game";
description = "Rotates the entity around the z axis, like an item pickup";
networked = true;
};
ItemRotateBehavior.addBehaviorField(rotationsPerMinute, "Number of rotations per minute", float, "10.0");
ItemRotateBehavior.addBehaviorField(forward, "Rotate forward or backwards", bool, "1");For adding a behavior in script during runtime, it would be something like this:
%instance = ItemRotateBehavior.createInstance(); %entity.addBehavior(%instance);
Loading from a mission file, as said, doesn't use nested news, but specially interprets a _behavior field on the entity and parses the value on the field, like so:
new Entity(TestEntity) {
position = "-0.957538 6.32989 1.00435";
rotation = "1 0 0 0";
scale = "1 1 1";
canSave = "1";
canSaveDynamicFields = "1";
eulerRotation = "0 0 0";
_behavior0 = "ItemRotateBehavior\trotationsPerMinute\t20\tforward\tfalse";
};The first part of the behavior delcaration is the template, and after that is field-value pairs, delimited by tabs.
As those are read in, it creates an instance, attaches it, and sets the field data. When writing, it only writes the field-value pair if it's different from the template.
The _behavior fields have a trailing number indicating unique behaviors. So _behavior0, then _behavior1, etc.
If I can figure a workaround for the non-conobject class issue for unique templates based on one of the engine classed ones, then we can implement nested new declarations, which would look a lot cleaner, but the way it handles con classes makes it a bit harder.
If you've got an idea for a workaround, I'd greatly appreciate the input.
#57
I guess the obvious way around the conobject class issue is to do something like
(Man, I really hope we get this funded. I pimped it a bit in the IGDA Sydney facebook group, but they're all Unity devs over there :P. I'm excited to see what I can make with this and t3d-bones!)
09/29/2013 (10:17 pm)
Interesting, thanks for the writeup. The fact that behaviors aren't a conobject class makes a lot of sense. And just defining templates as regular objects makes editor integration difficult, I imagine.I guess the obvious way around the conobject class issue is to do something like
new Behavior() {
class = ItemRotateBehavior;
};but that's only if your Behaviors are actually all the same conobject subclass. I'll be able to make more sensible suggestions after seeing the code.(Man, I really hope we get this funded. I pimped it a bit in the IGDA Sydney facebook group, but they're all Unity devs over there :P. I'm excited to see what I can make with this and t3d-bones!)
#58
www.indiegogo.com/projects/t3d-component-system-community-purchase
Has just passed 50% and is 8 days to go!
10/02/2013 (1:57 am)
I thought its worth mentioning:www.indiegogo.com/projects/t3d-component-system-community-purchase
Has just passed 50% and is 8 days to go!
#60
www.indiegogo.com/projects/t3d-component-system-community-purchase
10/09/2013 (4:27 am)
Only 20 hours to go!www.indiegogo.com/projects/t3d-component-system-community-purchase
Torque Owner Jeff Raab
[ghc]games
I'm in the last pass of cleanup and documentation(noticed some GUI shenanigans and whatnot that need-a-fixin)
Should have it wrapped and ready for the purchase campaign this week here, barring any delays.