I believe it is time to make the Piston ecosystem work with Winit and WGPU as the default backends.

Piston’s modular architecture allowed testing multiple backends, but this was before Winit and WGPU, which are now reasonable APIs and relatively stable. We’ll continue to support the other backends, but these particular backends will be our top priority.

Once this transition is made, I want to improve this library to include more batteries, e.g. Audio (Kira) and possibly Dyon scripting (behind feature flags). We could also integrate Rapier2D and Rapier3D. Possibly Bevy’s ECS too. I want reasonable default libraries, but I also don’t want to lock users into a particular choice of architecture. We’ll support multiple paradigms of game development.

I also have some editor plans for the Turbine game engine using a server/client architecture, which might be integrated with PistonWindow. This means you can work on the game as normal with Rust code, but also host a server for the editor that enables you to see the world and make changes on the fly. We might want servers for Rust coding too in the same editor, supporting the Rust Language server, Dyon syntax, various level editors, plus auto generated configuration tools based on Dyon data (it’s like JSON but for Dyon). Due to Piston-Meta, we can also support JSON, TOML and other human readable formats.

This is part of my dream of Additive computing, a visionary architecture to utilize all hardware in your home. A full distribution chain for Apps that can be accessed instantly, without pre-installation. The basic idea is that we use the game engine as a local distribution platform. You just plug in new devices. It will run thin-clients first time on new devices and do optional background installation. You will be able to use multiple devices at the same time, accessing the same virtual worlds, using the server/client architecture of the Turbine game engine.

My main interest is in Animation. I plan to use Turbine-Process3D for content generation and on-demand ray tracing. I want to combine this with production renderers such as Renderman and Blender workflow integration. Turbine will be designed from scratch for content production, not primarily for running games. However, the content production pipeline might also be used for games.

Eco will be updated and perhaps with a visual interface for maintenance of large code bases. In the long term, AI integration.

The overall idea is:

• PistonWindow (Winit + WGPU + batteries included) as the default Piston game framework
• Turbine (content production, multi-device utilization, editor) as the visual game engine system
• Eco (large code base maintenance and AI developer assistance)

Dyon and Piston-Meta will be heavily used for system integration. This makes it easier, since it’s a special purpose scripting language for game development that we can control and add supporting features to. However, it will be optional and not required when shipping games. We won’t put restrictions on the platform targets.