Retrograde

Heads up!

Though I did start work on this project already, I have since paused it as I plan to rewrite the runtime and editor using Conjure. This means this project is currently on hold as I won’t succeed at anything if I work on 4 projects at once.

I have a graveyard of projects that I’ve started and never finished. Some of which represent years of effort that I’d hate to see go to waste. While hitting my own scope limitations for a similar project, I decided that by widening the scope just a bit — I could merge serveral projects together and finally bring these ideas to completion.

If the name “Retrograde” sounds familiar, then you may have seen my write up on the initial version of the project. However, this project is a complete rebuild with a different architecture and goal than my original concept.

Where the first version was a personal project to teach myself more about low-level programming, this new version is focused on being a purposely restrictive platform for creating, playing, and distributing games with a retro aesthetic1.

#Let’s talk about the restrictions

When you’re developing for actual hardware, you’re working with a fixed set of resources — but — there are usually a wide range of tricks and optimizations you can employ to do incredible things2. I would call this a “soft” set of limitations, since there’s not a strict, explicit set of rules that you have to follow.

Example

Try to answer the question: how many polygons can you have in a game on a modern computer?

This is almost impossible to answer as there are a number of factors, like how many you’re drawing, the cost of the shaders, and how many textures you’re using, the resolution of the screen, the hardware of the computer, etc…

The Retrograde SDK3 would have a hard set of limitations. The SDK handles this by placing “costs” on resources, which are grouped by “scenes”. The runtime only allows a single scene to be loaded at a time, making it easy to enforce these limits.

Here’s some examples of limitations that I’m considering for the platform:

• A limit of 100k polygons and up to 8MB of textures per scene. This limitation is a pretty obvious one and is a primary way to enforce a more “retro” aesthetic4.
• Objects cannot be dynamically created or destroyed and must be defined ahead time within the scene.
• Visual scripting blocks/nodes each have a “cost” that limits how complex scripts can be. If, say, “Add Ints” has a cost of 1, then a function adding three integers together would have a cost of 3.

#Defining the platform runtime

Retrograde’s primary runtime is described as an “emulator”, but more accurately it’s a “virtual machine” that runs .rgx files5. These .rgx files support a custom stack-based bytecode alongside embedded binary data (like scenes & object definitions, textures, meshes, and so on).

This emulator also supports running an embedded default .rgx file, which receives some elevated permissions and operates like a visual shell for launching other .rgx files6. This provides a way to create a “launcher” for the platform, which can be used to quickly browse and launch other .rgx files.

Having this built-in visual shell would also provide a way to manage the “virtual memory card” for the console and could connect to a distribution web service where players could download .rgx files created by developers on the platform.

#Releasing your game outside of the platform

Creating content, especially games, is a lot of work. Investing time into an extremely niche platform is a risk to the creator, meaning it’s unlikely there will be content for the platform. This in turn creates a poor experience for the player due to a lack of content.

To solve this, Retrograde supports producing standalone executables for specific platforms. It’s just a variant of the emulator, but designed specifically to run a single, embedded .rgx file. This allows you to create a game that can be distributed both on the platform and outside of it.

Experiments in Nativization

I’ve also been experimenting with being able to translate the bytecode into native code, allowing the game to run with full native performance. It’s possible that I may allow for the hard-coded limitatons to be lifted when building for “nativized” standalone targets.

#Let’s get physical

The final goal of the project is to create an open-source, physical console that can be built using low-cost hardware. This sounds particularly fun to me because it means we don’t just emulate the feeling of the software, but also that nostalgic feeling of playing on a physical console, in the living room, on a TV, with friends and family.

The current runtime uses a fixed amount of memory that is reserved when it first boots up7 and the design decisions I’ve been making means it should be possible to run it on a a Raspberry Pi Zero 2 Wireless. The RPi build of the runtime would be paired with a heavily customized Linux Kernel that immediately (and only) boots into the runtime.