Question, Suggestion, Request. Obi Rope + Game Creator 2

[josemendez]

- Player able to jump towards a handing rope and grabbing it, swinging and possibly back and forth, then using the jump to dismount the rope.

You can use collision callbacks to determine whether there's a collision between the player and a rope particle, then attach the player there:
http://obi.virtualmethodstudio.com/manua...sions.html

- A grappling hook / whip action to grab onto surfaces and pull the player towards it. 

If you want the player to be immediately pulled towards the surface, just reduce the length of the rope as soon as it attaches. You can use ObiRopeCursor for this, (like in the RopeGrapplingHook demo scene, but reduce rope length immediately instead of waiting for user input).

You are a very intelligent individual to have created these assets, I've used your search feature and seen numerous requests for a 3D swinging, and 3d grappling hook. I know you believe the demo scene is a great starting point for purchasers of your asset.

Believe it or not, intelligence doesn't play a huge role in writing (or using) these. Perseverance and patience do, ask any game developer .

However, I'm not nearly intelligent as you with these scripting and game object setups.

Scripting and GameObjects are the bread and butter of making games in Unity. Even if you do use Game Creator (or PlayMaker, or Bolt, or any other visual scripting system) these are just wrappers over the basics. They can ease you into game programming, but at the end of the day you'll need to know and work with the exact same concepts regardless of what you use.

If you create a integration with Game Creator 2 and sold it as an asset, you would get a lot of purchases.

The same could be said about integration with a lot other assets. However this poses a few important problems:

- maintenance: every time Game Creator or <insert third party asset here> changes something in its API or alters the way it works, we'd need to adapt our system to work with it. To be honest, the same can be said about Unity itself: trust me there's not been a single Unity release where we haven't had to hotfix stuff because it broke in newer versions or made something incompatible with previous versions. Keeping up with Unity is difficult enough.

- logistics: sometimes it's not possible for Obi to adapt to a certain third party asset, and it's the third party asset that needs to adapt to Obi. Keeping in touch with its creators requires they are willing to invest time and effort in getting both assets to play nice with each other, which is often not the case.

- stagnation: as a result of having to chase what's essentially moving goalposts, development on the actual physics engine and its features would likely stagnate. Hiring more developers to compensate would likely be an option, but:

- pricing: extra work -> hire people -> increase asset price to cover the cost. Increasing the price would make it so less people can afford to purchase the asset, even if few of them are interested in the Game Creator / Bolt / Playmaker integration.

We've tried similar stuff in the past and it didn't work out as well as one might expect. I've come to the conclusion that focusing on the engine itself and keeping it as simple as possible (no bloat) is the best approach. A lot of the functionality requires using HPCS since its target audience are intermediate and advanced developers looking for a high-performance, highly flexible system, so sticking to a pure C# API is the simplest and most flexible approach, and definitely the one that makes most sense.

Game Creator 2 doesn't add a rigid body to the player until play mode, so trying to add the Obi Rigid body doesn't happen unless I add the component in play mode.

I'm not sure why this is a problem, you can add a ObiRigidbody component (or any other Unity component) at runtime just fine. Could you explain further?

Im not sure if my player prefab has to be a child of the obi solver, as the cube is in the demo scene.

Not necessarily, only your rope has to. Solvers act in the same way Canvases for UI do: they become responsible of managing all ropes inside their hierarchy.

In the demo scene the player is a child of the solver for convenience, but it all depends on how you want to set up and organize your hierarchy. Take for instance the Crane sample scene: the cube that is attached to the crane's rope ("Load" GameObject) is not a child of the crane, or the solver.

A concept you need to understand well is vector spaces: specifically, world space and local space. These are important regardless of what system/assets you use to create the game, even if you're not using Obi.

kind regards,