Best practices to build upon Lyra

Development Getting Started & Setup
6

At the moment Lyra is just too different to consider merging anything or building from it.
Considering the advanced animation I think this would be a great place to start trying to integrate into our games. Has anyone had any success breaking down the complexity of this ? I’d like to know the relevant c++ references & how they link to what seem to be multiple blueprints.
Character blueprints with no defined animbp are confusing & once again there seem to be multiple character blueprints. I am overwhelmed with how all these correlate & the c++ code seems to be very empty. I guess it’s all derived from plug-in classes ?

More documentation is needed on this.

2 Likes
7

Have been looking at Lyra for a few days now. Have to say I have a really hard time understanding the build. The code is all over the place, assets are all over the place. There is really no clear way to see how the logic flows. 15 different plugins for this little demo. Editor is extended quite extensively with custom plugins. Modularity is good, but where is the point where its gone too far, and the complexity is just crippling. This project needs a lot more documentation and explanation, for me anyways.

19 Likes
8

Lyra is a great starting point for any kind of game, unlike the other example projects this feels like more of an actual starting project.

Essentially you don’t really need to change anything in the main games content directory but instead create a new feature module to house your games core logic I made “RPGCore”. Then you can look at the shooter core to see what data assets are required to turn your new module into a functioning experience.

Everything is very modular for example the input bindings are a data asset attached to an experience that populate the menus when you load a new experience at runtime.

It also has a nice foundation for an inventory system that takes advantage of fast arrays.

I highly suggest taking a deep dive into Lyra the whole framework is a game changer.

7 Likes
9

The Lyra Framework isn’t so complicated. Different to the old way. But the added complexity is the result of layers of abstraction. This is what makes the magic happen. Using the Lyra content is pretty straightforward to. Instead of directly referencing assets in an “illegal” manner, declare dependencies the prescribed way. This video breaks it down in simple terms: UE5 Lyra - Asset Referencing Error PROPER FIX - Mastering the Lyra Framework - YouTube

4 Likes
10

I’m new to Unreal Engine and so I’ve decided to dive head first into Lyra. There is so much integration of mandatory-non-fun already done in Lyra, I have zero desire to recreate the wheel on that front.

IMO the benefits of starting with a working game foundation vastly outweigh the eventual certain code merges.

My thought is to store a blank default copy of Lyra in a Git repo so that I’ll have it as a reference. If/when Epic ever publishes updates, I can easily see exactly what they changed so I can merge it into my own code.

It would really be so much better if Epic would just put this on Github themselves, and push changes to it if/when they are necessary. Otherwise I’m not really sure how I’ll even know if/when they update it.

6 Likes
11

FYI searching around for Lyra stuff and I found this confirmation from Epic that they are considering putting Lyra on Github:

12

My take on this is that you should treat Lyra as a “total conversion,” or as a “copy and paste re-use.”

If you already have a game, you copy-and-paste the bits that you want out of this project, to merge into your game.

If you’re starting a new game, rename this one from Lyra to YourGame, and start editing inside the actual code/assets of the sample. The code does not look like it’s set up to receive easy API-preserving updates from upstream changes, so any “later update” would have to be big surgery anyway.
If there is a later version with bug fixes you want to include, the best way to do it, is likely to do a three-way merge with the original Lyra as the base. See what changed from Lyra-Base-Old to Lyra-Base-New, and fold those changes into your code if it’s easy, or make a note to make those same changes in your code, if it’s a hard clash.

1 Like
13

I like many have a game that I’ve been working on in ue4 & like many I used the shootergame example from ue4.
I have managed to get lyragame animations working in shootergame with all the functionality I need. However, the upper body isn’t blending the way it does in Lyra.
Migrating the animbp directly seemed to break it so I reassigned the the animbp baseclass to the default anim state before migrating, then copied lyracharactermovement & lyraanimstate to my c++ project & made the necessary code changes then reassigned lyraanimstate as base class.
Obviously you need to create calls to your functions such as aiming, firing ect.
Does anyone know anything about the upper body blending ?

14

The easy way ia create a new game feature with c++, no blueprint ok, and close the project, regenerate a visual studio project, and edit plugin and put to shoot core how to dependency to access ao feature context, if need shoot maps add to lugin dependency, restart the project or rebuild to project and should be works.

15

Thanks but I’d like to just implement the animation & get a comprehensive understanding of what’s going on during the process.
The thought of merging all of Lyra with my game is daunting & would be a mess full of unnecessary assets & code.
I’d love to hear from someone who feels they have a good understanding of the animation system. As I said before I have everything working but there seems to be some additional upper body blending in Lyra that isn’t translating when merged to another project.

Thanks, let’s keep the conversation going :+1:t2:

1 Like
16

By this point I think I obsessively read every single document, web page, watched every YouTube tutorial, reached last page of Google, went into the final frontier of the space-time continuum and converged with alternate realities. (I know it’s strange) I still haven’t found single example how to create separate game feature plugin and have it extend Lyra in this vast world wide informational highway of interwebs.

Pretty much every example I saw, everyone puts their code either in the main Content folder or in the one of the Shooter plugins. I tried myself and have met issues on every step.

Did anyone had success with this? Or do you know any link/tutorial/doc explaining best practices for this? I am really up for leaving Lyra plugins unchanged so I can easily update them later but it just seems so complex to figure it out and connect everything. It doesn’t help that Lyra content is (seemingly?) randomly sprinkled over three different locations (Content and two plugins).

1 Like
17

I had a similar experience as you. I finally decided just to figure it out myself.

This is far from perfect, and is very much a work in progress, but this should help point you in the right direction:

Also I’ve come to the conclusion that it is 100% impossible to “not modify base Lyra code”. There are bugs. There are massive numbers of classes that you’ll need in C++ that are not exported. There are private scoped variables with “allow blueprints to modify private” meta uproperties that spectacularly fail to consider derived C++ classes as a possibility.

You will be forced to modify Lyra code. Just try to do the bare minimum modifications as necessary, that is my goal. That means I’ve copied all the Lyra blueprints, Data Assets, etc to my own project to modify them. It also means I’m extending C++ code in my own project and adding the functionality that I want to those classes (but again I’m forced to export Lyra stuff and/or change variable/function scopes in some cases).

A lot of what I’ve done isn’t documented on that site, but the starting steps are there. Hopefully it’s enough to point you in the right direction.

Good luck. :slight_smile:

6 Likes
18

Hey thanks, amazing stuff! Just went through your blog and really impressive and detailed. Especially the dissection you started to write. Also subscribed to your YouTube channel, loved the short videos with fixes for some of the annoying issues. Thanks for sharing , keep up the amazing work!

How much of the files did you end up copying and changing? In one of my attempts I decided to try something similar to what you did but kinda ended up in the copy-pasta spiral getting more and more files copied, and then when I see most of the other developers just merging their code directly I wonder how much use it is of going the long way?

For example, if you want to just change elimination mode from 15 points to let’s say 50 points it’s 2 seconds change of 1 node inside the score BP file. But if you want to do it from your own plugin you have to copy quite a lot of connected files even some UI Widgets connected to that BP.

Is extra work worth it? If you end up copying and changing a lot of files you won’t be able to seamlessly update to the new version of the plugin anyway, right?

19

In general I’m trying to modify as little as possible. My strategy so far has been as I build out my game, I’m trying to use unmodified Lyra assets as much as possible. However when I see that I’ll need to change something, I copy that asset (sometimes necessarily including one or more of its dependencies) to my project, and change the ones on my end.

In this way I don’t have an ENTIRE copy of EVERY Lyra asset in my code, only the ones that I actually needed to modify.

Unfortunately a lot of what seems to be to be core Lyra code is done in blueprints, which while accessible and easy for scripters to see what’s happening, are otherwise TERRIBLE and ANNOYING AF for knowing who changed what and when, and whether I want that change or not, which to me is far more important than accessibility.

The thought of trying to merge in future Epic BP updates is mind numbing so I’m trying to avoid ever having to do that.

The more I dig into Lyra the more I’ve come to the conclusion that you should NOT try to extend ANYTHING that is implemented as a BP or a DA. Only use the C++ base, and even that (as of 5.0.1) requires you to make minor changes to it to be usable.

Treat the BPs and DAs purely as examples. Make your own BPs and DAs.

If the LyraGame or dependent modules C++ changes, you’ll be able to see exactly what is different from their version to yours, and merging their changes will be as painless as possible.

If their BP/DA examples change, and you’ve derived from them, the amount of work necessary to visually inspect every single aspect of every single BP/DA to try to find meaningful changes is likely going to dwarf the up front cost of spending a few minutes duplicating their example stuff to your project and just building out your own stuff from there.

In your example you change the elimination mode in an Epic-owned BP. If you import their future upgrades, you’ve effectively removed that change you made to their BP, you’ve replaced it with you-have-no-idea-what change they’ve made and there is no real evidence that your expected change no longer exists. :nauseated_face:

BPs and DAs are great for artists and scripters and end users. They’re garbage for building extensible systems that other developers might consider building upon.

So, “is it worth it?” The answer IMO is if you are just messing around with Lyra and you’re going to throw your work away anyway, then no it’s not worth it. Do what the majority of developers are currently doing and modify Lyra in place and know that you’ll never be able to get updates with a reasonable amount of effort in the future.

However if you’re building an actual game that you intend to maintain for a while, and you know you want Epic’s C++ upgrades along the way, then treat the BPs and DAs as reference material, and try to NOT modify them AT ALL. If you need to change a BP/DA then you need to duplicate it to your project and change the one in your project only.

(I have lots of history maintaining C++ for long periods of time, I just started UE5 though so I’m new to BPs/DAs. If someone shows me how I can get reasonable version diffs on BPs/DAs this opinion is subject to change).

4 Likes
20

Ah I think now it “clicked” for me! Yeah I guess you are right about that. I guess I was trying to find the way to extend BPs and DAs without realising that I probably shouldn’t even try. Thanks!

To be embarrassingly honest I am actually developing my game for a year now and am still at the square one. This is going to be probably my 16th version I start from scratch and every time I promise myself this is the last time I am starting from scratch. I progressed quite well last time and then Epic swooooop in with the UE5 and all the Lyra goodness and as you said, it was just so much of amazing stuff provided in for free and already built, I couldn’t pass on this opportunity and miss out on it.

Which is why I am trying now to nail the setup once and for all and not look back. Guess it’s time to create NewGame(1)_definitly_final_Last_version_Finalest-For-sure project :rofl:

2 Likes
21

:rofl: :+1:

I have a ton of C++ experience but only a few months of UE. I had just gotten comfortable with UE4 when UE5 dropped and I couldn’t pass up the opportunity to learn about Lyra so I could build off of it. It has consumed a few weeks of dedicated learning but it has been well worth it.

Starting and restarting is an amazing way to teach yourself. The best way to do that is just to keep trying to build stuff, learn from your experiences, then do it again and try to make it better. Rinse, repeat.

In my experience it takes a few tries trying to do something before I think I understand the base systems well enough to implement a solution that’s actually worthwhile.

Those early attempts weren’t waste - they were an investment in learning.

That being said at some point you’ll find yourself spending a lot of time redoing things for not much real benefit, and then it’s (past) time to move on.

To move a new project from UE4 to Lyra? 100000% worth the learning time investment IMO.

4 Likes
22

I have been checking out Lyra for a couple of days and I was thinking it would be better to have my own C++ project with the LyraGame and LyraEditor source files to extend from, then build upon that, but it seems like the gameplay tags require to load assets from the Lyra Modules so you have to add those modules, only to find out that if you do you go down a rabbit hole having to setup the asset manager from Lyra, some config files, etc. I’m about to dive into using the plugins to make my own game but I do wonder what the best path would be.

If I end up extending the Lyra Project files I’ll make sure to share that with the community. Also a shoutout to @xi57 for documenting the setup using plugins, thanks for making my life easier :slight_smile:

1 Like
23

I have met the same problem.
I think the main content cannot reference the assets in Plugins, but Plugins can reference other Plugins after config.
Open the GameFeatureData file in your GameFeature folder, and click Edit Plugin Button.
Then add your reference plugin to Dependencies → Plugins.

24

I have met the same question

25

Project Settings > Game > Asset Referencing Policy > Project Content > Default Project Content Rule > Can Reference These Domains … add an array element and select “ShooterCore”

3 Likes