Best practices to build upon Lyra

Development Getting Started & Setup
1

Hey!

What would be your recommendations to build a project upon the new Lyra Starter Game?

Probably best to split this question into multiple parts:

Code

  • When I create completely new gameplay-related C++ classes, should I add them to the LyraGame module, or should I make a new gameplay module that depends on LyraGame?

  • In general, when I create my own gameplay-related classes like pawns or characters, should I inherit from Lyra C++ Classes, like “LyraCharacter”, or should I rather create a duplicate of “LyraCharacter” and rename it?
    I fear that if I inherit from Lyra classes, every future engine and LyraStarterGame update might mess up my game, and I think it would be good to keep the engine and Lyra updated as long as possible while developing my game.
    So I think I currently prefer creating duplicates of Lyra classes and renaming them, then hooking up everything in the game to my duplicated classes, and when Lyra gets an update, my game does not break, and I can manually copy over the changes from the new Lyra files.
    When my duplicated classes get messed up by an engine update, I can also just have a look at the new Lyra version and see if some changes there solve my issues.
    What do you think about that? Is that approach dumb?

Content:

  • I think the folder structure and naming conventions in Lyra are pretty good. Currently, I think it would be best to just use the existing folder structure and put my new stuff in the same folders where the Lyra Starter Game stuff is located.
    My own main menu widget blueprint would then be located under “Content > UI > Menu”, in the same folder as “W_LyraFrontEnd”.

  • Most of the asset names from the Lyra Starter Game contain the term “Lyra”; some of them don’t, unfortunately, like “MI_UI_TitleMaterial” or “W_UserWatermark”. To keep things a little bit more organized, I thought about putting all files from the Lyra Starter Game into a “Lyra Collection”.
    Sadly there is no function to hide objects in the content browser that are part of a certain collection, but at least I can see that a file came from Lyra when I hover over it.

  • Then there is the inheritance vs. duplicate question again, pretty much the same as with the C++ class duplicates. My gut feeling tells me that it would be good to keep the Lyra files as they are and only modify duplicates from them (or create new ones from scratch that have similar implementations of certain things).
    If I create children from the Lyra blueprints, a Lyra update might mess up my game, and editing the existing Lyra files is probably also not a good idea, as every update would then overwrite my changes.

I also noticed that quite a lot of content is put into plugins, like “ShooterCore Content” or “LyraExample Content”. Not sure why though, and how I should tread those in the future.

Well, these are my thoughts so far. What would be your recommended way of building a game upon the Lyra Starter Game? Maybe some kind of “Build upon Lyra best practices” would be a good tutorial or a good addition to the Lyra documentation.

Thanks,
Sascha

16 Likes
2

Thanks for starting this thread. I had been working on a 3rd Person zombie shooter in UE5 EA, but a lot of my blueprints were not set up for multiplayer. I was dreading having to go back and work that in.
With Lyra, I see an opportunity to build on their multiplayer base, but like you, I am worried about upgrades.

1 Like
3

Same questions here. I created a new level inside the lyra project and when I try to use blueprints from the plugins folder or duplicate any blueprints and copy them out of plugins (such as B_WeaponSpawner), I get errors such as:

mymap.umap: Illegally references asset /ShooterCore/Effects/Material/MI_WeaponSpawnerTimerIndicator. You may only reference assets from EngineContent, Plugin:LyraExampleContent, Plugin:LyraExtTool, Plugin:PocketWorlds, and ProjectContent here. (AssetValidator_AssetReferenceRestrictions)

Is there a way to fix this? The only other option I see is moving all my stuff under one of the “allowed” folders it lists, but surely that’s not right. Thanks for any advice and help!

5 Likes
4

I haven’t made a deep dive into the “modular game features” system yet. Still, as far as I understand it, the supposed workflow is to create a new custom modular game feature, which will then also be listed in the “plugins” folder. Then you can tell your new modular game feature that it depends on another Lyra game feature, and then you would be allowed to reference assets from the Lyra plugin elsewhere (maybe even inherit from them?). I haven’t tried yet.

The modular game system and a lot of other things in Lyra are very different from how I used to work with Unreal 4. Quite a lot of new stuff to learn. I hope Epic will make a deep dive into “how” and more importantly “why” they made Lyra that way.

7 Likes
5

Yes, I believe you are correct. I haven’t found the pertinent documentation on that yet, but I did find an easy fix in the meantime. If you go to Project Settings → Game → Asset Referencing Policy → Project Plugins, you can remove the rule that is there, which causes the errors I was getting. I would of course like to know the correct way to do it, so if anyone knows, please link the docs. Shoutout to Youtuber JohnnyTries VR for finding this fix for me.
Thanks!

2 Likes
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.

3 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.

22 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

5 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