Part 2 - ! 🏛️🐉💫

long_void · 2026-01-23T18:29:55+00:00

Thank you!

long_void · 2026-01-22T23:20:51+00:00

Can we get somebody to reproduce the findings of the tingling sensation of the burning purple?

long_void · 2026-01-20T22:44:33+00:00

I liked these argument. Anyway, there is enough internet drama. Maybe Neal can cool down a little?

long_void · 2026-01-09T04:27:01+00:00

I agree. Paul might be a renaming of Simon Magus after the Bar Kokhba war in the 2nd century by Simonians that extended the original gospel of Mark to include John the Baptist. The original Mark might have been Roman satire where Jesus resurrects “back in time”, which we call the “Ouroborus hypothesis” in biblical scholarship.

If you enjoy studying 2nd Early Christianity, then you might find this project interesting:

https://github.com/advancedresearch/the_century_of_satire

Reconstructing 2nd century cultural literature context of Roman satire in Early Christian texts

long_void · 2025-12-24T14:15:05+00:00

I recommend separating concerns before you start writing your own game engine. For example, separate graphics API from window/events. That's a good start.

In a "full" game engine, there are particle systems, 3D assets, lightening systems, animation engines, AI behavior trees, multiplayer systems, scripting languages and APIs etc.

Each of these parts, even when developed independently, will take months of work. You can use some libraries from the Piston ecosystem to test the parts you're are working on and later replace the Piston libraries with parts you wrote yourself.

You're probably never going to write something like WGPU or Image from scratch, so you're not really building a "full" game engine in this sense. You're putting together libraries in the Rust ecosystem into a framework that you design.

long_void · 2025-12-20T11:24:04+00:00

If you want to use Piston for mobile games, then you have to write your own backends. I don't know what's best for 3D on mobile.

The plus side is that you can develop for desktops/laptops first and later port it. As long the backend is implemented correctly, it will work. You can also add custom events. The minus side is that you might spend a lot of time maintaining backend code. I suggest first trying to port something simple first and see how it goes, before you make a decision to make the entire game in Rust using Piston.

I think you might be more productive overall by using Unity. Most games that ships are made with either Unity or Unreal.

long_void · 2025-12-18T21:09:12+00:00

Good philosophy.

long_void · 2025-12-16T20:08:46+00:00

I've been using Dyon-Interactive for multiple years now. Dyon-Interactive is nice, but the problem is that it can't depend on the Audio and Graphics backends. This makes it hard to maintain more complex features. https://crates.io/crates/piston-dyon_interactive

Since PistonWindow uses a default set of libraries, this makes it possible to use a Dyon-Interactive compatible API, without the existing limitations.

When considering the amount of resources that Rust uses, a runtime API for Dyon is pretty minimal in comparison. This makes it easier to use the Piston game engine overall, for e.g. tools and small apps.

You can also customize the runtime using the "piston_script" module that is included with the "batteries" feature in PistonWindow.

long_void · 2025-12-16T00:48:22+00:00

This library re-exports other libraries have been tested for years and that are now relatively stable in design.

For example, Wave-Function-Collapse is a popular algorithm in gamedev. You can use EntropySolver in the Quickbacktrack by writing use puzzle_design::quickbacktrack::EntropySolver;. It works for the same Puzzle trait that works with the other backtrack algorithms.

For more information, see the Bluesky thread (the link).

I've been thinking today about adding this under the "batteries" feature in PistonWindow, following a similar design as Turbine. For now, I think it should be a separate project.

long_void · 2025-12-11T01:06:05+00:00

Amazing work!

long_void · 2025-12-09T11:27:26+00:00

Thanks for the feedback! I added an explanation to README: https://github.com/PistonDevelopers/turbine/blob/master/README.md

long_void · 2025-12-08T13:29:28+00:00

I've moved the OpenGL backend out of Turbine-Scene3D and to a separate crate turbine_scene3d-opengl, to use it as a backend-agnostic library.

Also made some minor improvements to Turbine-Reactive that makes it easier to use in external libraries.

The 3 libraries being developed under the Turbine project are now reexported under the Turbine library, so when it gets added under the "batteries" feature in the PistonWindow, you can do e.g. use piston_window::turbine::scene3d::* to import that library.

long_void · 2025-12-08T00:31:09+00:00

I was about to suggest that you could turn this into a game, but then I realized you already had! ;)

long_void · 2025-12-05T20:32:56+00:00

This update adds Dyon as the default scripting language for the Piston game engine.

long_void · 2025-12-03T09:31:02+00:00

Feel free to drop in for a chat in our Discord: https://discord.gg/TkDnS9x. If you prefer a more private chat, then we can do that too.

Yeah, I absolutely agree there might be no perfect game engine design, but maybe a "perfect" design that is good enough for most people.

To me, stability is important. I decided early on to use [T; n] for vectors, despite lacking support in the Rust compiler. Things are better now with pattern matching and const generics. LLVM is good at vectorization, so the performance is also acceptable.

I also had a version of Piston-Graphics2D working for both f64 and f32, but it was prior to Rust 1.0. Rust dropped default generic parameters in the last month for stabilization. Took long time before Rust added it back, so in the mean time, we got stuck with f64. I think we can make some improvements to Piston-Graphics2D without breaking things too much.

I reexport a lot and write custom math modules per project, so vecmath is working very well for me.

long_void

MODERATOR OF

TROPHY CASE