Development has slowed down a lot recently, but OpenRA is far from dead. I wanted to write something to bridge the news gap until our next official news post, so here’s a brief update on a couple of recent projects. We hope to ship these plus many other changes in a new playtest series starting in a few weeks.
One big change affects how we package and distribute our "official" OpenRA builds on Linux. For many years we have automatically generated a deb package, but then relied on downstream packages for other distributions. This has worked well in most respects, but sometimes delays in updates would strand players on older versions, stopping them from playing online. Another long-standing issue on many distros is the (lack of) support for installing playtests and releases at the same time, as players are able to on Windows and macOS.
Our solution to these problems is to adopt the AppImage packaging format, which allows us to distribute a portable version of OpenRA that should work on most modern Linux distributions. AppImages can exist alongside normal distro packages and even other versions of OpenRA, which makes it perfect for trying out playtest versions without overwriting the stable release. We will be retiring our deb packages and OBS repository as part of this change, but fear not because stable OpenRA releases are also available on Flathub if you prefer a "proper" installation that integrates more closely with your system.
A sneak-preview of the new download page featuring Linux AppImages.
Our modding community has continued to be a major focus, driven in a large part by active discussions with and Pull Requests from the modders themselves. We have recently achieved two major modding milestones which we are looking forward to support from the next playtest:
- Feature parity between the Mod SDK and the main OpenRA mods: the Mod SDK can now package Linux AppImages alongside the existing macOS .apps and Windows installers. Mods now also integrate properly with the online and in-game server lists (no more "Unknown Mod (id)"), and modders can define their own acknowledgements text to be displayed in the in-game Credits dialog.
- Improved tools and documentation for mod updates: Updating mods to a newer OpenRA engine has historically been difficult and prone to errors. We have developed a completely new OpenRA.Utility command that significantly improves on the old command for semi-automating the update procedure. More information about this tool and how to use it can be found on the Mod SDK Wiki.
Another major project over the last few months has been identifying and eliminating performance bottlenecks in the graphics renderer. These changes have roughly doubled the FPS that can be achieved on many systems, which is great news for for Tiberian Sun and some of the ambitious community mods where modest systems previously struggled to achieve a stable 60 FPS. It is useful for our default mods too, because less time spent rendering the game means more time is available to smooth over other performance hiccups that can occur during large battles, resulting in a smoother play experience.
The main driver for this work has been a project to improve OpenRA’s performance on the latest Raspberry Pi devices. These changes have improved performance from a painful 10 FPS during large battles (using the Red Alert main menu as a test case) to a more tolerable 20 FPS. We are still not happy with performance on the Pi, and have identified several areas in the game code that could be targeted to improve performance further. We hope to be able to officially support a Raspbian release in the future once performance has improved to an acceptable level.
Renderer improvements (red and orange lines) significantly improve performance on a Raspberry Pi 3B+.
The next target for optimisation will be the tick_time (light blue line).
The upcoming playtest includes several other great features that I haven’t covered above as well as the usual set of iterative balance tweaks and bug fixes. Keep an eye on the development changelog and release milestone over the next few weeks if you are curious about the full feature set and progress towards a release.
At the end of May we made the jump to a new forum, splitting away from the old Sleipnir’s Stuff content. See this thread for more details. This move opens up a number of opportunities, such as resurrecting our plans (which were prototyped and then shelved in 2016 due to lack of web developers) to include an in-game authentication system that can be used to securely identify yourself to game servers and other players, instead of relying on insecure passwords or IP addresses. This may not be completed in time for the next release, but if it isn’t then we plan to make it a priority for the following one.
We still receive a lot of questions about a release date for the Tiberian Sun mod, and unfortunately the answer has not changed in the last year: we don’t know, but it won’t be soon unless we can attract new developers with the right skills to help. Progress is still being made on gameplay features (e.g. we recently merged support for placing gates on top of walls, and the special logic for tiberium critters), but a release is blocked by a handful of critical bugs and missing features that cut deep into some of the oldest and ugliest parts of OpenRA’s code. Resolving these issues takes a significant amount of work, and we currently only have one person (with very limited time) with the knowledge required to tackle them.
Tiberian Sun progress has all but stalled due to lack of manpower.
While the mod is broadly playable, it is still missing some important features (e.g. super weapons) and other important features contain game-breaking bugs (e.g. subterranean units, cloak generators). We would have to disable these features if we wanted to release a public build now (like we did in the early days of Red Alert, Tiberian Dawn, and Dune 2000), and try to rebalance the rest of the game around their absense. This is not a path we want to repeat after our experiences with Red Alert.
OpenRA’s Red Alert mod is well known in the C&C community for including a collection of arbitrary gameplay changes that were not in the original game or series. Many of these changes were introduced in the early days of OpenRA to help balance the game and make it play well despite missing core gameplay features (back then these were things like like 5 infantry sharing the same cell or a proper implementation of the “classic” engineer behaviour). Over time, these changes became entrenched, for better or worse, as part of OpenRA’s identity. Many of these changes are considered almost universally positively (e.g. the fog of war, unit veterancy, Flak Trucks), but others have been much more controversial (e.g. Hinds on the Allies, Kill Bounties, re-usable engineers).
This dichotomy between "Original Red Alert" and "Original OpenRA" has caused significant conflict among our players and contributors on the forum and the community Discord channels. These discussions were reignited last year by the change to building auto-targeting, and have increased in passion with recent discussions about finding a way to move Hinds back to Soviets and removing Kill Bounties as a default feature. On one side of the issue are thoughts that the RA mod should abandon some of the changes that don’t make sense in the world of Red Alert 1 (e.g. Kill Bounties, but not the Flak Truck) and instead double down on the things that made the Command and Conquer series memorable. On the other side are thoughts that it is exactly these changes that made OpenRA great, and that it is an insult to our community to discard these features motivated by misplaced nostalgia.
The Allied Hind. Hero, or heresy? Let us know what you think about OpenRA’s gameplay changes below!
We would greatly value input from the wider OpenRA community on the topic, so leave your thoughts in the comments below or on our new forum. The results of this discussion will steer the future direction of OpenRA’s Red Alert mod. Please aim to be polite and constructive; comments that insult or abuse others will be moderated.