Cogito Sittable 🪑

[OvercastInteractive]

Hey all,

I'd like to propose a feature that is considered a standard capability you'd expect from most types of games and experiences, especially immersive sims: Sitting.

There are numerous ways to implement this, some more immersive than others, but having the capacity to assign places the player can sit, whether that's on a couch, driver's seat, wheelchair, airplane seat, Ferris wheel, dining table chair, park bench, work desk, swing, or other unconsidered places. I don't intend for this feature to bleed out into actual driving mechanics or anything, just sitting.

This would entail moving the player to a fixed target position with a look direction. It could be done in a single frame, during an eye blink or be more of a smooth interpolation or even blended with an animation.

The reason I would want it to be a Cogito feature rather than implemented per use-case or project is simply because it's a standard feature that one would expect from a comprehensive, fully functional project that Cogito is currently valued as.

Thoughts?

[Phazorknight]

I'm open to it. Would probably call it something more generic (Cogito Sit/Sitting? Cogito Seat? Sitable? 😁 )

I'd lean toward having the player view transition to the target position in a tween (Ideally one that's controllable in the exposed object parameters), then would lock movement but still enable freelook + certain interactions.

I'm currently busy with other improvements/bug fixes, but this could be a fun addition and there's quite a few objects in the current demo scenes to try this out on.

[Phazorknight]

I'd simply not allow it. 😁

@niefia haven't looked at your attmept at this yet, but I'd prob make it it's own cogito class that is derived from something like AnimateableBody3D or StaticArea3D, so that way it's a bit more controlled.

Or we just could allow it, and it's up to the devs to design their objects to avoid unexpected behavior.

[OvercastInteractive]

It's a good first attempt niefia 👏

A couple of ideas for the next iteration if you don't mind:

1. (To avoid traveling through the backs of chairs) An AABB plane test to make sure the player is not behind the chair when attempting to sit and only displaying the sit interaction component when their position relative to the seat is in bounds
2. (To test sitting on a moving object) Pass a sittable_node var into cogito_player when entering a seat and use the _process() function to assign the player position to the sittable_node every frame that is_sitting is true, to see if it's feasible to move the player when seated. If it becomes untenable, like Phazorknight suggested, just allow dev's to determine if they need to write in their own custom behavior.

Thanks for putting this together!

[niefia]

Code has been refactor so that player now controls all player movements and sittable only handles itself with signals used to communicate with player

Thanks for the feedback @OvercastInteractive , I had the 2nd point in mind already, and have implemented it now. My concern was more to do with the weird collisions issues that will arise, may be able to solve some of these by using a single collision shape for both seat and player when the player is sat down though. Not tested it but figured it should be a reasonable solution for most issues and beyond that it's up to users.

For the 1st point I added in a Sittable area that only allows interaction if the player is inside the area, figured this was most user customisable way of doing it.

In terms of next steps, there's still have some bugs that need fixing like sitting when crouched causing issues.
Really need to sort out the look marker for defining player horizontal sitting vision too but can't seem to get it working.
Will probably also need testing with controller, but I don't have a controller to do that with.

If there's any more suggestions let me know, could also make a pull request and move the conversation there since we've moved beyond the idea stage.

[ac-arcana]

I'd like to add a fringe use case to test, if you don't mind. Try testing it when you are already on a ladder and go to sit.
This is a fringe case that is uncommon but in some games it's a bug that lets you fly.

[Phazorknight]

@niefia Agree, a PR seems to make sense at this point!

[teebarjunk]

Since such a class/feature could be used for beds, work stations, traps, moving platforms, maybe a more abstract name would work better like CharacterContainer, or Station, or Restrainer.

[Phazorknight]

I see where you're coming from.
I'm not too worried about the name being too specific, as long as it communicates its purpose well enough. Cogito Door is a good example of something that's straightforward to understand, but is then used for a plethora of other things.

I feel Container or Station is too generic, but restrainer makes sense. Could call it PlayerRestrainer

[OvercastInteractive]

I think PlayerRestrainer is okay since that explicitly states the behavior of the class while also making it sound like a modular feature able to be used for a variety of actions. If you just make the class icon a chair, then it should communicate its basic use-cases quite clearly.