GlitterWorld Prime: A look inside

In this post I thought I would share what the infrastructure of GlitterWorld Prime looks like, why it is the way it is and where’s I plan to go with it.

The frontend

For simplicity and familiarity I decided that the best way to implement the front end would be to use what the game already offers.

RimWorld already has an extensive in-game UI and the trade interface is no exception.
It already shows buy and sell prices along with the quantities held by two parties, the direction of trade, allows sorting and the total cost.
This was everything I needed to start with.

RimWorld's Trade Window
RimWorld’s Trade Window

However, I feel that the code within RimWorld is not exactly the easiest or most accessible code to extend.

The Mono Project Logo
The Mono Project Logo

Whilst Tynnan and Ludeon have done a great job with the game, extending it is far from simple.
Most of the games classes and methods have been defined as private or sealed except for the ones closest to the surface.

Creating any serious mods for this game requires extensive workarounds by using harmony, reflection or detours and reverse engineering of the games code.

Thankfully, I’ve been able to avoid these methods except for a little reflection to eliminate dependencies.

RimWorld also suffers from another indirect issue, Mono, although whilst Mono itself is not a problem, the version used is.
Currently the version of Unity in use relies on a very old version of Mono, Version 2.0 to be exact while the current release of Mono now at time of writing is 5.4.0.
This makes it very difficult to write network code as 2.0 lacks support for GZIP compression and TLS versions later than 1.0.

To summarise, RimWorld itself is fine, but the underlying dependencies desperately need updating.

The backend

The server side of GlitterWorld Prime consists of four separate components:

The REST API

The API itself for GlitterWorld Prime is written entirely in Python and is served by NGINX, GUnicorn and Flask.
I designed the code to be as absolutely minimal and light weight as possible to ensure maximum speed and efficient memory usage.
The entire API only requires 4 dependencies and the only framework in use is the awesomely minimal Flask to handle the HTTP side of things.

The Database

The speed and size of the GlitterWorld Prime database was my largest concern, based on my past experience as a developer I decided to try a new approach and opted for a In-memory Key-Value pair storage system instead of the traditional RDBMS.

TheRedis Logo
The ultra-fast, in-memory database, Redis.

For GlitterWorld Prime I chose to use Redis based on a number of reasons.

  • It is a very mature KVP system.
  • Has numerous data types to take advantage of.
  • Has clients and binding for almost every programming language in existence.
  • Very efficient storage of data in-memory.
  • In-memory storage engine that can also persist data to disk.
  • Can process requests as fast as your CPU can handle them.
  • Has great synergy with Python and JSON.

The list goes on and on. I have found Redis to be instrumental in the creation of GlitterWorld Prime. The flexibility offered and the synergy with Python/JSON datatypes has made data storage a breeze.

There is also the possibility that I could migrate it to a hosted version such as Amazon’s ElastiCache should the need ever arise.

 

GlitterBot
GlitterBot
The GlitterBot

This component will be responsible for maintaining adequate stock levels of Things in the GlitterWorld Prime market, the other primary function is to adjust prices based on the demand of Things being bought and sold.

GlitterBot is also written in Python and runs continuously, monitoring, adjusting and collecting/processing statistics.

 

The Website

Again, Written in Python utilising Django as the template rendering system.

Django Badge
Lightweight, easy and powerful.

I opted for Django over Jinja2 which I know can be integrated with Flask for a few reasons.

Django has a lot of polish, includes things like authentication, URL pretification, redirects, URL based routing of methods and a feature rich template engine.

Whilst Django is quite a hefty framework, It is very fast and Jinja2/Flask don’t include much out of the box.

Even though the Website is currently a work in progress, the GlitterWorld Prime website currently has the following features:

  • Display all Colonies using GlitterWorld Prime.
  • Viewing all the items currently in stock
  • Show the trade history of all Things and Colonies

And will eventually have:

  • Placing Bids for buying and selling items.
  • Contracts, Buy and sell items directly with other users.
  • Graphs of Thing prices and stock levels.

The bid and contract system will be available on the website only as trying to add these to the game itself would prove incredibly difficult,

Building them into the website will be far quicker and allow more flexibility in future updates.

For associating Colonies to users, I imagine the best way to do this would be to

A: Have the user input their Steam ID on their account page, this will allow GlitterWorld Prime to automatically associate new colonies to their account as well.
Or B: Have the user copy the Colony ID from within the game and paste it into the account page, but the user would have to do this for each colony.

I haven’t quite decided on what to do yet, But I will make another post in due time.

Please share and leave me a comment if you liked this post.

Best regards,

TwistedSoul / Adam.

Please Share!Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn