Game development on Rust. Ecosystem Overview
Hello! I am developing a game on Rust and want to talk about it.
My first article will be useful to those who want to start making a game in Rust, but are not sure which packages ( crates ) are worth using and what is going on in the Rust ecosystem for a game developer.
A small digression - why all this? Is there a ready X?
Impressed by this performance here, I started writing my game engine on Haskell. Things didn’t go far, but I wrote a render model, simple lighting, a bit of network.
Haskell made it possible to move contracts from runtime checks to the type system. Well, the rest of the things Carmack talks about is to be sure that the function does exactly what it declares in its type. To be a little closer to the real formal verification of our game code - that is, in theory, to have a guarantee of correct operation without any tests at all.
But, with Haskell there were several problems - for 3D output in real time it is rather slow. There was no community involved in games on it. There were not enough libraries needed for games.
With Rust, everything went a lot more fun.
In my opinion, Rust combines all the properties needed by game developers in a very correct ratio:
powerful, but at the same time simple type system;
abstractions are free in performance - there is no need to pay for those abstractions that you do not use explicitly;
- Simple and secure multithreading
And while it is very easy to write code on it, the language is small and simple.
Back to the ecosystem:
Work with windows:
Glutin - a rast -alternative to GLFW , is used in Servo , is actively developing. Creates windows on win / osx / linux / android. It still doesn’t work on ios, someone wanted to do it, but since 2015 no one has heard about this one.
And there are binders for non-rasta libraries: glfw-rs rust-sdl2 rust-sfml ( site ). All three are alive and supported.
Graphics APIs:
It is possible to use OpenGL / DirectX / Vulkan directly ; moreover, raster-specific graphic libraries have already been created.
Glium - a secure wrapper over OpenGL, in fact - mainly over OpenGL 3, OpenGL <4 and OpenGL ES are well supported. The author does not plan to deal with all the tricks of the fourth version of OpenGL, he believes that then it is better to immediately take on Vulkan. It is developing at the moment rather slowly - the author mainly deals with his game on the volcano.
Nevertheless, on a PC, glium manages its functions - it is really convenient to write OpenGL code on it.
There is a whole textbook . It is not complete, but very useful at first.
Vulkano is an analogue of glium, but for Vulkan . It is he who is the author of glium, the development is very active. The presentation of vulkano is available here .
Gfx is a universal API without a graphic backend. Now it works on top of OpenGL and DirectX, and Metal and Vulkan are planned soon . It is being developed more actively by glium. With gl es and mobile devices, at the moment everything is a little worse than in glium, but very active work is being carried out right now in this direction.
Gfx and Glium differ in their tasks - glium simply provides an api for stable opengl, gfx is focused on its versatile and type-safe api for the most advanced graphic backends.
Kiss-3d is a small, simple graphics engine. Not rich in functionality, but it does not strive for this. Allows you to create windows and draw graphic primitives. It looks supported, but no active development has been noticed. On the other hand - it is already completely ready, it performs its functions.
Ready-made graphics engines:
Piston PistonDevelopers - in fact, this is a huge number of projects united by a common goal - to become, someday, a modular game engine. “Not every project has a piston in its entirety, but each has a little piston” (“No Rust game project uses most of Piston, but most uses some of it!”).
The main developer in recent months exclusively deals with his scripting language Dyon and demo games on it ( asteroids ).
There is something almost ready in the PistonDevelopers repository heap, but, for the most part, it's all very fragmented and far from some practical use.
Amethyst is much younger than Piston, is still far from its intended use, but is actively developing. Design inspired by BitSquid / Stingray (from Autodesk). There is already a graphic pipeline, forward / deffered rendering, asset pipeline, configuration via yaml. The main developer has disappeared, but the community is very actively sawing further.
Math Libraries:
Cgmath - used in the examples of both gfx and glium. He wants to become the main math library for games in Rust.
Nalgebra - Used in ncollide and nphysics. Mostly used where ncollide / nphysics are needed.
And this and that works, all the basic operations are.
Glm-rs - as far as I know, it was used before cgmath with nalgebra, just bindings to the quite famous GLM.
Collision Search:
Collision-rs - collision search system, uses cgmath. Created as part of cgmath. Unlike the rest, cgmath was accompanied by itself and was placed in a separate crate. Not all the necessary functionality is implemented, the test coverage is so-so, but, however, built on cgmath, you do not need to drag two different mathematical libraries.
ncollide is a collision system from nphsysics using nalgebra. It is developing actively, has a beautiful site . Tested and developed by all nphysics users.
Entity-component-system:
https://shaneenishry.com/blog/2014/12/27/misconceptions-of-component-based-entity-systems/
http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/
Quite a popular idea for designing games, there are already ready-made ones raster implementations:
Specs (https://github.com/slide-rs/specs ) is the only truly multi-threaded ecs. Actively enough developed, used in amethyst.
https://crates.io/keywords/ecs - a whole bunch of systems that existed before specs, each with its own nuances, describing each is a topic for a separate article.
When I started the specs were not there yet, and I wrote my bike .
Work with resources:
obj - rastovy implementation .obj, works :)
Assimp - binders to assimp - the library working with a bunch of 3D formats
image - rastovy implementation of popular formats 2d. It works, but there is a nuance - in cargo there is no way to connect the binary / release version of the dependency to the debug build. Because of what debugging Image, it takes a very long time to open pictures in debug assemblies. There are no problems with release builds. We are waiting for cargo to learn how to use dependencies with other parameters.
stb-image - binders to the image library system library. In terms of functionality, it’s an analogue of image, but it solves the problem of debugging dependencies - even in debug builds it works quickly because the code is assembled with its own flags.
zip rs - just a zip archiver, compress resources.
Work with sound:
ears are just bindings for OpenAl. I use it, for sounds - everything is fine.
vorbis - bindings to vorbis.
rodio is a higher level job with vorbis.
GUI:
With gooey things are not very. There is no perfect gaming library yet. However, there are:
Imgui - imgui bindings. Works great with glium. But it is ground for developer tools, does not support skins, it is inconvenient to make custom windows.
Awesomium awesomium-rs is expensive for non-indies, only the ancient version has a C API. But it works fast enough, api is convenient.
Skeletal animation:
skeletal_animation - Piston has it, but it’s already abandoned. Json describes an animation graph a bit like Unity's Mecanim. Supports gpu skinning. But, unfortunately, there are dependencies on both piston and gfx - it is not so easy to integrate into a project on glium.
Physics:
Since I make a game about physics, this is an important question for me. There is only github.com/sebcrozet/nphysics for rasta .
Nphysics consists of nphysics2d and nphysics3d. For 2D, they say, it’s enough, but in 3D it’s not very - to the same Bullet is still far in capabilities, I had to add quite a lot. However, work is going on and going quite actively.
I would like to use Bullet, but to the current version of the C API not yet, we are waiting .
Tools:
cargo-apk - addition to cargo, which allows you to create android apk file + library for working with the Android environment from the code.
cargo-profiler - using valgrind via cargo.
hprof - frame profiler, not finding hprof I wrote my same, but worse - tinyprof . It’s very convenient to watch what happens in each frame .
As an editor of scenes, materials and game entities, I use Blender. This, if it will be interesting, I will tell in the next part. In general - I am satisfied, comfortable.
With the IDE, things are as follows:
There is racer , a separate project that provides editors with data for autocompletion and simple navigation. In terms of functionality, it still does not even reach ghc-mod. There are plugins for all popular editors (Vim, Emacs, Atom, VS Code, etc.).
A full-fledged ide-backend 'Oracle' has already been planned. This is the same racer, but with compiler support and more working.
Plugins for eclipse and visual studio can be fully debugged - walking the steps, etc.
You can see the survey results for the popular IDEs. The results are strange - the Idea plugin (as far as I know) is one of the poorest in functionality - it does not use racer, it uses the Idea autocomplete, which so far works even worse than racer. But it is actively developing.
Read more about the state of affairs here .
Open games in development:
https://github.com/bfops/playform
https://github.com/ozkriff/zoc
https://github.com/kvark/vange-rs
https://github.com/PistonDevelopers/hematite
https://github.com/kvark/claymore
https://github.com/PistonDevelopers/piston/wiki/Games-Made-With-Piston
Our game:
At the beginning of the article, the video gameplay of our game is a network shooter with synchronous destructibility. We are in pre-alpha so far, preparing for public alpha, playtests. We are looking for people;)
Community:
The friendly rust-gamedev community is always happy to answer questions in irc (# rust-gamedev) or in the Russian-language gitter: gitter.im/ruRust/gamedev .
