Hello world!

Welcome to my blog! I guess this is a kind-of introductory post, introducing the subject I will be writing about over the next couple of months. I’ve been meaning to set up a blog for a while now, but I was selected for the Google Summer of Code (GSoC) program this summer (to work on a game called Terasology), which is a good incentive to start writing.

I’ll be posting updates about my project over the summer, and will hopefully be including tips and notes about my workflow, problems I encounter, and talking about how I overcome challenges.

What is GSoC?

The Google Summer of Code (GSoC), is a program run by Google to help university students work closely with an open-source organisation, spending a summer writing code for them. It’s probably easier to explain by linking to the website and the Wikipedia page.

What is Terasology?

I’m working on a game called Terasology, which is an open-source game similar to Minecraft. The website is here, and the GitHub repository is here. It’s exactly what I want a voxel sandbox game to be: open source, and focused on modding.

I’ve spent a lot of time playing Minecraft, most of which was with mods and modpacks like Tekkit (providing machinery, magic, and automation to Minecraft), so I want modding to be a first-class citizen. Minecraft mods relied on decompiling the main game, and they broke with every update, when internal code changed. They were a pain to install and you couldn’t easily turn them off, so I ended up with lots of copies of the game for different combinations of mods.

Terasology is taking a different approach: the engine is just the core features, and all of the content is added in modules, which have a stable and well-defined API. This means you could use the Terasology engine, but write all of the blocks, animals, items, world generation, progression, etc. that you want, and include them as modules. These modules can be enabled/disabled at will, and combined with any other modules that are available, to make a completely customizable experience.

What is my project?

[Note: the architecture, implementation and uses of this are not set in stone, and will likely change as they are used and tested]

The first part of the project I’ve been working on is a set of features called sectors and caches (but those names may yet change), but to explain them I’ll have to go into a bit of detail behind Terasology’s inner workings. Change is effected in Terasology by the entity system, which consists of entities that have components attached to them. Systems that are associated with those components can receive and send events, which can cause effects that the player can see.

Caches

rrently, all of the entities and components are stored in one big cache, and systems run on one thread, acting on the same cache. That’s fine for small worlds, but when there are lots of entities or computationally-heavy systems, the performance can suffer. Many entities will be tied to specific locations in a world, so one option is to unload them when the chunks they are in aren’t loaded. But that means that the world outside of the direct vicinity of the player remains static and unchanging, which diminishes the gameplay experience.

ches allow the entity store to be split up into smaller groups, which can be interacted with separately. In the future, they can provide options for running the game across multiple threads, or even across multiple computers, by assigning threads to certain caches to split up the load.

r example, a detailed climate simulation might be computationally expensive, but would not need to interact with the rest of the world very often (only when visible events occur, such as rain/snow/sun, storms, or rivers overflowing). This would be a good candidate to run in a separate cache on its own thread, so it doesn’t slow down the main game.

Sectors

sector is just a cache which holds sector-scope entities. Sector-scope entities can stay loaded while the chunk they’re associated with is unloaded, allowing for processing to continue when the player is away. They can be aware of the state of the chunk and other nearby entities, so when they are in an unloaded chunk, they might be able to do computation at a less granular level, saving computation time.

r example, the Dynamic Cities module provides cities, which produce goods. When the chunks of the city are loaded, the goods could be calculated at a fine level of detail, managing which workshops/workers produce which items, and placing them accordingly (so if the player comes in and breaks something in a workshop, its production would decrease). But when the chunks are not loaded, the sector-scope entity can take control, continuing to calculate production at an average rate, and spreading the goods between the workshops when the player returns to the city.

The rest of the project

Sectors/caches are just the first part of my GSoC project. After working on them, I’ll move onto other world-generation-related topics. but this blog post is getting rather long, so that discussion will have to wait for another day.

Technical blog notes

The blog is built with Jekyll and hosted on GitHub Pages, and they’ve been pretty easy to setup and use so far. I still have some problems, but I haven’t had to faff about with PHP, DNS, external servers, or anything like that. They’re also free (as in beer), and Jekyll is free (as in speech; A.K.A. open-source or libre), which is a big plus.

I’m writing this post with Org mode in Emacs, which has been one less thing to learn, as I already use Org for lots of my notes and planning. I’m sure I’ll be writing more about Emacs and Org on this blog in the future. I had to install a custom Jekyll plugin (org_converter.rb) to be able to use Org files instead of markdown, but this setup works much better for me (though it does mean that I can’t use GitHub’s native Jekyll hosting, so I’m going to have to host the source code and the generated site separately; I’ll have to work out the best way to do that).