revolutionary-games / thrive

The main repository for the development of the evolution game Thrive.

Thrive

This is the code repository for Thrive. For more information, visit Revolutionary Games' Website.

Build Status

Patreon

Overview

Repository structure:

• assets: This folder contains all the assets such as models and other binaries. The big files in this folder use Git LFS in order to keep this repository from bloating. You need to have Git LFS installed to get the files. Some better editable versions of the assets are stored in a separate repository.
• doc: Documentation files. Contains style guide, engine overview and other useful documentation.
• simulation_parameters: Contains JSON files as well as C# constants for tweaking the game.
• scripts: Utility scripts for Thrive development
• src: The core of the game written in C# as well as Godot scenes.
• test: Contains tests that will ensure that core parts work correctly. These don't currently exist for the Godot version.

Getting Involved

Depending on what you want to contribute, you need to take different steps to get your development environment set up.

Read the contribution guidelines and code of conduct first. If you need help please ask on our forums.

There are also other useful documents in the doc folder not mentioned here.

If you have game development skills, you can apply to the team here.

If you'd like to translate the game to your language, you can find the relevant information here.

The planning board contains all issues and pull requests grouped by their priority and status. It can be found here.

Programmers

Thrive is written in C#. In order to work on the C# you need to compile Thrive yourself. You can find instructions for how to do that in the setup instructions. And if you've never used Godot before please read learning Godot. This repository also contains a few helper scripts written in C# for working on the game. These can be ran with dotnet: dotnet run --project Scripts -- help

Be sure to have a look at the styleguide, both for guidelines on code formatting and git usage.

Binary files should be committed using Git LFS.

Modellers, texture and GUI artists, and Sound Engineers

To work on the art assets you will want to install Godot and work on the project files with it. Instructions for that are the same as for programmers: setup instructions. And if you've never used Godot before please read learning Godot.

Alternatively some art assets can be worked on without having a working copy of the Godot project, but then you need to rely on other artists or programmers to put your assets in the game.

You should familiarize yourself with the Godot Asset pipeline.

To contribute assets you can contact a developer and provide that person with your assets and the developer can add the assets to the official repository. It will at a later time be possible to commit to Git LFS server yourself, currently it is limited to only Thrive developers. Note that you must have Git LFS installed for this to work. Any artists on the team should preferrably modify the project in Godot themselves and commit the assets using Git LFS.

Extra note for modellers: There are extra instructions for how to import models here: import tool

Miscellaneous

The history for this repository has been slightly cleaned up to remove large old binary files that were added before we used Git LFS. The original history can be found here: original_master

thrive's Issues

Design and implement a dynamic spawning system

For now, this is for the microbe stage, but it might be applicable for other stages as well. If possible, the design should take that into consideration. However, if in doubt, simplify in favor of a specialized version for the microbe stage.

The microbe stage is an open world in which the player can move around freely. This obviously requires dynamically creating "stuff" in the world so the player doesn't float around in empty space. That stuff includes

• Other microbes
• Collectible agents
• Obstacles (?)

The spawning system should be easily augmentable with new things to spawn. To save resources, it (or a complementary system) should also handle despawning entites that are too far away from the player to matter anymore.

Design and implement a mechanism for discrete game states

Eventually, the game will need to switch between different states. Examples for game states are "main menu", "microbe gameplay" or "microbe editor".

Each game state is associated with a set of active systems and active entities. Transitioning from state A to state B should follow this rough procedure:

1. Pause all systems associated with state A
2. Switch the set of active entities (?)
3. Resume all systems associated with state B

Implementing the entity switch could be achieved in multiple ways.

1. Let the EntityManager hold a flagset per entity indicating whether the entity is active in a particular state. When queried for a component, the manager first checks if the entity is supposed to be active. If not, it returns a nullptr.
2. Instead of filtering on queries, the EntityManager actually reorganizes its internal data on each state change.
3. Make the EntityFilter accept state flags in its constructor (or as template parameter, but that could get ugly real quick). The filter only keeps those entities that are active in the states it filters for. This would obviously require the EntityManager to keep state flags for each entity around as well.

Closing finished issues

There seems to be a bunch of issues that seem actually done but not marked as closed. Clearing them up would allow for easier finding of things to do. At first glance, they seem to be the following ones:

• Integrate OpenAl #53
• Make the mingw setup script log to a file #49
• Fix bug with oxygen emitter producing 2 oxygen on game start, on top of the player. #58
• Rename "Agent" to "Compound" #67
• Design and implement basic microbe AI #68
• Change vacuoles to be general storage and add let empty hexes store aswell #70
• Basic AI implementation #81

I'm personally waiting on #49 to see if it can be considered done, the other ones seem finished but i'm not sure.

Move binary assets out of git

Git doesn't handle binary files like zips, meshes and textures very well. They tend to bloat the repository, because git has to maintain a complete copy for each change that has been committed to the file. Besides, GitHub would like to keep each repository below 1 GB. If we continue putting binary files into the repository, we will quickly reach that.

There are a variety of options to keep binary files in one place and share them amongst developers and artists:

• Dropbox
• FTP server
• Perforce (free for open source projects)

Both the FTP and Perforce server could be set up on the build server, once we have such a thing.

Integrate OpenAL

Integrate openAL into the engine. The graphics thread seems like a good place, as sound should not take too much resources.

The script to install OpenAL and link it is done alredy (in the physics branch, wich should be merged soon)

Fix bug with oxygen emitter producing 2 oxygen on game start, on top of the player.

The oxygen emitter will instantly, when the game starts, emit 2 oxygen units somewhere on top of / below the player microbe (even tho the emitter is far away from the player) which the microbe will then instantly absorb.
You'll see the microbes process organelle be non-grey due to this. If you disable distribution of oxygen to processorganelles you will notice that 2 oxygen are stored from the start. You can verify that it actually is the emitter by removing the code that generates the emitter in setup.lua, and the two oxygen wont appear.

Define Microbe Interaction

After fleshing out the basic microbe structure (see #9), the interaction between microbes and their environment must be defined.

The environment consists of at least other microbes and inert nutrients.

• A microbe can ingest nutrients, destroying the nutrient and raising the microbe's energy level
• A microbe can absorb other microbes that are smaller than itself
  • Absorbing another microbe may release nutrients from the absorbee
  • Absorbing another microbe may give the absorber new traits
• A microbe may bond with other, compatible microbes to form a multicellular organism

Scriptable Viewports

As an addition to #14, add a script interface for adding, manipulating and removing viewports in the render window. This could be useful for showing the player events from another place in the world through a picture-in-picture.

The easiest approach would be to add an OgreViewPortSystem to the ogre engine and an OgreViewport class for the script bindings. The system should provide an interface for creating and removing viewports in a thread-safe way (e.g. with a SharedQueue). It should also apply any changes that were made to an OgreViewport since the last frame.

An OgreViewport should have the following properties, shared as RenderData:

EntityId cameraEntity;
Ogre::Real left;
Ogre::Real top;
Ogre::Real width;
Ogre::Real height;
Ogre::ColourValue backgroundColor;

Ogre::Viewports that belong to the same render target are uniquely identified by their z order, which is also fixed at construction of the viewport. To avoid scripting mistakes with duplicate z orders, the script side of OgreViewport should not offer a constructor. Instead, the OgreViewPortSystem should offer a function

std::shared_ptr<OgreViewport>
getViewport(
    int zOrder
);

This function should either return an existing OgreViewport or create a new one, queueing it for addition on the next frame.

Conversely, there should be a removeViewport method in OgreViewportSystem that takes an existing OgreViewport and removes it from the render target in the next frame.

Add performance profiling

Profiling is essential for identifying bottlenecks and optimization opportunities. We could use an instrumenting profiler like callgrind, but they tend to slow things to a crawl, possibly distorting the results and deterring developers from profiling routinely.

The alternative is manual instrumentation, which requires adding profiling instructions to the source code, telling the profiler what we are interested in. There is the Shiny profiler, but it is only suited for single threaded applications.

Then there is the High Performance C++ Profiler, described in detail in this blogpost. It's a little old, but probably still works.

Finally, we could roll our own profiling library, tailored to our needs. Getting this right will require some research to keep the profiling overhead to a minimum, so it's no small feat. But it would allow us to, e.g. render the profiling data in an overlay directly in the game.

Set up a workflow for art assets

The steps required to bring a model, texture or sound into the game must be documented. They should include:

Which file formats to use

For textures and sounds (see #35), this should be relatively straight-forward. For models, not so much, as Ogre uses its own custom file format for them.

I recommend using the OgreAssimpConverter which seems to work with many input file formats.
For the time being, we could tell modellers to use the frontend and move the exported meshes to the right location manually. Eventually, a more automated tool might be nice that converts the files and moves them to the right folder in one go, without much user interaction.

How to test the assets in-game

Artists should be able to easily test their work in the game. For that purpose, a few tweaks in the resource management might be in order, like adding a "test" directory in resources.cfg. Also, a way to reload assets in the game would be great to avoid having to restart the whole application.

Where to upload assets

This is closely related to #32. We shouldn't use git for binary files. It might work for the short term, but eventually, the repository will get prohibitively large, making cloning slow and bandwidth intensive.

Lua errors not giving useful information.

After gamestates were merged into the branch it seems that any lua errors will just give a generic error message instead of being moderately informative as before.

Generic error message looks like this:

terminate called after throwing an instance of 'luabind::error'
  what(): lua runtime error

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Commit ATP files to SVN.

I don't seem to have permission myself with the anonymous user.

Files:
http://www.mediafire.com/download/8h4r8j45krln93o/ATP.zip

Fix text allignment in HUD

Currently it seems impossible to allign text properly on the HUD even with formatting functions (see the ingame hud component for agents).

I'm fairly confident that the underlying problem here is that the "Thrive" font isn't monospaced. My verification of this is that i tried printing the same formatted text to the console and it looks fine there.

I see three solutions:

• Patch problem whenever it arises by creating multiple entities with TextOverlayComponents for each alligned part of the text.
• Switch to a monospaced font for all or some items on the hud
• Have the thrive font changed to be monospace.

Create a RandomManager class

Perhaps a better name for the class.

It appears we will need random generating capabilities several places in the codebase, so gathering the functionality at one place would be advantageous. Keeping track of seeds can become very useful and using the right methods important.

I recommend an interface something like this:

RandomManager(seed) constructor/init method
getRandomBetween(a, b) getRandom(vector)``getSeed()

A singleton or static class pattern could be used, but several different instances could potentially be useful in the future (mostly happens for multiplayer games, however)

I strongly recommend watching http://channel9.msdn.com/Events/GoingNative/2013/rand-Considered-Harmful to get up to speed with the new C++11 random generating features, and using those!

Make player movement in microbe stage more readable

Currently, players have very few reference points to gauge their movement speed and direction. Even if there are other objects on the screen, they might be moving, too, distorting the perception player movement.

To remedy this, design and implement a system for displaying "floaters". Floaters are small, mostly transparent particles that are overlayed onto the game world as if looking through dirty water. Those particles are dense enough to be easily visible without occluding the game world.

Floaters will not interact with other objects, but only react to player movement. They will always move in the direction opposite of the players'. When the player stands still, the floaters stand still also.

Write coding guidelines

The guidelines should include:

• Formatting rules (indentation, tabs / spaces)
• Naming style (case, descriptive names, m_ prefix for members)
• File system structure (file endings, where to put what)
• Comment guidelines (doxygen for public stuff, inline comments for private implementation notes)
• Git workflow (forking, feature branches, pull requests)

Add BOOST_ROOT and BULLET_ROOT to mingw toolchain file

Add the two lines

SET(BOOST_ROOT ${MINGW_ENV}/install)
SET(BULLET_ROOT ${MINGW_ENV}/install)

to the file mingw_setup/toolchain_win.cmake.in, then rerun the setup script and test project generation with CMake.

Process Organelles and Microbe homeostasis

It has been suggested that microbes attempt to achieve a sort of state where they eject extra compounds to try to achieve an appropriate ratio of wanted compounds.

As part of this, I think the processing organelle code should be cleaned up to follow this new structure.

In particular, the code for processing organelles should be migrated to processOrganelle:update()

instead of being hardcoded into the microbe, and should make use of the microbe's programmed methods to request compounds.

Fix bug with spawn system causing a crash after loading a save.

The spawn system will occasionally try to index what i suspect to be a no longer existing entity after having loaded. The reasoning i think is due to that entity being created in a now invalid timeline of the game and therefore no longer exists.

Merge prototype branch into trunk!

Hell, it's about time!

Add camera system & component

Currently, the camera is hard-coded in OgreEngine::Implementation::setupCamera. To make the camera properties scriptable, a CameraComponent should be created to enable entities to become cameras. The CameraComponent should have at least the following properties:

Ogre::Real nearClipDistance;
Ogre::Real farClipDistance;
Ogre::ProjectionType projectionType;
Ogre::Radian fovY;
Ogre::Real focalLength;
Ogre::Real aspectRatio;

The accompanying CameraSystem should create an Ogre::Camera if necessary and apply the above settings, together with position and orientation from a TransformComponent.

Modify MicrobeComponents to reflect how they will be created

Right now, microbes are entirely made up by their organelles. What is actually needed is:

The cell's shape (Which hexes are part of the cell)
The organelles + their orientation (organelles themselves already exist)
Any sort of texturing data (may be handled later)

Add Physics Engine

Add components and systems for simulating physics. The Bullet physics engine (http://bulletphysics.org/wordpress/) seems like a good choice.

For starters, a RigidBodyComponent would be sufficient. In the script API, properties like mass, friction and the collision shape should be configurable. There should also be a way to apply a force or impulse (possibly through a function, not a property). In the physics thread, a RigidBodySystem would apply the properties from a RigidBodyComponent to Bullet's own data structures.

Another system should handle the propagation of the physics position back to the script thread and into the TransformComponent.

Possible caveats: The propagation of the physics position from the physics thread over the script thread to the graphics thread could introduce annoying stuttering.

Add an AgentRegistry

To facilitate the management of agent types in the microbe stage, we need a central registry for storing information about agents. The information required (or useful) per agent is currently limited to

• id: A unique integer id, generated with generateAgentId and possibly different per game instance
• name: A unique string for identifying the agent across game instances. Should be in English and expressive, but short.
• displayName: A string that can be displayed to the user, may be localized some time in the future.

The list of properties might grow in the future, so the AgentRegistry should account for that. Users, i.e. script authors, must be able to easily register new agents as well as query information about already registered ones.

The simplest implementation can just be a table like this:

AgentRegistry = {
    energy = {
        agentId = generateAgentId(),
        name = "energy",
        displayName = "Energy",
    }
    oxygen = {
        agentId = generateAgentId(),
        name = "oxygen",
        displayName = "Oxygen",
    }
}

Plus a simple API function registerAgentType(name, displayName) that generates an agentId and inserts the necessary information into the above table.

let empty hexes store as well

Vacuoles should not be specialized storage as it is now, but be able to hold a mixture of compounds.
The discussion can be found in this thread from halfway down:
http://thrivegame.forum-free.ca/t997p150-microbial-compounds-and-organelles

Add apt package for 7za to mingw_setup/setup.sh

The mingw setup script for Linux is missing a command to install 7za if it's not there. For Ubuntu, the proper package to install is p7zip-full.

Design and implement basic microbe AI

Racing around with the player microbe is fun. For about 5 seconds. Let's add a little more variety and populate the world with more microbes.

To make them do something, we need some AI. For the moment, I think it would be enough to let the AI microbes chase after energy floating in the environment. If their energy storages are full, they should swim around idly until the storage is down to, say, 80%. Or they could chase and harass the player by bumping into him.

Compound models

For the Christmas Prototype, we could really use some models for compound particles. The planned compounds are:

• ATP: Energy, used for moving and some metabolic processes
• Glucose: Raw material for ATP
• CO2: Waste product of some metabolic processes and, raw material for others
• Sunlight: raw material for photo-synthesis
• RpAse: Reproductase, causes cell-divison / evolution at a certain threshold
• Oxytoxy: Poison, destroys RpAse

The models should be easy to distinguish from each other, ideally even for color-blind players.

Rock Textures

I have finished making some textures for rocks.

Rock Textures:
RT 1: http://i.imgur.com/YjMvIFS.png
RT 2: http://i.imgur.com/nqolsaH.png
RT 3: http://i.imgur.com/KceCjOl.png
RT 4: http://i.imgur.com/DD46bCg.png

Download Link:
https://dl.dropboxusercontent.com/u/137682043/Rock%20Textures%20Set%201.zip

Define Basic Microbe Structure

Before implementing actual gameplay, we require a basic model of how microbes in the game should behave. To get that moving along, I propose the following structural model. Most of this is gleaned from the Microbe Stage Final Draf.

A microbe has a basic shape, either

• Sphere
• Rod
• Comma
• Spiral

A microbe has these "attributes":

• Size
• Maximum movement speed
• Acceleration
• Nourishment level

A microbe has "traits". These traits may modify the microbe's appearance and / or grant additional abilities or bonuses. Examples are:

• Flagella: Increases movement speed
• Cilia: Increases movement speed
• Pilus: Grants a poisonous spike
• Sticky Enzymes: Enables multicellular structures

Traits should be implemented as extensibly as possible. The above linked thread has many more examples of traits and knowing designers, they will come up with even more.

Traits may exclude or prerequire each other.

Traits take up space in the cell. A cell's size must be greater than the sum of its traits' sizes.

Proposal: Make Microbe:storeAgent "drop" any residual agent behind microbe.

Instead of returning the remaining amount of agent and leaving it up to the caller of Microbe:storeAgent to do something with the residue. Leaving it up to the caller is certainly more flexible, but there is already code where nothing is done with the residue and it would be bothersome to have to manually "drop" it every time you call the function, as this is what i see having to happen almost every time.
I just reached a point while working on #41 where i don't know what to do with agents produced by a ProcessOrganelle that the microbe can't absorb.

I'm not sure how this would be implemented exactly, perhaps a call to a SpawnSystem somehow to queue a drop.

Implement organelles for processing agents into other agents

To simulate a simple metabolism inside a microbe, organelles for transforming agents (materials) into other agents (products) are required. These ProcessOrganelles should take a set (but configurable) amount of materials from their microbe with Microbe:takeAgent and, if enough materials are available, store the products with Microbe:storeAgent.

To make the process configurable, the following API functions are suggested:

ProcessOrganelle:setMaterialAmount(agentId, amount)
ProcessOrganelle:setProductAmount(agentId, amount)

The material and product amounts are stored in a table. The ProcessOrganelle:update() function iterates over the material table, checking if a sufficient amount is available. If yes, it takes those amounts from the microbe's storage organelles and stores the product amounts in turn.

Light System

Create an OgreLightComponent with the following properties (shared as RenderData):

Ogre::Light::LightTypes type; // Point, directional or spotlight
// Colors
Ogre::ColourValue diffuseColor;
Ogre::ColorValue specularColor;
// Attenuation
Ogre::Real attenuationRange;
Ogre::Real attenuationConstant;
Ogre::Real attenuationLinear;
Ogre::Real attenuationQuadratic;
// Spotlight
Ogre::Radian spotlightInnerAngle;
Ogre::Radian spotlightOuterAngle;
Ogre::Real spotlightFalloff;
Ogre::Real spotlightNearClipDistance;

A complementary OgreLightSystem should apply those settings to the respective Ogre::Light, creating one if necessary.

Update locking in OgreEngine::update()

Use the SharedLock template for exception safe locking

Compile a christmas prototype!

It's time to get it out there!
It should include the master branch, the AI branch and possibly the sound branch!
I'll look into it, but if anyone else have comments let me know!

Add GUI components

GUI elements like buttons, text input or simple labels will be needed throughout the game for menus and HUD elements. They should be completely scriptable in both creation, modification and event handling.

Steps to implement:

1. Select a GUI library that plays well with Ogre. CEGUI and MyGUI look alright, but there may be better alternatives.
2. Add this GUI library to the build setup scripts
3. Implement some basic components for push buttons, labels, text input and other widgets, along with accompanying systems to create, update and destroy them
4. The GUI systems for updating the widgets should run in the graphics thread
5. The GUI systems for propagating events from the widgets to the script will have to run in the script thread

Speed up compiling

I'm not sure whether there is a solution too this, but compilation for me is really slow. I don't know whether it is just that g++ links slowly or that something is wrong with the program. Whatever the reason, if there is a way to fix it that doesn't break anything, it would be nice.

Example: As a test, In Game::Implementation, changing unsigned short m_targetFrameRate from 60 to 61 compiled in 1 minute and 14 seconds on my computer. Changing it back (as a second test run) took the exact same amount of time.

If I make no changes at all, compiling took around 6 seconds. That also seems rather long considering that the program should only be checking the modification dates of files, but if there are a lot of files and the files are scattered across the hard drive, I can see it taking this long.

But for the 1 minute and 14 second compiling, I hope there is a way to fix that. If there is not, feel free to close the issue, but I feel like as the project gets bigger and bigger (more than just the cell stage), compiling is only going to take longer and longer.

Suggestion: Perhaps there is some optimization going on during the linking phase that takes a while. Is there a flag to disable that?

Write tutorials for script authors

Providing script authors with instructions and examples on how to achieve certain tasks will help in bringing more people onboard for development.

Basic tutorials should include:

1. Short Lua primer
2. Introduction to entities and components
3. Creating a visible object in the game world
4. Making it move
5. Adding light
6. Viewports and cameras

Whenever a major component is added, like physics, GUI or similar, the tutorials should be updated to provide a short introduction to it.

Add documentation about building Thrive in Linux

That documentation should list all dependencies (with versions) and common caveats when compiling them.

Additionally, an automated bash script (similar to the mingw_setup) would be nice. The documentation is still essential, though, because the script might not work as expected on all distributions.

Make the mingw setup script log to a file

For troubleshooting, it would be very helpful to log the output of the setup script to a file that users can upload for diagnostics.

The start-transcript and stop-transcript cmdlets may be useful for this, but they have problems as detailed in this bug report. One of the workarounds listed there might be interesting.

Implement new textures for compounds

Please notice NickTheNicks comment below

The textures can be found here: http://s1016.photobucket.com/user/sciocont/library/CellstageSprites

We are currently just using pure models for compounds so changing to a texture approach isn't completely trivial. I don't currently have enough knowledge about ogre to make this easily, so perhaps someone else will be able do it.

I'm also personallly having issues with SVN, not sure if this is a problem on my side or the server, but the textures will need to be added to SVN aswell.

Implement debug drawing for Bullet

Bullet offers a feature to hook into a graphics engine and draw stuff that's helpful for debugging, such as collision hulls and contact points.

Unfortunately, we can't use the btIDebugDraw interface to directly draw into the scene, because Bullet and Ogre run in separate threads. So we need an adapter that "records" the draw calls in the Bullet thread, transfers them through the script thread to Ogre that eventually consumes them.

A good starting point for consuming the draw calls is the BulletDebugDrawer.

Include compound models from #78

They need to be added to the assets SVN and implemented in the scripts.

Add CPack targets

With some configuration files, CPack can easily generate various distribution formats. Most interesting for us would probably be zip and NSIS installer.

Ogre and Components

Currently, our systems all create their own Ogre::SceneNodes when necessary. See for example MeshSystem::update, where for each entity that has a MeshComponent, an Ogre::SceneNode is created.

This could prove inefficient if an entity has multiple components that all require an Ogre::SceneNode to function. Those components should share a scene node. To that end, we should introduce a new Component, aptly named OgreSceneNodeComponent. This component would not need any properties (at least not yet), but would only hold a pointer to the Ogre::SceneNode. All systems that require such a scene node, like MeshSystem and the proposed CameraSystem (see #14) could add OgreSceneNodeComponent to their entity filter to gain access to the underlying Ogre::SceneNode pointer.

There's a potential problem with adding and removing OgreSceneNodeComponents. When such a component is added to an entity, the accompanying Ogre::SceneNode should be created before any other systems are run in the OgreEngine, so that they all have access to a valid pointer. On the other hand, when an OgreSceneNodeComponent is removed, the accompanying Ogre::SceneNode should be removed after the other systems have been updated, because those other systems may access the pointer to do cleanup work.

A possible solution would be to create two systems, one for creating Ogre::SceneNodes that is run early, and one that removes them and is run late.

Implement functionality for reacting to collisions.

There currently seem to be no way to add custom functionality on collisions, such as actions when microbes attack eachother, so i'll attempt to include it. I already have some very simple working code.

I'm thinking of making a CollisionSystem that relevant collision events are added to and then handled with the update method.

The way to add functionality in bullet seems to be to define a global callback function and assign the global variable gContactAddedCallback to it. That global variable will then queue the events to the CollisionSystem.

Aspects to figure out:

• Encapsulating the global bullet aspects (should be easy enough)
• Differentiating between which parts of an entity are colliding, attacking parts, passive parts etc.
• Order of reacting, who collided with who.
• Which components to give the CF_CUSTOM_MATERIAL_CALLBACK flag
  Will have to find a good way to encapsulate this.
• Getting a handle to the system from a global function (seems to go against the engine design tho) to queue collisions. The "correct" way to do this would be not to get a handle the to system and instead use an entity for each collision, but with the high amount that will be occouring seems too ineffecient.

Add code to properly remove process organelles.

I forgot to do this when i first added process organelles.

What needs to be done is to add a "removeProcessOrganelle" to the microbe class and add a "onRemovedFromMicrobe" handler to the process organelle that calls the removeProcessOrganelle function.
Look to the corresponding functions for storage organelles for how to do this.

Add a HUD element for displaying all agents stored in the player microbe

Add a system for continually updating a TextOverlayComponent to display all agents that are stored in the player's microbe.

Add a named entity "hud.playerAgents" and attach a TextOverlayComponent to it. Give it a size and position somewhere in a corner.

To find out which agents are even stored by the player, you can iterate over the vacuoles table inside the player entity's MicrobeComponent. Use the AgentRegistry described in #42 to find a suitable display name for the agent and the Microbe:getAgentAmount function for finding the current amount, then construct a string that displays the information in a suitable format.

Add a drop-down console for run-time Lua scripts

The ability to run arbitrary Lua snippets during runtime would be a great tool for debugging and tweaking.

There's an example implementation of an Ogre console here that could possibly be adapted for our purposes.

The control flow would go something like this:

1. Receive input from console in the graphics thread, put it into a SharedQueue
2. In the script thread, execute all the queued strings
3. Send back script output over another SharedQueue
4. In the graphics thread, update the console to display the script output

Rename "Agent" to "Compound"

As noted in this forum post, agents are a special case of compounds. To avoid confusion and miscommunication between programmers and designers, all current occurences of "agent" should be replaced by "compound".

This includes:

• Renaming the components and systems defined in src/microbe_stage/agent.*
• Renaming the files src/microbe_stage/agent.* to src/microbe_stage/compound.*`
• Searching all scripts inside res/scripts/microbe_stage for occurences of "agent" and replacing it with "compound"