DEV Community: Lunaria

This Month in Lunaria – July 2021

Jan David — Sat, 31 Jul 2021 18:39:49 +0000

I'm back! Let's just say that living through a global pandemic takes its toll, and I wasn't able to focus on the project as much as I would have liked. I'm trying to learn from this and set smaller, more achievable goals for the future. But the big news for July is that there has been some progress again!

Switch to Godot Engine

The original plan was to use the new game engine Bevy to create Lunaria. Bevy is written in Rust, which provides a good foundation for the low-level services that Lunaria's API needs to run. But Bevy is still very young and in active development, which makes it hard to find good beginner resources.

Godot on the other hand is very mature, and its community has created an abundance of tutorials for all kinds of games. The engine is written in C++, which means tightly integrating the backend into the engine will be more difficult. But Godot supports plugins written in Rust, which should make it possible to stick with Rust for the backend and the core logic.

I have decided to experiment with Godot, since Bevy overwhelms me as complete game development novices. As I gain experience and a better understanding of this domain, I might reconsider this decision. But for now, I want to prototype as quickly as possible to learn if Lunaria can even work as a game...

Streaming API for the Game State

The most interesting development has been a streaming API for the game state, which uses server-side streaming in gRPC to push changes to the client. The idea is that a client can start the game by calling the startGame method. The response to the method is a stream of game states, starting with GAME_STATUS_RUNNING. When the game ends or is stopped by the user, the server streams a GAME_STATUS_STOPPED update to the client, indicating that it can stop running itself.

After experimenting with this idea for a while, I don't think it is well suited for this particular use case. For one, it introduces a significant barrier to entry. Players would have to implement asynchronous methods just to start the game, which will be challenging for less experienced developers. And the value of server-side streaming for this use case is pretty low, as changes do not happen frequently and can easily be captured by an error response to API calls. For example, a call to moveUnit can simply return an ERROR: Game stopped response, which eliminates the need to stream the state change in real-time.

A better use case for server-side streaming are updates to systems that are controlled by the server. Taking a weather system for example. Clients could poll the weather ever so often using synchronous method calls, or they could subscribe to a stream of real-time weather updates that get pushed from the server whenever the weather changes.

I am very excited about this experiment, since it enables a few very interesting game mechanics later on...

Camera Controls

Less exciting but very practical is the implementation of camera controls in Godot. The controls are inspired by modern strategy games, in which the camera can be moved with the keys W, A, S, and D. Additionally, players can zoom in and out using the keys Q and E.

Future plans for the camera controls are to support moving the camera with the mouse, for example my moving the cursor to the border of the screen.

The implementation is done in GDScript, which is the default scripting language in Godot. Once the missing features have been implemented and the controls have been tested sufficiently, the plan is to open source the implementations and publish it as a plugin for Godot.

Next Month in Lunaria

This month has laid quite a good foundation with the switch to Godot, a better understanding of gRPC and its capabilities, and the camera controls as a prerequisite for navigating the in-game world.

The focus for August is stabilizing the features introduced in July, and working towards the first game mechanic. This means finishing the implementation of the camera controls, implementing an API to start and stop a game, and then figuring out what the first game mechanic should be.

gRPC

Jan David — Mon, 19 Oct 2020 18:41:42 +0000

Lunaria is a video game for programmers. It is played by writing code that sends commands to the game, and watching the effects of those commands on the game world. In this post, I will introduce the API between the players' code and the game, and explain why I chose to use the gRPC framework.

Introduction

On a high level, Lunaria consists of two components: a simulation running the game, and an API enabling players to interact with the simulation. Because players can only control the game through the API, it probably has the most significant impact on how much fun it is to play the game.

Lunaria is also supposed to be a sandbox for beginner and expert programmers alike, and a place where they can practice their skills. To do this, the game must be compatible with as many programming languages and paradigms as reasonably possible, so that developers can freely choose what to learn. Since the API is again the most important factor determining compatibility with the game, its design matters even more.

gRPC

After much research and consideration, I made the decision to adopt the gRPC framework to build Lunaria's API. gRPC is described as a high-performance, open source universal RPC framework, and it has some interesting features.

API Specification

As the primary touchpoint between players and the game, the API has to be well documented. With gRPC, the endpoints of the API and the messages it consumes and produces are defined as Protocol Buffers, a language-neutral standard to serialize data. Protocol Buffers are strongly typed and fairly easy to read, making them ideal candidates for API documentation.

The following example defines the API that returns the current version of the game. It defines a Version type with three field, an RPC endpoint GetVersion, and two types for the request and response.

syntax = "proto3";

package lunaria.v1;

message Version {
  int64 major = 1;
  int64 minor = 2;
  int64 patch = 3;
}

message GetVersionRequest {}
message GetVersionResponse {
  Version version = 1;
}

service Lunaria {
  rpc GetVersion(GetVersionRequest) returns (GetVersionResponse);
}

Multi-platform

gRPC supports many programming languages and ecosystems out-of-the-box. It has official support for Node, Python, Go, Ruby, Java and more, and other languages are supported by their communities.

Auto-generated libraries

While gRPC is built on open standards and can theoretically be used with any programming language, official or community supported languages provide a lot of tooling that makes it very easy to use gRPC. Most notably, client libraries for many languages can be generated from an API's Protocol Buffer definition. For Lunaria, a Node and a Rust library are already being published as a proof of concept.

Take the Node.js library for Lunaria (lunaria-api) as an example. The library can easily be installed from npm, and requesting the version is as simple as calling a method on the client:

// Asynchronously send the request and process the response in a callback
lunaria.getVersion(request, (err, response: GetVersionResponse) => {
  const version = response.getVersion();

  if (version != undefined) {
    const versionString = [
      version.getMajor(),
      version.getMinor(),
      version.getPatch(),
    ].join(".");

    console.log(`Lunaria is running version ${versionString}`);
  }
});

Streaming and Authentication

Two other builtin features of gRPC are streaming and authentication. Streaming might be interesting for certain game mechanics, and authentication will come in handy for multiplayer. Even though there are no concrete plans for these features yet, it is still nice to know that they are there when we need them.

Alternatives

Before deciding on gRPC, I did a lot of research and considered the following alternatives. Each has its pros and cons, but none checked as many boxes as gRPC.

REST

Probably the most widely supported API would have been an REST API. Every language on the planet has a way to query an HTTP endpoint (don't @ me), and especially web developers are very familiar with it. There are also decent ways to document these APIs, and some tools to auto-generate client libraries.

In my experience, though, it requires a lot of effort to keep the documentation up-to-date, and the generation of client libraries is often fragile. But maybe more importantly, it is not a very fun API to use. The industry is moving to other solutions such as RPC or GraphQL, which are either more performant or offer more flexibility to clients.

GraphQL

Another option I considered was GraphQL. It is widely supported, easy to document through its schema, and has excellent tooling such as the Playground to explore the API.

There are not many arguments against GraphQL, and most will probably resolve themselves in the future. Streaming and subscriptions are still fairly new, as is the Rust implementation of GraphQL.

Maybe my biggest issue with GraphQL is that it feels very focused on web technologies, while Lunaria is more of a distributed system. This probably wouldn't be a problem, but gRPC felt like the better fit.

Message queues

A third solution I considered where message queues, because it is a very simple solution that other video games have already implemented. In Screeps, for example, players queue up commands for their units that get executed in the next turn.

But compared with the alternatives, message queues are very hard to use. It's difficult to document their message formats and ensure that the documentation stays up-to-date, and it is not possible to generate client libraries that would hide some of the complexity. And since GraphQL and gRPC support streaming, the same pattern can be implemented in a much nicer environment.

Conclusion

gRPC feels like a great choice for Lunaria. It provides a good experience to players, is easy to document and use, and is blazingly fast. The playlunaria/lunaria-api repository contains the specification for Lunaria's API, tooling that publishes client libraries to npm and crates.io, and automated integration tests for each language.

gRPC is of course no silver bullet, and I can already see a few challenges ahead. At least in its initial form, Lunaria will expose a single service, and I am not sure if that's how gRPC is intended to be used. And it might turn out that players would actually feel more comfortable with GraphQL than gRPC. But we'll learn this as we go.

With the API design out of the way, it is now time to focus on the actual game...

Announcing Lunaria

Jan David — Mon, 05 Oct 2020 18:27:37 +0000

A few weeks ago, I wrote a lengthy blog post about why I want to build a video game for programmers. Today, I am happy to announce Lunaria.

Lunaria is a video game for programmers. It is played by writing code that sends commands to the game, and watching the effects of those commands on the game world. As players progress through the game, they unlock new capabilities and have to expand and adapt their programs to solve new and ever increasing challenges.

This post is split into the following sections:

Vision
Gameplay
- Setting and Scenario
- Programming Mechanic
Roadmap

Vision

To create the most engaging platform to practice programming

Let's start by taking a look the motivation to create Lunaria. This section repeats a lot of arguments from the post linked above, and I invite you to check it out for a more in-depth discussion of the following points.

Briefly summarized, I am unhappy with the tools that are available to freely practice programming. Yes, there are plenty of course and tutorials available on the internet. And yes, it has never been easier to start and launch a side project. But neither is what I am looking for. What I want is a sandbox in which I can play around with code. Experiment and learn, without a strict curriculum or the pressure to produce something that would look good on a portfolio.

And I want to combine this sandbox with the mechanics of video games to make it engaging and fun. Give users goals that they can pursue if they want some structure and direction. Create feedback loops that can be used to measure the efficiency and effectiveness of experiments. And provide a bit of a story around the programming so that it is interesting to come back and continue practicing. Mechanics that video games have perfected over the last few decades.

The very ambitious dreams for Lunaria is to become the most engaging platform to practice programming, for beginners and experts alike. Because my theory is that a vast sandbox video game, in which players can pick and choose their own adventures, is generally more interesting than most courses or side projects...

Gameplay

This section is divided into two topics. First, the setting and scenario of Lunaria is introduced. Second, we take a look at the initial design of the programming mechanic inside the game.

Setting and Scenario

Lunaria is heavily inspired by existing video games. It combines mechanics and ideas from strategy, base building, and survival games, and remixes them to work well with its core mechanic: programming.

When starting the game, players find themselves in charge of an expedition to a foreign planet. A rocket has dropped them off on the planets surface, and unloaded some supply and a few drones. The player's first tasks are to set up a rudimentary base that protects against the environment, and to generate some energy so that the base and its drones continue to function.

What happens next still needs to be designed, but the story arc will most likely focus on the following progression:

Set up an automated base that produces resources
Bring in humans to unlock new capabilities
Launch rockets into space to explore the solar system
Unlock long-range travel, and explore the galaxy

The long-term vision is that the game takes place in a persistent massive-multiplayer online world. As players progress through the game, they can meet other players and collaborate to tackle the hardest challenges. Building the infrastructure for this is a serious undertaking, so in the beginning development will focus on the singleplayer experience and stand-alone multiplayer servers for a handful of players. Large-scale multiplayer will follow later.

Over the next few weeks, I will publish a series of blog posts about the video games (and books and movies) that inspire Lunaria, and the ideas and mechanics that this game might adopt from them. The sum of these influences will hopefully paint a compelling picture of the game that Lunaria might become...

Programming Mechanic

The most important game mechanic of Lunaria is without a doubt programming. Two technical components will dominate the look & feel of this mechanic:

The runtime that executes the player's code
The API that players use to interact with the game

Certain technical limitations are unavoidable, but I find it very important that the game does not constrain players too much. To this end, I want Lunaria to deliver the following functionality:

Support as many programming languages are reasonably possible. Do not require players to use a single language or tech stack.
Give players freedom in their software design. Treat their code as a blackbox and interact through a well-defined API.

Runtime

In the beginning, especially as long as there is no multiplayer, the game will run locally on a player's machine. When running locally, no special runtime is required and players can simply run the code in the terminal:

# A Rust player
cargo run

# A Ruby player
ruby lunaria.rb

The long-term vision for the game is to become a massive-multiplayer game, which executes the player's code "in the cloud". For this environment, the idea is to utilize Docker to allow players to upload their own runtimes. Players will package their code in a Docker image and upload it to the server where it will get executed. This enables each player to choose their own runtime and execution environment, even when playing online.

API

The code that players write to play Lunaria interacts with the game through an API. Because of this, the API has a huge influence on how Lunaria feels to play. It should provide a high-level interface that is easy to use, and provide good documentation about the parameters that are passed along requests and responses. It is also important that it is performant, especially in a future MMO scenario. And finally, to not limit the choice of programming language, the API implementation should be as widely supported as possible.

The best fit for these requirements is gRPC. It is widely supported, has low-latency and small message sizes, and supports auto-generated client libraries. I am particular excited about the client libraries, because they provide a well-documented, strongly typed, and high-level interface to interact with the game. By using gRPC and its libraries, players do not need to deal with transport protocols, message formats and encoding, or other low-level details. Instead, they can call a method and focus on the impact they'd like to have.

// Send an asynchronous request to move a drone to a new location.
game.moveUnit(drone.uuid, new Coordinate(1, 1)).await?;

I will write more about this decision in the future.

Roadmap

Shoot for the moon. Even if you miss, you'll land among the stars.

Lunaria as introduced here is an overly ambitious project. I think it is helpful to have the long-term vision as a north start to work towards, but its success is of course not guaranteed. For foreseeable future, I have much more modest plans for the project.

The goal for the next 6 months is to create a playable prototype of the game. The prototype will be limited to singleplayer, and it will only implement a narrow slice of the game mechanics I ultimately want to have in the game. Its purpose is to find a solid foundation for both the game design as well as we technical architecture.

With a prototype in hand, I want to focus the following 6-12 months on building out more game mechanics. The goal is to create something people actually like to play to make sure the concept works. This is also when I want to invest time and effort to foster the community. I expect that it will be much easier to participate in the project when there is something to see, try, and comment on.

Everything beyond the next year is probably too early to pin down, and depends very much on the health of the project by then. If we get there, a focus for the second year could be:

Bigger game world, e.g. going from planets to solar systems to galaxies
Procedural world generation to add more variety and depth
Multiplayer

The biggest risk for the success of the project is me burning out or losing interest before a significant milestone is achieved. If I can get a prototype out, and we can gather as a community around the game, I will feel more optimistic about the long-term sustainability of the project.

Stay in Touch

This post was only able to scratch the surface of what Lunaria is and might become. Therefore, make sure to check in here regularly for updates on the project. I intend to write roughly two posts per months, covering the progress on the project, important design decisions, and games and other content that inspire Lunaria. The following posts are already in the pipeline:

A detailed look at gRPC and why it was chosen for Lunaria
A discussion about the decision to build Lunaria as open source
A bunch of posts of various video games and movies that inspire Lunaria

https://playlunaria.com/blog

You can also join Lunaria's Discord server to chat with me and others. Right now, the server is pretty empty, but I hope that'll change as the project develops.

https://discord.gg/WkgJcsq

And then there is GitHub of course, where you can find Lunaria's source code. This is also where I'll plan to have in-depth technical discussions on new features and game mechanics, probably through an RFC process once there are more contributors than just me.

https://github.com/playlunaria

Thanks for your interest in the project! 👋