Dev

Way of Rhea Ships After 6 Years in Rust, Developer Shares Inside Story

Key takeaways from the launch and AMA of Way of Rhea, a puzzle game built in Rust over six years.

7 min read Reviewed & edited by the SINGULISM Editorial Team

Way of Rhea Ships After 6 Years in Rust, Developer Shares Inside Story
Photo by Growtika on Unsplash

Way of Rhea is a puzzle game developed in Rust. Development spanned six years from 2018. The author is Mason Remaley. He published a Q&A after the release. According to coverage of gamesbymason.com via PuercoPop on Lobsters, its key points have been summarized. The subject is an AMA posted to r/rust_gamedev. It covers a wide range of topics, from language choice and a custom engine to sales strategy.

The work is described as close to Braid, The Talos Principle, and Portal. It is structured around single-player puzzles. Rust was adopted as the development language. The engine was also built from scratch. The Q&A is divided into three parts: language, engine, and development operations. Language-related questions asked about reasons for adoption, obstacles, and crates used. Engine-related topics included window handling, scripting language, and macOS support. Operations-related topics included the definition of success and securing playtesters.

Turning Point and Background of the Move from

C++ to Rust

The trigger for adoption was a pause in C++ engine development. Remaley was working on a C++ game engine at the time. Faced with a problem in the build system, he chose to take a break for a few days. During that time, he read through Steve Klabnik’s explanation of Rust. It was reportedly equivalent to the official documentation at the time.

His own account reads as follows.

Before Rust, I was working on a C++ game engine. A friend had been nagging me to check out this cool new language, but I was skeptical and hadn’t yet given it a chance.

Although skeptical, his assessment changed once he actually tried it. The built-in build system made a strong impression. Unit testing and documentation generation were included by default. Algebraic data types and error handling without exceptions also drew attention. He reportedly could find no reason to stay with a high-friction language.

He also acknowledges memory safety as an advantage. However, he says it was not the main focus for a single-player work. There are few situations where invalid memory access directly harms users. Instead, development efficiency and maintainability were prioritized. The combination of low-level control and productivity drove the choice.

High Evaluation of the Build System and

Type System

Rust’s type system contributes to early detection of errors. Ownership and the borrow checker eliminate overlapping references. They also help prevent races in concurrent processing. In games, per-frame processing heavily consumes resources. In that area, the checking mechanism appears to have helped the design.

Dependency management with Cargo is also important. In C++, build descriptions tend to become complex. As shown by Cloudflare Strengthens Vite/Astro Development with VoidZero Acquisition, well-maintained build infrastructure affects development efficiency. In Rust, fetching, building, and testing are integrated into a single tool. Ensuring reproducibility is also easy. In long-term development, this difference accumulates.

Built-in documentation generation is also suited to long-term maintenance. It limits divergence between specification and implementation. Test code can be kept in the same place. Over six years of development, a maintainer’s memory fades. The integration of documentation and code appears to have worked effectively.

He is involved in efforts to promote migration from C and C++. He also participates in the Zig community. He serves as a director of the Zig Software Foundation. He is critical of treating languages like competing factions. He also touches on the psychology of beginners fixating on the one correct language. His position is that fit for purpose matters, not which tool is superior.

Reasons for Choosing a Custom Engine and

Scripting Language

The game does not use an existing game engine. Layers including rendering, audio, and physics were built in-house. Building from scratch requires additional time. The AMA included questions about that burden. The detailed allocation of effort cannot be determined from the published summary. Even so, it certainly contributed to the extended timeline.

He was also asked why he did not use an existing product for the scripting language. The game includes a dedicated language for describing in-game logic. Introducing an external language increases dependencies. Predictability of behavior and ease of testing are involved. A custom language increases freedom for optimization and integration. On the other hand, maintaining documentation and tools becomes a burden.

There was also a question about restoring macOS support. The difficulty of support was at issue. Differences in rendering layers and window handling have an effect. Signing and distribution procedures are also relevant. The specific policy is unclear within the scope of the summary. It bears watching along with future plans for the engine and language.

Implementation Details in Crash Reporting and

Window Handling

Crash reporting strategy was also subject to questions. It is a mechanism for collecting anomalies after release. In solo development, securing reproduction information is difficult. Diversity of user environments hinders identification of causes. Both automatic collection and user consent must be balanced. The fact that effectiveness in practice was questioned is suggestive.

Window handling and input processing are also important areas. Supplementary information on Steam Input was included. Diversification of controllers complicates support. Standard reception and extended features must be coordinated. Consideration for handhelds and diverse input devices is essential. Implementation in a low-level language directly ensures responsiveness.

He was also asked about the impact of ecosystem changes. Over six years, languages and crates changed significantly. Specification updates and tool replacements occur. In long-term development, decisions on whether to follow are difficult. Judging when to pin and when to update affects maintainability. His view on LogLog’s account of stepping away was also sought. This can be seen as an issue reflecting community challenges.

Launch in a Difficult Genre and Record of the

Testing Process

The definition of success was also a central issue. Sales numbers and revenue alone are not the metrics. Recoupment and the ability to continue development are involved. Supplementary remarks on participation in events were also attached. Balancing exposure opportunities with preparation burden is a challenge.

3D puzzle games are considered a difficult genre to sell. It is a highly competitive area on Steam. Securing discoverability is a hurdle. Questions probing that perception were also included. Unearthing demand and pricing are key points. How to convey the uniqueness of the work holds the key.

Securing playtesters was also discussed. There was supplementary information about a feedback-oriented community. How to face criticism was also taken up. He was asked why he chose closed testing. The aim appears to have been to control early reactions. Quality and information management may have been intended to coexist.

Lessons learned were also shared. In long-term development, maintaining motivation is a challenge. Judgment to curb scope expansion is required. Separation of tools and work is also important. Becoming absorbed in building the engine delays completion. The published summary shows the difficulty of that balance.

Editorial Opinion

In the short term, we expect case studies of game development in Rust to accumulate. The Way of Rhea Q&A illustrates long-term maintenance and custom-engine practice. The effectiveness of the ownership checker and Cargo is discussed concretely. Over the next three to six months, we expect citations to increase as reference material for solo developers. We assess that discussion will shift from the merits of the language to operational ingenuity.

In the long term, we expect low-level language options to become established. The C++-only landscape has already broken down. Rust and Zig may be used selectively by use case. In one to three years, we expect sharing of educational materials and engine components to advance. We assess that integrated building and testing, more than memory safety, will drive migration.

We raise three questions from the editorial team. First, how should the cost-effectiveness of a custom engine be measured. Second, does building a custom scripting language impair reusability. Third, how should success in a difficult genre be defined beyond numbers. These are unverified areas. Accumulation of cases and critical examination are needed.

References

Frequently Asked Questions

What kind of work is Way of Rhea
It is a single-player puzzle game developed in Rust. It is described as close to Braid, The Talos Principle, and Portal. It was developed over about six years from 2018, and features a custom engine and a dedicated scripting language.
Why was Rust chosen
Its built-in build system, unit testing, documentation generation, algebraic data types, and error handling without exceptions were valued. The author says memory safety is also an advantage, but was not the main focus for a single-player work. Development efficiency and maintainability were prioritized.
What was discussed in the AMA
Language obstacles and crates used, custom-engine effort, crash reporting, window handling and input, scripting language, macOS support, definition of success, securing playtesters, and other topics were discussed. Lessons from long-term development and responses to ecosystem changes were also at issue.
Source: Lobsters

Comments

← Back to Home