Lyra should be a plugin with API exporting for portability and extensibility

General Feedback & Requests
, ,
1

I’ve been using the Lyra framework in our project. Generally it is an amazing foundation to start a game on. However, I keep running into situations where I’d like to make a childclass of a C++ class in our GameFeature module’s source, but it isn’t exported via the api.

My desire is to not modify the base Lyra files if possible. So to add new functionality I’d like to use a child class. For instance, with the LyraQuickbarComponent, I’m unable to make a childclass in C++ except in the main project because its API isn’t exported.

There’s quite a few assets in the Lyra content folder that aren’t necessary for Lyra to work.
Ideally these would be separated out a bit and have better settings for extensibility. Example:

  • LyraFramework as its own plugin that would have the code for the game startup, menu, settings modification.
  • LyraGenericGame plugin with the functionality like Inventory management, and player code.
  • ShooterCore already exists and is a nice separation from the rest.

P.S. It would be really nice to have Lyra on GitHub so we can make pull requests, see changelists, report issues, and discuss practices.

2

I agree with your overall sentiment.

It is impossible to use Lyra as a C++ developer without exporting large numbers of classes, as you have seen.

Along these lines, I have posted my thoughts on how to extend Lyra as a C++ developer:

Regarding source control:

Lyra ships with a bunch of plugins as part of its source. This approach is deeply flawed at a fundamental level.

Each plugin should be its own project on Github, Lyra then needs to include them as Git submodules, and then Lyra should be released on Github, with references to the other projects that it depends on.

Obviously it would be optimal if Epic learns to use Git submodules correctly, and stops trying to force everything into monolithic copy-pasta nightmare repositories.

Even if they can’t do that, a Lyra copy-pasta repository would still be better than nothing at all.

3

Yeah, I’m doing plenty in C++. But having so much of their code isn’t API exported, so I have to modify it to use it in my gamefeature plugin.

It would indeed also be nice if some of those other plugins didn’t just live in the Lyra project.

1 Like
4

Obviously it would be optimal if Epic learns to use Git submodules correctly, and stops trying to force everything into monolithic copy-pasta nightmare repositories.

Well, internally they use Perforce (and so do most licensees I’m assuming), so git submodule doesn’t really feel generic enough for this problem.

But yeah, some kind of package management would be very helpful, similarly to npm/composer, being able to fetch from GitHub, internal servers, Marketplace, etc.