Download to read offline
Modularity In Lyra - A new studio's experiences building their prototype on Unreal Engine's LyraStartergame
- 1. Modularity in Lyra OurExperiences and Learnings Building Our Game On The Foundation of Lyra
- 2. Founded August 2023as a First Party NetEase Studio What were we building? What we knew: Session-based, Multiplayer, Third Person Shooter, with an innovative, high-level differentiator. What we didn’t know: A lot of details on how we would express the innovations in the moment-to- moment. That’s what was fun about it! The game could be anything. We had a lot of room to “find the fun” and a talented team that was experienced enough to make it happen. We can divide our time into 2 main phases: 1. Early days (2023 - 2024). Find the fun / Develop process and culture 2. Later days (2025 - The End?). Need money. Demo mode. About T-Minus Zero
- 3. Lyra - WhatIs It? At face value, Lyra looks like a nice simple third person shooter with a handful of game modes. An updated ShooterGame In practice, the bulk of the code and content ends up being a demonstration of Epic’s approach to building modular, extensible game systems. ● Game Feature Plugins (demonstrated) AND Experiences (the focus of my talk) ● Demonstrates that modularity in its usage of the Gameplay Ability System (Mike will cover this in a moment)
- 4. Lyra - WhatIs It? CORE Game Features / Experiences
- 5. Adopting Lyra -How Much?
- 6. Adopting Lyra -How Much?
- 7. Lyra - WhatIs It? CORE Game Features / Experiences Our Game
- 8. Lyra - WhatIs It? At face value, Lyra looks like a nice simple third person shooter with a handful of game modes. An updated ShooterGame In practice, the bulk of the code and content ends up being a demonstration of Epic’s approach to building modular, extensible game systems. ● Game Feature Plugins (demonstrated) AND Experiences (the focus of my talk) ● Demonstrates that modularity in its usage of the Gameplay Ability System (Mike will cover this in a moment)
- 9. Lyra - WhatIs It? Game Feature Plugins - A special plugin (with content) meant to be dynamically loaded. References: ● Game Feature Can references Core Game Code and Content ● Core Game Feature Code and Content cannot reference the Game Feature Plugin ○ Make an interface base class, event, etc! When loaded, Game Feature Actions are applied ● Game Feature Actions are lists of added components, widgets, ability sets, actor types, data layers that can be added. The Game Feature Plugin has an asset manager that discovers User Facing Experiences ○ The User Facing Experience loads Map, Player Pawn Data, and an Experience Experience: ● Additional Game Feature Actions So we are able to assemble lots of useful pieces in lots of individual asset. Powerful, right? BUT: Organizing all this is HARD.
- 10. Adopting Lyra -What Did TM0 Do? ● Keep LyraGame Module - Add and extend but avoid modifying. ● One Game Feature Plugin - GemProto ● One Experience - GemDefaultExperience ● Many User Facing Experiences (mainly for loading different maps).
- 11. Adopting Lyra -What Did TM0 Do? The Wins! ● On Steam with “online” multiplayer very early ○ (Great for a remote-first studio) ● Minimal fussing with new systems. Nearly everything we made built on the systems in Lyra: ○ Front End Flow ○ Weapons ○ Abilities We were quickly focusing on what mattered for our game.
- 12. Adopting Lyra -What Did TM0 Do? Too Modular Not Modular Enough Struggle #1 - Modularity Dilemma
- 13. Adopting Lyra -What Did TM0 Do? Struggle #2 - What is core? The Team frequently asks: “Where do I put this new content?”
- 14. Adopting Lyra -What Did TM0 Do? Struggle #3 - Additional Loading / Replication Complexity Wait for Experience Ready + Other Delay nodes.
- 15. Adopting Lyra -Recommendations & Recap Use Lyra Core game and content. Make your own Game Feature Plugin - Dupe and Diverge from Shooter Core Expect to make edits. ● Inventory ● Interactions
- 16. Adopting Lyra -Getting Started Goals: ● Minimal Code Editing - Want to take sample code updates from Epic ● TM0Game.exe not LyraGame.exe Steps: 1. Replace Lyra*.Target.cs -> TM0*.Target.cs 2. In each Target.cs file, replace LyraGameTarget with TM0GameTarget Your module name will still be LyraGame, but your executables will be TM0Game.exe
- 17. Adopting Lyra -Getting Started Practical Suggestions: ● When you add new code, prefix the file and class name with a codename or studio name (Ex: TM0JetpackAbility.h) ● Avoid editing Lyra Systems ○ Extend ○ Duplicate and Modify
- 18. References: ● Game FeaturePlugins (Unreal Docs) ● Plugin-afying Lyra Unreal Fest 2024 ● x157 Dev Notes ● Fixing Lyra’s Inventory System ● Gameplay Blueprint Attributes plugin (Highly recommended!)
Editor's Notes
- #2 We knew next to nothing specific about: Specific player movement mechanics Specific player equipment options RPG Mechanics Enemy density and style. Mission Objectives We didn’t build systems that we would call “feature complete”. All development was focused on finding the fun. So, tying this back to our topic, Was Lyra a good starting point for our project? What lessons did we learn? Would we do it again?
- #4 The core is fairly simple. Many types exist to support being GameFeature or Experience - driven Also some simple core systems that are meant to be common to all games: Inventory / Equipment Systems Character Cosmetics Context Effects Input Settings and Mapping The Experiences, which exist in Game Feature Plugins are meant to be modular, game-specific “add-ons” Think Fortnite Save-The-World vs. Battle Royale
- #5 Imagine a continuum of degrees to which a team might adopt Lyra and its concepts…
- #6 …we were at the far end. This got us shooting and moving around very quickly! Some basic config changes got us up and running on Steam with EOS-supported Multiplayer sessions. Yay that was fast.
- #7 Our Game built on Shooter Core, so we had 2 layers of content modules to contend with.
- #8 Going back to the previous slide, you can sort of visualize the difference between the very general “Core” and an “Experience”
- #9 So… everyone’s eye may glaze over as we look at this wall of text that tries to describe exactly HOW Game Features and Experiences assemble little bits of
- #10 As mentioned way back at the beginning, there was a lot we didn’t know, and we weren’t exactly focused on building everything “right”. So we didn’t put much thought into it.
- #11 No regrets
- #12 Too Modular - You don’t know up front what might want to be swapped out Abstract, confusing Not Modular Enough - Your Character Pawn becomes a monolith. Try a new jetpack? Not without breaking the old one. Swap out a new widget? Not without breaking the old one. New Movement type? Each movement type refers to the other. Sweet Spot: You can add and try new things without major surgery. Metric I use is: Can the purpose of a class, component, or system be described in a few sentences? If yes, then it should be a system. If no, break it down and clarify. Avoid referring specifically to another system in this description
- #13 As mentioned way back at the beginning, there was a lot we didn’t know, and we weren’t exactly focused on building everything “right”. So we didn’t put much thought into it. This meant that in practice Game Feature Plugins and Experiences were slowing us down!
- #14 Game Feature Plugins and experiences add an extra step to an already complex world initialization and replication process. Actors like Player Controller, Player State, Player Pawn must be replicated and each feature plugin must also be loaded and applied.
- #15 IF: You are a session-based multiplayer game.