I haven't gotten super deep into it yet, but there's the Player physics component(that replicates the behavior of the current player object) and a beginning foray into a rigid body physics component.
From there, the plan is to expand and hit on the major checkboxes, including spring forces and the like for vehicle usage, maybe cloth, and i want a component for ragdolls as well you can flip on to make an animated mesh go all captain flopsy.
What are Game Objects? I'm sure most of you are familiar with prefabs. You take a selection of objects, convert to a prefab object, and you can quickly spawn copies of that selection of objects, move 'em around, and all that good stuff. This is good, but there are some limitations to this approach. For one, you can't do any modification to a prefab. You have to explode it out and edit it. If you want to retain that modified version, you have to save over the original prefab, or make a new one. You're not really supposed to 'do' things with prefabbed objects. You can, but it tends to lead to weird stuff if you start going around manipulating the child objects directly, etc. They're largely designed for mapping/level building, not gameplay stuffs.
That's where Game Objects come in.
Game objects broadly are similar to prefabs. You take an entity you've dolled up with components, maybe child objects mounted to it, etc, and go 'this is a setup I'd like to use multiple times'. Examples would be your player object, weapons, light switches with an associated light, etc, etc.
So how do we use it? So what you do is take that entity, and convert it into a Game Object. This generates a GameObjectAsset, making it readily appear in the Asset Browser, but also makes it so you can very quickly spawn copies of that entity. Another thing that happens when creating a GameObject is it has an associated script file. When the entity is made a game object, it is assigned the GameObject's namespace for it's class name, allowing the GameObject entity to have scripted behavior associated to it directly.
So lets use one of the example cases we listed off above - a player object. We already created our entity, it's various components, and have them all configured the way we want it so it behaves like a player object. So we save it out as a Game Object: MyPlayer.
While we did up our various components, such as the mesh, collision, player physics, inventory, etc. There may be times where we want specific behavior/functionality for JUST this game object, and not a more broad general behavior that we'd put into a component. Or we have a bunch of systems that touch a lot of things and components, and feels too broad in scope for a component. Or you just prefer to code in a localized fashion rather than spreading everything out in a script component.
Any of those cases are a good reason to utilize the script file for the Game Object.
So lets say we want special behavior for our MyPlayer object, that would be distinct from other similar player objects, like AI. We can copy the game object asset, name that one MyAI so there's the distinction. The object is generally similar, still has the same components and configuration, but we can make the MyPlayer game object do stuff the MyAI GO can't, such as have inventory, or special concessions for players like a sneak system the AI don't need.
All this can, of course, be done in other ways, such as components, but the point is the system enables you to go about it in such a way that's the most flexible/comfortable to you. Personally I do a mix-n-match of scripted components and GameObject scripts.
You can also readily edit the GameObject entity, and any child objects it has right in the editor without needing to un-make the Game Object like you would a prefab. Spawn a Game Object that acts as a static shape, and change it's mesh and collision setting, and it'll only change for that instance. Spawn a light + switch combo and move the light child object into the position in the room you want, and so on.
It's not fully implemented yet, but I also plan to implement a system that compares an active Game Object to it's originating TAML file, so it'll track if a GO is 'dirty'. If you do one of the above cases, where you modify a Game Object in some way that makes it distinct from the original TAML file, it's considered 'dirty'. The editor will then have buttons in which you can either: Save the current form as the Game Object, which is how you can quickly modify the GO. Save the current form as a entirely new Game Object Or Reset the game object back to how the TAML file describes it.
This should make editing fast and flexible. When saving, it'll also only save fields that are different from the TAML file, to keep data compact. Another fun thing is that nothing stops you from having GameObjects in GameObjects. So you can quickly get some pretty fancy setups rolling while keeping things data-compact, and templated for easy modification across the board.
Example Below is a video that goes over some examples of Game Objects and shows off how they can be pretty convenient to work with.
Took a chunk of the weekend to cool off and play around with some fun bits. The end result was this:
Got my example dude working with some look animation action. It's subtle, but you can see him always turning to look in the direction the camera's facing, even as the rest of his body orients in the direction of movement.
This is a lot more natural compared to the normal third person fare of either the player always looking in the direction of movement, leaving other players wondering how you saw behind you, or locked to a rigid over the shoulder, forward/back/strafing view, which isn't really how people move about.
Also got the vertical look thrown in, because why wouldn't we, and a quick test that i did because I couldn't remember if I'd rigged in the prone keybind or not at the time, haha.
Incidentally, outside of one new math function i added that gets the signed angle between two vectors, which'll be PR'd in the near future, all that business was implemented with art and scripts.
It suffers a bit when it does a full 360 turnaround, because it's jumping from one extreme end of the animation to the other, so I need to correct that, but once it gets dialed in, I'll probably do a quickie tutorial and doing that sort of thing. Natural animations are a big deal, and I'm all for encouraging it