### Work Blog - JeffR

#### Re: Work Blog - JeffR

JeffR
Steering Committee
Posts: 808
Joined: Tue Feb 03, 2015 9:49 pm

Not 100% sure what you mean, Chelaru.

Do you mean like, completely bundled in? Then no, probably not, as Timmy said.

I do want it to be updated so it's easy to compile right off the repo, and have precompiled links so people can nab it easily though. In my build, I have it has a editor setting where you point the path to the exe, so it'd be wherever you install it to, and then just point that path to it and the 'opens the file in torsion' bit happens automagically after that.

#### Re: Work Blog - JeffR

Chelaru
Posts: 199
Joined: Wed Jul 01, 2015 10:33 am
JeffR wrote:Not 100% sure what you mean, Chelaru.

Do you mean like, completely bundled in? Then no, probably not, as Timmy said.

I do want it to be updated so it's easy to compile right off the repo, and have precompiled links so people can nab it easily though. In my build, I have it has a editor setting where you point the path to the exe, so it'd be wherever you install it to, and then just point that path to it and the 'opens the file in torsion' bit happens automagically after that.

Wouldn't be nice to have it in the engine by default.

#### Re: Work Blog - JeffR

JeffR
Steering Committee
Posts: 808
Joined: Tue Feb 03, 2015 9:49 pm

Yeah, I get ya. Part of what makes it weird is separated repositories, and not everyone needs/wants it, so it'd be considered bulk in those cases. Part of the reason we wouldn't merge it directly into the engine is because it uses Qt for the UI stuffs and bunch of other supporting libs, which is a big ol' blob of extra stuff hanging off the engine if people don't want to use Torsion, and wouldn't be used elsewhere.

Can't include the binary right in the download of the repo due to the no-no about exes.

That said, one possible option is to bundle it in with the updated Project Manager. So you download the PM, and it could possibly include Torsion with it or something.

#### Re: Work Blog - JeffR

RasterRon
Posts: 53
Joined: Sun Oct 25, 2015 7:36 am

Awesome update Jeff! As for the Torsion stuff, I think that's WxWidgets or is there a Qt version?

#### Re: Work Blog - JeffR

JeffR
Steering Committee
Posts: 808
Joined: Tue Feb 03, 2015 9:49 pm

Whoops, yeah, WxWidgets, thanks for the correction.

#### Re: Work Blog - JeffR

Posts: 74
Joined: Sat Feb 07, 2015 1:29 am
Hey @
JeffR
got a question about game objects / Prefabs - Would is it possible to create prefabs from a group of statics inside the level editor? Preferably via a Hotkey or right click context menu. Preferably while maintaining the rotations, scaling and locations of each prefab.

For example - I know at Bethesda Softworks they have a prefab system that allows them to make modular bits into a Prefab. Modular bits can make up lets say an part of a House. They did a talk about the level design of Fallout 4 at GDC and this was brought up a few times.

Edit - Looks like we got it in T3D.

#### Re: Work Blog - JeffR

JeffR
Steering Committee
Posts: 808
Joined: Tue Feb 03, 2015 9:49 pm

Entities

What are Entities?
Entities are a root game class. Think like how ShapeBase is the parent for all the different game classes, like Item, Player, Vehicle, etc. The big difference is that Entities, on their own, do very little.

They exist in the scene like scene objects, can be parented in a mount hierarchy, can be moved around, etc. The real meat of what they do is the fact that they can have Components added to them, giving them specific functionality. Because Entities do very little without Components, lets change gears and talk about Components real fast.

Components

What are Components?
Components are objects that exist to do a very specific chunk of functionality, and impart that functionality on the Entity that owns it. For example, lets say we have a need to render a 3d shape. An entity, on it's own, cannot do that. The old method of doing classes, is we'd inherit off Entity, making a child class named, say, ShapeRenderingEntity as an example. We'd add the mesh render code to it and it can render. But then if we need it to collide, we'd have to add more code. If we want a lighter weight object that ONLY renders, and doesn't need to worry about collisions, we either have to have the bulk of the collision code added to our ShapeRenderEntity class, even though we don't use it sometimes, or we derive another class CollidingShapeRenderEntity, and add the collision logic to that and so on.

If you've poked through Shapebase, and any of the classes that derive from it, there's a LOT of functionality wedged in there, oftentimes completely unneeded for the child classes. Items don't need shields or cloaking, so that's a lot of additional cruft code that exists on Items because it derives from Shapebase, etc.

It makes the code bulky, often less efficient, and can eventually cause classes to balloon into monoliths that are incredibly hard to navigate and make changes to without impacting a ton of things you didn't want to.

This is where components come in. Instead of having our various child classes of Entity, we make one object, MeshComponent. All it does is do rendering of a 3d mesh for it's owner entity. Nothing else.

So instead of needing to make a bunch of various custom classes for all cases, if we want an Entity that ONLY renders a mesh, we spawn an Entity, and add a MeshComponent to it, like so:

new Entity(MyEntityExample){   position = "0 0 0";   rotation = "0 0 0";   new MeshComponent()   {      shapeFile = "game/art/myNeatShape.dae";   };};

And just like that, our entity will render our myNeatShape mesh. If we want to have a different entity also have collisions, we would have a collision component, add it like our mesh component above and poof, that entity collides AND renders a mesh. If you only want one to collide, without rendering anything, add only the collision component, and so on.

This way, you don't have to worry about spiraling, interconnected monolothic blobs of code. Everything can be piecemealed out into descrete parts of functionality. It also means updates and fixes are a lot easier to apply. Rather than needing to fix a render bug in 8 different classes, you fix it in the MeshComponent and everything that uses it is corrected.

Sure enough, there are times where to let a component do what it needs to, you've sometimes got to make components talk with one another. This is actually pretty easy in most cases. To use our CollisionComponent as an example, sure, it's easy enough to make it collide like a box. But a lot of times, we want it to collide in accordance to collision shapes defined in the mesh file we're rendering in our MeshComponent.

The good news is, there's a bunch of ways to get the info we need!

When a component is added to an entity, all other components under that entity are informed of this event. Similar if a component is removed. This way, when we spawn our entity with it's mesh and collision component, our collision component can be told 'Hey dude, our owner Entity has a MeshComponent'.

This lets us reference that MeshComponent and ask it if it has any collision shapes and the like our CollisionComponent can then use to set up with.

Another way is to just straight up ask our owner Entity if it has a component of a certain type.

You can easily go:

MeshComponent* meshComp = mOwner->getComponent<MeshComponent>();if(meshComp){   //Do stuff}

And if the entity has one, it'll pass it back so we can get our work done.

Beyond that, both Entities and Components have OODLES of events and callbacks so that any given thing that occurs can be caught and handled by whatever needs to.

The ultimate plan is that the existing gameplay classes: Shapebase, Player, Item, Vehicle and so on, all are replaced with prefabbed Entities + Components done up as Game Objects.

So the end result of usage is largely the same, but it means customizing, expanding, and tweaking those objects is miles easier to do compared to the monolith classes we have now.

Example
The video example below walks through some particulars with Entities, Components, and using them in the editor to make various objects. It doesn't cover everything, because these suckers can actually do a pretty crazy amount of stuff even in raw script, to say nothing of what Game Objects can further open up for prototype/iteration speed.

The end goal, is to shift the engine to a place where you can nab the binary and at MINIMUM, be able to prototype most all your project right in script, without ever having to crack open the source code. Source code will be available, as always of course, but rather than the current mandatory-use vector, it'll be come more of a 'For optimization or really complex-stuff(like rendering) use' thing. The main of it being, as said, you really should be able to make at minimum most of your game before having to crack open the source and get dirty with it. Prototyping and Iteration speed, and letting people just focus on the development side of things.

#### Re: Work Blog - JeffR

Steve_Yorkshire
Posts: 240
Joined: Tue Feb 03, 2015 10:30 pm

Crikey that's cool!
And now I finally understand the whole modules/components thing.

#### Re: Work Blog - JeffR

RasterRon
Posts: 53
Joined: Sun Oct 25, 2015 7:36 am

JeffR wrote:Whoops, yeah, WxWidgets, thanks for the correction.

Ah got it. Yes, it would be nice for Torsion users to download this as a packaged option.

#### Re: Work Blog - JeffR

JeffR
Steering Committee
Posts: 808
Joined: Tue Feb 03, 2015 9:49 pm

@
Steve_Yorkshire
Yeah, this stuff is pretty neato. The next post/video will show the final piece of the puzzle: GameObjects.

@
RasterRon
Yeah. Like said, probably not integrated directly into the engine, but I do want to make it nice and easy to get your hands on, especially with the deeper editor integration for ease of scripting.

#### Who is online

Users browsing this forum: No registered users and 1 guest