Jekyll2017-08-29T14:10:59+01:00https://vizaxo.github.io/VizaxoMy blog
GSoC 2017 Wrap-up2017-08-26T00:00:00+01:002017-08-26T00:00:00+01:00https://vizaxo.github.io/2017/08/26/gsoc-2017-final-post<p>I’ve spent the last ~3 months working on my <a href="https://developers.google.com/open-source/gsoc/">GSoC</a> project for <a href="http://terasology.org/">Terasology</a>. I’ve recorded my progress on the project in several places: the code (along with some discussion) is presented in GitHub PRs that are linked throughout the rest of this article; there’s an introduction to my project in a previous blog post; and I documented my progress over the summer in a series of forum posts.</p>
<ul>
<li><a href="/2017/06/28/google-summer-of-code-introduction.html">Introductory blog post</a></li>
<li><a href="http://forum.terasology.org/threads/new-conceptual-layer-sector-plus-musings-on-multi-world-node.1420/#post-15124">Progress forum posts</a></li>
</ul>
<h2>Project work</h2>
<h3>Pools</h3>
<p>The first part of this project was implementing pools. These are an extension of the game’s entity-component system which allow entities to be stored in multiple locations, in preparation for splitting the game into multiple worlds, or splitting servers across multiple machines.</p>
<p>They also lay the groundwork for the next part of the project, sectors, by allowing sector-scope entities to be stored in their own pool.</p>
<p>The terminology between sectors/pools can get confusing, because the main reason for implementing pools is to allow multiple sector pools, so they are often discussed together under the name ‘sectors’.</p>
<h4>PRs:</h4>
<ul>
<li><a href="https://github.com/MovingBlocks/Terasology/pull/2975">Initial pools PR</a></li>
<li><a href="https://github.com/Vizaxo/Terasology/pull/1">Rename cache to pool</a></li>
<li><a href="https://github.com/Vizaxo/Terasology/pull/2">Bug fixes and cleanup</a></li>
<li><a href="https://github.com/Vizaxo/Terasology/pull/3">More fixes</a></li>
<li><a href="https://github.com/Vizaxo/Terasology/pull/4">More fixes 2</a></li>
</ul>
<h4>Discussion issue:</h4>
<ul>
<li><a href="https://github.com/MovingBlocks/Terasology/issues/2976">Sectors and pools implementation/API</a></li>
</ul>
<h3>Sector simulation</h3>
<p>The second part of this project was sector-scope simulation, allowing entities to undergo simulation that is based on the time between simulation events rather than the number of events that are sent. This allows the simulation rate to be decreased, especially when the chunks that the entity affects aren’t loaded, to improve performance scaling with lots of entities.</p>
<h4>prs:</h4>
<ul>
<li><a href="https://github.com/Vizaxo/Terasology/pull/5">Sector simulation</a></li>
<li><a href="https://github.com/MovingBlocks/Terasology/pull/3009">PR that merged pools work, and the first sector simulation PR</a></li>
<li><a href="https://github.com/MovingBlocks/Terasology/pull/3022">Add SectorRegionComponent to allow sector entities to span multiple chunks</a></li>
<li><a href="https://github.com/MovingBlocks/Terasology/pull/3037">Convert alwaysRelevant to entity scope</a></li>
<li><a href="https://github.com/MovingBlocks/Terasology/pull/3041">Allow sector entities to simulate at a different rate when loaded</a></li>
</ul>
<h3>Zones</h3>
<p>The final part of the project was zones (initially called surfaces). Zones allow the world to be split into different areas for world generation, and allow those different areas to have their own section on the world preview.</p>
<p>The most useful type of zone at the moment is the layered zone (or just layer). Layers are a special type of zone that lie horizontally in the world, and don’t overlap with each other. They are used to split up each of the layers in the world into separate areas, which allows each one to be provided by its own module (increasing the modularity and customisation of the game), and will open up further options in the future (such as splitting the sectors in the world according to the layers that exist).</p>
<p>Zones also provide a way of improving the world preview system, which allows the player to see what a world will look like before loading the world. Previously there was only one preview screen for the whole world, so you couldn’t show multiple separate parts of the world. Each zone has the option to act as a preview screen, so each part of the world (e.g. a layer of deep lava lakes, a cave layer, the surface of the world, and some floating islands) can have its own display screen.</p>
<ul>
<li><a href="https://github.com/Terasology/TutorialWorldGeneration/wiki/Zones">More information and tutorials on the zones wiki page</a></li>
</ul>
<h4>PRs:</h4>
<ul>
<li><a href="https://github.com/MovingBlocks/Terasology/pull/3054">Zones</a></li>
<li><a href="https://github.com/MovingBlocks/Terasology/pull/3079">Zones 2</a></li>
</ul>
<h3>Module updates</h3>
<p>To showcase the changes listed above, I updated some of the existing Terasology modules to use these new features.</p>
<h4>Dynamic Cities</h4>
<p>The first module I updated was <a href="https://github.com/terasology/dynamiccities">Dynamic Cities</a>, which was created for last year’s GSoC. I updated the cities to use sector simulation, so the cities grow at a predictable rate even in games with different framerates, and to allow the simulation to be performed at a lower rate when the city is unloaded. This means that when no players are near the city, fewer updates need to be done, while still having the city grow at a consistent rate.</p>
<ul>
<li><a href="https://github.com/Terasology/DynamicCities/pull/30">Update Dynamic Cities to use sector-scope simulation</a></li>
</ul>
<h4>Inferno</h4>
<p>I also updated <a href="https://github.com/terasology/inferno">Inferno</a>’s world generation to be a layered zone, and turned it into a world plugin. This means that it can be added as a layer to any world, instead of needing its own custom world generator.</p>
<ul>
<li><a href="https://github.com/Terasology/Inferno/pull/4">Convert Inferno into a layer</a></li>
</ul>
<h4>TutorialWorldGeneration</h4>
<p>The final module update was adding an example generator to <a href="https://github.com/Terasology/TutorialWorldGeneration">TutorialWorldGeneration</a> which was based on layers and zones. This shows how the features can be used in a complete world generator, and how they can interact with each other, and with the normal world generation features.</p>
<ul>
<li><a href="https://github.com/Terasology/TutorialWorldGeneration/pull/5">Add example layer/zone generator</a></li>
</ul>
<h2>Comparison to original proposal</h2>
<p>My original proposal focused only on pools and sectors, and included more advanced features such as allowing sectors to dynamically split or merge depending on which entities were interacting with each other. However, it was decided that these features wouldn’t provide many advantages until multi-world games or multi-machine servers were being worked on, so they were not implemented as part of this project. Instead of these I added zones, which will have a more immediate impact than the features that were pushed back to a later time.</p>
<h2>Future work</h2>
<p>The features I have implemented during this project are already fit for use, and have been merged into the v2.0.0 staging branch ready for inclusion in the next major version of the game.</p>
<p>However, there are still changes and improvements that can be made to the work I’ve done, and long-term projects that can build off this work:</p>
<ul>
<li>Improve the ordering of layers, to allow blank space between them and to be able to specify a desired depth for the layer</li>
<li>Fix bug where “Entity x doesn’t have an assigned pool” appears repeatedly when the game is saved</li>
<li>Fix bug with Dynamic Cities not properly reloading after being saved</li>
<li>Implement multiple sectors, and sector splitting/merging</li>
<li>Add non-overlapping, tiling, columnar zones (to allow each <a href="https://en.wikipedia.org/wiki/Natural_region">natural region</a> to be its own zone)</li>
<li>Convert existing world generators to use layers and zones</li>
<li>Add connectors between zones so they can interact or merge at the edges</li>
<li>Allow zone world plugins to be nested zones (so that zones can be added to a specific layer in the world)</li>
<li>Allow each game save to consist of multiple worlds</li>
<li>Allow game servers to be split across multiple physical machines</li>
</ul>
<h2>Conclusions</h2>
<p>Overall, the project has been absolutely fantastic; I’ve learned a huge amount about contributing to an open source project with a large existing codebase, and about programming in general. I had a lot of fun doing the project, and I hope that my contributions are valuable and help developers and players of the game in the future.</p>
<p>I want to say a huge thank you to my mentors: they have been extremely helpful, both guiding the project and helping me learn a huge amount of new skills along the way. I also want to thank Google for running the program, which allowed me to spend my summer working on a great open source project while learning far more than I could by coding alone.</p>I’ve spent the last ~3 months working on my GSoC project for Terasology. I’ve recorded my progress on the project in several places: the code (along with some discussion) is presented in GitHub PRs that are linked throughout the rest of this article; there’s an introduction to my project in a previous blog post; and I documented my progress over the summer in a series of forum posts.Google Summer of Code Introduction2017-06-28T00:00:00+01:002017-06-28T00:00:00+01:00https://vizaxo.github.io/2017/06/28/google-summer-of-code-introduction<h2>Hello world!</h2>
<p>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 <a href="https://summerofcode.withgoogle.com/">Google Summer of Code (GSoC)</a> program this summer (to work on a game called <a href="http://terasology.org/">Terasology</a>), which is a good incentive to start writing.</p>
<p>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.</p>
<h2>What is GSoC?</h2>
<p>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 <a href="https://summerofcode.withgoogle.com/">website</a> and the <a href="https://en.wikipedia.org/wiki/Google_Summer_of_Code">Wikipedia page</a>.</p>
<h2>What is Terasology?</h2>
<p>I’m working on a game called Terasology, which is an open-source game similar to Minecraft. The website is <a href="http://terasology.org/">here</a>, and the GitHub repository is <a href="https://github.com/MovingBlocks/Terasology">here</a>. It’s exactly what I want a voxel sandbox game to be: open source, and focused on modding.</p>
<p>I’ve spent a lot of time playing Minecraft, most of which was with mods and modpacks like <a href="https://www.technicpack.net/modpack/tekkitmain.552547">Tekkit</a> (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.</p>
<p>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.</p>
<h2>What is my project?</h2>
<p>[Note: the architecture, implementation and uses of this are not set in stone, and will likely change as they are used and tested]</p>
<p>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.</p>
<h3>Caches</h3>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h3>Sectors</h3>
<p>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.</p>
<p>r example, the <a href="https://github.com/terasology/dynamiccities">Dynamic Cities</a> 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.</p>
<h3>The rest of the project</h3>
<p>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.</p>
<h2>Technical blog notes</h2>
<p>The blog is built with <a href="https://jekyllrb.com/">Jekyll</a> and hosted on <a href="https://pages.github.com/">GitHub Pages</a>, 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.</p>
<p>I’m writing this post with <a href="http://Orgmode.org/">Org mode</a> in <a href="https://www.gnu.org/software/emacs/">Emacs</a>, 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 (<a href="https://gist.github.com/abhiyerra/7377603">org_converter.rb</a>) 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).</p>Hello world!