[JeffR]

Hey guys, with the entity/component stuff just about to get rolled in under the experimental tag, one thing I've been wanting to do is give a solid gauntlet of various/weird gameplay-y things to throw at it and see what weak spots there are with the current implementation. It all works, I've been testing it a fair bit, but I haven't really pushed it, so there's no doubt a ton of soft spots on the thing I've yet to run into.

So, what I wanted to do is have people do suggestions for things to try and take a stab at implementing with the entity/components/game objects. This'll let people get weird ideas in there to hammer against the system to find weak points to get shored up, while also letting me toss them up on here afterwards for anyone that wants to utilize this stuff going forward.

It'll be kept as experimental for 3.9, but plan is to roll over to using them as standard for 4.0, so starting the testing/iteration gauntlet now is a good idea, I think.

Any idea for a individual element of gameplay functionality as a component, example Game Objects like items or simple players, or simple integrated tools like a object painter are the sorts of thing that'd be good for testing the gambut of this.

So if you've got an idea, feel free to throw it in here. I'll be shooting for doing one a week as possible.

As a primer, here's some that I've thought of that some people could find useful in their projects(as I plan to utilize them in mine)

• player controller
• camera
• collision w/ hitbox mode
• animation
• state machine
• pick-up item
• weapon
• throwable weapon
• interactable item(doors/switches)
• AI
• inventory
• breakable items(glass, barrels)
• mortar/artillery launchers
• capture zone trigger
• damage trigger
• tank/vehicle
• turret weapon
• bullet/projectile
• shell casing/debris
• spawn-camp kill trigger
• movers(scripted events)[use Tween?]
• spawnpoints
• area control flag
• layout prefab populator
• melee weapon

If you've got an idea that's not on the list, feel free to suggest it!

[Azaezel]

bullet/projectile - one thing that gets noted frequently, and this might fall under a hybrid weapon/throwable weapon is (at least stock physics) uses a raycast for projectiles even though you can feed it a visual mesh. this can lead to counterintuative results, like it seeming to 'pass though' due to not really hitting if you've got a large enough mesh.

on the oposite end of the spectrum - hitscan weapons that *just* use a raycast + leverage the ribbon code, a decal applicatoin, and an explosion at point of impact.

[LukasPJ]

puppy component which allows puppy-shading anywhere!

[MangoFusion]

Hooking it into the openvr code might prove to be insightful. After all T3D's current player code is a tad bit on the monolithic side so implementing extra things like controller interactions is a little bit of a PITA.

For reference, this would include:

* Interacting with objects using vr controllers (pick up, whack, etc)
* Walking around the scene (for vive full room tracking)
* Transmitting these movements over the network for other players to observe (think vr chat)

Also generally speaking, I think a real test of the current system is: can it run quake? As in, given what we have is it possible to implement monsters, doors, elevators, triggers, cutscenes, etc?

[Azaezel]

http://imgur.com/bQdGhAy

[JeffR]

Hooking it into the openvr code might prove to be insightful. After all T3D's current player code is a tad bit on the monolithic side so implementing extra things like controller interactions is a little bit of a PITA.

For reference, this would include:

* Interacting with objects using vr controllers (pick up, whack, etc)
* Walking around the scene (for vive full room tracking)
* Transmitting these movements over the network for other players to observe (think vr chat)

Yeah, excellent point. I think we'd be able to manage with a VRCamera component, one for translating the open room offset into a movement for the player controller, and a something to handle the VR controllers.

Could probably have a component to deal with the interaction/tracking, and have the rendering be a regular mesh component.

If we can figure a clean way to associate those controller objects to the owner player - maybe child entities mounted to it - then the networking aspect of it shouldn't take much wrangling beyond that.

Also generally speaking, I think a real test of the current system is: can it run quake? As in, given what we have is it possible to implement monsters, doors, elevators, triggers, cutscenes, etc?

Hah, yeah, that'd be a fairly solid baseline.

That and @

Azaezel 's AI killhouse would share quite a number of elements, so working towards either of those would be a good chunk of the other.

[Timmy]

Yeah i think what james mentions is a good idea about a full level. Even if it is just the freely available pacific level, throw in some bad guys, make the user kill them and find some random object and fight the boss in the cave and game over. That would demonstrate heaps from the above list and also show peeps some very basic gameplay mechanics.

[rlranft]

I could play with incorporating it in the upcoming RTS AI Tut.... I'm already handling mouse and player control differently and this might help make that better, but the real use would be in unit AI.

[PacoMontanes]

@

JeffR
Like artillery launchers, there are infantry launchers too. I would like to suggest 2 types of missile weapon/projectile:
- Wire guided missile
- Camera guided missile, for which I did some early tests few years ago:

[JeffR]

@JeffR
Like artillery launchers, there are infantry launchers too. I would like to suggest 2 types of missile weapon/projectile:
- Wire guided missile
- Camera guided missile, for which I did some early tests few years ago:

Hey, nice!

Yeah, don't think it'd be too hard.

Camera guided wouldn't be hard, you'd basically swap camera and control on the client to the components for those on the missle(effectively this is already done for the editor camera when hopping between a player and that) while the missile is in flight, and then swap back when it is destroyed.

What'd be the control/implementation for wire-guided though? That's a bit more broad category, so I'm not sure the exact setup you had in mind. Being able to lock onto a target and have the missle steer towards it?