I am both quite pleased with the plugins available with Lyra and extremely baffled.
The first thing I asked is why are these in a starter game? I didn’t even look at Lyra for months after it came out, busy as I was with my own project, which is a plugin. I only ended up looking at it for the settings screen. Once I found out I could take a more generic version of it out of the plugins, I jumped at doing so. But now my plugin relies on a plugin you have to download a whole project to get access to. It isn’t even just on the market as a free epic plugin or something.
Seeing more opportunity to save some work for me in the least convenient way possible for my end users I went through the rest of the plugins. Here is my feedback on each
CommonGame
A nice little library of better base classes for half the important engine classes, relies on ModularGameplayActors for absolutely no reason whatsoever. There is a single time that plugin is referenced, as a base class for UCommonPlayerController. The reason for this? So ULyraPlayerController can derive from it and UModularPlayerController. Nothing UCommonPlayerController does relies on being a child of UModularPlayerController.
Seeing as these are meant to be the new base classes and game features are an opt in thing maybe UModularPlayerController should be derived from UCommonPlayerController instead? ULyraPlayerController can derive from UModularPlayerController, dependency becomes common game->modular gameplay actors->lyra, instead of modular gameplay actors->common game->lyra.
But you could just make modular gameplay actors a bunch of interfaces. You can’t just have multiple base classes from opt in plugins relying on each other. Works against the whole plugin system. It is admirable that Epic is trying to demonstrate best practice in the engine, this is something I have missed from engines like UDK or Source. But it is like half your programmers don’t know about components, subsystems and interfaces. Too many cooks. This is a problem throughout the Lyra codebase.
CommonUser
Fantastic, thanks for this, whoever wrote this. Other staff: Please enable EOS in the launcher version of 5.2 so we can fully use it without building a project bigger than my main drive. It is kind of you to give Steam a free kick but I’m getting a bit concerned that you lot are just harming yourself now. Bit unrelated, but please for the love of god support your own online services. This should be strategically important for the whole company!
CommonLoadingScreen, GameplayMessageRouter, GameSubtitles, PocketWorlds, UIExtention
Nice, not much to say but these are good, useful, and shouldn’t be packaged with a example game.
GameSettings
Beautiful, couldn’t have possibly done a better job myself, the best kind of reusable code. Makes the old config CDO based settings look like a relic. Frankly, the use of it in Lyra is a little embarrassing. How could anyone read the plugin code and write Lyra to do direct accesses of a config CDO and a save game class? Every setting can be cast to a type that has direct access to the value of the setting, and its default value, along with events to hook into. You can pass something a game setting pointer and it can get what it wants and find out any time the things it wants changes. Don’t have a pointer? Search for it by dev name! This way, the settings registry becomes the live settings and the config files and save games the long term storage.
Two suggestions for this plugin:
It should have a local player subsystem that spawns the registry, instead of the settings screen. In my own plugin I have done this already and there was no particular barrier to doing so. It should have a settings registry class property in project settings or derived classes (plugin version of subsystem could be abstract?). Derived classes could have accessors for their long term storage. LyraStarterGame could demonstrate doing this.
Also, it seems like settings collections could offer built-in functionality to be collapsed or expanded, using edit conditions. All child settings of a collapsed collection would be hidden. Then an entry widget for a settings collection can trigger that by calling a function like Collapse, Expand. Would be very useful for large settings menus.
HOWEVER: My god, the settings screen widget in Lyra, what I found opening the event graph took my breath away. Given a registry of generalized but typed Settings objects it requests the specific settings collections by hard coded name, within a widget script. It searches for each of these by name. The top level settings are all the top level children of the registry and each has a display name as localized text. There is no reason to require changing the names in the blueprint and in the code.
This set of widgets were almost useful outside this example game. They’re decently skinned and show off how to use the layout widgets, and the animation system. In that way, I did get a bunch of value out of the widgets as they exist in Lyra, but wouldn’t it be better if there were no reason to not just duplicate the assets as the starting point for a settings screen for any unreal project? I feel like I am reinventing the wheel doing my own. But I can’t even attempt to use the actual widget assets in my project because they rely on classes within the Lyra game modules.
It would be nice if the GameSettings plugin provided a generic settings screen in its content, a really obviously unskinned looking one, that doesn’t rely on classes within the Lyra modules. Some of the stuff in the Lyra versions of these widgets could be in the plugin anyway, notably the tab list widget.
Implementing it outside Lyra has been a tedious journey learning all about several plugins worth of interconnected classes, hours of looking through blueprints, many with no care for previewing how it will actually look inside the designer. Please, I’m begging you, don’t put more developers through this. A basic user facing settings screen should be easier than this. You’ve almost done all the work for us.
