How productivity is tested in Piston


Piston is meant to be used in:

  • commercial production for gamedev
  • interactive applications
  • animation software

In addition there are fields that it might be useful:

  • computer science education
  • interactive prototyping
  • user interfaces for embedded hardware
  • robotics

To be an attractive alternative in these areas, there are some requirements to productivity.

Goals of productivity

5 min to get started

It should not take more than 5 min from starting a new project until you have a window on the screen.
This is tested occasionally using a stop watch.

Status: Done

1 hour of coding 2D before you run into parts that require planning

A very simple game should be possible to do within one hour.
I have done a few tests and it is close, but running into problems when you need configuration/content.
Done some iterations on the design of Piston-Meta to make this smoother.

Status: Unfinished/Untested

Parse custom text formats with a few lines of code

Data driven design is important. After all, most of the content in a game is data, not code.
To make this as easy as possible, I have designed a parsing meta language for text documents.
You type a few rules in a text document that tells how to read another document.
The rules generate a tree structure stored as Vec<Range<MetaData>>.
Strings are identical to JSON, so you can write a JSON parser that validates the structure of your files.

It can also be used to parse different versions of the same format, making it easy to keep
backward compatibility in an application.

Learning the meta language, and converting from meta data to Rust structures is what requires most effort now.
This could be made easier with some tutorials, and add some macros for converting.

Because text documents are important, we have to test the usage over time and during maintenance of a project. We use this library in several projects, such as Eco and Dyon.

Link: Piston-Meta

Status: Mostly done

User interface design

Interactive applications and editors requires an user interface (UI) framework.
Mitchell Nordine has been the chief maintainer on an immediate UI framework addressing these needs.
He has been testing this for various audio processing applications.
One goal is to able to combine the UI with 2D and 3D in Piston.

This is tested in various projects, and we have profiled and benchmarked it.
It is expected that the performance will improve over time as we get more experience.

Here we could use a stop watch to measure productivity for some simple cases.
A person is given a specification of an user interface, and then measure how long it takes to build.

Link: Conrod

Status: Unfinished

Other projects

The ecosystem is in its early stages, so there are a lot of libraries/editors we would like to have.
Rust is a new language, so figuring out the way to be most productive requires some experimenting.


Piston has a core for interfacing with generic libraries.
It is possible to swap a window backend with another.
We test the consistency using the “user_input” example in the piston-examples repo.

Our goal is that it should not really matter which window API that runs under the hood.
Applications should feel and behave similar across platforms.
When new hardware opens up new possibilities, we will try to adopt the existing libraries or develop new ones.
You should be able to run Piston anywhere where Rust is working.

One of the last things to make Piston fully portable is a pure Rust alternative to FreeType.
Luckily, this is being worked on outside PistonDevelopers, so we will probably not have to do this ourselves.