Stride 4.3 brings .NET 10 and C# 14, Bepu Physics, Vulkan compute shaders, custom assets, cross-platform build strides, mesh buffer helpers, Rider/VSCode support, and performance and stability fixes. Table of Contents: * Download and Upgrade * What's new in this release * What has changed since Stride 4.2 * Bepu physics integration * Vulkan compute shader support * User-defined Assets * Ongoing efforts to build projects from Linux and Apple desktops * Efficient API to manipulate meshes * Open project with Rider and VSCode from the GameStudio * Interface processor * And more minor changes * Fixes * Also good to know * Funding and Resource Allocation * Call for Skilled Developers * Join Us on This Journey * Links * Acknowledgements * Long-time Stride supporters * Gold Striders ## Download and Upgrade 🔗 You can download the Stride 4.3 Installer today. Release notes are available here. Make sure you read the guide to update Stride and projects properly. ## What's new in this release 🔗 Stride 4.3 includes numerous enhancements and improvements. Here’s what to expect: * **.NET 10 Integration** : Stride 4.3 is now fully aligned with .NET 10, harnessing its performance improvements and efficiency gains for game development. This means faster execution times, reduced memory footprint, and access to the latest C# features, making your development smoother and more efficient. Learn more * **C# 14 Features** : With C# 14, Stride users can write cleaner, more concise code thanks to new language features. These improvements reduce boilerplate and enhance readability. Introducing C# 14 ## What has changed since Stride 4.2 🔗 ### Bepu physics integration 🔗 Adding support for Bepu Physics, a ridiculously fast physics engine written entirely in C#. Having both a game and physics engine in the same ecosystem reduces the cost of maintaining and improving it, the overhead that we may incur when communicating between the two APIs, and the barrier to entry for contributors. Bullet is still the default physics engine, and we welcome any contribution towards it, but our efforts will be focused on Bepu from now. The integration is effectively done, with Bepu's feature set now being slightly ahead of Bullet's. Have a look at this page if you want to migrate to Bepu. ### Vulkan compute shader support 🔗 The Vulkan graphics backend has been modified to support compute shaders, and the shader compiler has also been modified to support compute shader generation for GLSL. ### User-defined Assets 🔗 Introducing Custom Assets, a way to define and store data which can be referenced across multiple components, scenes and through other assets. The asset compiler also gives you the ability to build more complex systems like custom file importers. ### Ongoing efforts to build projects _from_ Linux and Apple desktops 🔗 Stride can build games on Windows targeting the different devices we support, but building directly on those platforms was not supported until now. We've introduced a couple of changes to improve on that front: * Replacing our custom C++/CLI FBX importer with Assimp * Fixing the asset compiler to run on all desktop OSes * Many build-system refactors to move toward fully cross-platform development * Building VHACD for Linux * Adjust FreeImage and DirectXTex for all platforms Some work is still required on this front, but simpler projects can now be built on those platforms. ### Efficient API to manipulate meshes 🔗 Vertex buffers do not have a standardized layout, each mesh may have its own specific layout and data type it uses for its vertices. Some have blend weights, or tangents, while others only have positions - they may also use different data types, for example Half4 positions, 4byte color ... We added in two helpers in VertexBufferHelper and IndexBufferHelper to provide a standardized way to read and write to those buffers. ### Open project with Rider and VSCode from the GameStudio 🔗 While any IDE can open and build Stride projects, the editor button to open said project only had special handling for Visual Studio. Jklawreszuk added support for Rider and VSCode. ### Interface processor 🔗 Stride has a component processors, a user-defined class which can collect and process all components of a given type in the running game. It is also known as the `System` part of the `ECS` acronym. The new flexible processing system provides more type safety, and the ability to process components by their interfaces. You could, for example, implement a custom update callback any component could receive through this API. ### And more minor changes 🔗 * HDR Rendering Support for D3d/Windows * User-defined gizmos * Haptic feedback integration for VR runtimes * API for OpenXR Passthrough ### Fixes 🔗 Although there have been many fixes, we'd like to point some of them out: * Major performance improvements, particularly for graphics and UI * Multiple fixes improving Vulkan, OpenGL, games under Linux and OpenXR stability * And fixes for edge cases when reloading assemblies in the game studio ### Also good to know 🔗 We are already hard at work on a bunch of ongoing projects for version 4.4 and beyond: * Continuing work to allow for building games _from_ other platforms * Converting our Windows-only GameStudio to cross-platform through Avalonia We welcome anyone willing to contribute to this project over Here - just have to make sure to add a comment to one of the unassigned issues you want to work on * Improvements to shader compilation, reducing in-game hangs while building shader permutations. Here * More work on D3d12 and Vulkan as we slowly transition away from D3d11 ## Funding and Resource Allocation 🔗 ### Call for Skilled Developers 🔗 We are actively seeking skilled developers with experience in C#, the .NET ecosystem, mobile, XR, rendering, and game development. If you have these skills or know someone who does, we encourage you to get involved. There are opportunities to contribute to critical areas of Stride's development, supported by available funds. ### Join Us on This Journey 🔗 We’re always excited to welcome new contributors to the Stride family. Whether it’s through code contributions, spreading the word, or donations, every bit helps us grow stronger. If you’ve got skills in .NET, Android, and iOS development, there’s a special place for you here. Support us on OpenCollective. ## Links 🔗 * GitHub: https://github.com/stride3d/stride * Website: https://stride3d.net/ * Documentation: https://doc.stride3d.net/latest/en/manual/ * Twitter: https://twitter.com/stridedotnet * YouTube: https://www.youtube.com/@Stride3D * Stride Community Toolkit: https://stride3d.github.io/stride-community-toolkit/index.html ## Acknowledgements 🔗 We extend our heartfelt gratitude for all the hard work and donations we have received. Your generous contributions significantly aid in the continuous development and enhancement of the Stride community and projects. Thank you for your support and belief in our collective efforts. In particular, we want to thank these donors: ### Long-time Stride supporters 🔗 * VVVV🥇 ### Gold Striders 🔗 * Happenstance Games🏆 * Vašo ( Vaclav )🥇 * Lucid Silence Games🥇 * WidowMakes🥇 * Norbo🥇 * First Hour🥇 This article was co-authored by Eideren.

Distant Worlds 2, the sequel to the acclaimed 4X strategy game Distant Worlds: Universe, was developed by Code Force and published by Slitherine. In this blog post, the developers answer key questions from the Stride community, offering insights into their experience using the Stride engine to bring their ambitious galaxy-spanning strategy game to life. Table of Contents: * Intro * Engine and General Development * User Interface * Artists and Asset Creation * Level Design and Prefabs * DLC and Content Expansion * Performance and Optimization * AI and Game Systems * Future Use and Recommendations * Conclusion * Links ## Intro 🔗 Our Stride community has been eager to learn more about the development of Distant Worlds 2. We reached out to the developers at Code Force to hear about their experience using the Stride engine to create this ambitious 4X strategy game. We're incredibly grateful to the team for their generosity with both time and expertise. The depth and breadth of information they've shared, spanning everything from engine selection to performance optimization is impressive. Their willingness to provide such comprehensive insights is truly appreciated by the Stride community. Some questions were answered by the team collectively, while others were addressed individually by team members: Elliot, the Lead Developer; Kevin, the Lead Artist; and Alex, the 3D Artist. Buckle up and enjoy the ride, you're about to dive into a rich technical deep-dive and maybe learn something new along the way! ## Engine and General Development 🔗 #### Why did you choose Xenko/Stride over other alternatives for Distant Worlds 2? 🔗 Our requirements for the DW2 game engine were: * Full support for all features of C#/.NET * High quality rendering, also allowing for the use of custom shaders * Good asset pipeline support Stride handles all of these areas very well. One of Stride’s major strengths is how it integrates with .NET: it is nearly completely written in C# itself, and it stays up-to-date with .NET version releases. You are not locked into any specific approach to writing code. You have full access to all parts of the .NET environment. You don’t have to use scripting tied to a specific custom version of .NET. Instead you can simply make your own implementation of the `Game` class, overriding the `Update` and `Draw` methods from the base class. That’s the basic approach we took with DW2. We use Stride in two main ways for DW2: * Rendering engine, using PBR models and materials with the scene/entity system * Content/Asset bundling, using the Stride Game Studio to package assets for loading into the game Beyond that we write all of our code as a standard .NET application with classes, structs, etc. We don’t use any scripts. Additionally, because Stride is open-source, if you find an issue you can always fix it yourself. You can also figure out how things work by examining the source itself. Then, if required, modify things to work the way you want. Stride also has great rendering with PBR materials. And it has a very nice shader model that allows you to write your own custom shaders. #### How much modification was needed to adapt the engine for your needs? How difficult was this process for the developers involved? 🔗 We started experimenting with Stride back when it was called Paradox, around version 1.2. So there wasn’t much documentation back then. We had to just figure things out by examining the source. Documentation improved as the engine progressed through the 1.x versions, and became Xenko. A key requirement for DW2 was to mix entity-level rendering for units (ships and bases) with custom shaders for the larger galactic environment. Most of the DW2 environment uses custom procedural shaders to render things like planet surfaces, stars, nebulae and other items (see this article for details). However for the unit-level rendering we wanted to use Stride’s PBR materials and the scene/entity system. The artists would build space ship models and materials which we would load into a scene. We achieved this by separating out the custom shader rendering into pre- and post-scene rendering in the `Game.Draw` cycle. So we built our own rendering classes that inherited from `SceneRendererBase` and inserted them into the `GraphicsCompositor`. This also allowed us to have rendering layers that excluded the post-processing effects (bloom, lens flare, etc). This was especially useful for the user interface. There may be a better way to do all of this in Stride now, but that’s what worked for us. #### We noticed references to both Xenko and Stride in the build. Are there specific reasons older files were retained during the transition? 🔗 Any remaining Xenko files are just a holdover from our development history. We should probably remove them 🙂. #### How frequently do you update the engine for your project? 🔗 Initially we had some small custom changes to better support our pre- and post-scene rendering mentioned above. When we went more heavily multi-threaded we made some updates in some areas of Stride to better handle this. And whenever we want to move forward in .NET versions we have updated Stride to whatever version we were moving into (5, 6, 7, 8). And as Stride itself progressed we have periodically pulled in some of those changes. Stride’s approach to .NET has been a big plus. It’s quite amazing that we could move Stride to a new version of .NET ourselves. #### Did you create issues on the Stride GitHub repository? 🔗 We have not done that. Much of our changes are very specific to Distant Worlds. #### What were some notable technical hurdles in using Stride, and how did you overcome them? 🔗 Early on, the lack of documentation made progress slower. But this has improved a lot over time. We worked quite a bit on getting Stride to handle heavily multi-threaded scenarios. We had to make some areas more robust and defensive, particularly around null-checking and iteration of lists. ## User Interface 🔗 #### Which library did you use for UI elements in Distant Worlds 2? 🔗 ##### What led you to choose the current UI solution over others? 🔗 ##### Were there any features you found lacking in Stride for UI, and how did you address these gaps? 🔗 We initially tried out the built-in user interface elements of Xenko. But for various reasons we decided to instead build our own user interface system. So for UI rendering we took the `SpriteBatch` class and built some basic controls: buttons, panels, textboxes, etc. The input side is just reading keypresses and mouse actions from the `InputManager` class. From there we added more functionality as we needed it. Near the start of development it’s often hard to know exactly what you’ll need in the user interface. You have to tweak and extend things as you go. So it is important to have deep control over all parts of the user interface. For us that meant writing our own UI system. I think this happens quite frequently in games, because they often have very unique and specific UI requirements. So it’s important to have full control over how the UI works, which might mean writing it yourself. For DW2 we also had a requirement that the user interface be completely scalable. This was a major weakness of DW1, where the UI was fixed-size. So in DW1, as screen resolution increased, all the text became smaller and harder to read. With DW2, building our own UI system allowed us to bake scaling into everything. So you can change UI scale in DW2 from the game settings and everything just automatically resizes and repositions, regardless of resolution. #### How is the research screen (e.g., item order, dependencies) created? Are these elements procedurally generated, or are they manually crafted? 🔗 ##### How did you create the research graph, including arrows and other visual elements? 🔗 The Research screen is custom-rendered. Most of the data in DW2 is heavily moddable, and the tech trees are a big part of this. So the rendering for research projects has to be data-driven. We use some `SpriteBatch` helper classes to draw the lines and arrows between projects. The projects themselves use some basic textures for the main body. ## Artists and Asset Creation 🔗 #### How did the artists find the asset creation process when working with Stride? 🔗 **Elliot:** DW2 uses lots of ship and base models with all of their associated textures. We utilize all the standard material features like Diffuse maps, Normal maps, Metalness maps, Emissive maps, Ambient Occlusion and Gloss maps. So the artists use Stride Game Studio to simply bundle all the assets together before handing them over to the development side to use in-game. **Kevin:** It works well and is easy and intuitive. I like that there's multiple ways to do the same thing (i.e. clicking and dragging or using the 'click to add' interface for assigned textures for instance) **Alex:** The workflow is a lot like Unity or Unreal. It’s pretty simple for making PBR 3D models. The material creation is flexible and easy to pick up if you know Unity. It feels smooth and straightforward overall. I found it quick to get started with and the tools don’t get in your way. #### What are their thoughts on the physically-based rendering (PBR) pipeline in Stride? 🔗 **Elliot:** It’s very nice and produces great looking scenes. It’s pretty easy to understand. **Kevin:** Works great and again is easy to use. The only issue is there is a marked difference between my editing software (Substance Painter), Stride's asset preview, and in game. Though at least those last 2 items aren't the engine's fault. **Alex:** I’d say the artists thought it was pretty good. It works well and everything looks just fine in the game. There’s not much to add really. No problems to complain about that we know of. It just does the job nicely! #### Did you encounter any challenges or limitations with shaders, and how did you address them? 🔗 **Elliot:** Initially we had to figure out how we were going to mix our custom procedural environment shaders with the Stride PBR material rendering. But once we had settled on our approach to this, most things were pretty smooth. Early on, it took a bit of digging into the Stride code to figure out what we needed to do with PipelineStates, EffectInstances and other items. We ended up much as described in the Stride documentation here: Low-level API. **Kevin:** Plenty. Some of it was learning a new engine and some of it was a lack of certain features. A huge bonus for artists would be to be able to have a node-based editor for shader effects. Right now (at least on our current version) things like animated UVs has to be done manually. **Alex:** When it comes to challenges or limitations with shaders in Stride, I’d say we didn’t run into much. The default shaders were solid and covered all our project needs so far. We haven’t tried adding custom ones yet though. I did give it a shot once using an example shader but it didn’t go well. The editor crashed and I was left scratching my head. I might revisit it later and hope for better luck. From that one try, it felt like adding a custom shader would take way more effort than you’d expect. Maybe I missed something simple but I wish it was less frustrating to bring a custom one into the project. ## Level Design and Prefabs 🔗 #### How was the level creation process using Stride for your team? 🔗 DW2 doesn’t use levels in the normal sense. The galaxy is an open-world and is entirely procedurally generated. So we manage view changes and the transition between locations and scenes in code, adding and removing items as needed. #### Was the Prefab system easy to use for level designers, and did it meet your expectations? 🔗 We use Stride Prefabs mainly for particle effects. We instantiate particle effect Prefabs for various in-game effects, like weapons fire, hyperdrive effects, explosions, etc. These work well, allowing our effects artist to create things as he likes them, then package them together as a Prefab in Game Studio. In code we can then use these effects pretty easily, supplying their in-game world transform to scale and position them where they need to be. #### Did the component system in Stride prove to be intuitive for designers? 🔗 DW2 is probably not a typical game, so we only use the scene/entity system inside the game code itself, dynamically creating and updating scenes as needed. Stride Game Studio is really just an asset bundling tool for us. ## DLC and Content Expansion 🔗 #### Could you briefly outline the steps involved in creating a DLC for Distant Worlds 2? 🔗 DW2 DLCs typically involve adding one or more new alien factions into the game. Each faction has new game features unique to them. They likely also have their own unique government type, which also has new features. So there is a lot of code to support this. From the art side each new faction involves around 25-30 new ship and base models, each with their own full set of materials and textures. Ship models in DW2 are quite detailed, with individual meshes for various parts of the ship, e.g. engines, weapon mounts, hangar bays, sensor dishes, etc. So the models are created as super-sets with all of the meshes that might be used. Then the player can design their own ships using the in-game ship editor. As they add or remove components to the ship, the game enables or disables appropriate meshes. These models and textures are packaged together into faction-specific Stride bundle files inside Game Studio. We then load these bundles in-game for the new factions and can then show their ships and bases in scenes. Additionally we also have animated characters for each new faction. These are implemented as 2D texture atlases that are animated using Spine. In-game we can play appropriate mood-based animations for the characters. #### How do you detect whether a DLC is installed or not for a player? 🔗 Each distribution platform has their own mechanism for this. So whether it’s Steam, GOG or something else, we use their inbuilt features to check this. Then we can load the appropriate bundle files with all of the models and textures for that DLC. ## Performance and Optimization 🔗 Source: Steam - Distant Worlds 2 - Screenshots by Shrikebe #### The game achieves impressive performance, especially during large-scale fleet battles. How did you manage to optimize for several simultaneous battles, each with many ships and fighters? 🔗 Performance optimization has been an ongoing consideration throughout development. As we add new game features we periodically need to profile and improve performance in slow areas. Large galaxies can have a huge number of individual units and factions, all of which can have extensive logic that needs processing at some minimum level of frequency. We have test games that have more than 250,000 ships, fighters and bases. Individual locations/scenes might have over 3000 units in a single battle. Most of DWs performance demands are on the logic side, i.e. we are CPU-bound. So there have been 3 basic approaches we have used to improve logic performance: 1. Improve specific algorithms, i.e. find faster ways of calculating something 2. Cache the outputs of expensive operations as much as possible and only update them periodically 3. Use multi-threading to parallelize processing across all CPU cores. This requires very good locking, especially when iterating lists. It also requires a lot of defensive coding to check for null references which would never occur in single-threaded situations. Rendering in DW2 does not generally encounter performance issues in the same way as the game logic does. However there are some optimizations: * In large scenes we may exclude drawing for small meshes in models as the view zooms out, thus reducing the total number of draw calls * We use instancing in a number of areas to handle elements with a high draw count, for example the stars in the galaxy view are drawn using instancing #### Are there any specific techniques or approaches you'd recommend for simulating large-scale scenarios like fleet battles? 🔗 Early on we made the decision to optimize the way weapons are rendered to minimize draw calls. So all weapon blasts in a scene are drawn in a single draw call using a custom shader that handles all of the different textures and animations for all the various weapon types. The rendering is wrapped into a single vertex buffer with camera-facing billboards for each weapon blast. The shader determines what to draw using a number of texture arrays that allow various rendering features, e.g. flipbook animations, scrolling beams, etc. This places some definite constraints on what we can render. We can’t just go crazy with expensive particle effects. But it has huge benefits for performance. Weapon trails are handled in a similar way, where a single vertex buffer contains all of the trail particles, and is rendered with a single draw call per frame. ## AI and Game Systems 🔗 Source: Steam - Distant Worlds 2 - Screenshots by VoiD #### Did you require any kind of editor extensions? How did you implement them? 🔗 Our use of the Stride Game Studio is really just as a tool to bundle assets into the game. So we didn’t need this. #### Which serialization method did you use for saving games? Was it a database, YAML, or a mix? 🔗 The static source data for the game entities is mostly just XML files. Things like planet and star definitions, ship components, alien races, government types, research projects, etc. We have some internal tools for editing these files. And we also have auto-generated schema for most of these data types. For saving and loading games we use low-level binary serialization. So .NET `BinaryReader` and `BinaryWriter` with streams. This requires hand-coding all of the serialization, but has big payoffs in performance. This also allows easier version management as you add new data to the game. You can have conditional loading of new values based on game version. #### What AI libraries did you use? What techniques were used for AI, such as for fleet formations, battle decisions, or engage/retreat behaviors? How was diplomacy handled? 🔗 All game logic is custom written for each system. We don’t have any 3rd-party AI libraries. Logic happens at 3 main levels: * galaxy-wide logic that affects everyone * faction-wide logic where each faction makes high-level plans to explore, expand and conquer * unit-level logic where each ship decides what mission to select to advance their factions goals We try to make each entity have sufficient logic to carry out it’s normal tasks and to also be able to respond to unexpected events in a reasonably intelligent manner. So the units can be given missions from a faction-level AI or manually by the player, but they can also assign themselves missions that make sense for the current situation. This kind of logic forms the bulk of the code in the game. So this logic really **IS** Distant Worlds. In addition we have an extensive advisor system that can provide suggestions on what to do next. These advisors are deeply integrated with the faction- and unit-level logic. When you switch an area of the game to ‘advisor-mode’ then you will get periodic suggestions in that area that you can either approve or reject. So for Colonization you will get suggestions about which planets to colonize. Approving the advisor suggestion will build a new colony ship and send it off to claim the new planet as a colony for your faction. If you instead had the Colonization area fully-automated (no advisor suggestions) then the game logic would simply carry out whatever it thought was best, automatically establishing new colonies. You can fine-tune how each area of game logic works, even when it is fully-automated. These policy settings tweak precisely how the automated decisions are made, allowing you better control over things. This ‘intelligent automation’ is a key feature of Distant Worlds that allows it to scale very large while still being manageable for the player. The game logic (including the advisors) is constantly being developed and improved. With the very open game style of Distant Worlds, there are endless unexpected situations that can prove challenging for the game logic to handle. So we are always extending the game logic to handle new things. ## Future Use and Recommendations 🔗 #### What types of projects do you think the Stride engine is perfectly suited for? 🔗 For us, the key strength of Stride is it’s deep integration with the .NET ecosystem, providing easy access to all of its tools and features. This has meant that we can build a standard .NET executable that simply uses Stride for rendering. That flexibility is great. #### Are you planning to use Stride in the future, beyond maintaining Distant Worlds 2? 🔗 We currently have a development roadmap laid out for the next 12-18 months, with no end in sight after that. So Distant Worlds 2 will be keeping us busy for the foreseeable future 🙂. Stride will continue to be a core part of that work. #### How can the Stride engine be improved to help the modding community? 🔗 Each game no doubt has its own unique requirements. But Distant Worlds modders mostly encounter Stride when packaging up assets to use in the game. This typically means creating a new Stride project that just contains static art assets (textures, models, etc). The goal is to generate a Stride bundle file that can then be loaded in the game. So any improvements to bundle creation and updating are always welcome. One small pain-point that still exists is renaming the bundle files. In Stride Game Studio, the normal build process generates the bundle with the name “default.bundle”. This is ok if you put all of your assets in a single project. But when your game gets bigger, that is not viable. In Distant Worlds we load many different bundles. The models for each faction are contained in their own bundle. We currently have 14 factions, so that means 14 different bundles. We also have other bundles for other parts of the game. Each of these bundles must have different names. There is currently no way to change the bundle name directly from within Game Studio (that I know of). Instead you have to hand-edit the YAML in the *.sdpkg files, changing the bundle name and adding the appropriate Selectors. That may sound fairly simple, but it can still be an extra hurdle for modders. Having bundle-renaming built into the Game Studio would make this much easier. ## Conclusion 🔗 The journey through Distant Worlds 2's development offers valuable insights into what's possible with the Stride engine. Code Force's experience demonstrates how Stride's deep integration with .NET creates a flexible foundation for ambitious projects, allowing developers to focus on crafting unique gameplay experiences rather than wrestling with engine limitations. What stands out most is how the team leveraged Stride's strengths—particularly its rendering capabilities and open-source nature—while developing custom solutions where needed. Their approach to performance optimization, particularly for large-scale battles involving thousands of units, provides practical lessons for developers working on similarly complex simulations. We'd like to extend our sincere thanks to the Code Force team for sharing their expertise and experiences so candidly. Their willingness to detail both successes and challenges offers invaluable knowledge to the Stride community and game developers at large. For those inspired by what you've seen here, we encourage you to explore Stride for your own projects. Whether you're developing strategy games like Distant Worlds 2 or something entirely different, Stride's combination of powerful rendering, C# integration, and flexible architecture provides a solid foundation for bringing your vision to life. If you're already using Stride for your projects, we'd love to hear about your experiences in our GitHub discussion or on our Discord server. Your stories and insights help strengthen our growing community of developers. ## Links 🔗 * Steam: Distant Worlds 2 on Steam * DW2 Forum: Matrix Games Forum * DW2 Discord: Distant Worlds 2 Discord * YouTube: Slitherine Games on YouTube * GitHub Stride DW2 Discussion: GitHub Discussions * Kevin: You can find him on our Stride Discord server as @KevinC * Elliot: You can find him on DW2 Discord server as @elliot_333

In this first part of a new series of blog posts, we will learn more about Stride's shader system, its limitations and how to make it better thanks to a very useful shader language called SPIR-V. This will be the first step in implementing a new and better shader system. Don't forget to checkout part 2! Table of Contents: * What are shaders? * Rendering in game engines * How does it work in Stride? * The many problems shader systems are facing * GPUs are all different * Drivers are not all the same * Performance Cost * Why investigating SPIR-V? * Summary The Stride engine has a powerful shader system, helping users build very complex shaders thanks to its language features like composition and inheritance, and its C# integration through the very powerful material system. ## What are shaders? 🔗 Simply put, they are typically snippets of code that are run on the GPU, mostly written in C-like languages like GLSL and HLSL. When a game has to render on the screen, it starts by preparing the data on the GPU and then sends shaders with commands. The GPU then executes those commands and if everything goes well, the game ends with a lovely picture drawn on the screen. This single call of a GPU is called a `draw call`. It can be simplified to this view. There is a first stage called `Vertex stage` which is meant to compute vertices and make sure they are transformed into data that can be rasterized by your GPU, and a final stage called `Pixel stage` or `Fragment stage` that takes the rasterized output of the rasterizer and computes color for each pixel on the screen based on which triangles they belong to. In both stages, you can provide textures/images and data through buffers, this can help give more details to your rendering, or help you compute more complicated things. ## Rendering in game engines 🔗 Drawing a single mesh is simple, one buffer of vertices, maybe some textures, do a draw call and ✨ marvel at the screen ✨. Repeat it many times and you get a video, very useful to make video games 👾. In game engines, objects being drawn the same ways are grouped into `materials`. A material can be seen as a recipe for drawing a mesh with ingredients like shader code, textures, vertices and other informations. Having many different materials implies creating many shader source code, and depending if you use forward or deferred shading, you might need to reuse code from one file to another leading to lots of duplicate code 👩‍💻👨‍💻. To solve this problem, all game engines have developed shader systems that help create permutations of shader code depending on the material you're using. It helps reuse code you've already written, which speeds up development and gives you the power to organize your code in more manageable ways. A good example of that are shader graphs from Unity or the material editor in Unreal, whenever you add a block/function to the graph, it reuses shader code already written, to create a new permutation. ## How does it work in Stride? 🔗 Stride has its own shader language called SDSL which stands for **S** tri**D** e **S** hader **L** anguage. SDSL uses a very smart system of composition and inheritance, similar to object oriented programming. You can learn more about it through the manual. ## The many problems shader systems are facing 🔗 To create permutations you need to be aware of the many limitations you will face while writing code for GPU. ### GPUs are all different 🔗 As obvious as it sounds, it needs to be reminded. Whenever you write code for your GPU you have to be aware that it will not work for all other GPUs. 10 years ago, two languages were the most used for writing shader code: HLSL and GLSL. In the case of OpenGL, GPU vendors would provide you with their own GLSL compilers to work for their GPUs through different drivers. A valid code for one compiler would be a syntax error for another. It was a big mess 💩, but a manageable one! Stride was created during this period and it was designed to run on a wide variety of devices 🎮 🕹️ 💻 🖥️. The solution chosen for creating code permutations that could work on many different machine was transpilation. Text would be parsed in abstract syntax trees and the text would be translated from one language to another by manipulating those trees. To have a better idea of how abstract syntax tree work, this playlist of videos will definitely help. ### Drivers are not all the same 🔗 Drivers can be seen as a front-end API to use the GPU. They have different paradigm and logic which may result in your shader code needing to be different across different drivers. Here's a table of which language is supported by which machine depending on the driver used. I chose the most used machines for gaming. Note that some APIs are tied to the machine you're developing for, adding more complexity to the shader system, needing to handle GPUs that have very specific features. Vulkan and OpenGL can be used on Mac and iOS but OpenGL is deprecated and Vulkan run on MoltenVK, a Vulkan implementation on top of Metal. | Direct3D | Vulkan | OpenGL | Metal | PSGL | NVN ---|---|---|---|---|---|--- Windows/XBox | HLSL | HLSL/GLSL | GLSL | | | Linux | | HLSL/GLSL | GLSL | | | Mac/iOS | | HLSL/GLSL | GLSL | MSL | | Android | | HLSL/GLSL | GLSL | | | Playstation 4/5 | | | | | PSSL | Nintendo Switch | | HLSL/GLSL | GLSL | | | ? ### Performance Cost 🔗 Managed languages like C# are well known to be slower with string objects since they treat them as immutable. On top of that, tree structures, especially the one used for shader compilation in Stride, tend to perform very slowly and are prone to be slow and work against the GC. ## Why investigating SPIR-V? 🔗 Three things happened in the past 10 years: * Vulkan was released with a new kind of bytecode shader language called SPIR-V * .NET Core introduced a new high-performance feature for operating on slices of array (something that C# is way better at than processing string objects), namely `Span<T>` * Most importantly, tools like SPIRV-Cross and Naga were created as a means to translate shaders through SPIR-V It was clear for everyone that we had to investigate how we could compile SDSL to SPIR-V and use all those very performant tools to transpile SDSL to other languages. SDSL is a very peculiar language and shifting from processing tree structures to processing segments of byte code is a great endeavor, especially for an engine. The following parts of this series of blog posts will focus on how such a system can be created, thanks to the many new C# and .NET features that came out since the release of .NET Core. ## Summary 🔗 Embracing SPIR-V for Stride's shader system will hopefully empower us with a better control over the shader language but also improve performance for shader compilation 💪💪. Thank you for reading!

Let's take a closer look at the `DiagnosticAnalyzer` feature added in `Stride.Core.CompilerServices`. This feature offers real-time code analysis in your IDE, enhancing your workflow. Table of Contents: * What is a DiagnosticAnalyzer? * What does it do? * Example * Why use it? * Current State * For Engine Developers * Summary Stride continues to evolve, adding new utilities and features every week. This blog post will cover the newly added `DiagnosticAnalyzer` feature in `Stride.Core.CompilerServices`. ## What is a `DiagnosticAnalyzer`? 🔗 A `DiagnosticAnalyzer` is a feature from Roslyn that scans your code while you are typing in your IDE. C# also utilizes this feature; every time you see a warning or red squiggly lines in your IDE, a `DiagnosticAnalyzer` gets triggered. Analyzers are offline tools used by the compiler to assist programmers. They are not used to collect telemetry on how Stride is being used. ## What does it do? 🔗 The new `Diagnostics` primarily focus on Serialization. These analyzers generate warnings for code that is incompatible with Stride's Serialization Rules of Thumb. Each error code follows this format: `STRDIAGXXX`, where 'X' represents a numerical digit. Clicking on these error codes will open a help page that explains in depth why the `DiagnosticAnalyzer` was triggered and how to resolve the warning. You can find these error code pages here. ## Example 🔗 In this example, we'll delve into a common scenario where the `DiagnosticAnalyzer` spots issues related to Stride's serialization rules. We have a `Dictionary` property named `Name` within a class `Example`. We've also adorned the `Name` property with `[DataMember]` and `[DataMemberIgnore]` attributes which are contradictory, and this is where the `DiagnosticAnalyzer` steps in to provide valuable feedback. public class Example { [DataMember] [DataMemberIgnore] public Dictionary<Example, int> Name { private get; set; } } Upon compiling, the `DiagnosticAnalyzer` flags three diagnostic warnings related to the attributes and the property's accessibility: STRDIAG000: There is an Attribute Contradiction on 'Name' Member. [DataMemberIgnore] Attribute on a [DataMember] is not supported. Except if it has also [DataMemberUpdatable] Attribute. STRDIAG009: The member 'Name' implements IDictionary<T,K> with an unsupported type for the key. Only primitive types ( like int,float,.. ) are supported or string or enums as the Dictionary Key in asset serialization. When used in other contexts the warning may not apply and can be suppressed. STRDIAG004: The property 'Name' with [DataMember] does not have an accessible getter which is required for serialization. A public/internal/internal protected getter is expected. The following image demonstrates how these warnings are displayed in Visual Studio: These warnings provide immediate feedback, aiding the developer in adhering to Stride's serialization rules. The `DiagnosticAnalyzer` not only pinpoints the issues but also suggests the necessary adjustments to align the code with Stride's standards. For instance, it suggests the removal of the `[DataMemberIgnore]` attribute or the addition of a `[DataMemberUpdatable]` attribute to resolve the attribute contradiction on the `Name` member. It also highlights the requirement for an accessible getter for serialization, and informs about the supported types for the `Dictionary` key in asset serialization. ## Why use it? 🔗 This real-time feedback is invaluable, making the coding process smoother and less error-prone, and ensuring that the codebase remains compliant with Stride's serialization standards. This feature aims to minimize those "Why is my property not showing up in the Game Studio?" moments. It's often unclear why certain properties don't appear in the editor. These analyzers are designed to clarify such situations, aiding your development process in Stride. ## Current State 🔗 The pull request (PR) to introduce these analyzers has been merged. However, there hasn't been a release that includes them yet. If you're eager to test them out, you can build the engine from the source. Otherwise, you'll have to wait for the next release of Stride's NuGet packages. ## For Engine Developers 🔗 Adding new analyzers to the Stride engine is straightforward. However, be aware that Visual Studio (VS) has a bug caused by .NET, which makes VS load Roslyn only once at startup. To work around this, compile `Stride.Core.CompilerServices` and restart VS after adding a new analyzer. ## Summary 🔗 This is a new quality-of-life feature that simplifies development in Stride by providing immediate feedback on coding issues. Thank you for reading 📖, and happy coding 💻👩‍💻👨‍💻!

The Stride team is happy 🙌 to announce the release of our refreshed Stride website. We have been working on this for a while, and we are excited to share these updates with you and hope you enjoy the enhanced browsing experience. ## The Motivation for the Update 🔗 The Stride website has been around for some time ⌛. It was originally created using Jekyll. Over the years, we have added more content, but the website has not been updated for quite a while. Our main goal was to make the website future-proof and easy to maintain. We also wanted to improve the overall user experience and give it a more modern feel. ## What's New or Updated 🔗 * Improved consistency across pages, posts, and styling, offering an excellent reading experience * Enhanced content readability * Modern and simplified design * Updated static page generator: Eleventy 2.0 (previously Jekyll) * Bootstrap 5.3 (previously Bootstrap 3) * Font Awesome 6 (previously 4.4) * Removal of old, unnecessary code, such as AddThis, Disqus, JQuery, and JavaScript libraries * Improved website responsiveness (mobile, tablet, desktop) * Content review and minor corrections * Tags page * Archive page * Every single page was reviewed and updated 🤯 * Dark Theme (Experimental) * Search functionality now includes our documentation website * GitHub Wiki was enabled for content contributors, containing information about the website structure, how to add new content, and how to contribute. This new update will enable us to share more content with you faster and more easily. We will also be able to add more features and enhance the overall experience. __ The Disqus comment widget has been removed from the blog posts, as we would like to encourage our readers to use GitHub Discussion or Discord. We are considering integrating the GitHub Discussions with the blog posts. ## What's next 🔗 We will continue to improve the website and add more content. Additionally, we will be adding more features and further refining the overall experience. Our Stride website GitHub issue tracker is open for any suggestions or feedback. We encourage you to collaborate, create issues, and submit pull requests. ## Closing 🔗 We hope you like the updated website. With this new release, we would like to encourage our community to contribute as well. Your experiences, insights, and knowledge are invaluable, and we would love to showcase them on our blog. If you have a topic, tutorial, or success story you'd like to share, we invite you to get in touch. By contributing, you'll not only help others in the community but also gain visibility for your work and expertise. Let's work together to make the Stride community even more vibrant and enriching.

With so many free and open-source game engines out there, where do you even start? Table of Contents: * Introduction * Before we dive in * What is FOSS and why should I use a FOSS game engine? * What FOSS game engines are available today? * Bevy * Godot * Open 3D Engine * Stride * What engine should you pick? And other closing thoughts * Acknowledgments ## Introduction 🔗 The party is over. The era of companies offering their products and services at unsustainably low prices is coming to a close. Growing pressure from shareholders to transition from maximizing growth to maximizing revenue has pushed many commercial software companies to reevaluate their business models. In other words, introduce price increases and new fees. Those dependent on their software must now decide between accepting the increased financial burden or switching to alternatives. The video game industry is no exception to this changing tide as major game engine developers explore new ways to monetize their users. It raises a lot of questions for the community. How will we, as developers, manage these rising costs? Just as importantly, considering the immense impact licensing changes can have on developers, should Epic and Unity continue having a disproportionate influence on the game development landscape? While there is never a good time to wrestle with these questions, the rise of free and open-source game engines over the past decade gives independent game developers an opportunity to evaluate where free and open-source software can have a role in their next project. ## Before we dive in 🔗 I want to make this clear from the start: I will not be doing a head-to-head comparison of free and open-source game engines. The summaries of each engine discussed will not be exhaustive nor specifically highlight exclusive features. This is a celebration of the hard work of the game development community. I want to use this as a platform to get you excited about free and open-source game development and consider options beyond proprietary engines like Unity, Unreal, and GameMaker. If I tried to cover every feature of every modern free and open-source engine, this wouldn’t be a single article but an entire book series. For that reason, I identified notable features and characteristics of some handpicked engines I thought would be worth sharing. While reading this, keep in mind that no engine is one-size-fits-all, and, as I’ll explain later, picking an engine is about choosing the right tool for _you_. With that out of the way, let’s start! ## What is FOSS and why should I use a FOSS game engine? 🔗 As the name suggests, free and open-source software (FOSS) includes two notable characteristics: it is free (libre) and its source code is available. You can use free (or libre) software for any purpose at your sole discretion. You will most commonly hear something like: “free as in speech, not free as in beer.” It may be available at no cost, but even more importantly, the user has complete control over the software. The open-source aspect of FOSS describes how everyone has access to the code that makes up the software. Using a FOSS game engine provides several advantages. First, no licensing fees. While contributors always appreciate donations, none of the notable FOSS game engines expect or require upfront payment, subscriptions, or ongoing royalties. FOSS engines also provide independence from a single organization. If changes to a FOSS engine’s terms upset the community, the engine’s license allows developers to stick to the version with the most favorable terms and even fork off the project if they choose. The community guides the development and growth of their FOSS game engine of choice. Many FOSS game engines have active and passionate communities that share their knowledge, advocate for their engine, and help newcomers. These vibrant and dedicated communities serve as a potent learning resource when working solo or as a small team. Some community members even contribute to their engine, improving it for everyone. FOSS game engines allow anyone to modify the engine to fit their needs. For example, if the engine lacks a specific feature, has a persistent bug, or needs quality-of-life improvements, anyone can update it as necessary. They can even take the additional step of contributing the changes to the project for everyone’s benefit. One of the greatest strengths of FOSS game engines lies in their communities and a willingness for everyone to work towards a collective good. ## What FOSS game engines are available today? 🔗 Although FOSS game engines have existed for decades, the past several years have seen an explosion in the number of game engines available, as well as contributors, money, and resources dedicated to them. It would be impossible to cover all the FOSS game engines available now. In fact, if you have a passion for a particular language or framework, more likely than not, someone built a game engine with it. This post will focus on some of the more notable modern FOSS game engines: Bevy, Godot, Open 3D Engine, and (of course) Stride. However, this is not an exhaustive list. As I mentioned before, there are more engines out there than I could ever cover in a single blog post. Many skilled and dedicated folks have put serious time and effort into making game engines and shared them with the world. I encourage you to use this post as a starting point and look at what each community offers. ### Bevy 🔗 * Written in Rust, Supported Languages: Rust * Platforms: * Development (Code Only): Windows, Mac, Linux * Build Targets: Windows, Mac, Linux, iOS, Android, Web As the most popular Rust-based game engine, Bevy offers a rich code-only development environment (an editor is coming in the future) capable of running on all major operating systems (Windows, Mac, and Linux). At the heart of Bevy’s vision for game development lies the Entity Component System (ECS) paradigm. While there are other resources available that can explain the benefits of ECS better, in a nutshell, ECS breaks down the code into three core pillars: entities, components, and systems. Entities are composed of components that can interact with each other using systems. For example, the player character could be an entity with a health component that tracks the player character’s health bar. An enemy character could also use that health component for the same purpose. ECS encourages modularity and reusability by enabling developers to create components applicable to distinct entities. While other game engines can approximate a similar system, Bevy makes this part of its core design ethos. As established with Bevy’s use of ECS, the engine’s developers care deeply about modularity. The engine’s plugin system accentuates their commitment to that principle in every part of Bevy. Developers can organize the game’s systems into discrete plugins. An example of this is organizing all the UI code into a UI plugin. From there, developers can slot the plugin into the game’s initialization step. The plugin system helps organize the code and encourages modularity by allowing developers to add or remove the plugin based on their needs. This paradigm even applies to the engine’s core features, as they are all organized into plugins. It becomes trivial to activate or deactivate any part of the engine—including rendering, audio playback, and event loops—as the developer sees fit. Asset libraries provide a wealth of resources that empower developers to learn the tools quickly and get their game to a playable state. The community assembled a library of assets available on the official website for everyone to use and share. Bevy’s library includes tutorials, plugins, and templates that address subjects like physics, networking, and input management. Even entire games and applications are available in the asset library to either build on or use as a reference while learning the engine. Bevy’s structure encourages developers to use any of the resources from this library freely as part of the building blocks that will make up their game. In conjunction with Rust’s package manager, there is a strong emphasis on modularity at every level of the engine. ### Godot 🔗 * Written in C++, Supported Languages: GDScript, C# * Platforms: * Development: Windows, Mac, Linux, Android (Experimental), Web * Target: Windows, Mac, Linux, iOS, Android, Web Godot has the largest and most active community among all the modern FOSS game engines available to date. As the drama around Unity has unfolded, you have likely heard mentions of Godot on more than a few occasions. It is not without merit, as Godot encourages developers to shape the engine around their needs. Coming in at only 40 MB, the engine includes a lightweight, multi-platform editor capable of running on any major operating system (Windows, Mac, and Linux). In fact, you can even use a web-based or Android version of the editor, albeit with some constraints. Godot can meet developers on whatever platform works best for them. GDScript is Godot’s primary programming language. While the prospect of learning an engine-specific language may turn you off at first, don’t fret! It shares a lot of commonalities with Python and Godot provides detailed documentation on how to use the language. Assuming you already have some experience with object-oriented programming, it won’t take long to get going with GDScript. You can even use C# for scripting if that is more up your alley, as it’s the other language officially supported by Godot. That said, if you would still like to write some code in another language entirely, Godot provides the means to use alternative programming languages by way of GDExtension. Theoretically, GDExtension supports any programming language that can interact with its C-based API. While Godot officially supports scripting in GDScript and C#, GDExtension allows the community to introduce new language bindings to Godot’s development ecosystem, including Rust, Go, Swift, and Haxe. Not all language bindings are feature-complete, but many are in active development. With that in mind, committing to one language for an entire project is unnecessary, as GDExtension languages can work alongside GDScript. This means developers can, for example, even use GDScript with other languages like Rust in the same project. Work in an editor long enough and you will probably want to tinker with it. For those interested in creating utilities and tools, as is common practice when using Unity or Unreal Engine, Godot provides the option to customize the editor to your liking. You don’t need to write in C++ and re-compile Godot to create plugins. Because the editor runs on Godot itself, it is possible to tune or extend the editor with GDScript, Godot’s scripting language, by simply appending @tool to the top of the file. Writing a plugin becomes as easy as writing code for your game. ### Open 3D Engine 🔗 * Written in C++, Supported Languages: C++, Lua * Platforms: * Development: Windows, Linux * Target: Windows, Mac, Linux, iOS, Android Open 3D Engine’s origins trace back to Amazon’s foray into game development. Amazon licensed Crytek’s CryEngine 3 and then used it as the foundation for their own game engine: Amazon Lumberyard. In the following years, Amazon offered Lumberyard for free to the community with specific terms requiring games built with Lumberyard use Amazon Web Services for their online features. By 2021, Amazon overhauled Lumberyard, rewrote 95% of the code, rebranded it as Open 3D Engine (O3DE), and placed it under the supervision of The Linux Foundation. Now, O3DE is available as a free and open-source engine under dual Apache and MIT Licenses for everyone, with no strings attached. Only a few game engines offer visual scripting out of the box, and O3DE is one of them. O3DE supports both C++ and Lua for scripting, but for folks less inclined to write code, there is also Script Canvas, OD3E’s visual scripting environment. Visual scripting provides a way to write game logic without needing to write code in C++ or Lua. It presents programming concepts like functions, variables, and events as nodes that can be strung together in a graph. Script Canvas also allows developers to write custom nodes either in C++ or within Script Canvas itself to better fit their workflow. Fortunately, anything written using O3DE’s visual scripting system will not incur any serious performance hits, as the engine ultimately converts the graphs into Lua scripts. O3DE modularizes its engine by breaking down major components into plugins called Gems. This is the paradigm through which O3DE manages all its features and plugins. For example, it is possible to swap out features like the physics engine, allowing developers to choose between PhysX 4, PhysX 5, or another solution entirely, custom or commercial. The modularity afforded by O3DE through Gems allows developers to add and remove components of the engine with relative ease–using as many or as few of the features as they want and in whatever combination best fits their needs. With the Atom Renderer, the engine’s rendering system, O3DE strives to provide an advanced renderer that is also exceptionally customizable. The Render Pipeline Interface (RPI) and Rendering Hardware Interface (RHI) constitute the primary channels for working with Atom. The RPI provides the tools necessary for customizing the rendering pipeline and implementing higher-level graphical features, such as split screen or additional rendering passes. Meanwhile, the RHI abstracts access to the GPU’s functionality, allowing developers to write lower-level graphics logic without needing to target specific graphics APIs like DirectX or Vulkan. In short, the rendering stack provides incredible flexibility to developers. ### Stride 🔗 * Written in C#, Supported Languages: C#, F#, Visual Basic * Platforms: * Development: Windows * Target: Windows, Mac, Linux, iOS, Android Stride began life as Xenko (and before that, Paradox): Silicon Studio’s premium game engine. After several years of providing Stride to the public through a subscription-based model, Silicon Studio released the engine’s source code and editor freely to the community under the MIT license. Among the higher profile FOSS game engines available, it is unique because Silicon Studio completely wrote it in C# from top to bottom. There is no delineation between the language used for the core engine and the language you would write with day-to-day while working on the game. It becomes much easier to override or change any inherent engine behavior when coding in the same language. No need to develop an interop system to interface with the engine’s core logic. With that said, the code-only version of Stride supports any language that is part of the .NET family (C#, F#, and Visual Basic), providing some flexibility in language choice. The engine offers a pure .NET experience that includes many of the advantages inherent to the framework, like hot reloading. At the time of writing, Stride runs on .NET 8 (the latest version of the framework) and supports C# 12. Because the engine closely follows the .NET update schedule, you often get the most modern and up-to-date implementation of C#. You can seamlessly incorporate almost any C#-based library or tool available through NuGet, GitHub, and other platforms into Stride, enhancing your workflow. Stride is modular enough that sections of Stride are available as standalone NuGet packages. The engine provides the ability to tailor-make your game development experience. The engine does its best to ensure it does not become a technical bottleneck for your game. A lot of processing within Stride is multithreaded. This means it allows logic to run on multiple threads of execution concurrently. The engine even implements a custom thread pool to maximize engine performance. As a result, Stride takes full advantage of the hardware it is running on, providing players with faster and smoother experiences. All the tools Stride uses to support multi-threading under the hood are also accessible to developers. Nothing is out of reach. An entire library exists within the engine focused on multi-threading that anyone can leverage in their projects. Used with features like the upcoming Bepu physics integration, it becomes possible to have tens of thousands of physics-based objects concurrently in a scene with little effort. Stride provides the space to explore multi-threading and have fun with it. ## What engine should you pick? And other closing thoughts 🔗 There is no one right answer. Don’t trust anyone claiming otherwise. Here is the truth: the answer lies in whichever you enjoy using the most. Game development is a process. It requires a healthy level of commitment and discipline. Anyone can do it, but you need to put in the effort. The better your tools fit with your way of working and thinking, the more likely you’ll commit to your project and put in your full effort. All these engines are free and include active communities ready to help new folks. Pick whichever engines strike your fancy and try them. Maybe one of them has that one specific feature that hits just right. Maybe another has a community you love hanging out with or the engine integrates well with a tool you’re using already. Whatever the case, it’s a matter of taste and what works best for you. Wanting to know if an engine can make a specific type of game is asking the wrong question. People make games in Excel. You can make just about any game in any engine. It’s not always a trivial task, but you can do it. Instead, ask yourself which tools you enjoy using the most. When you settle on an engine, remember this: your engine is not your identity. Your tools are a means to creating something, not a core pillar of your very being. I cannot stress this enough. Your tools do not define you. This may sound obvious, but I have seen many, many folks make their engine of choice a centerpiece of who they are and become unnecessarily hostile toward other engine communities. Please don’t do that. You are not simply a Bevy developer, Godot developer, O3DE developer, Stride developer, or whatever else. You are a game developer. So don’t get hung up on which engine you should pick. Choose the engine that resonates with you the most, and you’ll quickly learn skills you can apply anywhere. Make creating something rewarding in and of itself. If you enjoy working in your environment, you will enjoy the act of development. Once you manage that, creating anything, game or otherwise, will feel immensely satisfying in its own right. Be curious and have fun. ## Acknowledgments 🔗 This article was only possible with the input of contributors and users involved in these game engines. I appreciate all the folks who were kind and patient enough to fact-check me and provide their feedback, including Vaclav Elias, Joreyk, Doprez, Judah Perez, Clay John, Adam Scott, Fredia Huya-Kouadio, Pāvels Nadtočajevs, as well as the Open 3D Foundation and Open 3D Engine contributors. Last but not least, thank you to Ed (Meltted) for creating the featured image.

Let's take a closer look at why currently you can't set private members of scripts and components in the Stride Editor and explore the options to change that in the future. Table of Contents: * What is public and what is private * Design vs runtime access * Editor runs your code directly * Serialization * What about constructors? * What about init properties? * UnsafeAccessor in .NET 8 * Summary It has been an amazing week for Stride and our Discord is booming with new people who want to learn more about the engine and maybe port some games from Unity. One of the questions that has been asked a few times was why we can't set private members on scripts in the editor. I thought it's a good opportunity to dive a little deeper into the technical reasons and engine architecture to explain the current limitation and explore the options to change it in the future. ## What is public and what is private 🔗 Let's run through a quick reminder. In C# members are annotated with access modifiers such as `public`, `protected` or `private`. The modifier describes the access objects of other classes will have when accessing the members. It allows us to control the API surface of an object by hiding away certain aspects of its state to allow the inner implementation to be changed without affecting other parts of code that would only interact with the publicly visible members. _To understand it better readthis analogy._ When designing systems we will often decide to make certain things public (maybe even use an interface to further describe the public API regardless of the class holding the methods) and keep most things private. This allows us to prevent accidental mistakes when another part of the systems makes changes to some delicate state. However, with a more Data Oriented approach we can find ourselves creating classes which hold mainly data. In many Entity Component System implementations the components are just data bags that systems read and update. With this kind of approach there's rarely need for private members, although sometimes the `internal` visibility is used for data on a component that is exclusively managed by its default system. Moreover, component's public properties are often not just modified at design time, but also at runtime. Think about the Transform component and how it's public properties are modified to move the entities around, or how changing the velocity on a Physics component affects how quickly the simulation will move it around on the next step. ## Design vs runtime access 🔗 We can talk about components in two contexts: setting the properties during level design in the editor and setting them at runtime while the game is running. We would generally expect in both cases that we can modify the properties of the component and they will be picked up by the processing system. With the introduction of Scripts, however, which are components containing logic, we get into a bit of a pickle. Yes, the script should be able to have private state and a public API for other components to interact with it. What if we want to restrict some data so that it can only be set once during initialization? Ideally the editor would not be constrained to modify the property during design, but once we hit the runtime it should be allowed to change. ## Editor runs your code directly 🔗 In Stride when you create a script in your project and open the project in the editor, the project will be compiled, the DLL loaded into memory of the editor, and when you add the script to an entity it will actually create a new instance of your script class. Same as at runtime. It won't run the script Update method, but if you have any logic in your property getters and setters those will be invoked at design time. This can give you enormous flexibility. But it also means that however you want your script to behave at runtime when it comes to properties the same will be enforced at design time. The editor uses reflection to access properties and fields on your script. It technically could modify private fields on the object instance it holds during design. But this needs to survive saving the project to disk. ## Serialization 🔗 Stride uses YAML for design time serialization of Assets. The assets can have a different form from the actual Content they are compiled to by the AssetCompiler. This is used for example by Audio or Model assets which at design time just hold a reference to your media files, but once compiled actually hold the bits of your media in a format that's easy to consume by Stride's runtime. For components and scripts rather than having a second class for each component and doing compilation from design to runtime representation, those classes are the same in both scenarios. This simplifies things but it means that serialization constraints need to be applied equally. While YAML is very flexible and the serializer currently uses reflection to set the properties, the runtime serialization is done using a custom binary serializer system. When you compile your game project, after C# compiler has done its job, the build system runs the AssemblyProcessor over your code to generate efficient serializer classes that do not use reflection to access members on the objects they deserialize. Access modifiers are enforced by the CLR, which means it's not possible to generate code that accesses private members of another class directly. ### What about constructors? 🔗 If we have a private field that we want to set once, why don't we use a constructor to accept a value for it? It's certainly an option and there are serialization systems which look at constructors to provide deserialization in this way. They may be a bit more complicated but it's possible to implement them. However, in a generic environment that Stride provides it's a bit difficult. How would the editor create a new instance of your class if it requires data to be passed in the constructor? Will it provide `default` values, will it look for a private parameterless constructor? ### What about init properties? 🔗 C# 9 has introduced `init` properties which are only allowed to be set at object construction. Reflection is able to bypass that of course, while at the CLR level a special marker `modreq` is placed on the property which asks the compiler to provide `modreq` marker on the callsite as well (see thread). Compilers which don't know about init properties would still prevent you from assigning them. And the CLR is not actually enforcing anything here - only compiler - thus the generated serializers are still able to use those properties. But in your code the constraint will be enforced and no runtime modification will occur after the object is initialized. public string MyProperty { get; init; } ### `UnsafeAccessor` in .NET 8 🔗 As we're trying to squeeze out more performance and improve the Stride codebase we're looking at rewriting the AssemblyProcessor from Mono.Cecil and manually emitting IL into a Roslyn C# source generator. This will also mean being restricted to whatever the compiler enforces, such as not setting init properties outside of object construction. Luckily in .NET 8 there's a new performance hack which allows you to access private fields on other classes. You can read about it more in the proposal and on the performance blog. [UnsafeAccessor(UnsafeAccessorKind.Field, Name = "_myField")] extern static ref string _myField(MyClass c); ## Summary 🔗 There might be some extra work needed to implement the changes to allow setting private members in the editor. At the moment using `init` properties is nice a middle ground. While in my opinion designing clear public APIs for components in a data driven approach is the way and it doesn't need access to private members, there's many users who see value in being able to use private members to their advantage and it's on the editor and engine to provide flexibility of choice in how you structure your code. Thank you for reading 📖, and happy coding 💻👩‍💻👨‍💻!

In this second part we're going to dive deeper in how the current SDSL compiler works and how we are improving on it for the SPIR-V compiler. This will be a sort of personal log book of my research on the subject. Table of Contents: * Preface * How it works currently * The idea for SPIR-V * Implementation * The easy way * "I should rewrite it from scratch..." * Buffers and instructions * Generation * Extending SPIR-V * The Irony * Conclusions In the last blog post, we briefly saw why SPIR-V was an interesting shader format for our new shader compiler. After a year of research on this subject I'm coming back with ideas and implementations! ## Preface 🔗 Rewriting the shader system is a complicated task in itself. As you may already know, Stride was initially a commercial product that was open-sourced not long ago, and some of the original devs left. This has led to a difficulty gathering information on the inner working of the engine. Fortunately we still have some of the original team members helping and answering questions, and the source code is well written and easy to understand, this has helped a lot of contributors to be able to fix issues quite fast. As for me, I started this project with no prior knowledge of how compilers worked and a very faint idea of how shaders works. I've learned some things and am trying my best, so if you have any ideas, improvements and criticism, I'll be happy to discuss it on our Discord server or in a GitHub discussion. 😊 The code related should be available in the SDSL repository of Stride. Hopefully it'll be merged in the Stride repository itself in the future! Also credit to Felicia Salomone/@phaelicis for the art! ## How it works currently 🔗 There are two components to SDSL : 1. The effect system 2. The shader mixin system The effect system sits at a higher level than the shader mixins. It drives the creation of shader permutations through mixin operations of shader mixins. A shader mixin is a building block for shaders in Stride, they are mixed and merged together to produce one final shader that will be used in rendering pipelines. Mixins is another way to reuse code without going through an inheritance hierarchy, there are many ways to go about it and SDSL has very specific kind of rules. A quick example for this : // Let's define two shader mixins with different fields and simple method shader MixinA { int a; void Foo() { int bar = a + 3; } } shader MixinB { float b; void Foo() { float bar2 = b * 0.5f; } } // And one that is going to inherit our two first shaders shader MixinC : MixinA, MixinB { float c; } The inheritance is going to reuse the code present in the mixins and mix them together using a set of rules. In this case the MixinC will internally look like : shader MixinC : MixinA, MixinB { // MixinC fields from MixinA and MixinB are copied as is int a; float b; float c; // Methods are merged together, statements appear in order of apparition of mixins. void Foo() { int bar = a + 3; float bar2 = b * 0.5f; } } This system makes it surprisingly easy to add shaders to material parts, say you want to add a shader to compute the emissive component of a material, just create a `CustomAwesomeEmissiveMixin`, inherit `Texturing, ComputeColor`, implement the `float4 ComputeColor()` method, ✨ _woopdeedoo_ ✨ Stride will automatically generate a new permutation of our material shader by adding in the emissive mixin! The way it's implemented comes from a very simple idea : 1. Generate syntax trees representing the SDSL code 2. Mix syntax trees together 3. Convert tree into HLSL code 4. If GLSL is needed, convert HLSL to GLSL But this has some issues regarding performance : * Mixing tree structures together to generate new permutations involves a lot of deep cloning/defensive copies. * Extracting information from text is slower than extracting it from compact binary data * The garbage collector is going to be stressed and have some stutters due to allocations needed by cloning/defensive copies and parsing data. It's important to note that these issues are only about shader permutation generation so far. ## The idea for SPIR-V 🔗 Dealing with tree structure is very rarely the fastest option, especially when using programming languages with managed memory. That's why we want to rewrite Stride's shader system, remove the need to process trees and instead focus on dealing with buffers since computers are faster at processing them. What is SPIR-V? How could it help? 🤔 Let's check the official specification as of today, to understand what it is : > SPIR-V is a simple binary intermediate language for graphical shaders and compute kernels. A SPIR-V module contains multiple entry points with potentially shared functions in the entry point’s call trees. Each function contains a control-flow graph (CFG) of basic blocks, with optional instructions to express structured control flow. Load/store instructions are used to access declared variables, which includes all input/output (IO). Intermediate results bypassing load/store use static single-assignment (SSA) representation. Data objects are represented logically, with hierarchical type information: There is no flattening of aggregates or assignment to physical register banks, etc. Selectable addressing models establish whether general pointer operations may be used, or if memory access is purely logical. Okay great, what about the goals for it : > > SPIR-V has the following goals: >> >> * Provide a simple binary intermediate language for all functionality appearing in Khronos shaders/kernels. >> * Have a concise, transparent, self-contained specification (sections Specification and Binary Form). >> * Map easily to other intermediate languages. >> * Be the form passed by a client API into a driver to set shaders/kernels. >> * Support multiple execution environments, specified by client APIs. >> * Can be targeted by new front ends for novel high-level languages. >> * Allow the first steps of compilation and reflection to be done offline. >> * Be low-level enough to require a reverse-engineering step to reconstruct source code. >> * Improve portability by enabling shared tools to generate or operate on it. >> * Reduce compile time during application run time. (Eliminating most of the compile time during application run time is not a goal of this intermediate language. Target-specific register allocation and scheduling are still expected to take significant time.) >> * Allow some optimizations to be done offline. >> WAIT! But, what if... we could extend the spec... > > SPIR-V can be extended by multiple vendors or parties simultaneously: >> >> * Using the **OpExtension** instruction to add semantics, which are described in an extension specification. >> * Reserving (registering) ranges of the token values, as described further below. >> * Aided by instruction skipping, also further described below. >> WOW! Now we're cooking! 🍽️ Here's the main idea : 1. We extend the SPIR-V specification with our own instruction set, telling Stride how to mix SPIR-V files together 2. We produce partial SPIR-V bytecode for those mixins, since mixins only contain partial code 3. We mix-in together those partial SPIR-V files at runtime, or offline Using SPIR-V is not going to be any faster than using GLSL or HLSL, those languages already have very performant compilers, but for SDSL, it would be a _game changer_. The tree structure manipulation we have is suboptimal and .NET is faster at manipulating buffers anyway, but using SPIR-V would make sure we process only binary buffers. Additionally, it allow us to potentially make all shader front-end processing offline, we would effectively skip the whole front-end written in C# at runtime, huge win for us. Now we just need an... ## Implementation 🔗 ### The easy way 🔗 The first instinct I had was to lookup for some libraries to generate SPIR-V bytecode with some constraints : * It should give us the ability to extend SPIR-V to support our mixin system * It should be easy to integrate in the engine and easy to package with games, the new shader compiler should not add more complexity to the engine * The libraries should be a native, with which we can easily generate bindings, or written in C# * If written in C# it should be AOT compatible, for potential future console support. * It should also run fast, or use the recommended practices for high performance The first solution I've considered was LLVM, there was an ongoing work to add SPIR-V generation, this seemed like a neat idea but was nowhere near read and not sure if LLVM is fast enough to be used at runtime without creating stutters. Shaderc and SPIR-V Tools have some SPIR-V generation capabilities to some degrees but from C# it would be hard to extend the SPIR-V specification. It has great support nonetheless, and our friends over at Silk.NET have some bindings for these tools. Another one was the Nintendo Switch emulator Ryujinx, written in C#, it can generate SPIR-V on the fly to translate/compile the console's shaders. They have generated C# code based on the SPIR-V headers and specification and are using it to assemble some SPIR-V modules. I decided to start from this Ryujinx code and made a little proof of concept by writing a little tool that takes the output of Stride's parser and convert it into shader modules. It only supported a very tiny subset of SDSL but it was enough to prove the compiler can be made, and to remind me that I do not know SDSL nor SPIR-V that well, and the Ryujinx code was not exactly suited for Stride. But then, the most intrusive thought a dev can have just crept in my mind... ### "I should rewrite it from scratch..." 🔗 And make sure it fits our needs, the constraints i've listed in the previous section. I decided to follow some core tenets and make sure I don't over-engineer anything for the sake of winning a few microseconds. First, as we're going to read, write and copy a lot, data should then be stored in a compact way using buffers and value types. This would improve enumeration of instructions and possibly garbage collection. We are also going to deal with a lot of small buffers, so pooling those buffers is going to be important to avoid stressing the garbage collector. Finally we should make sure SPIR-V data is arranged in ways that would benefit the compiler's performance. But most importantly, keep it as simple as possible. ### Buffers and instructions 🔗 According to the specification, instructions are made out of words/integers, they have a variable size and the size of the instruction is written in the high 16 bits of the first word. Instructions would be represented as slices of this buffer and to access those instructions we would need to iterate through this buffer. IT'S CODING TIME! // A RefInstruction will hold a Span and some cool methods and tools to extract information from this instruction. // We could also create an Instruction struct containing a Memory<int> and doing the same... public ref struct RefInstruction(Span<int> words) { public Span<int> Words { get; } = words; // ... } // A buffer class to represent our SPIR-V buffer, disposable because we're using MemoryOwner from the high performance community toolkit public class SpirvBuffer : IDisposable { // This will represent words and we'll extract instructions from it by taking Span<int> slices public MemoryOwner<int> Words { get; } public Enumerator GetEnumerator() => new(this); // An enumerator for our instructions public ref struct Enumerator(SpirvBuffer buffer) { int position = 0; public RefInstruction Current => new(buffer.Words.Span.Slice(position, buffer.Words.Span[position] >> 16)); public bool MoveNext() { // A simple advance, we read the size in the high bits, and just skip words based on this size. position += buffer.Words.Span[position] >> 16; return position < buffer.Words.Length; } } public void Dispose() => Words.Dispose(); } Instructions can have a variable number of operands and each operands can be one or multiple words. The simplest way to extract operand information from this slice is to generate C# source code with information on how to parse each instructions based on its type and size. And with just that, we can parse SPIR-V and even write our own SPIR-V disassembly tool! ### Generation 🔗 Now that we can load SPIR-V and parse it, the next step is to be able to write instructions. Fortunately for us, the SPIR-V headers repository provide a C# file containing all the enums and constants needed for instructions operands and some JSON files describing instructions and their operands as well as if the operands are optional or have to be passed as an array of values. With a few more, we can generate methods to add or insert instruction in a buffer! Here's an excerpt from the current unified core grammar of SPIR-V and its corresponding generated C# code : { "opname" : "OpFAdd", "class" : "Arithmetic", "opcode" : 129, "operands" : [ { "kind" : "IdResultType" }, { "kind" : "IdResult" }, { "kind" : "IdRef", "name" : "'Operand 1'" }, { "kind" : "IdRef", "name" : "'Operand 2'" } ], "version": "1.0" } And here's a function we can generate from it : public static Instruction AddOpFAdd(this SpirvBuffer buffer, IdResultType resultType, IdRef operand1, IdRef operand2) { // Extend the buffer and put the data needed int size = 1 + ComputeSize(resultType, operand1, operand2) buffer.Add(size << 16 | (int)Op.OpFAdd); buffer.Add(resultType); buffer.Add(operand1); buffer.Add(operand2); } After going through the core and the glsl grammar, we end up with a library that can both parse and assembler SPIR-V. ### Extending SPIR-V 🔗 This one was the easiest step as we've already made a source generator that generates the necessary C# code from json files, we just need an additional JSON grammar file made for SDSL and the generator will generate code to add custom instructions, there's really nothing else to it! What was left is creating a little tool that can read those extensions and pre-process many SPIR-V together to generate a valid SPIR-V module that can be consumed by Vulkan, OpenGL, WGPU and soon DirectX 12. I have made a prototype that works quite well but can be improved in the future, it's not a complicated task, it just takes time and efforts. Finally we can make sure we can generate SPIR-V mixins from the AST generated by the current Stride shader system. This should be easy, right? RIGHT? ## The Irony 🔗 The current shader parser was made for the specific use case of mixin abstract trees. Modifying the code would be a huge endeavor as I would have to dive into what's existing and try my best to understand what i can change without breaking anything, worse than that, the parser was written with Irony, a very good C# library to help anyone parse things in an LALR fashion, but with a lacking documentation and, in my personal opinion, has an "easy to write, hard to read" kind of API. CppNet is another library that Stride uses to preprocess SDSL code. It works like a C/C++ preprocessor, depending values given to the compiler, it will enable or disable some parts of the code. It's quite useful when you need target specific code, but it defeats the purpose of having a whole mixin system and would invalidate already compiled SPIR-V mixins. While it might be smarter and easier to continue using those libraries and just patch our new shiny SPIR-V assembler, rewriting the front-end seems like a necessary step if we want to embrace the newer .NET APIs for better performance. We just need to know how much performance we could squeeze from it... 🤔 But that's for another blog post, so much happened since last year and this blog post is getting long. 😀 ## Conclusions 🔗 Writing this SPIR-V library was very fun, I've learned a lot about SPIR-V and some of the possible use cases for it in the context of Stride. As you might have imagined, this was the easy part of this shader system rewrite. In the next installment we'll see the little adventure I went through to make the most of our shader front-end! Thank you for reading!

Explore the key differences between Unity and Stride, a C#-based, open-source game engine powered by .NET 6 (soon .NET 8). Learn how Stride's flexibility and native .NET support offer a unique development experience. Table of Contents: * Introduction to Stride * Difference Between Unity and Stride * Licensing * What games were made using Stride? * Operating System Support * IDE Support * .NET Hot Reload Support * Multiplayer Support * Unity Assets * Screen Capture * Shaders Available * Build Automation * Add-ons and Extensions * Transformations * Rendering * Gamepads * Other Q&A * What is the Equivalent of a Coroutine in Stride? * What is a StartupScript? * Using Other Assemblies/Projects in Stride * Is There an Asset Store for Stride? * Null Checking in Stride vs Unity * Where to Start * How to Find Answers * 🤝 Join Us: Stride Bug Bounties and Feature Funding 🛠️ * Flappy Bird - Stride Engine Demo * Closing Thoughts 🙂 ## Introduction to Stride 🔗 Stride is not just another game engine; it's written entirely in C# and serves as a powerful platform in the .NET ecosystem. This unique focus on C# offers developers the native .NET tooling and functionalities they are already comfortable with. What sets Stride apart is its project structure; Stride projects are standard `csproj` files, allowing them to integrate effortlessly into your existing .NET solutions. ## Difference Between Unity and Stride 🔗 Unity is developed by a large team and offers a feature-rich experience. On the other hand, Stride is open-source and built by community contributors. This means that Stride might not have all the features that Unity has, simply because there aren't as many people working on it. However, the open-source nature of Stride allows you to customize it according to your needs and provides a solid foundation for any rendering project. Additionally, Stride allows you to utilize any NuGet package and even provides access to the `Main` function of your game. You can also find useful resources such as documentation, community toolkits, and guides for migrating from Unity to Stride. * Stride for Unity Developers ## Licensing 🔗 Stride is released under the **MIT** license, which is important because it grants you significant freedoms to use, modify, and distribute the engine. ## What games were made using Stride? 🔗 For examples of games developed using Stride, check out Made with Stride section. ## Operating System Support 🔗 * Editor: Windows * Runtime: Windows, Linux, macOS, Android, iOS ## IDE Support 🔗 Stride games are "standard" C# projects, meaning you can use a variety of IDEs: * VS Code * Visual Studio 2022 * Rider * Blocknote + MsBuild * VVVV > **Note:** There's a Visual Studio extension for syntax highlighting, shader build keys and error checking. > **Note:** Another extension offers syntax highlighting only. ## .NET Hot Reload Support 🔗 Stride has the capability of using .NET Hot Reload for C# scripts, allowing real-time code modifications as your game runs. Importantly, this feature is also available when editing the engine side, giving you even more flexibility. Standard .NET hot reload rules are in effect. This feature streamlines development by minimizing the delay between coding and observing results, enhancing both efficiency and ease of use. If you're familiar with .NET and C#, you'll find that Hot Reload in Stride feels intuitively familiar. ## Multiplayer Support 🔗 Stride does not offer built-in multiplayer or Server/Client architecture. However, you can easily integrate any .NET networking library to implement these features. You have the freedom to choose from a variety of libraries and resources. For a curated list, you can check out Awesome-Stride's Networking section. ## Unity Assets 🔗 You can import some 3D models from the Unity store into Stride. However, scripts will need modification since the two engines differ. These are the basic Scripting Differences: * `StartupScript` is a MonoBehaviour without the Update method * `SyncScript` is a MonoBehaviour with an Update method that runs every frame * `AsyncScript` is unique and runs asynchronously ## Screen Capture 🔗 To capture a frame, you can use the following code snippet: var commandList = GraphicsContext.CommandList; commandList.RenderTarget.Save(commandList, stream, ImageFileType.Png); ## Shaders Available 🔗 SDSL is a shader language written on top of HLSL. * Shading language * ShaderExplorer ## Build Automation 🔗 Yes, since Stride uses .NET, automating the build process works out-of-the-box. ## Add-ons and Extensions 🔗 You cannot extend the editor in the same way as Unity, but you can create custom code extensions as seen in the following: * Terrain add-on * Level editor add-on ## Transformations 🔗 The `TransformComponent` class in Stride is a fundamental component for representing an entity's position, rotation, and scale within a 3D scene. **Important Features:** * **`LocalMatrix` and `WorldMatrix`**: These matrices manage the transformations of the entity. * **`Position`, `Rotation`, and `Scale`**: These properties represent the entity's position, rotation, and scale in the local coordinate system. The `Position` property is a `Vector3`, defining the entity's position. The `Rotation` property uses a `Quaternion` to represent the entity's rotation, and the `Scale` property is a `Vector3` that sets the scale. You can modify these properties to transform the entity. * **`UpdateLocalMatrix()` and `UpdateWorldMatrix()`**: These methods update the local and world matrices, respectively. * **`Parent` and `Children`**: These properties allow you to establish parent-child relationships between entities, affecting their transformations accordingly. ## Rendering 🔗 Stride primarily uses **clustered** forward rendering, with some additional features. Read more in the docs. * Stride Rendering Pipeline * Stride Graphics Compositor ## Gamepads 🔗 * Gamepads ## Other Q&A 🔗 ### What is the Equivalent of a Coroutine in Stride? 🔗 Unlike Unity, which uses `IEnumerator` for asynchronous code execution, Stride leverages C#'s built-in `await` and `async` features. This can be accomplished using `AsyncScript`, which essentially acts as a `SyncScript` (the Stride equivalent of Unity's MonoBehaviour) but with asynchronous methods. You can use async methods within sync scripts, the same as standard C#. ### What is a StartupScript? 🔗 A `StartupScript` in Stride includes a `Start` method that is invoked when it's added to the scene tree. This is similar to Unity's `Start` or `Awake` methods. However, `StartupScript` does not contain `Update` methods and therefore doesn't execute code every frame. ### Using Other Assemblies/Projects in Stride 🔗 In Unity, the packaging system is built on top of a `csproj` file, which allows Unity to protect its proprietary source code. Stride, however, grants you full access to your `csproj` and `sln` (Solution) files. This enables you to include any NuGet packages or other C# projects in the usual way, by adding project references. If you add a new subproject to your main project through the Stride editor, it will be correctly configured by default, including folder location and references to the Stride engine. ### Is There an Asset Store for Stride? 🔗 No, Stride does not have a dedicated Asset Store. However, most additional libraries specially designed for Stride can be found on GitHub or NuGet. For easier discovery, a summary has been made available at Awesome-Stride. ### Null Checking in Stride vs Unity 🔗 Does `is null` and `== null` work? Unlike Unity, which has overridden the `Equals` operator to be compatible with its C++ engine, Stride allows you to use `is null` and `== null` to compare the existence of an Entity or Component directly. ## Where to Start 🔗 Getting started with Stride is easy, thanks to a wealth of resources available. Here are some you shouldn't miss: * Stride's Manual: A comprehensive guide that covers everything from basic setup to advanced features. * Stride's Tutorials: Step-by-step tutorials to help you get your first project off the ground. * Discord: Join the community on Discord for real-time discussions and the latest updates. ## How to Find Answers 🔗 Consider checking these platforms where your query may have already been addressed or where you can gain more context: * Discord: Use the search functionality in our Discord channel to see if your topic has been discussed before. * GitHub Issues: Navigate to Stride's GitHub Issues to see if your question is related to a known issue or feature request. * GitHub Discussion: Participate in Stride's GitHub Discussions to engage with the community and explore various topics. This proactive approach not only helps you get immediate answers but also makes it easier for the community to focus on unresolved or unique queries. ## 🤝 Join Us: Stride Bug Bounties and Feature Funding 🛠️ 🔗 We invite talented developers to collaborate with us through our Bug and Feature Bounties. With tasks ranging from Vulkan support to decals and morph targets, there's something for everyone! Reach out via the specific GitHub Bounty tickets to get involved. 📬 For suggestions on new bounties, don't hesitate to connect with us on our Discord server or directly through GitHub. Participating in our bug bounties is a win-win! Not only will you be able to hone your skills, but you'll also contribute to the expansion and enrichment of the Stride community—and get **compensated** for your efforts! 💰 Stride's Open Collective Projects ## Flappy Bird - Stride Engine Demo 🔗 Ned Reid, a new member of the Stride community, has created a Flappy Bird demo, while exploring Stride as an alternative to Unity. He shared the following thoughts on his experience: I decided a couple of days ago that I would explore engines outside of Unity (for obvious reasons), and wanted to start with something simple. Over a fairly relaxed weekend, I've managed to put together a neat little Flappy Bird clone! _A screenshot of the Flappy Bird demo created by Ned Reid_ ## Closing Thoughts 🙂 🔗 If you've made it this far, congratulations 🎉! You now have a comprehensive understanding of Stride, its capabilities, and how it compares to Unity. The world of game development is vast and ever-changing 🌍, but the emergence of community-driven, open-source engines like Stride showcases the exciting directions the industry is taking. With its C# focus 🎯, extensive .NET support 💻, and flexible licensing 📜, Stride is a formidable option for both new and experienced developers. As the saying goes, the best way to learn is by doing 🛠️. So dive in 🏊, start a project 🚀, and don't hesitate to participate in the community discussions on Discord or GitHub 👨‍💻👩‍💻. Your journey with Stride is what you make of it, and the resources and community are here to support you every step of the way 🤗. Thank you for reading 📖, and happy coding 💻👩‍💻👨‍💻!

Stride contributors are thrilled to announce the release of Stride 4.2, now fully compatible with .NET 8 and leveraging the latest enhancements in C# 12. This release brings significant improvements in performance, stability, and developer experience. Table of Contents: * Download and Upgrade * Unity Licensing Model Impact: A Catalyst for Change * Stride's Rising Popularity * The Heartbeat of Stride: Our Community * Addressing the Pace of Updates in Stride * The People Behind Stride * Facing the Realities: Funding and Resources * Funding and Resource Allocation * Challenges in Distribution * Call for Skilled Developers * Join Us on This Journey * The Impact of Your Support * Looking Ahead * What's New in Stride 4.2 * Fixes * Exciting Development in Stride Physics * Introducing Bepu Physics in Stride * Future Prospects and Disclaimer * Also good to know * Cross-Platform Evolution: The Stride Editor and Avalonia * Links * Acknowledgements * Long time Stride supporters * Platinum Striders * Gold Striders A massive thank you to the open-source Stride community for your dedicated contributions. This release saw over 75 contributions from more than 22 amazing contributors, each playing a crucial role in making Stride 4.2 a reality. ## Download and Upgrade 🔗 You can download the Stride 4.2 Installer today. Release notes are available here. Make sure you read the guide to update Stride and projects properly. ## Unity Licensing Model Impact: A Catalyst for Change 🔗 The game development world has seen quite a stir with recent changes in Unity's licensing model. These shifts have led many in our community to rethink their choice of development tools. Stride 4.2 steps up in this scenario as a solid, C#-based alternative, offering a familiar yet distinct approach for game developers. ### Stride's Rising Popularity 🔗 It's been an exciting time for us. We've noticed more and more developers giving Stride a try, a trend clearly reflected in our growing user numbers. During the crazy Unity days, we were number 3 in the popularity rankings, just after Godot and Bevy. Also a big shoutout to gamefromscratch for his video "Stride For Unity Developers", which definitely helped. ### The Heartbeat of Stride: Our Community 🔗 What really makes Stride tick is you – the community. Your feedback, contributions, and ideas have been the driving force behind Stride 4.2. It’s your hands-on experience and insights that have helped shape this release, making Stride not just a tool but a community achievement. ## Addressing the Pace of Updates in Stride 🔗 Let's talk about how often Stride gets updated. We know it's something on your mind, and that is why we want to explain the dynamics that influence it. ### The People Behind Stride 🔗 Stride is maintained by a group of passionate developers, much like yourself, who contribute in their free time. This means our pace might not match that of other engines backed by full-time teams. Luckily we still have the original creator and lead of Stride among us to tackle tricky issues and infrastructure. ### Facing the Realities: Funding and Resources 🔗 Here’s the deal: our funding levels shape how much we can do. We’re grateful for every bit of support we receive, but we’re still on our way to having a full-time development force. This financial reality does affect how fast we can roll out updates. Although we might not be the fastest out there, we focus on making each update meaningful. ## Funding and Resource Allocation 🔗 ### Challenges in Distribution 🔗 The pace at which we distribute funds is often perceived as slow. However, this is not from a lack of willingness but rather the challenge of finding the right talent for the tasks. Nonetheless, we are actively funding projects at this moment, focusing on enhancements in XR, introducing morph target capabilities for 3D models (aka Blendshapes), and updating the bindings for the Assimp 3D importer to Silk.NET. ### Call for Skilled Developers 🔗 We are actively seeking skilled developers with experience in C#, the .NET ecosystem, mobile, XR, rendering, and game development. If you have these skills or know someone who does, we encourage you to get involved. There are opportunities to contribute to critical areas of Stride's development, supported by available funds. ### Join Us on This Journey 🔗 We’re always excited to welcome new contributors to the Stride family. Whether it’s through code contributions, spreading the word, or donations, every bit helps us grow stronger. If you’ve got skills in .NET, Android, and iOS development, there’s a special place for you here. Support us on OpenCollective. ### The Impact of Your Support 🔗 We believe that every donation has a substantial impact, perhaps more so than in some other projects. Why? Because C# as a language offers high productivity, and the Stride codebase has a great architecture. This means that every dime you contribute goes a long way. Imagine how much we could do if Stride got as much financial support as other big engines. With C#'s easy productivity and Stride's well-organized code, your donations could help us improve much faster. It's not just about keeping the lights on; your support can take Stride to new heights! ### Looking Ahead 🔗 With your support, we’re optimistic about picking up the pace. Our goal is to bring you new features and improvements more regularly, making Stride even better with each release. ## What's New in Stride 4.2 🔗 Stride 4.2 includes numerous enhancements and improvements. Here’s what to expect: * **.NET 8 Integration** : Stride 4.2 is now fully aligned with .NET 8, harnessing its performance improvements and efficiency gains for game development. This means faster execution times, reduced memory footprint, and access to the latest C# features, making your development smoother and more efficient. Learn more * **C# 12 Features** : With C# 12, Stride users can write cleaner, more concise code thanks to new language features. These improvements reduce boilerplate and enhance readability. Discover C# 12 * **Changed Assimp Binding to Silk.Net.Assimp** : This update transitions the asset compiler's binding from C++/CLR to Silk.Net.Assimp, a move that not only simplifies the codebase but also paves the way for asset compilation on non-Windows systems, broadening Stride's accessibility. See the pull request * **Migration NET6+ and More gettextnet#2** : Stride's commitment to staying current with .NET versions continues, ensuring compatibility and leveraging the stability and features of the latest .NET environment across all aspects of the engine. Check out the update * **Enable Multiple Profiler Consumers and Add a Timeline/Tracing Profiler** : This enhancement introduces a profiler with chrome://tracing output format, significantly improving the debugging and performance tuning process by allowing for a more granular analysis of game performance. Explore the feature * **Feature: Add Support for F# and VB Project Types** : Stride now welcomes developers using F# and Visual Basic, offering support for code-only projects in these languages. This opens up Stride to a broader audience. Learn about F# and VB support * **Stride Diagnostics Analyzer** : This new tool provides immediate feedback within your IDE, identifying potential compatibility issues with Stride's serialization system. It's about making your development process smoother and helping you catch and resolve issues faster. Discover how it works, the docs page and here is the pull request. * **OpenVR Handle Custom Resolution Specified by the User Through VR Settings** : Enhancing VR development, this update allows developers to specify custom resolutions for VR projects, optimizing performance and visual quality for various VR devices. See the details * **Editor Enhancements** : * **Dynamic Snapping for Selected Objects** : This feature introduces dynamic snapping while transforming objects, improving precision and workflow efficiency within the Stride Editor. Dynamic snapping PR * **Animation Stack Selection for FBX Imports** : Stride now allows you to select specific animations from a stack when importing FBX files, giving you more control over the assets you bring into your projects. Learn more * **Automatic Asset Copying to Resources Directory** : To streamline asset management, the editor can now automatically copy imported assets to the project's Resources directory, ensuring your assets are always where they need to be. See how it works ## Fixes 🔗 Although there have been many fixes, we'd like to point some of them out: * Runtime rasterized fonts are broken #1750 * Game Studio doesn't reload sub projects after changes #1703 * Changing the comparison project related and not UPath related #1704 * Translations fix #1717 * C# Beginner Tutorial Build Errors #1652 * Can not create "C# Beginner" project #1650 See the full list in the Release Notes. ## Exciting Development in Stride Physics 🔗 Stride 4.2's release isn't just about what's in the box; it's also about what it enables for the future. A standout development in this context is the integration of a new physics package in Stride. ### Introducing Bepu Physics in Stride 🔗 Our Discord community is buzzing with the news of Bepu physics, a project initiated by our user Nicogo1705. BepuPhysics v2 is a high-performance, multi-threaded physics library, written entirely in C#. Its compatibility with Stride's C# ecosystem offers the perfect alternative to the Bullet 3D physics engine, which relies on C++ Interop. With additional support from Doprez and Eideren, the efforts in integrating Bepu physics have already shown impressive results, especially in editor compatibility and performance. As you can see in this video, running on almost 10 year old hardware (yes, cube fountain included): Nicogo's YouTube channel features some more demo videos. GitHub: Nicogo1705/Stride.BepuPhysics ### Future Prospects and Disclaimer 🔗 Currently an independent package, Bepu physics is charting a course towards deeper integration within Stride. While it stands as a potential future replacement for Bullet physics, the package is still evolving. Future updates may necessitate adjustments to projects using its current version. We encourage users to stay updated and adaptable as we continue refining Bepu physics with the community's support. The pull request can be found here: [Physics] Bepu integration ## Also good to know 🔗 Although not directly tied to Release 4.2, we have some more big things going on. For instance to our website and documentation. We also had another community meeting to address all those new members. * Website and documentation revamped and build process updated * Contributor section moved to docs * Community meeting October 2023 And last but not least: ### Cross-Platform Evolution: The Stride Editor and Avalonia 🔗 One of the most ambitious projects for Stride to date has started: The porting of the entire Stride Editor from WPF to Avalonia, a cross-platform C# UI library. This significant endeavor, undertaken by Kryptos-FR, a former Stride developer. Currently, the project is in the early stages but it not only anticipates making the editor compatible with Linux and MacOS but also aligns with the long-standing community desire for broader platform support and enhanced editor functionality, including a robust plugin system. More details in this pull request: Cross-platform editor rewrite - prototype ## Links 🔗 * GitHub: https://github.com/stride3d/stride * Website: https://stride3d.net/ * Documentation: https://doc.stride3d.net/latest/en/manual/ * Twitter: https://twitter.com/stridedotnet * YouTube: https://www.youtube.com/@Stride3D ## Acknowledgements 🔗 We extend our heartfelt gratitude for all the hard work and donations we have received. Your generous contributions significantly aid in the continuous development and enhancement of the Stride community and projects. Thank you for your support and belief in our collective efforts. In particular we want to thank these donors: ### Long time Stride supporters 🔗 * VVVV🥇 ### Platinum Striders 🔗 * Happenstance Games🏆 ### Gold Striders 🔗 * Vašo ( Vaclav )🥇 * Lucid Silence Games🥇 * Skid Vis🥇 This article was co-authored by Aggror Jorn and Tebjan Halm.

Just a little reminder that Stride has been presented in a .NET Live! 🎥🎥🎥 Vaclav, Tebjan and I participated in a .NET live session to showcase the Stride engine, as well as some work done by users. Many questions were asked, and Manio answered many of them in the chat. ## Watch the .NET Live right here 🔗 **Content** * History of the Project * Roadmap * What are some of the big game titles that folks would recognize * The UI * Add Scripts to Entities * Integrating Stride into your projects * Add Interaction * Shader System of Stride * Shader Code * Shader Language ## The most important questions answered 🔗 In this live session, we answered the most important questions about the project, including how to use Stride and what it aims to be! Tebjan presented a bit about what contributors have done and what users (professionals/hobbyists, artists/developers) have done so far to show off the capabilities of the engine. He also gave a small presentation on how Stride is used with VVVV for 3D rendering! ## A fun experimentation 🔗 Vaclav, having dived into Stride with a desire to use Stride without an editor, created an API to experiment and create games using just a NuGet package. He presents his NuGet package, explains how to use it, and how to make games leveraging the power of .NET and hot reloading! ## Shaders 🔗 I've personally become interested in the shader system of Stride and found it refreshingly easy to use. I decided to show more about how to use shaders, update them, and extend the rendering engine of Stride. ## Closing 🔗 We strongly recommend watching this live session, as it will help you gain a better understanding of Stride. .NET is becoming more and more relevant for a game engine, as evident with Stride. Don't hesitate to reach out to our community through the Discord server!

On October 7th, a community meeting was held addressing new user influx, planning the release of Stride 4.2, contingent on the .NET 8 launch. ## Summary 🔗 During this almost 3 hour long session we talked about the following: improving domain knowledge, access rights, and documentation, transferring the Stride Community Toolkit to the official repository, and community-driven initiatives like a new demo project and extending tutorials. Significant attention was given to a substantial editor rewrite from WPF to Avalonia for enhanced cross-platform support, opening it up for community contributions. Table of Contents: * Summary * Short summary of Contributor meeting * Release of 4.2 * Open Collective * New projects * New Demo project * Community Toolkit * Stride Plugins * Stride UI Rewrite * Acknowledgements * Long time Stride supporters * Platinum Striders * Gold Striders ## Short summary of Contributor meeting 🔗 A few weeks prior to the community meeting, we held a contributor meeting. This was mostly to address the recent instream of many new users. Since we suddenly got an abundance of user feedback we took and planned some steps. * Inventorizing domain knowledge and access rights. * This overview will be posted soon on GitHub. * Moving the Stride Community Toolkit to the official Stride repositories. * Investigating nightly/weekly/monthly builds and releases. * The idea of having more frequent releases was discussed to provide users with the latest PRs and fixes, whilst also having more publicity. * Concerns were raised about the potential impact on development velocity and the need for stabilization phases. As soon as the new build system (arranged by Xen) is up and running, we can decide on how often we make an official (minor) release. More on this later this year. * Updating contributors' documentation. * Next to the official documentation/tutorials, we also have various wiki pages per repository. Especially the documentation for Contributors and building from source, needs some love. Aggror is going to make an initial pull request for this. * Planning and creating videos for contributors. * Adjusting the strategy with OpenCollective Projects: here we came to the consensus that we required more feedback which we would gather during the community meeting. ## Release of 4.2 🔗 Stride 4.2 is around the corner, but when exactly? * For 4.2 we are waiting for the official release of .NET 8 which is to be release on November 14, 2023. * Since we want to release a version for .NET 6 and .NET 8, our goal is to release within a few days after the release of .NET 8. * Prior to the official release we will have a release candidate. This will be announced when it is available. * At the moment there is 1 open bug and 1 open pull request for a feature. Other than that, the build is locked for features. Only bug fixes would be allowed in * The open pull request for Silk.NET. will be moved to 4.3 to ensure stability. * For more info on the final items. ## Open Collective 🔗 Next we discussed the use of Open Collective for donations and funding specific projects. Although not mentioned in the meeting, our current funding is **12,992.34 USD**. * Up until this point it has been quite a challenge finding the right developers for existing Projects. The most recent successfully funded Project was the Bug bounty for Vulkan fullscreen. * There have been several suggestions to make funding more attractive, such as increasing compensation and investing in areas like documentation, marketing, and design next to coding Projects. * Every project should have a referencing GitHub ticket that contains as much detail as possible for the deliverables. * There are currently two talks ongoing for specific development. Once we have confirmation we will communicate this with the community. ### New projects 🔗 We will add several new Projects to the Open Collective. This will give members a clear view on 'targets' that we like to see funded. * Extending tutorials. Both written and video tutorials * New tutorial set for a small 3D (platformer) game * Contributor tutorials * Demo scene 2024 (more on this below) * Stride editor Avalonia (more on this below) ## New Demo project 🔗 We want to have a new demo sample project that demonstrates Strides capabilities. Members who want to help out, can add to the discussion here. ## Community Toolkit 🔗 There is a new initiative called the Stride Community Toolkit, aimed at aggregating common features, helpers, and extensions to streamline Stride development. It allows community members to test and enhance tools and propose their integration into the engine. This project has come to fruition with the combined effort of several users, and specifically the repositories off dfkeenan and VaclavElias. ## Stride Plugins 🔗 A topic talked about for several years now and it's quite an important one. Plugins allow you, for one, extend the editor with new functionality without having to build the engine from source. Ideally you want to go to some (NuGet) store and click -> install this awesome extension/plugin for Stride. If you want to contribute to the discussion on how to do this technically. We can divide plugin support into 2 categories: * Asset plugins: these would be purely models, textures, prefabs, components For this Manio143 is taking the lead. * Editor plugins: this category currently is not viable because of the dependency to another large topic: the need to rewrite the editor to a new library, replacing WPF. Since we are short on development time here, we need to take into account that it will be a while before we can see the first results of this. ## Stride UI Rewrite 🔗 The Stride editor is built with WPF and therefore only works on Windows. WPF isn’t really being developed anymore and on top of that we want to start supporting the editor on Linux. We can only do so by rewriting the editor to another UI framework. Just like the Plugin topic, the Editor rewrite is a big topic. Probably the biggest topic of them all. The editor rewrite has been discussed in great lengths on both Discord and GitHub in the past few years. People have shared their ideas on which framework to use (Avalonia, MAUI, Uno etc), made some prototypes, even ported the Stride launcher. But we never really ‘actively’ made this an official item since it would take a full time developer many months to work on this task. Members have been asking if they can help out with the rewrite, but up until this point, there wasn't really an official starting point. We also don’t want to waste the prototype/knowledge already collected. That is why we will soon have an official GitHub branch in the Stride repository where all Editor UI rewrites are taking place. We are fully aware that this might take a long time and a lot of effort from multiple people, but we have to start somewhere. We also anticipate that we can use some of the OpenCollective funding for this. So regardless of time/developer power: we have landed on using the Avalonia UI framework to rewrite the editor. Aggror will set up a GitHub topic summarizing how people can contribute to this UI rewrite branch and inventorize how we can split this massive task into subtasks.. More details on this will follow later this year. ## Acknowledgements 🔗 We extend our heartfelt gratitude for all the recent donations that have been made. Your generous contributions significantly aid in the continuous development and enhancement of the Stride community and projects. Thank you for your support and belief in our collective efforts. In particular we want to thanks these donors: ### Long time Stride supporters 🔗 * VVVV🥇 ### Platinum Striders 🔗 * Happenstance Games🏆 ### Gold Striders 🔗 * Vašo ( Vaclav )🥇 * Lucid Silence Games🥇 * Skid Vis🥇

In this second part we're going to dive deeper in how the current SDSL compiler works and how we are improving on it for the SPIR-V compiler. This will be a sort of personal log book of my research on the subject. Table of Contents: * Preface * How it works currently * The idea for SPIR-V * Implementation * The easy way * "I should rewrite it from scratch..." * Buffers and instructions * Generation * Extending SPIR-V * The Irony * Conclusions In the last blog post, we briefly saw why SPIR-V was an interesting shader format for our new shader compiler. After a year of research on this subject I'm coming back with ideas and implementations! ## Preface 🔗 Rewriting the shader system is a complicated task in itself. As you may already know, Stride was initially a commercial product that was open-sourced not long ago, and some of the original devs left. This has led to a difficulty gathering information on the inner working of the engine. Fortunately we still have some of the original team members helping and answering questions, and the source code is well written and easy to understand, this has helped a lot of contributors to be able to fix issues quite fast. As for me, I started this project with no prior knowledge of how compilers worked and a very faint idea of how shaders works. I've learned some things and am trying my best, so if you have any ideas, improvements and criticism, I'll be happy to discuss it on our Discord server or in a GitHub discussion. 😊 The code related should be available in the SDSL repository of Stride. Hopefully it'll be merged in the Stride repository itself in the future! Also credit to Felicia Salomone/@phaelicis for the art! ## How it works currently 🔗 There are two components to SDSL : 1. The effect system 2. The shader mixin system The effect system sits at a higher level than the shader mixins. It drives the creation of shader permutations through mixin operations of shader mixins. A shader mixin is a building block for shaders in Stride, they are mixed and merged together to produce one final shader that will be used in rendering pipelines. Mixins is another way to reuse code without going through an inheritance hierarchy, there are many ways to go about it and SDSL has very specific kind of rules. A quick example for this : // Let's define two shader mixins with different fields and simple method shader MixinA { int a; void Foo() { int bar = a + 3; } } shader MixinB { float b; void Foo() { float bar2 = b * 0.5f; } } // And one that is going to inherit our two first shaders shader MixinC : MixinA, MixinB { float c; } The inheritance is going to reuse the code present in the mixins and mix them together using a set of rules. In this case the MixinC will internally look like : shader MixinC : MixinA, MixinB { // MixinC fields from MixinA and MixinB are copied as is int a; float b; float c; // Methods are merged together, statements appear in order of apparition of mixins. void Foo() { int bar = a + 3; float bar2 = b * 0.5f; } } This system makes it surprisingly easy to add shaders to material parts, say you want to add a shader to compute the emissive component of a material, just create a `CustomAwesomeEmissiveMixin`, inherit `Texturing, ComputeColor`, implement the `float4 ComputeColor()` method, ✨ _woopdeedoo_ ✨ Stride will automatically generate a new permutation of our material shader by adding in the emissive mixin! The way it's implemented comes from a very simple idea : 1. Generate syntax trees representing the SDSL code 2. Mix syntax trees together 3. Convert tree into HLSL code 4. If GLSL is needed, convert HLSL to GLSL But this has some issues regarding performance : * Mixing tree structures together to generate new permutations involves a lot of deep cloning/defensive copies. * Extracting information from text is slower than extracting it from compact binary data * The garbage collector is going to be stressed and have some stutters due to allocations needed by cloning/defensive copies and parsing data. It's important to note that these issues are only about shader permutation generation so far. ## The idea for SPIR-V 🔗 Dealing with tree structure is very rarely the fastest option, especially when using programming languages with managed memory. That's why we want to rewrite Stride's shader system, remove the need to process trees and instead focus on dealing with buffers since computers are faster at processing them. What is SPIR-V? How could it help? 🤔 Let's check the official specification as of today, to understand what it is : > SPIR-V is a simple binary intermediate language for graphical shaders and compute kernels. A SPIR-V module contains multiple entry points with potentially shared functions in the entry point’s call trees. Each function contains a control-flow graph (CFG) of basic blocks, with optional instructions to express structured control flow. Load/store instructions are used to access declared variables, which includes all input/output (IO). Intermediate results bypassing load/store use static single-assignment (SSA) representation. Data objects are represented logically, with hierarchical type information: There is no flattening of aggregates or assignment to physical register banks, etc. Selectable addressing models establish whether general pointer operations may be used, or if memory access is purely logical. Okay great, what about the goals for it : > > SPIR-V has the following goals: >> >> * Provide a simple binary intermediate language for all functionality appearing in Khronos shaders/kernels. >> * Have a concise, transparent, self-contained specification (sections Specification and Binary Form). >> * Map easily to other intermediate languages. >> * Be the form passed by a client API into a driver to set shaders/kernels. >> * Support multiple execution environments, specified by client APIs. >> * Can be targeted by new front ends for novel high-level languages. >> * Allow the first steps of compilation and reflection to be done offline. >> * Be low-level enough to require a reverse-engineering step to reconstruct source code. >> * Improve portability by enabling shared tools to generate or operate on it. >> * Reduce compile time during application run time. (Eliminating most of the compile time during application run time is not a goal of this intermediate language. Target-specific register allocation and scheduling are still expected to take significant time.) >> * Allow some optimizations to be done offline. >> WAIT! But, what if... we could extend the spec... > > SPIR-V can be extended by multiple vendors or parties simultaneously: >> >> * Using the **OpExtension** instruction to add semantics, which are described in an extension specification. >> * Reserving (registering) ranges of the token values, as described further below. >> * Aided by instruction skipping, also further described below. >> WOW! Now we're cooking! 🍽️ Here's the main idea : 1. We extend the SPIR-V specification with our own instruction set, telling Stride how to mix SPIR-V files together 2. We produce partial SPIR-V bytecode for those mixins, since mixins only contain partial code 3. We mix-in together those partial SPIR-V files at runtime, or offline Using SPIR-V is not going to be any faster than using GLSL or HLSL, those languages already have very performant compilers, but for SDSL, it would be a _game changer_. The tree structure manipulation we have is suboptimal and .NET is faster at manipulating buffers anyway, but using SPIR-V would make sure we process only binary buffers. Additionally, it allow us to potentially make all shader front-end processing offline, we would effectively skip the whole front-end written in C# at runtime, huge win for us. Now we just need an... ## Implementation 🔗 ### The easy way 🔗 The first instinct I had was to lookup for some libraries to generate SPIR-V bytecode with some constraints : * It should give us the ability to extend SPIR-V to support our mixin system * It should be easy to integrate in the engine and easy to package with games, the new shader compiler should not add more complexity to the engine * The libraries should be a native, with which we can easily generate bindings, or written in C# * If written in C# it should be AOT compatible, for potential future console support. * It should also run fast, or use the recommended practices for high performance The first solution I've considered was LLVM, there was an ongoing work to add SPIR-V generation, this seemed like a neat idea but was nowhere near read and not sure if LLVM is fast enough to be used at runtime without creating stutters. Shaderc and SPIR-V Tools have some SPIR-V generation capabilities to some degrees but from C# it would be hard to extend the SPIR-V specification. It has great support nonetheless, and our friends over at Silk.NET have some bindings for these tools. Another one was the Nintendo Switch emulator Ryujinx, written in C#, it can generate SPIR-V on the fly to translate/compile the console's shaders. They have generated C# code based on the SPIR-V headers and specification and are using it to assemble some SPIR-V modules. I decided to start from this Ryujinx code and made a little proof of concept by writing a little tool that takes the output of Stride's parser and convert it into shader modules. It only supported a very tiny subset of SDSL but it was enough to prove the compiler can be made, and to remind me that I do not know SDSL nor SPIR-V that well, and the Ryujinx code was not exactly suited for Stride. But then, the most intrusive thought a dev can have just crept in my mind... ### "I should rewrite it from scratch..." 🔗 And make sure it fits our needs, the constraints i've listed in the previous section. I decided to follow some core tenets and make sure I don't over-engineer anything for the sake of winning a few microseconds. First, as we're going to read, write and copy a lot, data should then be stored in a compact way using buffers and value types. This would improve enumeration of instructions and possibly garbage collection. We are also going to deal with a lot of small buffers, so pooling those buffers is going to be important to avoid stressing the garbage collector. Finally we should make sure SPIR-V data is arranged in ways that would benefit the compiler's performance. But most importantly, keep it as simple as possible. ### Buffers and instructions 🔗 According to the specification, instructions are made out of words/integers, they have a variable size and the size of the instruction is written in the high 16 bits of the first word. Instructions would be represented as slices of this buffer and to access those instructions we would need to iterate through this buffer. IT'S CODING TIME! // A RefInstruction will hold a Span and some cool methods and tools to extract information from this instruction. // We could also create an Instruction struct containing a Memory<int> and doing the same... public ref struct RefInstruction(Span<int> words) { public Span<int> Words { get; } = words; // ... } // A buffer class to represent our SPIR-V buffer, disposable because we're using MemoryOwner from the high performance community toolkit public class SpirvBuffer : IDisposable { // This will represent words and we'll extract instructions from it by taking Span<int> slices public MemoryOwner<int> Words { get; } public Enumerator GetEnumerator() => new(this); // An enumerator for our instructions public ref struct Enumerator(SpirvBuffer buffer) { int position = 0; public RefInstruction Current => new(buffer.Words.Span.Slice(position, buffer.Words.Span[position] >> 16)); public bool MoveNext() { // A simple advance, we read the size in the high bits, and just skip words based on this size. position += buffer.Words.Span[position] >> 16; return position < buffer.Words.Length; } } public void Dispose() => Words.Dispose(); } Instructions can have a variable number of operands and each operands can be one or multiple words. The simplest way to extract operand information from this slice is to generate C# source code with information on how to parse each instructions based on its type and size. And with just that, we can parse SPIR-V and even write our own SPIR-V disassembly tool! ### Generation 🔗 Now that we can load SPIR-V and parse it, the next step is to be able to write instructions. Fortunately for us, the SPIR-V headers repository provide a C# file containing all the enums and constants needed for instructions operands and some JSON files describing instructions and their operands as well as if the operands are optional or have to be passed as an array of values. With a few more, we can generate methods to add or insert instruction in a buffer! Here's an excerpt from the current unified core grammar of SPIR-V and its corresponding generated C# code : { "opname" : "OpFAdd", "class" : "Arithmetic", "opcode" : 129, "operands" : [ { "kind" : "IdResultType" }, { "kind" : "IdResult" }, { "kind" : "IdRef", "name" : "'Operand 1'" }, { "kind" : "IdRef", "name" : "'Operand 2'" } ], "version": "1.0" } And here's a function we can generate from it : public static Instruction AddOpFAdd(this SpirvBuffer buffer, IdResultType resultType, IdRef operand1, IdRef operand2) { // Extend the buffer and put the data needed int size = 1 + ComputeSize(resultType, operand1, operand2) buffer.Add(size << 16 | (int)Op.OpFAdd); buffer.Add(resultType); buffer.Add(operand1); buffer.Add(operand2); } After going through the core and the glsl grammar, we end up with a library that can both parse and assembler SPIR-V. ### Extending SPIR-V 🔗 This one was the easiest step as we've already made a source generator that generates the necessary C# code from json files, we just need an additional JSON grammar file made for SDSL and the generator will generate code to add custom instructions, there's really nothing else to it! What was left is creating a little tool that can read those extensions and pre-process many SPIR-V together to generate a valid SPIR-V module that can be consumed by Vulkan, OpenGL, WGPU and soon DirectX 12. I have made a prototype that works quite well but can be improved in the future, it's not a complicated task, it just takes time and efforts. Finally we can make sure we can generate SPIR-V mixins from the AST generated by the current Stride shader system. This should be easy, right? RIGHT? ## The Irony 🔗 The current shader parser was made for the specific use case of mixin abstract trees. Modifying the code would be a huge endeavor as I would have to dive into what's existing and try my best to understand what i can change without breaking anything, worse than that, the parser was written with Irony, a very good C# library to help anyone parse things in an LALR fashion, but with a lacking documentation and, in my personal opinion, has an "easy to write, hard to read" kind of API. CppNet is another library that Stride uses to preprocess SDSL code. It works like a C/C++ preprocessor, depending values given to the compiler, it will enable or disable some parts of the code. It's quite useful when you need target specific code, but it defeats the purpose of having a whole mixin system and would invalidate already compiled SPIR-V mixins. While it might be smarter and easier to continue using those libraries and just patch our new shiny SPIR-V assembler, rewriting the front-end seems like a necessary step if we want to embrace the newer .NET APIs for better performance. We just need to know how much performance we could squeeze from it... 🤔 But that's for another blog post, so much happened since last year and this blog post is getting long. 😀 ## Conclusions 🔗 Writing this SPIR-V library was very fun, I've learned a lot about SPIR-V and some of the possible use cases for it in the context of Stride. As you might have imagined, this was the easy part of this shader system rewrite. In the next installment we'll see the little adventure I went through to make the most of our shader front-end! Thank you for reading!

With so many free and open-source game engines out there, where do you even start? Table of Contents: * Introduction * Before we dive in * What is FOSS and why should I use a FOSS game engine? * What FOSS game engines are available today? * Bevy * Godot * Open 3D Engine * Stride * What engine should you pick? And other closing thoughts * Acknowledgments ## Introduction 🔗 The party is over. The era of companies offering their products and services at unsustainably low prices is coming to a close. Growing pressure from shareholders to transition from maximizing growth to maximizing revenue has pushed many commercial software companies to reevaluate their business models. In other words, introduce price increases and new fees. Those dependent on their software must now decide between accepting the increased financial burden or switching to alternatives. The video game industry is no exception to this changing tide as major game engine developers explore new ways to monetize their users. It raises a lot of questions for the community. How will we, as developers, manage these rising costs? Just as importantly, considering the immense impact licensing changes can have on developers, should Epic and Unity continue having a disproportionate influence on the game development landscape? While there is never a good time to wrestle with these questions, the rise of free and open-source game engines over the past decade gives independent game developers an opportunity to evaluate where free and open-source software can have a role in their next project. ## Before we dive in 🔗 I want to make this clear from the start: I will not be doing a head-to-head comparison of free and open-source game engines. The summaries of each engine discussed will not be exhaustive nor specifically highlight exclusive features. This is a celebration of the hard work of the game development community. I want to use this as a platform to get you excited about free and open-source game development and consider options beyond proprietary engines like Unity, Unreal, and GameMaker. If I tried to cover every feature of every modern free and open-source engine, this wouldn’t be a single article but an entire book series. For that reason, I identified notable features and characteristics of some handpicked engines I thought would be worth sharing. While reading this, keep in mind that no engine is one-size-fits-all, and, as I’ll explain later, picking an engine is about choosing the right tool for _you_. With that out of the way, let’s start! ## What is FOSS and why should I use a FOSS game engine? 🔗 As the name suggests, free and open-source software (FOSS) includes two notable characteristics: it is free (libre) and its source code is available. You can use free (or libre) software for any purpose at your sole discretion. You will most commonly hear something like: “free as in speech, not free as in beer.” It may be available at no cost, but even more importantly, the user has complete control over the software. The open-source aspect of FOSS describes how everyone has access to the code that makes up the software. Using a FOSS game engine provides several advantages. First, no licensing fees. While contributors always appreciate donations, none of the notable FOSS game engines expect or require upfront payment, subscriptions, or ongoing royalties. FOSS engines also provide independence from a single organization. If changes to a FOSS engine’s terms upset the community, the engine’s license allows developers to stick to the version with the most favorable terms and even fork off the project if they choose. The community guides the development and growth of their FOSS game engine of choice. Many FOSS game engines have active and passionate communities that share their knowledge, advocate for their engine, and help newcomers. These vibrant and dedicated communities serve as a potent learning resource when working solo or as a small team. Some community members even contribute to their engine, improving it for everyone. FOSS game engines allow anyone to modify the engine to fit their needs. For example, if the engine lacks a specific feature, has a persistent bug, or needs quality-of-life improvements, anyone can update it as necessary. They can even take the additional step of contributing the changes to the project for everyone’s benefit. One of the greatest strengths of FOSS game engines lies in their communities and a willingness for everyone to work towards a collective good. ## What FOSS game engines are available today? 🔗 Although FOSS game engines have existed for decades, the past several years have seen an explosion in the number of game engines available, as well as contributors, money, and resources dedicated to them. It would be impossible to cover all the FOSS game engines available now. In fact, if you have a passion for a particular language or framework, more likely than not, someone built a game engine with it. This post will focus on some of the more notable modern FOSS game engines: Bevy, Godot, Open 3D Engine, and (of course) Stride. However, this is not an exhaustive list. As I mentioned before, there are more engines out there than I could ever cover in a single blog post. Many skilled and dedicated folks have put serious time and effort into making game engines and shared them with the world. I encourage you to use this post as a starting point and look at what each community offers. ### Bevy 🔗 * Written in Rust, Supported Languages: Rust * Platforms: * Development (Code Only): Windows, Mac, Linux * Build Targets: Windows, Mac, Linux, iOS, Android, Web As the most popular Rust-based game engine, Bevy offers a rich code-only development environment (an editor is coming in the future) capable of running on all major operating systems (Windows, Mac, and Linux). At the heart of Bevy’s vision for game development lies the Entity Component System (ECS) paradigm. While there are other resources available that can explain the benefits of ECS better, in a nutshell, ECS breaks down the code into three core pillars: entities, components, and systems. Entities are composed of components that can interact with each other using systems. For example, the player character could be an entity with a health component that tracks the player character’s health bar. An enemy character could also use that health component for the same purpose. ECS encourages modularity and reusability by enabling developers to create components applicable to distinct entities. While other game engines can approximate a similar system, Bevy makes this part of its core design ethos. As established with Bevy’s use of ECS, the engine’s developers care deeply about modularity. The engine’s plugin system accentuates their commitment to that principle in every part of Bevy. Developers can organize the game’s systems into discrete plugins. An example of this is organizing all the UI code into a UI plugin. From there, developers can slot the plugin into the game’s initialization step. The plugin system helps organize the code and encourages modularity by allowing developers to add or remove the plugin based on their needs. This paradigm even applies to the engine’s core features, as they are all organized into plugins. It becomes trivial to activate or deactivate any part of the engine—including rendering, audio playback, and event loops—as the developer sees fit. Asset libraries provide a wealth of resources that empower developers to learn the tools quickly and get their game to a playable state. The community assembled a library of assets available on the official website for everyone to use and share. Bevy’s library includes tutorials, plugins, and templates that address subjects like physics, networking, and input management. Even entire games and applications are available in the asset library to either build on or use as a reference while learning the engine. Bevy’s structure encourages developers to use any of the resources from this library freely as part of the building blocks that will make up their game. In conjunction with Rust’s package manager, there is a strong emphasis on modularity at every level of the engine. ### Godot 🔗 * Written in C++, Supported Languages: GDScript, C# * Platforms: * Development: Windows, Mac, Linux, Android (Experimental), Web * Target: Windows, Mac, Linux, iOS, Android, Web Godot has the largest and most active community among all the modern FOSS game engines available to date. As the drama around Unity has unfolded, you have likely heard mentions of Godot on more than a few occasions. It is not without merit, as Godot encourages developers to shape the engine around their needs. Coming in at only 40 MB, the engine includes a lightweight, multi-platform editor capable of running on any major operating system (Windows, Mac, and Linux). In fact, you can even use a web-based or Android version of the editor, albeit with some constraints. Godot can meet developers on whatever platform works best for them. GDScript is Godot’s primary programming language. While the prospect of learning an engine-specific language may turn you off at first, don’t fret! It shares a lot of commonalities with Python and Godot provides detailed documentation on how to use the language. Assuming you already have some experience with object-oriented programming, it won’t take long to get going with GDScript. You can even use C# for scripting if that is more up your alley, as it’s the other language officially supported by Godot. That said, if you would still like to write some code in another language entirely, Godot provides the means to use alternative programming languages by way of GDExtension. Theoretically, GDExtension supports any programming language that can interact with its C-based API. While Godot officially supports scripting in GDScript and C#, GDExtension allows the community to introduce new language bindings to Godot’s development ecosystem, including Rust, Go, Swift, and Haxe. Not all language bindings are feature-complete, but many are in active development. With that in mind, committing to one language for an entire project is unnecessary, as GDExtension languages can work alongside GDScript. This means developers can, for example, even use GDScript with other languages like Rust in the same project. Work in an editor long enough and you will probably want to tinker with it. For those interested in creating utilities and tools, as is common practice when using Unity or Unreal Engine, Godot provides the option to customize the editor to your liking. You don’t need to write in C++ and re-compile Godot to create plugins. Because the editor runs on Godot itself, it is possible to tune or extend the editor with GDScript, Godot’s scripting language, by simply appending @tool to the top of the file. Writing a plugin becomes as easy as writing code for your game. ### Open 3D Engine 🔗 * Written in C++, Supported Languages: C++, Lua * Platforms: * Development: Windows, Linux * Target: Windows, Mac, Linux, iOS, Android Open 3D Engine’s origins trace back to Amazon’s foray into game development. Amazon licensed Crytek’s CryEngine 3 and then used it as the foundation for their own game engine: Amazon Lumberyard. In the following years, Amazon offered Lumberyard for free to the community with specific terms requiring games built with Lumberyard use Amazon Web Services for their online features. By 2021, Amazon overhauled Lumberyard, rewrote 95% of the code, rebranded it as Open 3D Engine (O3DE), and placed it under the supervision of The Linux Foundation. Now, O3DE is available as a free and open-source engine under dual Apache and MIT Licenses for everyone, with no strings attached. Only a few game engines offer visual scripting out of the box, and O3DE is one of them. O3DE supports both C++ and Lua for scripting, but for folks less inclined to write code, there is also Script Canvas, OD3E’s visual scripting environment. Visual scripting provides a way to write game logic without needing to write code in C++ or Lua. It presents programming concepts like functions, variables, and events as nodes that can be strung together in a graph. Script Canvas also allows developers to write custom nodes either in C++ or within Script Canvas itself to better fit their workflow. Fortunately, anything written using O3DE’s visual scripting system will not incur any serious performance hits, as the engine ultimately converts the graphs into Lua scripts. O3DE modularizes its engine by breaking down major components into plugins called Gems. This is the paradigm through which O3DE manages all its features and plugins. For example, it is possible to swap out features like the physics engine, allowing developers to choose between PhysX 4, PhysX 5, or another solution entirely, custom or commercial. The modularity afforded by O3DE through Gems allows developers to add and remove components of the engine with relative ease–using as many or as few of the features as they want and in whatever combination best fits their needs. With the Atom Renderer, the engine’s rendering system, O3DE strives to provide an advanced renderer that is also exceptionally customizable. The Render Pipeline Interface (RPI) and Rendering Hardware Interface (RHI) constitute the primary channels for working with Atom. The RPI provides the tools necessary for customizing the rendering pipeline and implementing higher-level graphical features, such as split screen or additional rendering passes. Meanwhile, the RHI abstracts access to the GPU’s functionality, allowing developers to write lower-level graphics logic without needing to target specific graphics APIs like DirectX or Vulkan. In short, the rendering stack provides incredible flexibility to developers. ### Stride 🔗 * Written in C#, Supported Languages: C#, F#, Visual Basic * Platforms: * Development: Windows * Target: Windows, Mac, Linux, iOS, Android Stride began life as Xenko (and before that, Paradox): Silicon Studio’s premium game engine. After several years of providing Stride to the public through a subscription-based model, Silicon Studio released the engine’s source code and editor freely to the community under the MIT license. Among the higher profile FOSS game engines available, it is unique because Silicon Studio completely wrote it in C# from top to bottom. There is no delineation between the language used for the core engine and the language you would write with day-to-day while working on the game. It becomes much easier to override or change any inherent engine behavior when coding in the same language. No need to develop an interop system to interface with the engine’s core logic. With that said, the code-only version of Stride supports any language that is part of the .NET family (C#, F#, and Visual Basic), providing some flexibility in language choice. The engine offers a pure .NET experience that includes many of the advantages inherent to the framework, like hot reloading. At the time of writing, Stride runs on .NET 8 (the latest version of the framework) and supports C# 12. Because the engine closely follows the .NET update schedule, you often get the most modern and up-to-date implementation of C#. You can seamlessly incorporate almost any C#-based library or tool available through NuGet, GitHub, and other platforms into Stride, enhancing your workflow. Stride is modular enough that sections of Stride are available as standalone NuGet packages. The engine provides the ability to tailor-make your game development experience. The engine does its best to ensure it does not become a technical bottleneck for your game. A lot of processing within Stride is multithreaded. This means it allows logic to run on multiple threads of execution concurrently. The engine even implements a custom thread pool to maximize engine performance. As a result, Stride takes full advantage of the hardware it is running on, providing players with faster and smoother experiences. All the tools Stride uses to support multi-threading under the hood are also accessible to developers. Nothing is out of reach. An entire library exists within the engine focused on multi-threading that anyone can leverage in their projects. Used with features like the upcoming Bepu physics integration, it becomes possible to have tens of thousands of physics-based objects concurrently in a scene with little effort. Stride provides the space to explore multi-threading and have fun with it. ## What engine should you pick? And other closing thoughts 🔗 There is no one right answer. Don’t trust anyone claiming otherwise. Here is the truth: the answer lies in whichever you enjoy using the most. Game development is a process. It requires a healthy level of commitment and discipline. Anyone can do it, but you need to put in the effort. The better your tools fit with your way of working and thinking, the more likely you’ll commit to your project and put in your full effort. All these engines are free and include active communities ready to help new folks. Pick whichever engines strike your fancy and try them. Maybe one of them has that one specific feature that hits just right. Maybe another has a community you love hanging out with or the engine integrates well with a tool you’re using already. Whatever the case, it’s a matter of taste and what works best for you. Wanting to know if an engine can make a specific type of game is asking the wrong question. People make games in Excel. You can make just about any game in any engine. It’s not always a trivial task, but you can do it. Instead, ask yourself which tools you enjoy using the most. When you settle on an engine, remember this: your engine is not your identity. Your tools are a means to creating something, not a core pillar of your very being. I cannot stress this enough. Your tools do not define you. This may sound obvious, but I have seen many, many folks make their engine of choice a centerpiece of who they are and become unnecessarily hostile toward other engine communities. Please don’t do that. You are not simply a Bevy developer, Godot developer, O3DE developer, Stride developer, or whatever else. You are a game developer. So don’t get hung up on which engine you should pick. Choose the engine that resonates with you the most, and you’ll quickly learn skills you can apply anywhere. Make creating something rewarding in and of itself. If you enjoy working in your environment, you will enjoy the act of development. Once you manage that, creating anything, game or otherwise, will feel immensely satisfying in its own right. Be curious and have fun. ## Acknowledgments 🔗 This article was only possible with the input of contributors and users involved in these game engines. I appreciate all the folks who were kind and patient enough to fact-check me and provide their feedback, including Vaclav Elias, Joreyk, Doprez, Judah Perez, Clay John, Adam Scott, Fredia Huya-Kouadio, Pāvels Nadtočajevs, as well as the Open 3D Foundation and Open 3D Engine contributors. Last but not least, thank you to Ed (Meltted) for creating the featured image.

Stride contributors are thrilled to announce the release of Stride 4.2, now fully compatible with .NET 8 and leveraging the latest enhancements in C# 12. This release brings significant improvements in performance, stability, and developer experience. Table of Contents: * Download and Upgrade * Unity Licensing Model Impact: A Catalyst for Change * Stride's Rising Popularity * The Heartbeat of Stride: Our Community * Addressing the Pace of Updates in Stride * The People Behind Stride * Facing the Realities: Funding and Resources * Funding and Resource Allocation * Challenges in Distribution * Call for Skilled Developers * Join Us on This Journey * The Impact of Your Support * Looking Ahead * What's New in Stride 4.2 * Fixes * Exciting Development in Stride Physics * Introducing Bepu Physics in Stride * Future Prospects and Disclaimer * Also good to know * Cross-Platform Evolution: The Stride Editor and Avalonia * Links * Acknowledgements * Long time Stride supporters * Platinum Striders * Gold Striders A massive thank you to the open-source Stride community for your dedicated contributions. This release saw over 75 contributions from more than 22 amazing contributors, each playing a crucial role in making Stride 4.2 a reality. ## Download and Upgrade 🔗 You can download the Stride 4.2 Installer today. Release notes are available here. Make sure you read the guide to update Stride and projects properly. ## Unity Licensing Model Impact: A Catalyst for Change 🔗 The game development world has seen quite a stir with recent changes in Unity's licensing model. These shifts have led many in our community to rethink their choice of development tools. Stride 4.2 steps up in this scenario as a solid, C#-based alternative, offering a familiar yet distinct approach for game developers. ### Stride's Rising Popularity 🔗 It's been an exciting time for us. We've noticed more and more developers giving Stride a try, a trend clearly reflected in our growing user numbers. During the crazy Unity days, we were number 3 in the popularity rankings, just after Godot and Bevy. Also a big shoutout to gamefromscratch for his video "Stride For Unity Developers", which definitely helped. ### The Heartbeat of Stride: Our Community 🔗 What really makes Stride tick is you – the community. Your feedback, contributions, and ideas have been the driving force behind Stride 4.2. It’s your hands-on experience and insights that have helped shape this release, making Stride not just a tool but a community achievement. ## Addressing the Pace of Updates in Stride 🔗 Let's talk about how often Stride gets updated. We know it's something on your mind, and that is why we want to explain the dynamics that influence it. ### The People Behind Stride 🔗 Stride is maintained by a group of passionate developers, much like yourself, who contribute in their free time. This means our pace might not match that of other engines backed by full-time teams. Luckily we still have the original creator and lead of Stride among us to tackle tricky issues and infrastructure. ### Facing the Realities: Funding and Resources 🔗 Here’s the deal: our funding levels shape how much we can do. We’re grateful for every bit of support we receive, but we’re still on our way to having a full-time development force. This financial reality does affect how fast we can roll out updates. Although we might not be the fastest out there, we focus on making each update meaningful. ## Funding and Resource Allocation 🔗 ### Challenges in Distribution 🔗 The pace at which we distribute funds is often perceived as slow. However, this is not from a lack of willingness but rather the challenge of finding the right talent for the tasks. Nonetheless, we are actively funding projects at this moment, focusing on enhancements in XR, introducing morph target capabilities for 3D models (aka Blendshapes), and updating the bindings for the Assimp 3D importer to Silk.NET. ### Call for Skilled Developers 🔗 We are actively seeking skilled developers with experience in C#, the .NET ecosystem, mobile, XR, rendering, and game development. If you have these skills or know someone who does, we encourage you to get involved. There are opportunities to contribute to critical areas of Stride's development, supported by available funds. ### Join Us on This Journey 🔗 We’re always excited to welcome new contributors to the Stride family. Whether it’s through code contributions, spreading the word, or donations, every bit helps us grow stronger. If you’ve got skills in .NET, Android, and iOS development, there’s a special place for you here. Support us on OpenCollective. ### The Impact of Your Support 🔗 We believe that every donation has a substantial impact, perhaps more so than in some other projects. Why? Because C# as a language offers high productivity, and the Stride codebase has a great architecture. This means that every dime you contribute goes a long way. Imagine how much we could do if Stride got as much financial support as other big engines. With C#'s easy productivity and Stride's well-organized code, your donations could help us improve much faster. It's not just about keeping the lights on; your support can take Stride to new heights! ### Looking Ahead 🔗 With your support, we’re optimistic about picking up the pace. Our goal is to bring you new features and improvements more regularly, making Stride even better with each release. ## What's New in Stride 4.2 🔗 Stride 4.2 includes numerous enhancements and improvements. Here’s what to expect: * **.NET 8 Integration** : Stride 4.2 is now fully aligned with .NET 8, harnessing its performance improvements and efficiency gains for game development. This means faster execution times, reduced memory footprint, and access to the latest C# features, making your development smoother and more efficient. Learn more * **C# 12 Features** : With C# 12, Stride users can write cleaner, more concise code thanks to new language features. These improvements reduce boilerplate and enhance readability. Discover C# 12 * **Changed Assimp Binding to Silk.Net.Assimp** : This update transitions the asset compiler's binding from C++/CLR to Silk.Net.Assimp, a move that not only simplifies the codebase but also paves the way for asset compilation on non-Windows systems, broadening Stride's accessibility. See the pull request * **Migration NET6+ and More gettextnet#2** : Stride's commitment to staying current with .NET versions continues, ensuring compatibility and leveraging the stability and features of the latest .NET environment across all aspects of the engine. Check out the update * **Enable Multiple Profiler Consumers and Add a Timeline/Tracing Profiler** : This enhancement introduces a profiler with chrome://tracing output format, significantly improving the debugging and performance tuning process by allowing for a more granular analysis of game performance. Explore the feature * **Feature: Add Support for F# and VB Project Types** : Stride now welcomes developers using F# and Visual Basic, offering support for code-only projects in these languages. This opens up Stride to a broader audience. Learn about F# and VB support * **Stride Diagnostics Analyzer** : This new tool provides immediate feedback within your IDE, identifying potential compatibility issues with Stride's serialization system. It's about making your development process smoother and helping you catch and resolve issues faster. Discover how it works, the docs page and here is the pull request. * **OpenVR Handle Custom Resolution Specified by the User Through VR Settings** : Enhancing VR development, this update allows developers to specify custom resolutions for VR projects, optimizing performance and visual quality for various VR devices. See the details * **Editor Enhancements** : * **Dynamic Snapping for Selected Objects** : This feature introduces dynamic snapping while transforming objects, improving precision and workflow efficiency within the Stride Editor. Dynamic snapping PR * **Animation Stack Selection for FBX Imports** : Stride now allows you to select specific animations from a stack when importing FBX files, giving you more control over the assets you bring into your projects. Learn more * **Automatic Asset Copying to Resources Directory** : To streamline asset management, the editor can now automatically copy imported assets to the project's Resources directory, ensuring your assets are always where they need to be. See how it works ## Fixes 🔗 Although there have been many fixes, we'd like to point some of them out: * Runtime rasterized fonts are broken #1750 * Game Studio doesn't reload sub projects after changes #1703 * Changing the comparison project related and not UPath related #1704 * Translations fix #1717 * C# Beginner Tutorial Build Errors #1652 * Can not create "C# Beginner" project #1650 See the full list in the Release Notes. ## Exciting Development in Stride Physics 🔗 Stride 4.2's release isn't just about what's in the box; it's also about what it enables for the future. A standout development in this context is the integration of a new physics package in Stride. ### Introducing Bepu Physics in Stride 🔗 Our Discord community is buzzing with the news of Bepu physics, a project initiated by our user Nicogo1705. BepuPhysics v2 is a high-performance, multi-threaded physics library, written entirely in C#. Its compatibility with Stride's C# ecosystem offers the perfect alternative to the Bullet 3D physics engine, which relies on C++ Interop. With additional support from Doprez and Eideren, the efforts in integrating Bepu physics have already shown impressive results, especially in editor compatibility and performance. As you can see in this video, running on almost 10 year old hardware (yes, cube fountain included): Nicogo's YouTube channel features some more demo videos. GitHub: Nicogo1705/Stride.BepuPhysics ### Future Prospects and Disclaimer 🔗 Currently an independent package, Bepu physics is charting a course towards deeper integration within Stride. While it stands as a potential future replacement for Bullet physics, the package is still evolving. Future updates may necessitate adjustments to projects using its current version. We encourage users to stay updated and adaptable as we continue refining Bepu physics with the community's support. The pull request can be found here: [Physics] Bepu integration ## Also good to know 🔗 Although not directly tied to Release 4.2, we have some more big things going on. For instance to our website and documentation. We also had another community meeting to address all those new members. * Website and documentation revamped and build process updated * Contributor section moved to docs * Community meeting October 2023 And last but not least: ### Cross-Platform Evolution: The Stride Editor and Avalonia 🔗 One of the most ambitious projects for Stride to date has started: The porting of the entire Stride Editor from WPF to Avalonia, a cross-platform C# UI library. This significant endeavor, undertaken by Kryptos-FR, a former Stride developer. Currently, the project is in the early stages but it not only anticipates making the editor compatible with Linux and MacOS but also aligns with the long-standing community desire for broader platform support and enhanced editor functionality, including a robust plugin system. More details in this pull request: Cross-platform editor rewrite - prototype ## Links 🔗 * GitHub: https://github.com/stride3d/stride * Website: https://stride3d.net/ * Documentation: https://doc.stride3d.net/latest/en/manual/ * Twitter: https://twitter.com/stridedotnet * YouTube: https://www.youtube.com/@Stride3D ## Acknowledgements 🔗 We extend our heartfelt gratitude for all the hard work and donations we have received. Your generous contributions significantly aid in the continuous development and enhancement of the Stride community and projects. Thank you for your support and belief in our collective efforts. In particular we want to thank these donors: ### Long time Stride supporters 🔗 * VVVV🥇 ### Platinum Striders 🔗 * Happenstance Games🏆 ### Gold Striders 🔗 * Vašo ( Vaclav )🥇 * Lucid Silence Games🥇 * Skid Vis🥇 This article was co-authored by Aggror Jorn and Tebjan Halm.

In this first part of a new series of blog posts, we will learn more about Stride's shader system, its limitations and how to make it better thanks to a very useful shader language called SPIR-V. This will be the first step in implementing a new and better shader system. Don't forget to checkout part 2! Table of Contents: * What are shaders? * Rendering in game engines * How does it work in Stride? * The many problems shader systems are facing * GPUs are all different * Drivers are not all the same * Performance Cost * Why investigating SPIR-V? * Summary The Stride engine has a powerful shader system, helping users build very complex shaders thanks to its language features like composition and inheritance, and its C# integration through the very powerful material system. ## What are shaders? 🔗 Simply put, they are typically snippets of code that are run on the GPU, mostly written in C-like languages like GLSL and HLSL. When a game has to render on the screen, it starts by preparing the data on the GPU and then sends shaders with commands. The GPU then executes those commands and if everything goes well, the game ends with a lovely picture drawn on the screen. This single call of a GPU is called a `draw call`. It can be simplified to this view. There is a first stage called `Vertex stage` which is meant to compute vertices and make sure they are transformed into data that can be rasterized by your GPU, and a final stage called `Pixel stage` or `Fragment stage` that takes the rasterized output of the rasterizer and computes color for each pixel on the screen based on which triangles they belong to. In both stages, you can provide textures/images and data through buffers, this can help give more details to your rendering, or help you compute more complicated things. ## Rendering in game engines 🔗 Drawing a single mesh is simple, one buffer of vertices, maybe some textures, do a draw call and ✨ marvel at the screen ✨. Repeat it many times and you get a video, very useful to make video games 👾. In game engines, objects being drawn the same ways are grouped into `materials`. A material can be seen as a recipe for drawing a mesh with ingredients like shader code, textures, vertices and other informations. Having many different materials implies creating many shader source code, and depending if you use forward or deferred shading, you might need to reuse code from one file to another leading to lots of duplicate code 👩‍💻👨‍💻. To solve this problem, all game engines have developed shader systems that help create permutations of shader code depending on the material you're using. It helps reuse code you've already written, which speeds up development and gives you the power to organize your code in more manageable ways. A good example of that are shader graphs from Unity or the material editor in Unreal, whenever you add a block/function to the graph, it reuses shader code already written, to create a new permutation. ## How does it work in Stride? 🔗 Stride has its own shader language called SDSL which stands for **S** tri**D** e **S** hader **L** anguage. SDSL uses a very smart system of composition and inheritance, similar to object oriented programming. You can learn more about it through the manual. ## The many problems shader systems are facing 🔗 To create permutations you need to be aware of the many limitations you will face while writing code for GPU. ### GPUs are all different 🔗 As obvious as it sounds, it needs to be reminded. Whenever you write code for your GPU you have to be aware that it will not work for all other GPUs. 10 years ago, two languages were the most used for writing shader code: HLSL and GLSL. In the case of OpenGL, GPU vendors would provide you with their own GLSL compilers to work for their GPUs through different drivers. A valid code for one compiler would be a syntax error for another. It was a big mess 💩, but a manageable one! Stride was created during this period and it was designed to run on a wide variety of devices 🎮 🕹️ 💻 🖥️. The solution chosen for creating code permutations that could work on many different machine was transpilation. Text would be parsed in abstract syntax trees and the text would be translated from one language to another by manipulating those trees. To have a better idea of how abstract syntax tree work, this playlist of videos will definitely help. ### Drivers are not all the same 🔗 Drivers can be seen as a front-end API to use the GPU. They have different paradigm and logic which may result in your shader code needing to be different across different drivers. Here's a table of which language is supported by which machine depending on the driver used. I chose the most used machines for gaming. Note that some APIs are tied to the machine you're developing for, adding more complexity to the shader system, needing to handle GPUs that have very specific features. Vulkan and OpenGL can be used on Mac and iOS but OpenGL is deprecated and Vulkan run on MoltenVK, a Vulkan implementation on top of Metal. | Direct3D | Vulkan | OpenGL | Metal | PSGL | NVN ---|---|---|---|---|---|--- Windows/XBox | HLSL | HLSL/GLSL | GLSL | | | Linux | | HLSL/GLSL | GLSL | | | Mac/iOS | | HLSL/GLSL | GLSL | MSL | | Android | | HLSL/GLSL | GLSL | | | Playstation 4/5 | | | | | PSSL | Nintendo Switch | | HLSL/GLSL | GLSL | | | ? ### Performance Cost 🔗 Managed languages like C# are well known to be slower with string objects since they treat them as immutable. On top of that, tree structures, especially the one used for shader compilation in Stride, tend to perform very slowly and are prone to be slow and work against the GC. ## Why investigating SPIR-V? 🔗 Three things happened in the past 10 years: * Vulkan was released with a new kind of bytecode shader language called SPIR-V * .NET Core introduced a new high-performance feature for operating on slices of array (something that C# is way better at than processing string objects), namely `Span<T>` * Most importantly, tools like SPIRV-Cross and Naga were created as a means to translate shaders through SPIR-V It was clear for everyone that we had to investigate how we could compile SDSL to SPIR-V and use all those very performant tools to transpile SDSL to other languages. SDSL is a very peculiar language and shifting from processing tree structures to processing segments of byte code is a great endeavor, especially for an engine. The following parts of this series of blog posts will focus on how such a system can be created, thanks to the many new C# and .NET features that came out since the release of .NET Core. ## Summary 🔗 Embracing SPIR-V for Stride's shader system will hopefully empower us with a better control over the shader language but also improve performance for shader compilation 💪💪. Thank you for reading!

Let's take a closer look at the `DiagnosticAnalyzer` feature added in `Stride.Core.CompilerServices`. This feature offers real-time code analysis in your IDE, enhancing your workflow. Table of Contents: * What is a DiagnosticAnalyzer? * What does it do? * Example * Why use it? * Current State * For Engine Developers * Summary Stride continues to evolve, adding new utilities and features every week. This blog post will cover the newly added `DiagnosticAnalyzer` feature in `Stride.Core.CompilerServices`. ## What is a `DiagnosticAnalyzer`? 🔗 A `DiagnosticAnalyzer` is a feature from Roslyn that scans your code while you are typing in your IDE. C# also utilizes this feature; every time you see a warning or red squiggly lines in your IDE, a `DiagnosticAnalyzer` gets triggered. Analyzers are offline tools used by the compiler to assist programmers. They are not used to collect telemetry on how Stride is being used. ## What does it do? 🔗 The new `Diagnostics` primarily focus on Serialization. These analyzers generate warnings for code that is incompatible with Stride's Serialization Rules of Thumb. Each error code follows this format: `STRDIAGXXX`, where 'X' represents a numerical digit. Clicking on these error codes will open a help page that explains in depth why the `DiagnosticAnalyzer` was triggered and how to resolve the warning. You can find these error code pages here. ## Example 🔗 In this example, we'll delve into a common scenario where the `DiagnosticAnalyzer` spots issues related to Stride's serialization rules. We have a `Dictionary` property named `Name` within a class `Example`. We've also adorned the `Name` property with `[DataMember]` and `[DataMemberIgnore]` attributes which are contradictory, and this is where the `DiagnosticAnalyzer` steps in to provide valuable feedback. public class Example { [DataMember] [DataMemberIgnore] public Dictionary<Example, int> Name { private get; set; } } Upon compiling, the `DiagnosticAnalyzer` flags three diagnostic warnings related to the attributes and the property's accessibility: STRDIAG000: There is an Attribute Contradiction on 'Name' Member. [DataMemberIgnore] Attribute on a [DataMember] is not supported. Except if it has also [DataMemberUpdatable] Attribute. STRDIAG009: The member 'Name' implements IDictionary<T,K> with an unsupported type for the key. Only primitive types ( like int,float,.. ) are supported or string or enums as the Dictionary Key in asset serialization. When used in other contexts the warning may not apply and can be suppressed. STRDIAG004: The property 'Name' with [DataMember] does not have an accessible getter which is required for serialization. A public/internal/internal protected getter is expected. The following image demonstrates how these warnings are displayed in Visual Studio: These warnings provide immediate feedback, aiding the developer in adhering to Stride's serialization rules. The `DiagnosticAnalyzer` not only pinpoints the issues but also suggests the necessary adjustments to align the code with Stride's standards. For instance, it suggests the removal of the `[DataMemberIgnore]` attribute or the addition of a `[DataMemberUpdatable]` attribute to resolve the attribute contradiction on the `Name` member. It also highlights the requirement for an accessible getter for serialization, and informs about the supported types for the `Dictionary` key in asset serialization. ## Why use it? 🔗 This real-time feedback is invaluable, making the coding process smoother and less error-prone, and ensuring that the codebase remains compliant with Stride's serialization standards. This feature aims to minimize those "Why is my property not showing up in the Game Studio?" moments. It's often unclear why certain properties don't appear in the editor. These analyzers are designed to clarify such situations, aiding your development process in Stride. ## Current State 🔗 The pull request (PR) to introduce these analyzers has been merged. However, there hasn't been a release that includes them yet. If you're eager to test them out, you can build the engine from the source. Otherwise, you'll have to wait for the next release of Stride's NuGet packages. ## For Engine Developers 🔗 Adding new analyzers to the Stride engine is straightforward. However, be aware that Visual Studio (VS) has a bug caused by .NET, which makes VS load Roslyn only once at startup. To work around this, compile `Stride.Core.CompilerServices` and restart VS after adding a new analyzer. ## Summary 🔗 This is a new quality-of-life feature that simplifies development in Stride by providing immediate feedback on coding issues. Thank you for reading 📖, and happy coding 💻👩‍💻👨‍💻!

On October 7th, a community meeting was held addressing new user influx, planning the release of Stride 4.2, contingent on the .NET 8 launch. ## Summary 🔗 During this almost 3 hour long session we talked about the following: improving domain knowledge, access rights, and documentation, transferring the Stride Community Toolkit to the official repository, and community-driven initiatives like a new demo project and extending tutorials. Significant attention was given to a substantial editor rewrite from WPF to Avalonia for enhanced cross-platform support, opening it up for community contributions. Table of Contents: * Summary * Short summary of Contributor meeting * Release of 4.2 * Open Collective * New projects * New Demo project * Community Toolkit * Stride Plugins * Stride UI Rewrite * Acknowledgements * Long time Stride supporters * Platinum Striders * Gold Striders ## Short summary of Contributor meeting 🔗 A few weeks prior to the community meeting, we held a contributor meeting. This was mostly to address the recent instream of many new users. Since we suddenly got an abundance of user feedback we took and planned some steps. * Inventorizing domain knowledge and access rights. * This overview will be posted soon on GitHub. * Moving the Stride Community Toolkit to the official Stride repositories. * Investigating nightly/weekly/monthly builds and releases. * The idea of having more frequent releases was discussed to provide users with the latest PRs and fixes, whilst also having more publicity. * Concerns were raised about the potential impact on development velocity and the need for stabilization phases. As soon as the new build system (arranged by Xen) is up and running, we can decide on how often we make an official (minor) release. More on this later this year. * Updating contributors' documentation. * Next to the official documentation/tutorials, we also have various wiki pages per repository. Especially the documentation for Contributors and building from source, needs some love. Aggror is going to make an initial pull request for this. * Planning and creating videos for contributors. * Adjusting the strategy with OpenCollective Projects: here we came to the consensus that we required more feedback which we would gather during the community meeting. ## Release of 4.2 🔗 Stride 4.2 is around the corner, but when exactly? * For 4.2 we are waiting for the official release of .NET 8 which is to be release on November 14, 2023. * Since we want to release a version for .NET 6 and .NET 8, our goal is to release within a few days after the release of .NET 8. * Prior to the official release we will have a release candidate. This will be announced when it is available. * At the moment there is 1 open bug and 1 open pull request for a feature. Other than that, the build is locked for features. Only bug fixes would be allowed in * The open pull request for Silk.NET. will be moved to 4.3 to ensure stability. * For more info on the final items. ## Open Collective 🔗 Next we discussed the use of Open Collective for donations and funding specific projects. Although not mentioned in the meeting, our current funding is **12,992.34 USD**. * Up until this point it has been quite a challenge finding the right developers for existing Projects. The most recent successfully funded Project was the Bug bounty for Vulkan fullscreen. * There have been several suggestions to make funding more attractive, such as increasing compensation and investing in areas like documentation, marketing, and design next to coding Projects. * Every project should have a referencing GitHub ticket that contains as much detail as possible for the deliverables. * There are currently two talks ongoing for specific development. Once we have confirmation we will communicate this with the community. ### New projects 🔗 We will add several new Projects to the Open Collective. This will give members a clear view on 'targets' that we like to see funded. * Extending tutorials. Both written and video tutorials * New tutorial set for a small 3D (platformer) game * Contributor tutorials * Demo scene 2024 (more on this below) * Stride editor Avalonia (more on this below) ## New Demo project 🔗 We want to have a new demo sample project that demonstrates Strides capabilities. Members who want to help out, can add to the discussion here. ## Community Toolkit 🔗 There is a new initiative called the Stride Community Toolkit, aimed at aggregating common features, helpers, and extensions to streamline Stride development. It allows community members to test and enhance tools and propose their integration into the engine. This project has come to fruition with the combined effort of several users, and specifically the repositories off dfkeenan and VaclavElias. ## Stride Plugins 🔗 A topic talked about for several years now and it's quite an important one. Plugins allow you, for one, extend the editor with new functionality without having to build the engine from source. Ideally you want to go to some (NuGet) store and click -> install this awesome extension/plugin for Stride. If you want to contribute to the discussion on how to do this technically. We can divide plugin support into 2 categories: * Asset plugins: these would be purely models, textures, prefabs, components For this Manio143 is taking the lead. * Editor plugins: this category currently is not viable because of the dependency to another large topic: the need to rewrite the editor to a new library, replacing WPF. Since we are short on development time here, we need to take into account that it will be a while before we can see the first results of this. ## Stride UI Rewrite 🔗 The Stride editor is built with WPF and therefore only works on Windows. WPF isn’t really being developed anymore and on top of that we want to start supporting the editor on Linux. We can only do so by rewriting the editor to another UI framework. Just like the Plugin topic, the Editor rewrite is a big topic. Probably the biggest topic of them all. The editor rewrite has been discussed in great lengths on both Discord and GitHub in the past few years. People have shared their ideas on which framework to use (Avalonia, MAUI, Uno etc), made some prototypes, even ported the Stride launcher. But we never really ‘actively’ made this an official item since it would take a full time developer many months to work on this task. Members have been asking if they can help out with the rewrite, but up until this point, there wasn't really an official starting point. We also don’t want to waste the prototype/knowledge already collected. That is why we will soon have an official GitHub branch in the Stride repository where all Editor UI rewrites are taking place. We are fully aware that this might take a long time and a lot of effort from multiple people, but we have to start somewhere. We also anticipate that we can use some of the OpenCollective funding for this. So regardless of time/developer power: we have landed on using the Avalonia UI framework to rewrite the editor. Aggror will set up a GitHub topic summarizing how people can contribute to this UI rewrite branch and inventorize how we can split this massive task into subtasks.. More details on this will follow later this year. ## Acknowledgements 🔗 We extend our heartfelt gratitude for all the recent donations that have been made. Your generous contributions significantly aid in the continuous development and enhancement of the Stride community and projects. Thank you for your support and belief in our collective efforts. In particular we want to thanks these donors: ### Long time Stride supporters 🔗 * VVVV🥇 ### Platinum Striders 🔗 * Happenstance Games🏆 ### Gold Striders 🔗 * Vašo ( Vaclav )🥇 * Lucid Silence Games🥇 * Skid Vis🥇

Let's take a closer look at why currently you can't set private members of scripts and components in the Stride Editor and explore the options to change that in the future. Table of Contents: * What is public and what is private * Design vs runtime access * Editor runs your code directly * Serialization * What about constructors? * What about init properties? * UnsafeAccessor in .NET 8 * Summary It has been an amazing week for Stride and our Discord is booming with new people who want to learn more about the engine and maybe port some games from Unity. One of the questions that has been asked a few times was why we can't set private members on scripts in the editor. I thought it's a good opportunity to dive a little deeper into the technical reasons and engine architecture to explain the current limitation and explore the options to change it in the future. ## What is public and what is private 🔗 Let's run through a quick reminder. In C# members are annotated with access modifiers such as `public`, `protected` or `private`. The modifier describes the access objects of other classes will have when accessing the members. It allows us to control the API surface of an object by hiding away certain aspects of its state to allow the inner implementation to be changed without affecting other parts of code that would only interact with the publicly visible members. _To understand it better readthis analogy._ When designing systems we will often decide to make certain things public (maybe even use an interface to further describe the public API regardless of the class holding the methods) and keep most things private. This allows us to prevent accidental mistakes when another part of the systems makes changes to some delicate state. However, with a more Data Oriented approach we can find ourselves creating classes which hold mainly data. In many Entity Component System implementations the components are just data bags that systems read and update. With this kind of approach there's rarely need for private members, although sometimes the `internal` visibility is used for data on a component that is exclusively managed by its default system. Moreover, component's public properties are often not just modified at design time, but also at runtime. Think about the Transform component and how it's public properties are modified to move the entities around, or how changing the velocity on a Physics component affects how quickly the simulation will move it around on the next step. ## Design vs runtime access 🔗 We can talk about components in two contexts: setting the properties during level design in the editor and setting them at runtime while the game is running. We would generally expect in both cases that we can modify the properties of the component and they will be picked up by the processing system. With the introduction of Scripts, however, which are components containing logic, we get into a bit of a pickle. Yes, the script should be able to have private state and a public API for other components to interact with it. What if we want to restrict some data so that it can only be set once during initialization? Ideally the editor would not be constrained to modify the property during design, but once we hit the runtime it should be allowed to change. ## Editor runs your code directly 🔗 In Stride when you create a script in your project and open the project in the editor, the project will be compiled, the DLL loaded into memory of the editor, and when you add the script to an entity it will actually create a new instance of your script class. Same as at runtime. It won't run the script Update method, but if you have any logic in your property getters and setters those will be invoked at design time. This can give you enormous flexibility. But it also means that however you want your script to behave at runtime when it comes to properties the same will be enforced at design time. The editor uses reflection to access properties and fields on your script. It technically could modify private fields on the object instance it holds during design. But this needs to survive saving the project to disk. ## Serialization 🔗 Stride uses YAML for design time serialization of Assets. The assets can have a different form from the actual Content they are compiled to by the AssetCompiler. This is used for example by Audio or Model assets which at design time just hold a reference to your media files, but once compiled actually hold the bits of your media in a format that's easy to consume by Stride's runtime. For components and scripts rather than having a second class for each component and doing compilation from design to runtime representation, those classes are the same in both scenarios. This simplifies things but it means that serialization constraints need to be applied equally. While YAML is very flexible and the serializer currently uses reflection to set the properties, the runtime serialization is done using a custom binary serializer system. When you compile your game project, after C# compiler has done its job, the build system runs the AssemblyProcessor over your code to generate efficient serializer classes that do not use reflection to access members on the objects they deserialize. Access modifiers are enforced by the CLR, which means it's not possible to generate code that accesses private members of another class directly. ### What about constructors? 🔗 If we have a private field that we want to set once, why don't we use a constructor to accept a value for it? It's certainly an option and there are serialization systems which look at constructors to provide deserialization in this way. They may be a bit more complicated but it's possible to implement them. However, in a generic environment that Stride provides it's a bit difficult. How would the editor create a new instance of your class if it requires data to be passed in the constructor? Will it provide `default` values, will it look for a private parameterless constructor? ### What about init properties? 🔗 C# 9 has introduced `init` properties which are only allowed to be set at object construction. Reflection is able to bypass that of course, while at the CLR level a special marker `modreq` is placed on the property which asks the compiler to provide `modreq` marker on the callsite as well (see thread). Compilers which don't know about init properties would still prevent you from assigning them. And the CLR is not actually enforcing anything here - only compiler - thus the generated serializers are still able to use those properties. But in your code the constraint will be enforced and no runtime modification will occur after the object is initialized. public string MyProperty { get; init; } ### `UnsafeAccessor` in .NET 8 🔗 As we're trying to squeeze out more performance and improve the Stride codebase we're looking at rewriting the AssemblyProcessor from Mono.Cecil and manually emitting IL into a Roslyn C# source generator. This will also mean being restricted to whatever the compiler enforces, such as not setting init properties outside of object construction. Luckily in .NET 8 there's a new performance hack which allows you to access private fields on other classes. You can read about it more in the proposal and on the performance blog. [UnsafeAccessor(UnsafeAccessorKind.Field, Name = "_myField")] extern static ref string _myField(MyClass c); ## Summary 🔗 There might be some extra work needed to implement the changes to allow setting private members in the editor. At the moment using `init` properties is nice a middle ground. While in my opinion designing clear public APIs for components in a data driven approach is the way and it doesn't need access to private members, there's many users who see value in being able to use private members to their advantage and it's on the editor and engine to provide flexibility of choice in how you structure your code. Thank you for reading 📖, and happy coding 💻👩‍💻👨‍💻!

Explore the key differences between Unity and Stride, a C#-based, open-source game engine powered by .NET 6 (soon .NET 8). Learn how Stride's flexibility and native .NET support offer a unique development experience. Table of Contents: * Introduction to Stride * Difference Between Unity and Stride * Licensing * What games were made using Stride? * Operating System Support * IDE Support * .NET Hot Reload Support * Multiplayer Support * Unity Assets * Screen Capture * Shaders Available * Build Automation * Add-ons and Extensions * Transformations * Rendering * Gamepads * Other Q&A * What is the Equivalent of a Coroutine in Stride? * What is a StartupScript? * Using Other Assemblies/Projects in Stride * Is There an Asset Store for Stride? * Null Checking in Stride vs Unity * Where to Start * How to Find Answers * 🤝 Join Us: Stride Bug Bounties and Feature Funding 🛠️ * Flappy Bird - Stride Engine Demo * Closing Thoughts 🙂 ## Introduction to Stride 🔗 Stride is not just another game engine; it's written entirely in C# and serves as a powerful platform in the .NET ecosystem. This unique focus on C# offers developers the native .NET tooling and functionalities they are already comfortable with. What sets Stride apart is its project structure; Stride projects are standard `csproj` files, allowing them to integrate effortlessly into your existing .NET solutions. ## Difference Between Unity and Stride 🔗 Unity is developed by a large team and offers a feature-rich experience. On the other hand, Stride is open-source and built by community contributors. This means that Stride might not have all the features that Unity has, simply because there aren't as many people working on it. However, the open-source nature of Stride allows you to customize it according to your needs and provides a solid foundation for any rendering project. Additionally, Stride allows you to utilize any NuGet package and even provides access to the `Main` function of your game. You can also find useful resources such as documentation, community toolkits, and guides for migrating from Unity to Stride. * Stride for Unity Developers ## Licensing 🔗 Stride is released under the **MIT** license, which is important because it grants you significant freedoms to use, modify, and distribute the engine. ## What games were made using Stride? 🔗 For examples of games developed using Stride, check out Made with Stride section. ## Operating System Support 🔗 * Editor: Windows * Runtime: Windows, Linux, macOS, Android, iOS ## IDE Support 🔗 Stride games are "standard" C# projects, meaning you can use a variety of IDEs: * VS Code * Visual Studio 2022 * Rider * Blocknote + MsBuild * VVVV > **Note:** There's a Visual Studio extension for syntax highlighting, shader build keys and error checking. > **Note:** Another extension offers syntax highlighting only. ## .NET Hot Reload Support 🔗 Stride has the capability of using .NET Hot Reload for C# scripts, allowing real-time code modifications as your game runs. Importantly, this feature is also available when editing the engine side, giving you even more flexibility. Standard .NET hot reload rules are in effect. This feature streamlines development by minimizing the delay between coding and observing results, enhancing both efficiency and ease of use. If you're familiar with .NET and C#, you'll find that Hot Reload in Stride feels intuitively familiar. ## Multiplayer Support 🔗 Stride does not offer built-in multiplayer or Server/Client architecture. However, you can easily integrate any .NET networking library to implement these features. You have the freedom to choose from a variety of libraries and resources. For a curated list, you can check out Awesome-Stride's Networking section. ## Unity Assets 🔗 You can import some 3D models from the Unity store into Stride. However, scripts will need modification since the two engines differ. These are the basic Scripting Differences: * `StartupScript` is a MonoBehaviour without the Update method * `SyncScript` is a MonoBehaviour with an Update method that runs every frame * `AsyncScript` is unique and runs asynchronously ## Screen Capture 🔗 To capture a frame, you can use the following code snippet: var commandList = GraphicsContext.CommandList; commandList.RenderTarget.Save(commandList, stream, ImageFileType.Png); ## Shaders Available 🔗 SDSL is a shader language written on top of HLSL. * Shading language * ShaderExplorer ## Build Automation 🔗 Yes, since Stride uses .NET, automating the build process works out-of-the-box. ## Add-ons and Extensions 🔗 You cannot extend the editor in the same way as Unity, but you can create custom code extensions as seen in the following: * Terrain add-on * Level editor add-on ## Transformations 🔗 The `TransformComponent` class in Stride is a fundamental component for representing an entity's position, rotation, and scale within a 3D scene. **Important Features:** * **`LocalMatrix` and `WorldMatrix`**: These matrices manage the transformations of the entity. * **`Position`, `Rotation`, and `Scale`**: These properties represent the entity's position, rotation, and scale in the local coordinate system. The `Position` property is a `Vector3`, defining the entity's position. The `Rotation` property uses a `Quaternion` to represent the entity's rotation, and the `Scale` property is a `Vector3` that sets the scale. You can modify these properties to transform the entity. * **`UpdateLocalMatrix()` and `UpdateWorldMatrix()`**: These methods update the local and world matrices, respectively. * **`Parent` and `Children`**: These properties allow you to establish parent-child relationships between entities, affecting their transformations accordingly. ## Rendering 🔗 Stride primarily uses **clustered** forward rendering, with some additional features. Read more in the docs. * Stride Rendering Pipeline * Stride Graphics Compositor ## Gamepads 🔗 * Gamepads ## Other Q&A 🔗 ### What is the Equivalent of a Coroutine in Stride? 🔗 Unlike Unity, which uses `IEnumerator` for asynchronous code execution, Stride leverages C#'s built-in `await` and `async` features. This can be accomplished using `AsyncScript`, which essentially acts as a `SyncScript` (the Stride equivalent of Unity's MonoBehaviour) but with asynchronous methods. You can use async methods within sync scripts, the same as standard C#. ### What is a StartupScript? 🔗 A `StartupScript` in Stride includes a `Start` method that is invoked when it's added to the scene tree. This is similar to Unity's `Start` or `Awake` methods. However, `StartupScript` does not contain `Update` methods and therefore doesn't execute code every frame. ### Using Other Assemblies/Projects in Stride 🔗 In Unity, the packaging system is built on top of a `csproj` file, which allows Unity to protect its proprietary source code. Stride, however, grants you full access to your `csproj` and `sln` (Solution) files. This enables you to include any NuGet packages or other C# projects in the usual way, by adding project references. If you add a new subproject to your main project through the Stride editor, it will be correctly configured by default, including folder location and references to the Stride engine. ### Is There an Asset Store for Stride? 🔗 No, Stride does not have a dedicated Asset Store. However, most additional libraries specially designed for Stride can be found on GitHub or NuGet. For easier discovery, a summary has been made available at Awesome-Stride. ### Null Checking in Stride vs Unity 🔗 Does `is null` and `== null` work? Unlike Unity, which has overridden the `Equals` operator to be compatible with its C++ engine, Stride allows you to use `is null` and `== null` to compare the existence of an Entity or Component directly. ## Where to Start 🔗 Getting started with Stride is easy, thanks to a wealth of resources available. Here are some you shouldn't miss: * Stride's Manual: A comprehensive guide that covers everything from basic setup to advanced features. * Stride's Tutorials: Step-by-step tutorials to help you get your first project off the ground. * Discord: Join the community on Discord for real-time discussions and the latest updates. ## How to Find Answers 🔗 Consider checking these platforms where your query may have already been addressed or where you can gain more context: * Discord: Use the search functionality in our Discord channel to see if your topic has been discussed before. * GitHub Issues: Navigate to Stride's GitHub Issues to see if your question is related to a known issue or feature request. * GitHub Discussion: Participate in Stride's GitHub Discussions to engage with the community and explore various topics. This proactive approach not only helps you get immediate answers but also makes it easier for the community to focus on unresolved or unique queries. ## 🤝 Join Us: Stride Bug Bounties and Feature Funding 🛠️ 🔗 We invite talented developers to collaborate with us through our Bug and Feature Bounties. With tasks ranging from Vulkan support to decals and morph targets, there's something for everyone! Reach out via the specific GitHub Bounty tickets to get involved. 📬 For suggestions on new bounties, don't hesitate to connect with us on our Discord server or directly through GitHub. Participating in our bug bounties is a win-win! Not only will you be able to hone your skills, but you'll also contribute to the expansion and enrichment of the Stride community—and get **compensated** for your efforts! 💰 Stride's Open Collective Projects ## Flappy Bird - Stride Engine Demo 🔗 Ned Reid, a new member of the Stride community, has created a Flappy Bird demo, while exploring Stride as an alternative to Unity. He shared the following thoughts on his experience: I decided a couple of days ago that I would explore engines outside of Unity (for obvious reasons), and wanted to start with something simple. Over a fairly relaxed weekend, I've managed to put together a neat little Flappy Bird clone! _A screenshot of the Flappy Bird demo created by Ned Reid_ ## Closing Thoughts 🙂 🔗 If you've made it this far, congratulations 🎉! You now have a comprehensive understanding of Stride, its capabilities, and how it compares to Unity. The world of game development is vast and ever-changing 🌍, but the emergence of community-driven, open-source engines like Stride showcases the exciting directions the industry is taking. With its C# focus 🎯, extensive .NET support 💻, and flexible licensing 📜, Stride is a formidable option for both new and experienced developers. As the saying goes, the best way to learn is by doing 🛠️. So dive in 🏊, start a project 🚀, and don't hesitate to participate in the community discussions on Discord or GitHub 👨‍💻👩‍💻. Your journey with Stride is what you make of it, and the resources and community are here to support you every step of the way 🤗. Thank you for reading 📖, and happy coding 💻👩‍💻👨‍💻!

Just a little reminder that Stride has been presented in a .NET Live! 🎥🎥🎥 Vaclav, Tebjan and I participated in a .NET live session to showcase the Stride engine, as well as some work done by users. Many questions were asked, and Manio answered many of them in the chat. ## Watch the .NET Live right here 🔗 **Content** * History of the Project * Roadmap * What are some of the big game titles that folks would recognize * The UI * Add Scripts to Entities * Integrating Stride into your projects * Add Interaction * Shader System of Stride * Shader Code * Shader Language ## The most important questions answered 🔗 In this live session, we answered the most important questions about the project, including how to use Stride and what it aims to be! Tebjan presented a bit about what contributors have done and what users (professionals/hobbyists, artists/developers) have done so far to show off the capabilities of the engine. He also gave a small presentation on how Stride is used with VVVV for 3D rendering! ## A fun experimentation 🔗 Vaclav, having dived into Stride with a desire to use Stride without an editor, created an API to experiment and create games using just a NuGet package. He presents his NuGet package, explains how to use it, and how to make games leveraging the power of .NET and hot reloading! ## Shaders 🔗 I've personally become interested in the shader system of Stride and found it refreshingly easy to use. I decided to show more about how to use shaders, update them, and extend the rendering engine of Stride. ## Closing 🔗 We strongly recommend watching this live session, as it will help you gain a better understanding of Stride. .NET is becoming more and more relevant for a game engine, as evident with Stride. Don't hesitate to reach out to our community through the Discord server!

The Stride team is happy 🙌 to announce the release of our refreshed Stride website. We have been working on this for a while, and we are excited to share these updates with you and hope you enjoy the enhanced browsing experience. ## The Motivation for the Update 🔗 The Stride website has been around for some time ⌛. It was originally created using Jekyll. Over the years, we have added more content, but the website has not been updated for quite a while. Our main goal was to make the website future-proof and easy to maintain. We also wanted to improve the overall user experience and give it a more modern feel. ## What's New or Updated 🔗 * Improved consistency across pages, posts, and styling, offering an excellent reading experience * Enhanced content readability * Modern and simplified design * Updated static page generator: Eleventy 2.0 (previously Jekyll) * Bootstrap 5.3 (previously Bootstrap 3) * Font Awesome 6 (previously 4.4) * Removal of old, unnecessary code, such as AddThis, Disqus, JQuery, and JavaScript libraries * Improved website responsiveness (mobile, tablet, desktop) * Content review and minor corrections * Tags page * Archive page * Every single page was reviewed and updated 🤯 * Dark Theme (Experimental) * Search functionality now includes our documentation website * GitHub Wiki was enabled for content contributors, containing information about the website structure, how to add new content, and how to contribute. This new update will enable us to share more content with you faster and more easily. We will also be able to add more features and enhance the overall experience. __ The Disqus comment widget has been removed from the blog posts, as we would like to encourage our readers to use GitHub Discussion or Discord. We are considering integrating the GitHub Discussions with the blog posts. ## What's next 🔗 We will continue to improve the website and add more content. Additionally, we will be adding more features and further refining the overall experience. Our Stride website GitHub issue tracker is open for any suggestions or feedback. We encourage you to collaborate, create issues, and submit pull requests. ## Closing 🔗 We hope you like the updated website. With this new release, we would like to encourage our community to contribute as well. Your experiences, insights, and knowledge are invaluable, and we would love to showcase them on our blog. If you have a topic, tutorial, or success story you'd like to share, we invite you to get in touch. By contributing, you'll not only help others in the community but also gain visibility for your work and expertise. Let's work together to make the Stride community even more vibrant and enriching.