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.
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
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.
Project Settings > Game > Asset Referencing Policy > Project Content > Default Project Content Rule > Can Reference These Domains ⌠add an array element and select âShooterCoreâ
For the anim BP, this is how I see the relationship. The animation BP tells how to do stuff based on State, like in UE4. Like if he is Jumping how high before you change from the start Jumping to the apex, then to the landing.
Animation Layers describe how you move from one state to another by blending the current state with other animations to get the desired result(Running and shooting overhead)
The Character BP is just to say WHICH animation to use for the other two. When running(Anim_BP) use this animation(Character BP), how you should combine the animations, Shooting when jumping(Anim Layers). Hope I got this right, but that is how I think they are working.
I think the main question Iâve had as I learn Lyra is whether itâs the right tool for prototyping, or if itâs more like a framework you rebuild/refactor your gameplay in once you know exactly what you need to make?
I realize it will get less frustrating with practice, but even once I know all there is to know, is the opportunity cost of iterating on this workflow actually worth it for small-to-moderate scope projects? You know, things that arenât long-maintenance live-service multiplayer games.
To do things The Lyra Way Iâm finding there is a lot of boilerplate effort to invest, dozens of assets and classes and references and chains of events that Iâm required (or at least strongly encouraged) to set up, all to do something very simple like adding an input binding that Does A Thing perhaps with a callback of some kind, or add a new weapon that has special functionality.
Lyra is definitely a steep, mostly undocumented (Epic! ) learning curve.
The reward that you get for figuring it out is that Epic has already done SO MUCH boilerplate *** for you. Literally 10000s of lines of plugging engine things together is already done.
If you think itâs a pain to figure out how it works after itâs already done, imagine what a pain it will be for you to figure out how all of the pieces work and plug them together yourself. It will take you months of work, at least, depending on how good you already are with all of those engine components.
Better just to learn Lyra IMO if youâre at the learning stage like me. Once you get used to it, itâs not really that bad to use.
Itâs true that Epic did way too much of Lyra in ***-binary uasset/blueprint form. It makes it much harder to develop real derivatives of Lyra without duplicating much of what they did.
On the plus side, itâs pretty easy to duplicate what they did and change it to work the way you want it to. Thus only Lyra C++ is reusable in any meaningful form, and all of the *** binary stuff they shipped should be considered example only, and you need to use your own versions of those assets.
Still, I reiterate that IMO itâs worth the time to learn Lyra. Even if you decide to ditch it in the future, youâll have a much better understanding of the core engine pieces and how Epic put them together to make what they consider to be the next generation starter game template.
Iâve seen your writing on the topic of Lyra and itâs been a tremendous help. Great stuff!
Itâs clear that a lot of annoying stuff is already taken care of, and I of course appreciate having all of that in a final product. My initial assessment of Lyra was that itâs Epicâs attempt to make âThe UDK of UE5â and so far that intent has more or less been confirmed (though not in those words) by Epic staff.
It doesnât address my concerns regarding prototyping and what the most time-efficient way of doing that is when developing atop Lyra. My perception is Lyra adds a lot of extra architecture on top of an already architecture-heavy engine. Do you think that using Lyra as intended speeds up your prototyping process or slows it down when compared to throwing together quick-and-dirty Blueprints? The long-term maintainability benefits of Lyra are self-evident but when youâre developing commercial indie games of small-to-medium scope for a living that is rarely the wisest thing to be prioritizing.
So I think the core question is this: What prototyping process are people using for games built with Lyra? Do they start with a rough prototype built outside of Lyraâs framework in service of fast iteration time and then convert it to Lyraâs architecture once validated, or is using Lyra as intended actually speeding up that early iteration/validation process?
No idea RE that. Iâm just learning how UE5 is supposed to work and so using Lyra to see how Epic connected all those Plugins together and got them to do stuff.
In the process I am developing a game, but Iâm not concerned about a quick prototype. Iâm looking at it more as a research project to see how to make it in the framework that Epic recommended for new developers/games to use.
At first the project is hard to digest cause it tackles multiple things: online/multiplayer; mesh generation; improved character animation; modular abilities; asset/reference use permissions; re-usability; project-organization; etc⌠(probably missed something). This makes the project quite intimidating at first. Contrary to all other existing templates, which allowed me to test and tweak from the get-go.
To a mere mortal⌠It took me several attempts to understand the fundamentals⌠Here are some thoughts.:
(a) UE team should have broken the project into smaller parts and take an approach similar to Visual Studio and their scaffolding pipeline/method of presenting their products. When creating a new project give options to the templates:
Include a starting menu and options;
Include Online gameplay;
Include the lyra mesh generation;
Include the Character Animation (FPP, TPP, etc⌠Which shoud be in theory the starter animation pack)
Include the character, modularity and ability system;
Include inventory and interaction system;
etc⌠What ever makes sense to break into smaller parts/fragments.
This way all of the parts of the lyra project could be useful to someone. And they can be updated individually (e.g., the Lyra modularity and character animations are behind an intimidating wall that most will avoid. It is completely different from the templates.)
(b) UE team doesnât explain the Why(s) and the How(s). Quickly leading to different branches. e.g., you left an inventory and interaction test, but no documentation in how to build upon it. We are left only with the desire to use something that is nothing more than a test.
(c) Overall, the content of the project is good. It is clearly well organized. It has amazing features. It is clear to me that UE team wishes to create some kind of STANDARD-way of doing things so it becomes possible to work in different projects without knowing all of the details.
I think it is a question of commitment from UE part: which parts are considered best practices and will receive support? I want to try the modularity and ability system but something doesnât feel rightâŚ
YouTube videos have the problem that ctrl-F doesnât work, plus they take longer to watch than documentation takes to read, plus you canât copy-and-paste from the video into your IDE.
Looking at the EPIC Dev best practices guide which recommends to build your game as a GameFeature Plugin, begs the question: What is the purpose of the main Content and C++ folders if everything is supposed to go to plugins?
The purpose of those folders is to implement Lyra, which is a framework that makes it easy for you to build your game as one or more GameFeaturePlugins.
Think of Lyra like the Engine. You donât go putting your code in the Engine source area right? Same with Lyra. Donât put your code in the Lyra source area. Instead, you make a GFP and put your source there.
There are rare circumstances where you must make a non-GFP plugin to contain some code (for example if you want to modify World Settings). But in general you can do most things in one or more GFPs.
) learning curve.
