Originally posted on /r/rustgamedev: https://www.reddit.com/r/rust_gamedev/comments/6ly9ol/some_thoughts_about_rust_gamedev_and_the_future/
Posting this here so we can continue the discussion.
I’ve just watched https://air.mozilla.org/game-developement-in-rust/ from my home in Norway, and unfortunately I had no time to participate. I’m currently heavily focusing on polishing path semantics, a unification of mathematics and programming I’ve dreamed of creating the past 5 years and now becomes a reality, and I have done some background research for what technological challenges humans face regarding climate change. This research, plus a few other things, was part of the Piston project earlier, but is now moved to the AdvancedResearch community.
Anyway, here are some inputs of my experiences with Rust gamedev and how I view the future of the Piston ecosystem:
Recently I have played around with raytracing in GLSL and I believe this could be a nice way to get procedurally generated content for animations. I’ve did some experiment in the browser, but have nothing to show because I lost the code when it crashed. Luckily I listed up the functions I used. It was a good learning experience to create randomized rays and normals and stuff, and I recommend checking out the videos of Inigo Quilez and The Book of Shaders. I wrote a shadertoy-like viewer in Rust using the notify crate for code swapping and it’s working very well. There is already a shadertoy client available, so I do not plan to open source my own viewer unless there is some interest for it. I have some plans about controlling the shader parameters through data driven design, perhaps with some Dyon integration, which could be a cool way to prototype shaders.
I also experiment a bit with VR, and got an OpenGL backend for Piston which I plan to open source. The idea I am most excited about VR, that I have not seen yet in the demos I’ve tried, is the feasibility to code while using the headset. If I could write in Dyon from within the game to modify it, then I would be happy! I have a plan about using scientific data about the newly discovered Trappist solar system as a concept for multi-player VR shooter (big dreams, haha).
Dyon is obviously screaming for an interactive coding library, but I have not simply gotten around to do it yet. If there are somebody interested in working on this, please open up an issue here https://github.com/pistondevelopers/dyon/issues.
I look forward to Gfx becoming more stable, and first time I heard of three-rs made my heart skip a few beats, since I am person who likes doing prototypes. I wonder how it would like to use with Dyon…
At some point early this year I was working on an idea for parallel stream processing, based on function composition, but haven’t got any time to kick it out of the lab. Some people were interested, but it is an untested design so I don’t give it high priority.
Piston will continue using its current architecture with Model/View/Controller as standard pattern and a modular core. I know some people do not like the extra crates, but I simply see no other way to build the kind of software I want to build. It requires extremely high portability, and there is no perfect underlying API (yet). Piston supports 3 window backends and 3 graphics APIs at the moment. My background is in 2D animation software and the biggest problem I had in the past was portability, so I want to be extra careful when building a new codebase. We have the piston_window crate to make things easier to set up for prototyping and such, but if you have some ideas for making this easier then I’m listening. The idea I have for the future is: People using some pre-packaged libraries that reexports everything they need, or they put together their own game engine with scripting integration if needed.
One idea that I have been thinking about is how to get native UI feel across platforms. A possibility is to develop a backend for Piston per platform that wraps common widgets interfaces. Got better ideas?
I figured out a new concept for UI layout design, but using anchor flags that tells how a dimension is interpreted (left, right, stretch, fill). Could use an efficient binary format for sharing across projects. I am working on a prototype editor, it is working really well, but there is lots of work to be done. Tell me if this sounds interesting.
Having a nice reusable editor pattern across projects would be great, and I have done some experimenting with new ideas using the history_tree crate. Still, I am not sure whether this is the right direction to go yet. When it comes to integrating editors with game engines, I think a data-driven approach like Amethyst is the right direction, also because it makes it easier to use with version control.
The Khronos group wants to use Vulkan for common graphics + computing, which sounds nice, but Apple is slow to adapt it. Any input on how to avoid writing duplicate shaders for everything?
Conrod, Image, Imageproc and VisualRust continues being worked on. I don’t know much about the plans because I’m not among of the main developers on these projects. There is also some renewed interest in the Sprite library https://github.com/PistonDevelopers/sprite/issues/149.
That’s it! Questions?
*Edit: Forgot to mentioned that I’ve experimented a bit with compiling Dyon to Rust. It will take a lot of effort to make dynamic and static types work seamlessly, so either it could be a subset of Dyon that is statically typed or it some very smart type inference. Considering I have to duplicate code on the standard library, I am unsure it’s worth it.