Piston Developers 🍿🥤🐸
@pistondeveloper.bsky.social
A modular game engine written in Rust https://piston.rs
Research branch: https://advancedresearch.github.io
Discord (Piston): https://discord.gg/TkDnS9x
Discord (AdvancedResearch): https://discord.gg/JkrhJJRBR2
Research branch: https://advancedresearch.github.io
Discord (Piston): https://discord.gg/TkDnS9x
Discord (AdvancedResearch): https://discord.gg/JkrhJJRBR2
There is a very different philosophy behind Piston than the one behind Unity and Unreal. While Unity and Unreal have their own issues, they have been tested in production of AAA games.
Developers know approximately what to expect from Unity and Unreal. These engines are popular: Predictable.
Developers know approximately what to expect from Unity and Unreal. These engines are popular: Predictable.
November 12, 2025 at 11:34 PM
There is a very different philosophy behind Piston than the one behind Unity and Unreal. While Unity and Unreal have their own issues, they have been tested in production of AAA games.
Developers know approximately what to expect from Unity and Unreal. These engines are popular: Predictable.
Developers know approximately what to expect from Unity and Unreal. These engines are popular: Predictable.
Sadly, at the moment we don't have any game engines in Rust that are on pair with the state of the art, like Unity and Unreal. The vast majority of games are developed in these two engines.
It might take 10 years to get there. Maybe it will get faster with AI.
Unity and Unreal are not like Piston.
It might take 10 years to get there. Maybe it will get faster with AI.
Unity and Unreal are not like Piston.
November 12, 2025 at 11:31 PM
Sadly, at the moment we don't have any game engines in Rust that are on pair with the state of the art, like Unity and Unreal. The vast majority of games are developed in these two engines.
It might take 10 years to get there. Maybe it will get faster with AI.
Unity and Unreal are not like Piston.
It might take 10 years to get there. Maybe it will get faster with AI.
Unity and Unreal are not like Piston.
Some people prefer walking. They like to take it slow. People who work on the their own game engines, do it usually for fun and for the coding adventure.
Other people want a train or an airplane. They need to go far or carry with them a lot of weight. So, you use a game engine that fits your needs.
Other people want a train or an airplane. They need to go far or carry with them a lot of weight. So, you use a game engine that fits your needs.
November 12, 2025 at 11:27 PM
Some people prefer walking. They like to take it slow. People who work on the their own game engines, do it usually for fun and for the coding adventure.
Other people want a train or an airplane. They need to go far or carry with them a lot of weight. So, you use a game engine that fits your needs.
Other people want a train or an airplane. They need to go far or carry with them a lot of weight. So, you use a game engine that fits your needs.
It takes some effort to learn to use MVC efficiently. However, once you've learned it, it's like riding a bike.
A bike isn't the best way to get from A to B in all cases. However, you know that a bike won't cost you a lot and you will get there in predictable time.
A bike isn't the best way to get from A to B in all cases. However, you know that a bike won't cost you a lot and you will get there in predictable time.
November 12, 2025 at 11:25 PM
It takes some effort to learn to use MVC efficiently. However, once you've learned it, it's like riding a bike.
A bike isn't the best way to get from A to B in all cases. However, you know that a bike won't cost you a lot and you will get there in predictable time.
A bike isn't the best way to get from A to B in all cases. However, you know that a bike won't cost you a lot and you will get there in predictable time.
Just like Rust has a higher learning curve than other programming languages, Piston has a higher learning curve. Why? Because programming in Piston is basically Rust with Model-View-Controller (MVC) patterns.
MVC a pattern that worked in the industry since the 1970s.
As predictable as it gets.
MVC a pattern that worked in the industry since the 1970s.
As predictable as it gets.
November 12, 2025 at 11:23 PM
Just like Rust has a higher learning curve than other programming languages, Piston has a higher learning curve. Why? Because programming in Piston is basically Rust with Model-View-Controller (MVC) patterns.
MVC a pattern that worked in the industry since the 1970s.
As predictable as it gets.
MVC a pattern that worked in the industry since the 1970s.
As predictable as it gets.
Once you learn the difference between convex and concave polygons, you have a choice:
1. Use Piston2D-Graphics to get an advantage of your knowledge
2. Continue to use path rendering with no advantage
What you've learn doesn't help you, because of the extra abstraction.
1. Use Piston2D-Graphics to get an advantage of your knowledge
2. Continue to use path rendering with no advantage
What you've learn doesn't help you, because of the extra abstraction.
November 12, 2025 at 11:21 PM
Once you learn the difference between convex and concave polygons, you have a choice:
1. Use Piston2D-Graphics to get an advantage of your knowledge
2. Continue to use path rendering with no advantage
What you've learn doesn't help you, because of the extra abstraction.
1. Use Piston2D-Graphics to get an advantage of your knowledge
2. Continue to use path rendering with no advantage
What you've learn doesn't help you, because of the extra abstraction.
Path rendering adds another level of abstraction where there are hidden costs. You can not longer reason easily about the performance of convex polygons.
That hidden cost means I have to spend more thinking about the tool. It's a higher learning curve to learn the difference, yes.
That hidden cost means I have to spend more thinking about the tool. It's a higher learning curve to learn the difference, yes.
November 12, 2025 at 11:19 PM
Path rendering adds another level of abstraction where there are hidden costs. You can not longer reason easily about the performance of convex polygons.
That hidden cost means I have to spend more thinking about the tool. It's a higher learning curve to learn the difference, yes.
That hidden cost means I have to spend more thinking about the tool. It's a higher learning curve to learn the difference, yes.
I can just use a library when I need concave polygons. I know it will be slower because it needs an extra triangulation step, but I can easily feed this into Piston2D-Graphics.
The key here is that the design is predictable. It doesn't have hidden costs.
Many people are used to path rendering.
The key here is that the design is predictable. It doesn't have hidden costs.
Many people are used to path rendering.
November 12, 2025 at 11:17 PM
I can just use a library when I need concave polygons. I know it will be slower because it needs an extra triangulation step, but I can easily feed this into Piston2D-Graphics.
The key here is that the design is predictable. It doesn't have hidden costs.
Many people are used to path rendering.
The key here is that the design is predictable. It doesn't have hidden costs.
Many people are used to path rendering.
For example, Piston2D-Graphics doesn't support concave polygons. It doesn't have a path renderer.
90% of my time, I use convex polygons.
So, when I know I'll only need convex polygons, I know it will work. It's a very simple constraint to think about.
There are libraries for concave polygons.
90% of my time, I use convex polygons.
So, when I know I'll only need convex polygons, I know it will work. It's a very simple constraint to think about.
There are libraries for concave polygons.
November 12, 2025 at 11:15 PM
For example, Piston2D-Graphics doesn't support concave polygons. It doesn't have a path renderer.
90% of my time, I use convex polygons.
So, when I know I'll only need convex polygons, I know it will work. It's a very simple constraint to think about.
There are libraries for concave polygons.
90% of my time, I use convex polygons.
So, when I know I'll only need convex polygons, I know it will work. It's a very simple constraint to think about.
There are libraries for concave polygons.
The more time I spend thinking about tools, the less time I have to do other things. When tools are not easy to predict, I have to spend more time thinking about them.
I think the same way about Piston: You know what to expect. There are things that are hard to do in Piston, yes.
I think the same way about Piston: You know what to expect. There are things that are hard to do in Piston, yes.
November 12, 2025 at 11:12 PM
The more time I spend thinking about tools, the less time I have to do other things. When tools are not easy to predict, I have to spend more time thinking about them.
I think the same way about Piston: You know what to expect. There are things that are hard to do in Piston, yes.
I think the same way about Piston: You know what to expect. There are things that are hard to do in Piston, yes.
However, after you have won against the Rust compiler, you know that the code will work again. There are few things that can go wrong and you can usually spot them by looking at warnings.
That's why I use Rust: It's predictable in its own way.
I don't want to use tools that are hard to predict.
That's why I use Rust: It's predictable in its own way.
I don't want to use tools that are hard to predict.
November 12, 2025 at 11:10 PM
However, after you have won against the Rust compiler, you know that the code will work again. There are few things that can go wrong and you can usually spot them by looking at warnings.
That's why I use Rust: It's predictable in its own way.
I don't want to use tools that are hard to predict.
That's why I use Rust: It's predictable in its own way.
I don't want to use tools that are hard to predict.
What makes Dyon more enjoyable to write code in?
I think it is predictability. You know what the future is going to look like, because the tool you use is behaving reliably the way you expect it to do.
In Rust, you get bombarded with things you need to fix that might seem surprising.
I think it is predictability. You know what the future is going to look like, because the tool you use is behaving reliably the way you expect it to do.
In Rust, you get bombarded with things you need to fix that might seem surprising.
November 12, 2025 at 11:08 PM
What makes Dyon more enjoyable to write code in?
I think it is predictability. You know what the future is going to look like, because the tool you use is behaving reliably the way you expect it to do.
In Rust, you get bombarded with things you need to fix that might seem surprising.
I think it is predictability. You know what the future is going to look like, because the tool you use is behaving reliably the way you expect it to do.
In Rust, you get bombarded with things you need to fix that might seem surprising.
You use `mut` in front of mutable arguments.
For example, `push(mut my_array, a)` inserts `a` into `my_array`.
It's easy to read and the `mut` is part of the function name: `push(mut,_)`.
Things that are difficult to understand in Rust, are easy to understand in Dyon.
For example, `push(mut my_array, a)` inserts `a` into `my_array`.
It's easy to read and the `mut` is part of the function name: `push(mut,_)`.
Things that are difficult to understand in Rust, are easy to understand in Dyon.
November 12, 2025 at 11:06 PM
You use `mut` in front of mutable arguments.
For example, `push(mut my_array, a)` inserts `a` into `my_array`.
It's easy to read and the `mut` is part of the function name: `push(mut,_)`.
Things that are difficult to understand in Rust, are easy to understand in Dyon.
For example, `push(mut my_array, a)` inserts `a` into `my_array`.
It's easy to read and the `mut` is part of the function name: `push(mut,_)`.
Things that are difficult to understand in Rust, are easy to understand in Dyon.
If you like Rust, then use Rust!
I find it easier to understand Rust after developing Dyon, because Dyon has a simpler lifetime checker and no borrow checker. Most of the time, you just add a `clone(..)` when needed.
There are no `&` or `&mut` in Dyon. No pointers.
I find it easier to understand Rust after developing Dyon, because Dyon has a simpler lifetime checker and no borrow checker. Most of the time, you just add a `clone(..)` when needed.
There are no `&` or `&mut` in Dyon. No pointers.
November 12, 2025 at 11:02 PM
If you like Rust, then use Rust!
I find it easier to understand Rust after developing Dyon, because Dyon has a simpler lifetime checker and no borrow checker. Most of the time, you just add a `clone(..)` when needed.
There are no `&` or `&mut` in Dyon. No pointers.
I find it easier to understand Rust after developing Dyon, because Dyon has a simpler lifetime checker and no borrow checker. Most of the time, you just add a `clone(..)` when needed.
There are no `&` or `&mut` in Dyon. No pointers.
I don't care that much what people think about Piston or Dyon. With other words, I don't do what I do every day, because of what other people think about what I'm doing. I do it because I want to do it.
It is kind of strange to think about peer pressure to use Rust. Why not use a language you like?
It is kind of strange to think about peer pressure to use Rust. Why not use a language you like?
November 12, 2025 at 11:00 PM
I don't care that much what people think about Piston or Dyon. With other words, I don't do what I do every day, because of what other people think about what I'm doing. I do it because I want to do it.
It is kind of strange to think about peer pressure to use Rust. Why not use a language you like?
It is kind of strange to think about peer pressure to use Rust. Why not use a language you like?
The main reason I use Rust is because of the time I don't have to program. This time, I can spend on doing other things.
I love writing code in Dyon. Why? Because it is mentally relaxing. Dyon has a very different design philosophy than Rust.
Rust + Dyon is better combo than either one alone.
I love writing code in Dyon. Why? Because it is mentally relaxing. Dyon has a very different design philosophy than Rust.
Rust + Dyon is better combo than either one alone.
November 12, 2025 at 10:54 PM
The main reason I use Rust is because of the time I don't have to program. This time, I can spend on doing other things.
I love writing code in Dyon. Why? Because it is mentally relaxing. Dyon has a very different design philosophy than Rust.
Rust + Dyon is better combo than either one alone.
I love writing code in Dyon. Why? Because it is mentally relaxing. Dyon has a very different design philosophy than Rust.
Rust + Dyon is better combo than either one alone.
I don't care about how many people use Piston.
What I care about, is how I spend my days.
Since there are fewer bugs in Rust, I can spend more time walking in the forest.
That why I use Rust. It's not because I want to program in it. I don't want to sit in front of the computer and use Rust.
What I care about, is how I spend my days.
Since there are fewer bugs in Rust, I can spend more time walking in the forest.
That why I use Rust. It's not because I want to program in it. I don't want to sit in front of the computer and use Rust.
November 12, 2025 at 10:50 PM
I don't care about how many people use Piston.
What I care about, is how I spend my days.
Since there are fewer bugs in Rust, I can spend more time walking in the forest.
That why I use Rust. It's not because I want to program in it. I don't want to sit in front of the computer and use Rust.
What I care about, is how I spend my days.
Since there are fewer bugs in Rust, I can spend more time walking in the forest.
That why I use Rust. It's not because I want to program in it. I don't want to sit in front of the computer and use Rust.
When I read about people going back to C++ or C# after using Rust for gamedev, I know they don't do it superficially. They might really like Rust and the community.
The problem? They don't feel comfortable working with a game engine that is unpredictable.
The problem? They don't feel comfortable working with a game engine that is unpredictable.
November 12, 2025 at 10:48 PM
When I read about people going back to C++ or C# after using Rust for gamedev, I know they don't do it superficially. They might really like Rust and the community.
The problem? They don't feel comfortable working with a game engine that is unpredictable.
The problem? They don't feel comfortable working with a game engine that is unpredictable.
The higher cost of learning Piston is the cost you pay in the long run. It's higher because it's predictable. Some other game engines have hidden costs, which make them seem cheaper than Piston in comparison.
Some developers swap game engines when they discover these hidden costs.
Some developers swap game engines when they discover these hidden costs.
November 12, 2025 at 10:45 PM
The higher cost of learning Piston is the cost you pay in the long run. It's higher because it's predictable. Some other game engines have hidden costs, which make them seem cheaper than Piston in comparison.
Some developers swap game engines when they discover these hidden costs.
Some developers swap game engines when they discover these hidden costs.
Piston's main motivation is to reduce costs for developers. That's why we are so careful with modular core libraries and stability, so developers know they can predict in advance the cost to maintain their projects.
It's harder to learn yes, but there is a good reason for it.
It's harder to learn yes, but there is a good reason for it.
November 12, 2025 at 10:43 PM
Piston's main motivation is to reduce costs for developers. That's why we are so careful with modular core libraries and stability, so developers know they can predict in advance the cost to maintain their projects.
It's harder to learn yes, but there is a good reason for it.
It's harder to learn yes, but there is a good reason for it.
You want players to want to figure out the mental worlds of your characters. That's why people produce TV series.
That's how you build a franchise. You want players to come back to playing your games. It's the experience that you give them.
Now, how does this fit with Piston's philosophy?
That's how you build a franchise. You want players to come back to playing your games. It's the experience that you give them.
Now, how does this fit with Piston's philosophy?
November 12, 2025 at 10:42 PM
You want players to want to figure out the mental worlds of your characters. That's why people produce TV series.
That's how you build a franchise. You want players to come back to playing your games. It's the experience that you give them.
Now, how does this fit with Piston's philosophy?
That's how you build a franchise. You want players to come back to playing your games. It's the experience that you give them.
Now, how does this fit with Piston's philosophy?
First we need a way to save code on the MVC pattern.
The developer might spend years figuring out the best Shader design they can use to produce a certain kind of entertainment. This part is usually secret. You keep your Shader secret, because it's the "soul" of your game.
The developer might spend years figuring out the best Shader design they can use to produce a certain kind of entertainment. This part is usually secret. You keep your Shader secret, because it's the "soul" of your game.
November 12, 2025 at 10:38 PM
First we need a way to save code on the MVC pattern.
The developer might spend years figuring out the best Shader design they can use to produce a certain kind of entertainment. This part is usually secret. You keep your Shader secret, because it's the "soul" of your game.
The developer might spend years figuring out the best Shader design they can use to produce a certain kind of entertainment. This part is usually secret. You keep your Shader secret, because it's the "soul" of your game.
If we are just playing animations for a pre-generated character, then we don't need a Shader at all.
The entire point with the Shader is that it can help us fine tune the balance of control needed to focus compute on producing reactions. We need pattern extraction, but also coherence.
The entire point with the Shader is that it can help us fine tune the balance of control needed to focus compute on producing reactions. We need pattern extraction, but also coherence.
November 12, 2025 at 10:36 PM
If we are just playing animations for a pre-generated character, then we don't need a Shader at all.
The entire point with the Shader is that it can help us fine tune the balance of control needed to focus compute on producing reactions. We need pattern extraction, but also coherence.
The entire point with the Shader is that it can help us fine tune the balance of control needed to focus compute on producing reactions. We need pattern extraction, but also coherence.
The compute has to be spent on the things that the player is interacting with. The Shader can use defaults for more distant characters or be turned off to handle animation at the physical level only. If the character is far away, then we use a statistical model and side step the Shader and physics.
November 12, 2025 at 10:32 PM
The compute has to be spent on the things that the player is interacting with. The Shader can use defaults for more distant characters or be turned off to handle animation at the physical level only. If the character is far away, then we use a statistical model and side step the Shader and physics.
That's why you want to scale up or down the control AI has over the character dynamically and for different parts of the body.
When we filter out e.g. facial expressions, we let the Shader do the heavy lifting. When we want more control, we turn off the filter and feed the Shader new data.
When we filter out e.g. facial expressions, we let the Shader do the heavy lifting. When we want more control, we turn off the filter and feed the Shader new data.
November 12, 2025 at 10:29 PM
That's why you want to scale up or down the control AI has over the character dynamically and for different parts of the body.
When we filter out e.g. facial expressions, we let the Shader do the heavy lifting. When we want more control, we turn off the filter and feed the Shader new data.
When we filter out e.g. facial expressions, we let the Shader do the heavy lifting. When we want more control, we turn off the filter and feed the Shader new data.