T3D Component System Community Purchase: An Update
by Jeff Raab · 09/29/2013 (6:53 am) · 33 comments
Well, as Indie GoGo's Updates sumission system doesn't understand how numbers works, it things my update is too long while the character counter clearly indicates I'm under limit. So whatever I'll Just post the thing here and link back:
What's up people?
I'm just dropping a pre-update breakdown. I've been doing work on updates, including new behaviors. I'll also be putting together a new video that demos what this sort of thing can do and why its helpful.
While I'm working on it, here's an update:
So what's been updated?
Bug fixes and documentation updates! I also improved the level loading, so behaviors saved into the level can load an unlimited number of fields. There were some limitations to the way it loaded levels before, but now you can have any number of fields saved. This is especially helpful for some of the new stuff being added, such as...
The New Stuff:
Mounted Camera Behavior!
The original camera behavior worked perfectly, but it operated much akin to the spectator camera. There wasn't a real easy, editor-friendly way to set up mounted cameras for shooters, or Side Scrollers or the like. This fixes that. It's a camera behavior that integrates in the mounting stuff so all you need to do is set the mount target and any transform offsets and it does the rest.
Animation Behaviors!
There are 2: Ambient Animation and Animation Controller.
Ambient animation is What It Says on the Tin. You define an animation for the entity if it has a shape behavior with animations and it plays it for you.
Animation Controller is more general purpose. It gives you up to 16 animation threads with full control. Start and Stop points, speed, forward or backwards, looping, triggers, script controls, etc. This lets you use it for everything from movement and look animations, to facial animations.
And the last major behavior addition, State Machine Behavior
This is a general-purpose state machine behavior. It allows for any number of states and fields to each state, and I'll be setting up hooks for everything from state timeouts, external events, animation triggers and more to allow tons of flexibility in how states operate.
The animation triggers are especially interesting, as that lets you rig up small states that transition from animation-to-animation, so you have a state play an animation for the character laying down that locks player movement, and then it automatically transitions into the prone state. All in all, very flexible.
So that's the update prefacing the video that should be up here before too long demo'ing it off. If you haven't donated yet and aren't sure, keep your eyes on this, and be sure to tell people you know that think it would be a good addition to the Torque Community!
And if you don't have it, here's a link to the campaign:
igg.me/at/T3DComponentSys/x/4589845
-Jeff out
What's up people?
I'm just dropping a pre-update breakdown. I've been doing work on updates, including new behaviors. I'll also be putting together a new video that demos what this sort of thing can do and why its helpful.
While I'm working on it, here's an update:
So what's been updated?
Bug fixes and documentation updates! I also improved the level loading, so behaviors saved into the level can load an unlimited number of fields. There were some limitations to the way it loaded levels before, but now you can have any number of fields saved. This is especially helpful for some of the new stuff being added, such as...
The New Stuff:
Mounted Camera Behavior!
The original camera behavior worked perfectly, but it operated much akin to the spectator camera. There wasn't a real easy, editor-friendly way to set up mounted cameras for shooters, or Side Scrollers or the like. This fixes that. It's a camera behavior that integrates in the mounting stuff so all you need to do is set the mount target and any transform offsets and it does the rest.
Animation Behaviors!
There are 2: Ambient Animation and Animation Controller.
Ambient animation is What It Says on the Tin. You define an animation for the entity if it has a shape behavior with animations and it plays it for you.
Animation Controller is more general purpose. It gives you up to 16 animation threads with full control. Start and Stop points, speed, forward or backwards, looping, triggers, script controls, etc. This lets you use it for everything from movement and look animations, to facial animations.
And the last major behavior addition, State Machine Behavior
This is a general-purpose state machine behavior. It allows for any number of states and fields to each state, and I'll be setting up hooks for everything from state timeouts, external events, animation triggers and more to allow tons of flexibility in how states operate.
The animation triggers are especially interesting, as that lets you rig up small states that transition from animation-to-animation, so you have a state play an animation for the character laying down that locks player movement, and then it automatically transitions into the prone state. All in all, very flexible.
So that's the update prefacing the video that should be up here before too long demo'ing it off. If you haven't donated yet and aren't sure, keep your eyes on this, and be sure to tell people you know that think it would be a good addition to the Torque Community!
And if you don't have it, here's a link to the campaign:
igg.me/at/T3DComponentSys/x/4589845
-Jeff out
About the author
#2
09/29/2013 (10:16 am)
Well to be fair he is advertizing to what is supposed to be a game developers group. I know some may be new but there wasn't anything there that should be over the head of a novice. Word like State Machine behavior is something you SHOULD know if you are serious about developing almost any type of game. I hope this came off as informative, and not condescending. Although, there are new developers here, as I once was before here and college, but seeing term that I did not understand made me find what they are. So what I am getting at is you point is not completely invalid, but a little out of place. Also the link he put at the bottom of the post does provide more information. 
#3
maybe just this
with Jeffs Component System - T3D would almost level up and be on the same
track like UDK/ Unity in the way how things are handled
and so far Jeff is the only one who is publicly going to share his work
depending on the communitys support
@Jeff
what if the goal fails?
i mean, do you still plan to share your work?
09/29/2013 (11:09 am)
There is not much to explain,maybe just this
with Jeffs Component System - T3D would almost level up and be on the same
track like UDK/ Unity in the way how things are handled
and so far Jeff is the only one who is publicly going to share his work
depending on the communitys support
@Jeff
what if the goal fails?
i mean, do you still plan to share your work?
#4
track like UDK/ Unity in the way how things are handled"
that's right.
there is another project which is using component based t3d system.
most probably that is not going to be available for public.
jeff's work will give this community a chance to adopt t3d with modern component based game object creation.
09/29/2013 (12:32 pm)
" on the sametrack like UDK/ Unity in the way how things are handled"
that's right.
there is another project which is using component based t3d system.
most probably that is not going to be available for public.
jeff's work will give this community a chance to adopt t3d with modern component based game object creation.
#5
I'll see about writing a few breakdown examples to better convey why components are more useful than writing on new/existing full classes for everything.
@J0linar
I'm still thinking on what the exact plan is. My current guess is that I'd probably try again a few months down the road with better refinement(I plan on using this for my projects regardless, so it'll continue to see development on my side) but that's quite a while for the community to not have something so useful.
I might look at licensing it out or something in the meantime to people who ask after it, but I'm not super keen on doing that.
09/29/2013 (1:51 pm)
@DuionI'll see about writing a few breakdown examples to better convey why components are more useful than writing on new/existing full classes for everything.
@J0linar
I'm still thinking on what the exact plan is. My current guess is that I'd probably try again a few months down the road with better refinement(I plan on using this for my projects regardless, so it'll continue to see development on my side) but that's quite a while for the community to not have something so useful.
I might look at licensing it out or something in the meantime to people who ask after it, but I'm not super keen on doing that.
#6
thats a schame, it would boost the upcoming developement
at least i expected it todo -
anyways am thankfull
to get insight on the developement and your future plans
still some days to go
...
09/29/2013 (2:29 pm)
ye i fully understand thatthats a schame, it would boost the upcoming developement
at least i expected it todo -
anyways am thankfull
to get insight on the developement and your future plans
still some days to go
...
#7
09/29/2013 (3:31 pm)
It looks not that bad, half way through, maybe some will gather up at the end. 
#8
IMO, a component system is going to be absolutely necessary if T3D is to make it as a general-purpose game engine. This should have happened years ago. Before T3D was released in binary-only form, for sure.
To anyone who is uncertain what this will change: this is always a good read.
A component system like this breaks down functionality into little reusable bits. It means there's less hardcoded behavior in game objects. For example, the current Player class has its own way of controlling the camera, which is different to the vehicle class, and so on. With components, all those functions get separated out, and you can remix-and-match them to be more to your liking. For example, you could use the vehicle camera with a Player control object. Or a stationary camera. Or whatever you like.
It also makes it easier to develop new functionality, because you can just implement it as a module, which involves some API to connect it to the rest of the module system, but then you can develop it entirely in isolation. You don't have to work inside a big class hierarchy and override inherited functionality. It also means changes are more readily shared between developers (just drag and drop the behavior files) and between game objects (everything's an entity, so everything can, to some extent, react the same way to each behavior).
09/29/2013 (4:36 pm)
Ohhhhhhhh my goooooooshhh I really want this. Might have to up my contribution.IMO, a component system is going to be absolutely necessary if T3D is to make it as a general-purpose game engine. This should have happened years ago. Before T3D was released in binary-only form, for sure.
To anyone who is uncertain what this will change: this is always a good read.
A component system like this breaks down functionality into little reusable bits. It means there's less hardcoded behavior in game objects. For example, the current Player class has its own way of controlling the camera, which is different to the vehicle class, and so on. With components, all those functions get separated out, and you can remix-and-match them to be more to your liking. For example, you could use the vehicle camera with a Player control object. Or a stationary camera. Or whatever you like.
It also makes it easier to develop new functionality, because you can just implement it as a module, which involves some API to connect it to the rest of the module system, but then you can develop it entirely in isolation. You don't have to work inside a big class hierarchy and override inherited functionality. It also means changes are more readily shared between developers (just drag and drop the behavior files) and between game objects (everything's an entity, so everything can, to some extent, react the same way to each behavior).
#9
09/29/2013 (5:01 pm)
sounds a bit like the Torque 2D ?! Components, behaviors ? Regardless, no doubt this will be useful in any project I do ... +1 more supporter 
#11
09/29/2013 (6:31 pm)
OK, here you go +
#12
Another reason that components would be so helpful for new people, is everything is broken down into much more bite-size elements.
Dan mentioned the Player class, for example.
On my last check, the player cpp file has over 7,000 lines of code to it.
It handles everything from physics, collisions, animation, input, health and stamina mechanics, mounting, camera stuff, sounds, water interaction and so on.
If you haven't looked at it for a while, I encourage you to go and open it up, and take a glance to figure out what you would do if you wanted the camera to not mount to the eye node for first person view, but be stationary in the mission file while still having full control of the player object.
...good luck with that.
With components, however, everything is in very small, self-contained bite sized peices.
The most complicated behavior I have in there right now is the core Collision behavior, which acts as a cornerstone for other collision behaviors. It peaks at 855 lines currently, and could use some cleanup, but pretty much deals exclusively with collisions. If someone wanted to know how Torque handles collisions between objects, setting up Convex volumes for collisions, reporting collisions to other objects, etc. they can find out by reading through that behavior.
I plan to document as much as I can get away with for these core files to make it as comprehensive as possible.
From there, The Box Collider behavior, which has a arbitrarily sized box for the collision volume(not dissimilar from the player class, but not hard-coded in size) has only a shy over 500 lines.
Many virtualized functions that override the core collision behavior to do unique stuff(like using boxes for it's collision).
But the point is, compared to the monolithic spaghetti monster that is the player class, being able to open a single file and glean the core workings of how Torque deals it's collisions is far easier to deal with.
It's very similar, in premise, to the RenderMeshExample, RenderObjectExample and RenderShapeExample classes, only even more granular that than.
Each behavior on it's own can act as a tutorial for the innerworkings of torque, while making it that much easier to expand on it.
09/29/2013 (9:17 pm)
Dan's breakdown is pretty accurate. Another reason that components would be so helpful for new people, is everything is broken down into much more bite-size elements.
Dan mentioned the Player class, for example.
On my last check, the player cpp file has over 7,000 lines of code to it.
It handles everything from physics, collisions, animation, input, health and stamina mechanics, mounting, camera stuff, sounds, water interaction and so on.
If you haven't looked at it for a while, I encourage you to go and open it up, and take a glance to figure out what you would do if you wanted the camera to not mount to the eye node for first person view, but be stationary in the mission file while still having full control of the player object.
...good luck with that.
With components, however, everything is in very small, self-contained bite sized peices.
The most complicated behavior I have in there right now is the core Collision behavior, which acts as a cornerstone for other collision behaviors. It peaks at 855 lines currently, and could use some cleanup, but pretty much deals exclusively with collisions. If someone wanted to know how Torque handles collisions between objects, setting up Convex volumes for collisions, reporting collisions to other objects, etc. they can find out by reading through that behavior.
I plan to document as much as I can get away with for these core files to make it as comprehensive as possible.
From there, The Box Collider behavior, which has a arbitrarily sized box for the collision volume(not dissimilar from the player class, but not hard-coded in size) has only a shy over 500 lines.
Many virtualized functions that override the core collision behavior to do unique stuff(like using boxes for it's collision).
But the point is, compared to the monolithic spaghetti monster that is the player class, being able to open a single file and glean the core workings of how Torque deals it's collisions is far easier to deal with.
It's very similar, in premise, to the RenderMeshExample, RenderObjectExample and RenderShapeExample classes, only even more granular that than.
Each behavior on it's own can act as a tutorial for the innerworkings of torque, while making it that much easier to expand on it.
#13
You can check that out here:
www.garagegames.com/community/forums/viewthread/134222/3#comments
09/29/2013 (9:21 pm)
Also, for those of you that are interested, I posted a response to a question from Dan about how behaviors are created in script over in the discussion thread.You can check that out here:
www.garagegames.com/community/forums/viewthread/134222/3#comments
#14
I am surprised to see not much of a response.
Looking forward to seeing the contributions increasing and more info and news about it as we get closer to the end.
09/29/2013 (9:45 pm)
This is sounding better the more we hear about it.I am surprised to see not much of a response.
Looking forward to seeing the contributions increasing and more info and news about it as we get closer to the end.
#15
i also was surprised.
looks like old t3d geeks are all busy with their life.
none of t3d based campaign got success from open crowd funding.
so it will be better if here(in this forum) we make these campaigns.
problem is with this site.
it makes thread disappears.
09/29/2013 (10:27 pm)
"I am surprised to see not much of a response."i also was surprised.
looks like old t3d geeks are all busy with their life.
none of t3d based campaign got success from open crowd funding.
so it will be better if here(in this forum) we make these campaigns.
problem is with this site.
it makes thread disappears.
#16
I say that only half-facetiously...
09/29/2013 (10:55 pm)
Yeah, I'm disappointed at how few people are backing this. Really, GG should just fund it themselves. It'll only result in a better (and eventually more popular) engine for them to engage clients with (assuming their service work is actually using T3D for at least some of the time). And on a corporate balance sheet, a couple of hundred dollars would be nothing.I say that only half-facetiously...
#17
+1
*********************************
"it makes thread disappears."
was thinking about the space left for "Employee Blogs" ?
most of them are old threads.
if u guys give that space to community to highlight big announcement+progress on going then it will definitely attract eyes of new comers.
official blogs still will be posted on "Spotlight" section.
+an scrolling system for both section.
with an javascript will that be hard to implement!!!!!!!!!
09/29/2013 (11:18 pm)
" And on a corporate balance sheet, a couple of hundred dollars would be nothing."+1
*********************************
"it makes thread disappears."
was thinking about the space left for "Employee Blogs" ?
most of them are old threads.
if u guys give that space to community to highlight big announcement+progress on going then it will definitely attract eyes of new comers.
official blogs still will be posted on "Spotlight" section.
+an scrolling system for both section.
with an javascript will that be hard to implement!!!!!!!!!
#18
Well if you are going to license it out between campaigns, you could make it on a "pay what you want but at least x to get early access" and subtract the amount from the campaign goal. Not saying this is without complications (what if second campaign doesn't make it and someone paid above x and it turns into a commercial product with price x, but I for one would love to pay in advance to get my hands on this earlier!
09/30/2013 (1:45 am)
@Jeff RaabWell if you are going to license it out between campaigns, you could make it on a "pay what you want but at least x to get early access" and subtract the amount from the campaign goal. Not saying this is without complications (what if second campaign doesn't make it and someone paid above x and it turns into a commercial product with price x, but I for one would love to pay in advance to get my hands on this earlier!
#19
09/30/2013 (3:12 am)
@Lukas, agreed 
#20
09/30/2013 (10:10 am)
Increased my contribution. 
Duion
I guess your things are useful, but honestly I for example dot not fully understand what it is, at the moment, maybe I will miss it some time later, but not now.
Have you watched these shopping shows? They have a product and to market it, they show as many fictional scenarios and problems you can solve with their product as they can and they do not bother so much with technical details nobody can understand.
The viewer will then think: "This product can solve so many problems, I need this"
For example make a video or pictures with "So you are designing a game and want to do this, but there is no tool for it, you would have to program it spending much time, but with my tool you can have it instantly"
Just my ideas.