Added links
This commit is contained in:
Родитель
50e02ac774
Коммит
7ee21f8e46
|
@ -43,11 +43,11 @@ This post will focus on some of the more notable FOSS game engines: Bevy, Godot,
|
|||
* 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) 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 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 the most popular Rust-based game engine, Bevy offers a rich code-only development environment (an editor is coming) 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)](https://bevyengine.org/learn/quick-start/getting-started/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 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 systems 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.
|
||||
As established with Bevy’s use of ECS, the engine’s developers care deeply about modularity. [The engine’s plugin system](https://bevyengine.org/learn/quick-start/getting-started/plugins/) 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 systems 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 the community 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.
|
||||
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 the community to use and share](https://bevyengine.org/assets/). 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#
|
||||
|
@ -59,9 +59,9 @@ Godot has the largest and most active community among all the modern FOSS game e
|
|||
|
||||
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, Python, Swift, Lua, and Java. 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 in the same project.
|
||||
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](https://godot-rust.github.io/), [Go](https://github.com/grow-graphics/gd), [Swift](https://github.com/migueldeicaza/SwiftGodot), and [Haxe](https://hxgodot.github.io/). 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 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 in 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 tinker with 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.
|
||||
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 in Unity or Unreal Engine, [Godot provides the option to customize the editor to your liking](https://docs.godotengine.org/en/stable/tutorials/plugins/editor/making_plugins.html). 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 tinker with 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
|
||||
|
@ -71,11 +71,11 @@ Work in an editor long enough and you will probably want to tinker with it. For
|
|||
|
||||
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 online features to use Amazon Web Services. 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.
|
||||
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](https://docs.o3de.org/docs/user-guide/scripting/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. It is possible to swap out features like the physics engine, for example, allowing developers to choose between PhysX 4, PhysX 5, or another solution entirely, custom or commercial. The modularity afforded to 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 they want and in whatever combination best fits their needs.
|
||||
O3DE modularizes its engine by breaking down major components into plugins called [Gems](https://www.docs.o3de.org/docs/user-guide/gems/). This is the paradigm through which O3DE manages all its features and plugins. It is possible to swap out features like the physics engine, for example, allowing developers to choose between PhysX 4, PhysX 5, or another solution entirely, custom or commercial. The modularity afforded to 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 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 the Atom renderer. 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.
|
||||
With [the Atom Renderer](https://www.docs.o3de.org/docs/atom-guide/), 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 the Atom renderer. 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#, and Visual Basic
|
||||
|
@ -83,11 +83,11 @@ With the Atom Renderer, the engine’s rendering system, O3DE strives to provide
|
|||
* Development: Windows
|
||||
* Target: Windows, 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.
|
||||
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](https://stride3d.github.io/stride-community-toolkit/manual/code-only/index.html) 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, or 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 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, or other platforms into Stride, enhancing your workflow. Stride is modular enough that [sections of Stride are available as standalone NuGet packages](https://www.nuget.org/profiles/Stride). 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 objects concurrently in a scene with little effort. Stride provides the space to explore multi-threading and have fun with it.
|
||||
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](https://github.com/Nicogo1705/Stride.BepuPhysics), it becomes possible to have tens of thousands of 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.
|
||||
|
||||
|
@ -103,6 +103,6 @@ You are not simply a Godot developer, Bevy developer, O3DE developer, Stride dev
|
|||
|
||||
## Acknowledgments
|
||||
|
||||
As a general practice, I think it’s good to recognize everyone who helps you put something together, no matter how big or small. This article would not have been possible without the input of contributors and users involved in these communities. 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, and Pāvels Nadtočajevs. (tentatively adding more)
|
||||
As a general practice, I think it’s good to recognize everyone who helps you put something together, no matter how big or small. This article would not have been possible without the input of contributors and users involved in these communities. I appreciate all the folks who were kind and patient enough to fact-check me and provide their feedback, including [Vaclav Elias](https://github.com/VaclavElias), [Joreyk](https://github.com/IXLLEGACYIXL), [Doprez](https://github.com/Doprez/), [Judah Perez](https://www.inconsistent.software/), [Clay John](https://github.com/clayjohn), [Adam Scott](https://github.com/adamscott), [Fredia Huya-Kouadio](https://github.com/m4gr3d), and [Pāvels Nadtočajevs](https://github.com/bruvzg). (tentatively adding more)
|
||||
|
||||
Also, thank you to [Melt/Ed](https://twitter.com/meltt_ed) for creating the feature image.
|
||||
Last but not least, thank you to [Melt/Ed](https://twitter.com/meltt_ed) for creating the feature image.
|
Загрузка…
Ссылка в новой задаче