Cervator edited this page Feb 22, 2017 · 33 revisions
Clone this wiki locally

Google Summer of Code

We have participated in GSOC and hope to do so again. This page serves the related information and some suggested ideas for proposals!

The items listed here are drawn from our issue tracker's GSOC category, suggesting tasks suitable to be worked by a student over a summer.

More conceptual work is likely needed for most items and there may be existing contributors familiar with and able to help guide a student, beyond any mentors made available for GSOC normally. Other proposals are of course also welcome but they need extra justification to be considered :-)

Difficulties and contacts are best estimates - please see the "How to get involved" section below.

This page is likely to get updates and new entries repeatedly during the warmup period before GSOC formally starts, then go somewhat dormant during the off-season.

For more GSOC specific details see its site at

What is Terasology

In short Terasology's goal is to make a heavily extensible voxel world game where actual gameplay can be defined in batches of modules. The engine is minimal, primarily serving to support modules of different kinds. Even systems that seem central to games in general, like a first person player, inventory, combat, and so on is here provided in modules instead and everything can be replaced with a customized version or disabled if not needed.

We plan to make a few typical game types available, like a content creation sand box mode, a twisted Alice in Wonderland style base warfare mode, a more difficult "start from scratch" world with a realistic tech tree to claw your way up while surviving, and so on.

Inspiration is obviously sourced from Minecraft, as well as other classics like Dwarf Fortress and Dungeon Keeper. One heavy focus is making sure the world contains more realistic creatures that'll interact with the player in a number of different ways as well as develop their own societies.

Overall Requirements

As an incoming student you should meet these general requirements:

  • Intermediate level Java skills
  • Knowledge of version control, preferably Git (the project is hosted on GitHub)
  • Experience with an IDE such as IntelliJ or Eclipse would be helpful
  • A good attitude and willingness to learn!

More specific requirements (if any) can be found listed with corresponding proposals.

To earn some bonus points familiarize yourself with the Codebase Structure and the concepts of our entity system. Get an overview of the project and get set up!

How to get involved

The sooner you contact us the better! As mentioned above, set up your environment, browse through our primary Issue Tracker and get your hands on some minor fixes or a simple module.

For a bunch of sample small tasks you could also see our tasks completed entry for Google Code-In 2016 - several of them are still repeatable and all of them were doable since they got done! :-)

If you have any questions don't hesitate to enter #terasology on Freenode IRC or post a thread in our dev portal forum.

Here is a more step-by-step guide:

  • Check our main site, look at the source code and read the available guidelines
  • Pick an idea that you think is interesting from the ideas list below or come up with your own idea
  • Get familiar with what exactly GSOC is! We can provide you with some information to get started, and most of the time give you some feedback, but its still you working out an idea
  • Post an introduction of yourself in our intro forum and of what your interests are, including what you might like to do for GSOC
  • After we get to know each other a bit and you've picked an item then write a draft proposal, posting updates for instance in your intro thread
  • The contact people listed below aren't necessarily going to mentor - although some will - but they have been involved with each idea or its general area. After acceptance and discussion we will identify the best available mentor for chosen tasks. By keeping the discussion open we might even find that the best mentor isn't even listed yet :-)

Project Ideas

Cameras as components

Currently Terasology has one main camera: the player camera. Under the hood a number of classes such as PerspectiveCamera provide its implementation.

Ideally however, cameras would be data-only components attached to entities - i.e. the player entity. Systems would then be responsible for manipulating the components, i.e. updating or retrieving their data as needed - in line with how much of Terasology works and in line with its ES-based architecture.

This project involves a fair amount of Math as camera implementations are ripe with 4x4 matrices and operations on them. Assuming a student with a good knowledge of matrices this aspect might not be as big as challenge. Cameras crop up in many location in the codebase however. Replacing the existing camera-related code with code taking advantage of an ES-based cameras architecture will likely require a challenging amount of delicate integration work.

Renderer Visual Debugging System

Terasology uses a deferred renderer: every frame it renders a number of separate layers (stored in FBO attachments) which are combined to produce the image seen on the display. Existing bugs or newly introduced bugs affecting the rendered will tend to negatively affect its visual output.

An important aspect of debugging these issues is to isolate and identify the rendering node that introduces the problem. Currently, we have a visual debugging system in place, displaying the content of a number of FBO attachments when enabled. The current system has a number of shortcomings however.

First of all, it is hardcoded and does not take advantage of the new, node-based, extensible architecture of the renderer. Second, a number of nodes may write to the same FBO but the current system visualizes the content of the FBO only at the end of the frame: ideally we'd want to be able to inspect the contribution of each node to that FBO separately. Third, the current system visualizes the color attachments of the various FBOs but does not allow inspection of other important attachments, for example depth and stencil buffers. Finally the current system displays the content of an attachment and only that: there is no label allowing the user to uniquely identify the visualized attachment nor additional metadata such as attachment type, size in pixels, size in memory and other useful information.

If you are interested in this particular problem, please engage in a discussion in the space provided by issue 2795.

API for Integration Tests (Headless Client?)

As of the start of 2017 Terasology has several hundred unit tests and a barely implemented code coverage (25% woo!) setup in our build scripting / Jenkins. We can do better!

But to move beyond very basic unit testing we need to improve our testing toolchain, both including more external tools (automated acceptance testing!) and better engine support for partial game environment launching for faster integration tests.

There is a forum thread linked from the issue that covers a wealth of possibilities, but one good initial goal would be for a more complete way to launch the game client, but in a headless fashion, to simply exercise a set script of actions, asserting that all went as expected.

This could relate to a few other items like a RESTful API server (which could communicate with the game server via a headless client)

Exploration World

While this is a relatively easy item the challenge will be writing an ambitious GSOC proposal that can fill a summer with what might become the most involved world to play in yet - just enabling all the suggested modules and throwing in a few random extras won't be enough!

There needs to be a solid theme and feel to playing through the world. Exactly what that should be is up to the student's imagination and design/writing skills. Expect code to be focused on gameplay logic systems meant to tie the different pieces together.

This item may be suitable for combining with something else, like a unique feature that would fit well into the designed world.

World storage / phase improvements

This is an ambitious idea that may be difficult to write a GSOC-scoped proposal for without some existing understanding of advanced topics like persistent multiplayer game servers.

However, the issue covers several large topics so with the right student and a subset of the desired features it should be doable!

In short: Currently Terasology stores a single world full of chunks which are cubic sections of the world made out of blocks. Entities (anything beyond primitive blocks) are loaded into a single global store, although some may be tied geographically to a specific chunk and only loaded if needed.

Our goal is to expand on this so you can have geographically isolated stores, whether for distant pieces of the same world so far apart they don't need to know about each other, or entirely independent worlds in the same game.

We also want to improve world setup and simulation at different scopes, so you could see a world map with cities marked without even entering the game world yet, much like browsing a Dwarf Fortress world before embarking on your adventure.

Crash/Issue reporting improvements

We have a CrashReporter project that allows users that crash an easy way to retrieve log files and submit an error report - but manually, merely aided by the CR.

This item would take it a step further to do automatic return of analytics to some back-end system we control, so we can easily see related error reports and spot patterns like all crashes of one type coming from a particular OS or video card.

There are existing frameworks that support such efforts, part of this idea would be researching what's available and writing a proposal for how to achieve this for Terasology

A closely related idea focuses on making more details available while this is more for reporting it better.

VR-oriented gameplay elements

This item naturally requires the student to actually have access to virtual reality gear, but on the plus side odds are then good you've already tinkered with VR development too! If not then probably skip this item :-)

With existing exposure to VR development this item may only be of moderate difficulty, although the specifics depend on the target VR experience you aim for.

The goal for the idea is providing some sort of VR specific gameplay, which will most likely include developing the supporting in-game user interface to allow regular players with VR gear to experience the content naturally.

Enhancements for our Genome system

Fairly open and possibly small idea. We have a Genome module allowing for basic tracking of mutations and other fun genetics related stuff, but it isn't being used for much.

Plenty of potential on this item but the student will have to write up an interesting proposal to cover most the details. Likely this will end up involving plant breeding, animal husbandry, or even mutations applied to the player somehow.

Some similar projects from the past exist in various states of completion, such as

This item could potentially be combined with another idea, like Anatomy or the advanced plant growth simulator

Light & Shadow

Our Light & Shadow concept is the oldest design we have with the most available game assets, however the game world itself isn't really prepared yet.

While we still lack key features in combat and meaningful PvP to achieve full replayable content with L&S at a scope suitable for GSOC the world setup should be doable, including many of the central gameplay features like base setup and maintenance.

Player avatar selection

Fairly straight forward item that can be extended as necessary to fit GSOC scope. Add support for having the player configure their avatar of choice, possibly overridden by certain gameplay templates that put restrictions on what the player can play as.

Closely related with the Customizable characters, naturally, but that item is more about the support while this is about configuration. Ideally they'd be done together.

Expose the game server for something other than a regular player

This item started as a request for a RESTful API server facade and we have an initial attempt at

However, two main observations came from initial work on the topic:

  • It may make more sense to first allow for a different kind of player to connect to the server regularly, so a possible web facade could be using such a headless player to run commands in-game regularly. Another example would be an observer player
  • We need to actually have some use cases for interesting features to base on this. Some types of server management might be easier to control via grabbing standard in/out on command line.

Any student interested in this item should be sure to spend extra time discussing the possibilities with the community first. It may be possible to write a proposal mixing together elements from this item, the server management tool item, and/or the improved testing setup

Customizable characters

While Terasology already supports animated meshes, they don't get currently used for the player controlled character yet.

Thus if you view another player in multiplayer you see just a place holder monkey head mesh.

Since the character is something players identifies with it should be made good looking and customizable.

Some brain storming in that area:

*The armor of the player could be made of many small parts that can be individually chosen and added

  • An item/NPC could allow the modification, form and color of the hair
  • The face could be based on many small parameters. e.g. one parameter controls the form of the mouth, the other the color and form of the eyes, etc. (even if it may just be a single pixle)

Ideally of course the API for generating the customizable model should be separated from the in-game mechanism to activate it, so that alternative activation strategies are possible.

Renovation for MasterOfOreon

The MOO module contains a basic command menu akin to how you manage your dwarves in Dwarf Fortress. While a few very basic functions work most of the menu options remain unimplemented (and somewhat awkward to use).

We need somebody to help modernize it (replacing a dependency on the old Miniion module) and flesh it out further to arrive at some DF-inspired gameplay within Terasology, managing creatures in a sensible fashion.

The DynamicCities module may integrate well with this item as it already has population-based cities - they just need to be populated by something!

Physics-based combat system

We had a nearly complete physics-based system back in the legacy days, see the linked issue for details. While that was never merged and may be too out of date at this point the concept was sound and neat, going especially well with the anatomy system mentioned below.

While we can simulate basic combat purely on proximity and angles actual impacts with physics-enabled objects would be vastly more impactful, if such a pun could be excused. Especially with positional damage.

In theory for somebody familiar with game physics this might not be terribly difficult, although with multiplayer in the mix that may make it a little more tricky (prediction, anti-lag, cheating)

Behavior tree renovation / documentation

We have a working behavior tree based AI system in the game complete with an editor UI! Very cool and powerful, with a neat demo video

However, it hasn't aged gracefully and lacks features. Synopia started a rewrite with trees defined in Groovy in modules rather than in the engine (preferred) and was nearly done before running out of time. A later rewrite/port was done by MarcinSc, also detailed in the issue.

The issue has a wealth of added details but in essence the system needs a nice overhaul with better documentation and tutorial work especially to make it more approachable for regular content developers needing AI.

GPU-based Occlusion Queries to load medium-distance chunks only if they are visible

Terasology currently loads and unloads chunks (boxes containing 32x64x32 blocks) purely depending on their distance from the player. A ViewDistance set in the Video Setting to "Moderate" for example, will trigger the loading of 13x7x13=1183 chunks centered on the player. Depending on the circumstances many of these will be invisible, either because they are underground or because they are behind large obstacles such as hills and mountains.

While the chunks representing the immediate surroundings of the player will probably need to be always loaded (so that the player can interact or perceive entities in her proximity even if they are behind obstacles), Terasology would benefit from loading medium-distance chunks only if they are visible from the point of view of the player or other significant point of views (i.e. the shadow map camera).

By using GPU-based occlusion queries it could be possible to limit the number of chunks loaded by verifying that the bounding box of a chunk (a 32x64x32 box) is effectively visible given the geometry rendered so far. If it is the chunk gets loaded and rendered, if it isn't, the chunk remains in a "loadable" state until it is no longer occluded or until the player gets close enough to it.

By using this technique on average we could be able to reduce the number of loaded chunks for a given view distance or extend the view distance maintaining the number of loaded chunks.

This item on its own may be too small to fit GSOC scope well. It could be combined with improved chunk sorting (side-item for the world storage idea) or maybe the new approach for far rendering.

If you are interested on working on this particular challenge please engage in the discussion space provided by issue 1710.

Game / saved world / module preview image content

This is a fairly straight forward addition to the create world / load game screens, and similar locations in the main menu. Currently we only use text to describe modules and worlds. But a picture is worth a thousand words!

When a player looks at an existing world we could present any screenshots the player has taken in that game, or if none have been taken use a logo or other placeholder graphic from the primary module.

For viewing modules you could again have logos or preview screenshots associated with each module. These could also be used on a module browsing site on GitHub or elsewhere.

For bonus points this could be extended into easy screenshot uploading (to imgur maybe?) or even in-game video recording made available along with the world as saved assets.

Update: As of February 2016 there is a pending PR with a first step to a newer create game approach. It is pending a solution to a game context issue (to what degree is what loaded during setup/preview).

Improve visibility of missing resource scenarios and general user reporting

Currently we've put a fair amount of work into hardening the game against missing resources, crashes, and leaks, and want to improve that further and make even non-fatal warnings more visible.

We have our own Crash Reporter project that'll catch most ways the game crashes then encourage the user to report the error back to us.

However, some issues are subtle and non-fatal, like some missing resources just not being drawn instead of crashing the game. And it could be easier yet to report back details.

Frameworks exist for better reporting of errors, warnings, metrics, and so on, sending them automatically to a database (if the user opts in). This would be a good next step.

A newer issue/idea focuses on automatic reporting of the details back to a back-end system, this item should focus more on gathering more information. Ideally they should be done together.

Noise-based generation of distinguishable terrain features

Infinite terrain worlds are typically generated by noise generators such as Perlin or simplex. While the generated patterns are aperiodic, no distinguishable terrain features are created. Regions such as desert areas have only very little high-frequency noise while mountainous regions will have a lot.

A first step could be to create abstract, large, high-level regions which are then refined depending on the type. Smooth transitions between such regions must be created.

Some regions such as lakes have additional requirements (flatness). Some effort on that particular issues has already been invested:

Sorted by difficulty, desired regions are: grassland, ocean, dessert, forest, mountain, lake.

Leap Motion implementation

We did a proof-of-concept implementation for using the Leap Motion Controller in-game quite a while ago and actually made a video on it:

While Terasology isn't really super apt for motion control there are some interesting niche areas like spell casting or flying that could lend some novelty if a user happens to have a Leap unit laying around. This is a fairly open-ended item on how it should work, although an external library named Jitter was started to help out the effort and fleshing it out further would be ideal.

A few existing contributors have Leap units (we've had some good contact with the company - they actually reached out to us first!) and some additionally have Oculus Rifts, which we can also support, so there could be some interesting combination potential there like Leap VR... :-)

This item might go well with our VR item.

Mobile server management utility

You can launch a Terasology server easily enough, but configuration is still pretty manual. We need to start expanding administrative options available and it would be very convenient (and a novel experiment to break into mobile land with) to also offer a small utility for smart phones and tablets to interact with a server, from managing users to viewing logs and maybe even observing from a map view (the AWT facade could hold some premise here)

Work on this item would go hand-in-hand with actual server configuration options being developed, and working on both at once would be a bonus.

There are likely existing similar utilities for administering MC servers that could be used for inspiration.

There is another item/idea focused on expanding the ability to connect to a game server, which may be required for this item to work.

Anatomy system

This is a very open ended idea that could be approached in all sorts of ways:

  • Procedural generation of creatures with differing organs, limbs, etc
  • Combat system targeting parts of the body (external and internal) instead of working on straight HP (Dwarf Fortress style)
  • Models with parts that can fall off when damaged
  • Indirect affects such as diseases and poisons that damage a creature over (possibly very long) time

We actually had directional damage (physics-based) in the old combat system but its maintainer Aherber disappeared before it was committed :-(

A start on this could simply be defining a range of body parts in prefabs and components, differing them by creatures, and letting damage and/or effects target them randomly. Perhaps a ragdoll type display in-game showing affected parts of the body. Maybe a relation to the existing hunger system.

There is a newer item closely related to this focusing on the Genome module. Ideally the two would be done together, they may be too small alone.

New rendering approach for very far distances

This calls for a new rendering technique to support showing the world beyond normally visible chunks (where every block is rendered). The more distant detail would have to be reduced in some fashion to display the world in a more simplistic fashion at range. While there is a little more detail in the issue begla or KaiKratz would probably need to be consulted for more details, or any other 3D wizard we have with the know-how :-)

Note: This is a very old item and may be blocked waiting for more progress on - it may be possible to start working on it. Contact Manu3d!

Port advanced organic growth simulator from Python

Long ago cfkurtz / Woodspeople reviewed some old work she had done and prepared a growth simulator in Python that bases its growth on available water and mineral values in the soil, among other things (sunlight!). While we've since gotten an initial "growing trees" implementation working that is sufficient for showcasing growth in-game (doesn't consider its location much) it could be amazing to take it one (to many) steps further!

At a minimum this would port the Python version to Java based on simulated values where no exact data currently exists

  • Sunlight is available
  • Soil nutrients could be approximated by soil type, possibly the block could even change as it is depleted (and fertilizer bring it back)
  • Moisture could be based on distance to water or again on block type (while aquifers could later yield a more exact per-block moisture level)
  • Custom block shapes could be added to get higher detail level for branches and other smaller tree components

Any additional detail in the original plant simulator could be considered for extras.

Update: Since this topic was originally posted we improved engine support to where a large amount of extra information can be included via per-block biome data. There are also several more advanced flora-related content modules.

Advanced and dynamic geology based on plate tectonics

This item is for generating a world based on plate tectonics such as provided by PlaTec or some sort of simulated version. At a minimum it should be able to read maps generated separately from PlaTec (or some comparable source) and in turn prepare one or several layered maps usable in-game to guide placement of actual blocks such as minerals in appropriate layers. A series of bonus features are possible:

  • Connecting to PlaTec natively from Java to C to request a map (and maybe to take advantage of extra per-step data)
  • Visually showing the plates moving during world generation in a simple map view mode in-game
  • Placement in the world of volcanic and other interesting biomes related to tectonics

An actual study of the involved sciences is best left to surfing Wikipedia although a certain level of artistic creativity to enhance gameplay value would be welcome :-)