Window V1.0

Follow @PistonDeveloper at Twitter!

This is an announcement that the core library pistoncore-window has been stabilized. Version 1.0 is released!

The ecosystem has been upgraded (with help from Eco, as usual).

What this means to end-users and maintainers, is that the Piston ecosystem will be more stable from now on, with fewer version bumps.

Piston has been designed from the ground up to enable stability and modularity. Looking back, I am happy that the architecture has been delivering this promise very well:

  • To an end-user, using Piston should be like writing idiomatic Rust code (trait for Window etc.)
  • To a maintainer, using Piston should be independent on the OS platform or hardware

Special thanks to

These 12 people (including myself, bvssvni) are listed as authors of the Piston core:

  • bvssvni
  • Coeuvre
  • gmorenz
  • leonkunert
  • mitchmindtree
  • Christiandh
  • Apointos
  • ccgn
  • reem
  • TyOverby
  • eddyb
  • Phlosioneer

Stability and modularity

Most of the collaborative work in Rust Gamedev goes into standalone libraries which are shared among projects. Besides the 90% of code that goes into an average game, 10% is about stuff that one could call “game engine”. Out of this 10%, there is 9% which are independent libraries. Only the remaining 1% is a glue system for the ecosystem of libraries that orbit projects.

Piston is a glue system for game engines. It enables library maintainers to write code for targeting multiple game engines. Here, a “game engine” is defined as a set of libraries used to build a specific game.

The way people use Piston is that they can opt-out or work around almost everything. This is how it should feel like to end-users: It should be like writing Rust code. Rust has a standard library, but it is not necessary. In that way, Piston tries to follow idiomatic Rust.

Piston does not try to solve productivity problems with just one solution, because there is not one unique way to be productive. When I want to be productive, I write a Dyon api on top of a customized game engine. I created Dyon, so my love for it is biased, but I still use it on a daily basis. However, I also frequently develop customized domain-specific languages using Piston-Meta. Other people prefer other scripting languages or other techniques to stay productive. Most of these techiqnues do not require a lot of code.

Therefore, the primary objective of Piston is to provide stability and modularity.

Recommendations to new Rust gamedev developers

There is a saying “there are 50 game engines in Rust, but only 5 games”. This is not actually true, but it says something about a particular mindset. In reality, I have written over 50 small games, just for myself, but they are written in Dyon, not Rust. However, Dyon is written in Rust, so… it depends on how you count games.

The reason people say this is that most game engines in Rust are glue code designed to achieve productivity. Since people have different opinions and ways to think about productivity, you get many game engines. The people who make all these game engines, are probably the ones that do not use scripting for productivity. To people who like this kind of productivity style, I do not have particular recommendations, since there are so many good alternatives. Just pick one.

If you are making a game and you don’t have high requirements:

  • Just pick a game engine that suits your style of productivity
  • You can always switch game engine later

If you are making a game and have high requirements about features:

  • Bevy (ECS based, lots of plugins)
  • Fyrox (feature rich and includes a well designed editor)

If you are making a game and require highly customized architecture for your game engine:

  • Piston

Piston’s architecture helps you to modify the design and change it later.

If you want to ship a game and come from a C background:

  • Just use SDL2, write the code and ship it (:P)
  • Accelerate productivity by gradually importing libraries (e.g. use Piston’s SDL2 backend)

There are very few libraries in the Rust gamedev ecosystem that have reached stability. When you get into Rust, you take risks, so you have to trade these risks with other benefits.

One benefit is that in Rust there are usually fewer bugs per line of code compared to e.g. C++. This is because, not that C++ produces bugs, but that in C++ you have to ask for guidance from the compiler, while in Rust you get it by default.

Another benefit is that Rust concurrency is memory safe.

However, except from that, everybody knows that the choice is not about Rust vs C++, but which scripting language you will use to stay productive (:P).

Here are some:

Toward Piston 1.0

Follow @PistonDeveloper at Twitter!

Update: There is a Rust gamedev meetup in Oslo coming up:

https://www.meetup.com/Rust-Oslo/events/261774885/

Sadly, I’m on vacation at that time, but you can meet people from the Amethyst project. Happy coding!

About the Piston core

The Piston core is a set of libraries that defines a core abstraction for user inputs, window and event loop.

If you take a look at the dependency graph in the README, it might look a bit scary:

piston dependencies

In this post I will go through each library, explain what it does and describe the status of stability.

Serde

Serde is a library for serializing and deserializing Rust data structures.

The reason Serde is used by the Piston core, is to support:

  • Sending events over network
  • Store logs of events
  • Record and play back player input for testing and debugging

Today, there is no functionality built into the core for these features. The intention is to handle these cases in separate libraries, if necessary. Piston’s design philosphy is to move complexity away from the core, since it is easier to keep the ecosystem stable when the core is stable.

By using Serde, these libraries gets much easier to write later.

Status: 1.0 (stable)

Piston-Float

This is a set of traits to abstract over f64 and f32 in Rust.

Piston-Float was designed to stabilize Piston’s ecosystem in a time where we needed stability at the bottom of the dependency graph.

Before Piston-Float, we used numeric traits from Rust’s standard library. However, when Rust got close to 1.0, it was decided to move numeric traits into a separate library. At the time, these trait were put together with lots of unstable stuff. They were designed/changing to be more generic than for the primitive float types we needed. The need for stability, plus restricted requirements, made it easier to create a new library.

Status: 1.0 (stable)

Piston-Viewport

A viewport is a rectangle inside the window that sets up the coordinate system for a graphics API.

This library has a simple struct Viewport that stores viewport information. It is used to pass viewport information from render events to 2D graphics backends.

Piston’s 2D graphics library is designed to be decoupled from the core. You can use it without the core, or you can use the core without the 2D graphics libraries. By using a common viewport structure, it is easier to make these libraries work together.

Status: 1.0 (stable)

Bitflags

A Rust macro to generate structures that behave like a set of bitflags.

A set is a mathematical structure that supports operations like intersection, union, etc. Normally, a C-programmer uses some tricks with bit masks to do work with bitflags. However, in idiomatic Rust we like to keep things type safe, which is why this macro exists.

This macro is used by the structure for modifier keys in the core library for user input.

Status: 1.0 (stable)

PistonCore-Input

This library is separated from the others in the core, since a lot of libraries only need to know how to handle user input and do not need to know about the window or event loop abstractions.

For example, when you press a keyboard key or a click a mouse button, this information is stored in a structure that is defined in this library.

The same goes for gamepad or joystick events, touch events, render, update and idle events etc.

While designing the Piston core, we did some research about the problems of modelling user input. What we found was the following:

  • New hardware for user input is not widespread, because software does not support it
  • Software does not support new hardware, because it is not widespread

The way we solve this problem, is to not restrict software to a particular model, but to use traits when handling events. This is why this library contains a lot of event traits, in order to make libraries work with new hardware.

The current design has been kept unchanged for a long time. There are no unstable dependencies. Without further redesign, it is ready to be stabilized.

There might be a few changes in the future, before stabilization.

Status: 0.25 (unstable)

Shader-Version

A helper library for detecting and picking compatible shaders.

Graphics APIs, such as OpenGL, Vulcan, Metal, DirectX etc. comes with shader languages. The shader languages have their own version numbers, which works with various versions of the API.

To pick which shader to use can be tricky, so this library does this for you.

Today, only OpenGL/GLSL is supported by this library. It is because OpenGL was the primary graphics API used at the time of design. Besides, for newer graphics APIs, it is also common to use cross-compiling.

In the future, it is likely that the library becomes replaced by another in the core. New graphics APIs come out all the time, so it will be difficult to stabilize this library. Also, detecting and picking compatible shaders is not needed in the core, only graphics API versions.

Status: 0.3 (unstable)

PistonCore-Window

This library contains the window abstraction.

The most common usage is window backends for GLFW, SDL2, Glutin etc.

However, a window in Piston might be more abstract and higher level than a cross platform window API.

It can be a custom designed backend for server-client logic, or it can be a convenience wrapper, such as Piston-Window.

This library requires some changes before stabilization.

Status: 0.38 (unstable)

PistonCore-Event Loop

This library contains a game event loop.

The event loop supports fixed time step updates, extrapolated time for rendering, benchmark mode etc.

A common problem I see people have, is figuring out the right event loop settings for their game. The defaults are designed for a First-Person-Shooter, which is pretty bad for many other kinds of games and applications. In order to address this issue properly, some changes are needed.

Status 0.43 (unstable)

Piston

This library re-exports the core libraries. That’s all.

Status: 0.43 (unstable)

Notes

The Piston core has been in use for so long time, relatively unchanged, so it has not been much focus around it.

  • Most of the interests experienced people have are in various modular libraries, not in the core
  • Experienced people don’t think too much about the core, which makes it hard to see through the eyes of beginners

For example, I noticed that some projects uses Piston-Window in libraries. It is designed to be a convenience wrapper, not an abstraction. The Piston core is more suitable for generic libraries.

I tried to put information about this in various places, but not sure if it is efficient enough. This is a common problem because the project is so big: Even if something is documented somewhere, it does not necessarily mean people will see it.

Transitioning to Image-rs

Follow @PistonDeveloper at Twitter!

This blog is about the transition of image libraries from The Piston Project to a new organization: Image-rs

Why Image Libraries are Moving

Today, the transitioning of the popular image library to the new Image-rs will be completed.

This is the first of several libraries that be moved, which I and other maintainers feel belong under the new organization. Now that the main issues and concerns have been resolved for the image library, I expect that much less time is required to move other libraries.

There are several reasons these libraries are moving:

  • Better security
  • More focus
  • More activity

In addition to these important reasons, there is an opportunity for new people to lead.

Publishing Permissions

The permissions to publish on crates.io for these crates will move from the Publish team in The Piston Project to the Publish team under Image-rs.

I (bvssvni) plan to participate in the new organization as a contributor.

Today, crates.io requires private owners to add or remove other owners. For security reasons, my own owner permissions will be removed and replaced by the owners of Image-rs.

Owner and Leadership Transition

Previously, the image libraries were part of The Piston Project and therefore under supervision of myself (bvssvni).

Under the new organization, there are 3 active contributors to image libraries that will serve this role under the transition, in case anything unexpected happens (alphabetic order):

  • fintelia
  • HeroicKatora
  • theotherphil

Among those 3, HeroicKatora has been working on inviting policy for the new organization, which is important for setting a future direction of these projects.

Personal Comments on the Transition

Due to two recent occurences of suspicious activity, my focus has been on the security of The Piston Project. This has delayed other work and made me aware of how much time it takes to just run The Piston Project and AdvancedResearch.

  • People working on image libraries deserve the best working environment it is possible to make
  • Now fundamental image libraries are in place, The Piston Project should continue focus on research and experimenting
  • Security is not just important for safety, but also to reduce waste of time

It makes completely sense to me to move these libraries to a new organization.

The way it looks now for Image-rs, I am proud to be part of the new organization.
I hope that other people will feel the same and welcome the change.

Older Newer