Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for either Box2D or Bullet? #84

Open
RubyNova opened this issue Nov 27, 2019 · 10 comments
Open

Add support for either Box2D or Bullet? #84

RubyNova opened this issue Nov 27, 2019 · 10 comments
Labels
engine api Tickets pertaining to NovelRT's end-user API. engine core Tickets pertaining to the engine core codebase. feature A feature ticket for the NovelRT. proposal A proposal up for debate.
Milestone

Comments

@RubyNova
Copy link
Member

There has been many discussions about LLAPI supporting a variety of games.

To that end, I am wondering if we should provide physics support via Box2D or Bullet.

It would only be LLAPI though, as I have no intention of supporting physics in the HLAPI due to the nature of said HLAPI.

Thoughts?

@RubyNova RubyNova added proposal A proposal up for debate. feature A feature ticket for the NovelRT. engine core Tickets pertaining to the engine core codebase. engine api Tickets pertaining to NovelRT's end-user API. labels Nov 27, 2019
@capnkenny
Copy link
Member

Hmm...I think this really comes down to how versatile this engine should be.

If we're still on track for all 2D but a focus on VN, I think this would be a really interesting addition later on - not only can we provide physics for non-VN users but we can also give VNs a unique quirk to mix things up a bit from the norm.

Also, no HLAPI? (I'm not familiar with what the HLAPI for this would look like so don't mind me.)

@RubyNova
Copy link
Member Author

No HLAPI specifically because the HLAPI is geared towards bog-standard VN tools such as dialogue box, "CGs" as they're called (why are they even called this though? All I ever think about is the trauma Unity Cg gave me) and so forth.

Therefore I don't think an HLAPI for physics makes much sense.

@capnkenny
Copy link
Member

Ahh, okay that makes sense. This goes in line with a (unsure if) proposed editor that was briefly discussed in Discord.

@RubyNova
Copy link
Member Author

The design for the visual editor is very much up in the air, but, yes I imagine that the vanilla editor will just be for VNs.

I hadn't really considered the implications for the editor for this stuff. I'm unsure if we even want to consider supporting physics in the editor, we need to watch the scope there I'd reckon.

Maybe the editor can support scriptable editor modules, so we can add support for things like this in-editor later if there's a demand for it? Would be a safe way to cut down on workload, at least until the demand is there.

@capnkenny
Copy link
Member

I'd agree, however I suggest we open a new proposal for the editor so that this thread does not go OoS 🙂

@RubyNova
Copy link
Member Author

So back to the main focus of the proposal; is this a good idea in any capacity?

@capnkenny
Copy link
Member

I believe it is a good addition once we can scope it out (with graphics and audio getting done, as well as the possible revamp of NovelRenderer, I think we'd probably push this back until that is done).

Looks like they're both accessible via vcpkg as well 👍

@RubyNova
Copy link
Member Author

Awesome to hear! But yes I agree it is not an immediate priority, I want to get the VN focus semi done

@Pheubel
Copy link
Contributor

Pheubel commented Mar 25, 2021

i'm gonna have a look at to how i could incorporate box2d

@capnkenny capnkenny added this to the Proposals milestone Jun 20, 2022
@Pheubel Pheubel removed their assignment Nov 1, 2022
@Pheubel
Copy link
Contributor

Pheubel commented Jan 31, 2023

Adding support for both box2d and bullet should be possible. But it might be better to first come up with a plugin interface, that way it should be easy for users to just use a simplified implementation through the plugin interface. If the plugin interface does not provide enough power to the user, then they should still be able to use the underlying physics engine.

it might be good to throw this issue on the backburner for not and instead look at providing a standardized interface that can handle the heavy lifting in a new issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
engine api Tickets pertaining to NovelRT's end-user API. engine core Tickets pertaining to the engine core codebase. feature A feature ticket for the NovelRT. proposal A proposal up for debate.
Projects
None yet
Development

No branches or pull requests

3 participants