GSOC 2017 - An Overview

Posted by skaldarnar on July 14, 2017

The first hurdle of Google Summer of Code is already over for our students, so it’s about time to happily announce that all ten students have passed the first evaluation. Yes, you read that correctly, we are mentoring TEN students this year! We want to take the opportunity to thank everyone involved in the project, mentors, students, and every contributor chiming in with ideas, tips, and tricks. You make this the awesome experience it truly is!

The Projects - An Overview

To shed some light on the projects currently in progress I’ll go through each and every one of them and briefly explain its purpose. Some students have set up awesome blogs, interesting dev diaries, or are using our forum for communicating progress. If you want to learn more about a specific project, just follow the provided links.

Anatomy System and Genome Integration

Arpan is working on improving the game play experience to bringing some more detail into the current health system. Instead of a simple health bar, the project aims to add anatomical body parts (like head, arms, legs etc.) to creatures and implement a Dwarf Fortress style health system which has effects on specific body parts (like a broken leg from falling down a cliff).

The second part of the project deals with integration of the Genome module for genetics effects with other modules like SimpleFarming and WildAnimals for breeding and mutation effects. This opens up a whole new play-style of breeding and crossing animals and plants to retrieve varieties of specific characteristics.

Read more about this project in Arpan’s Blog.

External Server API

The main goal of this project is to provide a HTTP/WebSocket server running inside the game server process that will allow access to Terasology functionalities for players and server admins alike. For instance, actions like kicking or teleporting players, changing game properties, adjusting game time, or loading a save game become available through those protocols - according to user permissions.

Sending chat messages from the web client to the running game instance Sending chat messages from the web client to the running game instance.

Up to now, the server exposes some basic resources through HTTP and Websocket, and there is a web client that can connect to the server. Client side authentication is supported and allows to trigger in-game commands from the web interface. The blog entries contain all information you need in order to test it by yourself!

Read more about this project in Gianluca’s Blog.

Behavior Trees

The concept of behavior trees has been around for some time now, the first implementation in Terasology dates back to 2013 when our contributor synopia introduced them in the forum. For this Google Summer of Code project, Terasology’s behavior tree AI implementation is to be completed to the point where it is easily usable by module authors and generally whomever wants to give their mobs behavior of any kind.

We are looking forward to a well documented behavior system living in the Behaviors module, providing pre-defined behaviors, behavior nodes, and easy hooks from a behavior node to check an actor’s status. Furthmore, communication with other Actors is going to be simplified. The project also includes tutorials and example creatures using the system. You see, there will be nothing stopping you from bringing some clever mobs to the game!

Read more on this topic in David’s Blog.

Blender MD5 Exporter

Kartikey chose to improving the current md5 exporter for blender to be better suited to the needs of Terasology. The script will automate most of the tasks for creating new blocks and models while providing an easy to use GUI for the blender environment. Features like automating triangulation of faces, separating faces, exporting multiple animations, creating a prefab file for specific AI animations and GUI development will be implemented during this project. I probably have to point out that this project sticks out of the others in that it uses Python for implementation (we are Java/JVM language dominated, otherwise).

You may want to check out Kartikey’s Project Board to stay up-to-date.

Destination Sol Overhaul

Started back in 2015 as a demo, Destination Sol is a Space Shooter that gives the player a chance to be the captain of his own fantasy ship, fighting enemies and looting gold. After the initial hype settled down, the developers who originally made the game drifted off to other projects, and Destination Sol came to be managed by Moving Blocks. However, the game has gone too long without updates, the associated tools that were once used to create assets for the game are no longer functioning, and a lot of features just leave the player discontent.

This project aims to change all that, and more. ‘Vampcat’ already applied a lot of work under the hood, for instance splitting up the games core and engined, fixing the asset handling, and more. Have a look at Vampcat’s Project Board to learn more about the project status and what is yet to come.

Exploration World Gameplay

The idea of this project is to bring together a ton of different independent features and develop a gameplay mode that has more depth. Currently Terasology has a lot of different features, but there is not really a good way for the user to enjoy them. What is really missing is a consistent gameplay setting which offers some challenge to the end-user and makes the game enjoyable.

With this background Nihal is dragging all the modules together - bringing wild animals to life (oh my deer!), integrating exploration logs into the journal, and building a bunch of traps and puzzles. There are videos and images in the blog posts alongside great summaries of the work done. For a taste, here is a video showcasing the “Wipe Out Lava Room”.

You should check out Nihal’s Blog for details, explanations, and background information.

Telemetry System

Terasology has a CrashReporter that allows users to upload log files and report bugs in forum or Github issues. However, the error reporting process is kind of manual. It might limit the awareness of existing error. Besides, developers treat the error report in an inconvenient way: they need to read the log file line by line, collect the environment information manually and guess what might be the cause of the error. Furthermore, more feedback from users is also needed: What are their systems? Does Terasology run smoothly in their PCs? What is the users’ favorite module? Collecting this data can help Terasology make the decision of what kind of optimization could be applied as well as help Terasology provide more fun for users.

Therefore, Gabriel is implementing automatic metric & error reporting. Exceptions and errors, i.e., abnormal behavior of the game, are tracked locally and may be send to a server to collect the reports. For metrics, Snowplow tools are used to collect custom metric events. The data can be visualized on a dashboard for easy consumption. Note that no information is sent without the user’s confirmation (opt-in).

Check out Gabriel’s Blog for more information.

Physics-based Combat System

Currently, Terasology lacks a proper physics-based combat system. Basic combat, based entirely on proximity and angles, can currently be simulated. However, creating a combat system that could use high velocity projectiles and reacts with environment much more dynamically (e.g., projectiles bouncing off surfaces) will be an important addition to the gameplay.

‘0shine0’ aims at restoring much of the functionality of an old branch of the legacy combat system while also improving AI with regard to new events and situations introduced by a functional combat system. The project also aims at defining the characters in anatomical way with different body parts and making them susceptible to disease.

Check out the module’s wiki to learn more about the available features.

Sectors

The focus of this project is to add sectors to the Terasology engine. Sectors are a level of entity storage between chunk-scope and global-scope, which allows entities that would usually be put in the global scope to be split into multiple groups. Each of these groups can be run on a separate thread, or even on a separate server node.

Sector-level entities are still loaded when their chunks are unloaded, allowing simulations to continue when the player is away, but they can be stopped if a whole sector is unloaded to increase performance. Vizaxo currently is in the process of integrating this concept with Dynamic Cities (developed during last year’s GSOC) and potentially extend it towards even more dynamic (moving) simulation subjects.

Get more information on this project in Vizaxo’s Blog and the forum update posts.

Scenario Creation

Tyler ‘Cata’ took inspiration from the Minecraft community along with some pre-existing suggestions and ideas within Terasology. The concept of Scenarios has been suggested in the past and is essential in order to properly develop any notion of static worlds such as what would exist for Light & Shadow. In addition, it provides assistance to creation of exploration worlds such parkour or puzzle maps.

Implementing scenarios can be thought of as creating a game maker utility set baked into Terasology. The following video shows the tool for defining regions in action. Regions, for instance, can be used by map makers to trigger events when the player enters.


The way students report their progress is determined by the student and their mentors. There is no policy applying to all participants, that’s why you might find blogs, forum reports for others, or only technical discussion and documentation for one or another student. We encourage this diversity and are always excited about the format of project documentation.

The project summaries and descriptions are partly taken from the student’s proposals.