Rust game development. Ecosystem overview

Hello! I am developing a game on Rust and want to talk about it.

My first article will be useful for those who want to start making a game on Rust, but not sure which packages ( crates ) should be used and what generally happens in the Rust ecosystem for a game developer.

A small digression - why all this? Is there a finished X?

Impressed by this performance, I began to write my Haskell game engine. Far from going, but I wrote a render of models, simple lighting, a bit of web.

Haskell made it possible to take contracts out of checks in runtime to the level of the type system. Well, the rest of the things Carmack talks about - to be sure that the function does exactly what it declares in its type. To be a little closer to the present formal verification of our game code - that is, in theory, to have a guarantee of correct work without tests at all.

But, there were several problems with Haskell - it is rather slow for outputting 3D in real time. There was no community involved in playing games on it. There were not enough libraries for games.

With Rust, everything went much more fun.

In my opinion, Rust combines all the properties needed by game developers, in a very correct ratio:

• powerful but simple type system;

  
  

• abstractions are free by performance - no need to pay for those abstractions that you do not use explicitly;

  
  
• simple and safe multithreading;

And while it is very easy to write code, the language is small and simple.

Back to the ecosystem:

Work with windows:

Glutin - a growth alternative to GLFW , used in Servo , is actively developing. Creates windows on win / osx / linux / android. It still does not work on ios, someone wanted to do it, but since 2015 it is not audible about it.

And there are binders to non-plant libraries: glfw-rs rust-sdl2 rust-sfml ( site ). All three are alive and supported.

Graphic APIs:

It is possible to use directly OpenGL / DirectX / Vulkan , in addition, the site-specific graphics libraries have already been created.

Glium is a secure wrapper over OpenGL, in fact, mostly over OpenGL 3, OpenGL <4 and OpenGL ES are well supported. The author does not plan to deal with the support of all the tricks of the fourth version of OpenGL, he believes that then it is better to immediately take on Vulkan. It is developing quite slowly at the moment - the author is mainly engaged in his game on the volcano.

Nevertheless, PC glium copes with 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. Vulkano presentation is available here .
Gfx is a generic API without reference to a graphic backend. Now works on top of OpenGL and DirectX, Metal and Vulkan are soon planned. Developed more actively glium. With gl es and mobile devices at the moment everything is a little worse than in glium, but very active work is underway right now in this direction.

Gfx and Glium differ in their tasks - glium simply provides api to a stable opengl, but gfx is focused on its universal and type-safe api to the most modern graphic backends.

Kiss-3d is a small, simple graphics engine. Not rich in functionality, but this does not aspire. Allows you to create windows and draw graphic primitives. Looks supported, but active development is not noticed. On the other hand, it is already fully prepared, fulfilling its functions.

Ready 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 full piston, but each has a little piston" (“No Rust game, use most of the Piston, but most use some of it!”).

The main developer in recent months has been working exclusively on his Dyon scripting language and demo games on it ( asteroids ).

In the heap of PistonDevelopers repositories there is something almost ready, but, for the most part, it is all very fragmented and far from any practical use.

Amethyst is much younger than Piston, still far from its intended use, but it 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 is gone, but the community is very actively cutting further.

Mathematical Libraries:

Cgmath is used in both gfx and glium examples. Wants to be the main math library for games on Rust.
Nalgebra - used in ncollide and nphysics. Mostly used where ncollide / nphysics is needed.

And this and that works, all the basic operations are.

Glm-rs - as far as I know, was used before cgmath with nalgebra, just binding to the fairly well-known GLM.

Collision Search:

Collision-rs is a collision search system that uses cgmath. Created as part of cgmath. In contrast to the rest of the cgmath, so-so was accompanied and brought to a separate crate. Far from all the necessary functionality, the test coverage is so-so, but, on the other hand, built on cgmath, you don’t have to drag two different mathematical libraries.
ncollide is a nphsysics collision system that uses nalgebra. It develops actively, has a beautiful site . It is being 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/
A fairly popular idea for designing games, there are already ready-made implementations:

Specs ( https://github.com/slide-rs/specs ) are the only truly multi-threaded ecs. Quite actively developed, used in amethyst.
https://crates.io/keywords/ecs - a whole bunch of systems that existed before the specs, each with its own nuances, describe each - a topic for a separate article.

When I started specs was not there yet, and I wrote my bike .

Work with resources:

obj - growing implementation of .obj, works :)
Assimp - binding to assimp - a library that works with a bunch of 3D formats
image - rastov implementation of popular formats 2d. It works, but there is a nuance - in cargo there is no possibility to connect the binary / release version of the dependency to the debug build. Because of this, the debug Image opens a very long time for pictures in debug builds. There are no problems with release builds. We are waiting for cargo to learn how to use dependencies with other parameters.
stb-image - bindings to sishnoy library for working with pictures. In terms of functionality, it is analogous to image, but it solves the problem of debugging dependencies - even in debug builds, it works quickly, because the generic code is built with its own flags.
zip-rs - just zip archiver, compress resources.

Work with sound:

ears - just binding to OpenAl. I use it for the sounds - everything is fine.
vorbis - binding to vorbis.
rodio - higher level work with vorbis.

GUI:

With Gui things are not very. The perfect game gui library does not yet exist. However, there are:

Imgui - binding to imgui. Work great with glium. But sharpened for the developer's toolkit, does not support skins, it is inconvenient to type up non-standard 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 - there is a Piston, but already abandoned. In json, an animation graph is described, a bit similar to Uncan's Mecanim. Supports gpu-skinning. But, unfortunately, there are dependencies on both piston and gfx — it’s not so easy to integrate into a project on glium.

Physics:

Since I am making a game about physics, this is an important question for me. For rasta, there is only github.com/sebcrozet/nphysics .
Nphysics consists of nphysics2d and nphysics3d. For 2D, they say, there is enough, but in 3d it is not very good - up to the same Bullet as far as possible, it was necessary to finish quite a lot. However, the work goes and goes quite actively.
I want to use Bullet, but we are not waiting for the current version of the C API yet.

Tools:

cargo-apk is an add-on to cargo that allows you to create android apk file + library for working with the Android environment from code.
cargo-profiler - use valgrind through cargo.
hprof - frame profiler, not finding hprof, I wrote my own one, but worse - tinyprof . It is very convenient to watch what happens in each frame .

As an editor of scenes, materials and game entities, I use Blender. About this, if it will be interesting, I will tell in the next part. In general, I am satisfied, comfortable.

With the IDE, things are like this:

There is a racer , a separate project that provides editors with data for autocompletion and simplest 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' is already planned. This is the same racer, but with support in the compiler and more working.

The plug-ins for eclipse and visual studio can be fully debugged - walking along the steps, and so on.

You can see the results of a survey on popular IDE. The results are strange - the Ideevsky plugin (as far as I know) is one of the poorest in terms of functionality - it does not use a racer, it uses an ideological autocompet, which so far works even worse than a racer. But it is actively developing.

More information about the state of affairs can be found 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/hemat
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 destructible. We are still in pre-alpha, preparing for a public alpha, playtest. We are looking for people;)

Community:

Friendly growth gameddev community is always happy to answer questions in irc (# rust-gamedev) or in Russian-language gitter: gitter.im/ruRust/gamedev .