Releases Roadmap

This is an overview of all planned features for near future release versions, with progress tracking for each. Though this page will be frequently updated, more accurate information can be found on our GitHub page and development forums.

Discussion on planned features is ongoing here.

New members (having read page on Getting Started) should take a look at upcoming features and consider which they'd be best suited to tackle. Alternatively, you can suggest a feature to work on not yet considered.


This is a preliminary outline of which features are being worked on and what targets we're aiming for in future. All are subject to change based on feasibility and availability of time/resources.

Items with a strikethrough have been completed to a satisfactory standard. Items in bold are the most important features for a particular release version.


  • Basic agent production
  • Agent environmental diffusion
  • Refactor engine to remove lag
  • Bacteria and bacteria swarms
  • Options menu
  • Basic rewrite of the CPA code
  • Fluid simulation carries microbes around
  • Rescaled organelles
  • Updated flagellum model
  • Organelle endocytosis
  • Microbial biomes


  • Overhaul of combat system
  • Loading screens


  • Full CPA system implementation
  • Dynamic membrane
  • Full tutorial
  • Basic balancing


These are features which may fit into any release whenever we finish them.

  • OSX support
  • Editor improvements
  • Bloom and blur visuals
  • Improved AI

Release Process

Thrive has no release schedule, and cannot have one due to the voluntary nature of the project. As a result, we have little idea how long a certain update will take to complete. Generally we set a series of features we'd like to have in the next update, and once those are completed with as few bugs as possible, we release. Often several other features will be completed in the intervening time anyway, allowing us to update our release notes and plans and provide a fuller-feeling release.

When we appear to be approaching the completion of all set tasks for a release, we designate a vague time for publishing it (usually a certain month) and work to lock down features in time. Once all features are added, we make a test release candidate available, posting it to our community forums and elsewhere so fans can find bugs and give feedback on the new features. Often there may be several of these candidates posted each time major bugs are addressed. This process can take a while. Once satisfied that the release is stable, we prepare release notes for the full release. At the same time, we write an accompanying Devblog and create a trailer showing off the new features (using footage captured by developers and fans from the release candidates). A final release date is set, and the current version is pushed to GitHub under its release list. The Downloads page of the website uses a custom API to present the releases from GitHub in reverse chronological order, with the most recent at the top.

In summary, here are the actions taken at each release point:

  • Verify the launcher works with the new release
  • Prepare trailer
  • Prepare Devblog (REMEMBER to add exceprt)
  • Write release notes
  • Publish release on GitHub
  • Publish update to launcher configuration on GitHub
  • Publish trailer to YouTube channel
  • Publish Devblog to News page
  • Link release notes, Devblog and trailer to each other
  • Update website front page trailer
  • Post to community forums
  • Post to the community discord
  • Post to subreddit
  • Post to ModDB
  • Post to Facebook and Twitter
  • Update releases page of Wiki
  • Update releases post on development forum
  • Remove release features from this page
  • Remove release features from this thread
  • Post everything to Facebook and Twitter again because nobody will see it the first time

What to Work On

Our team policies state that anyone is free to work on what they wish, though final contributions will always be reviewed by a senior team member. If you apply and post a thread in our Introductions category, developers can give you suggestions of what to work on based on current progress towards the next release. All team members except programmers should use the development forums as guidance of what to work on.


Wiki page: Programming Team

Programmers are the most vital team members, but often the most difficult to get up to speed with development since we need to introduce them to the codebase. Team leads will happily help here.

The most valuable roadmap resource for programmers is the issues list on GitHub. Some issues are features intended for near future releases, while others are bug reports which need addressing. Any programmer is welcome to work on any of these as long as they have the required skill level.


Wiki page: Graphics Team

Many upcoming features involve visual assets or updates, giving artists and graphic designers of multiple disciplines options of what to work on.

3D modelers can work on organelles, environmental objects and, if they're skilled with animation too, procedural microbe membranes. Animators will be responsible for making these items function in the game, working closely with programmers. Vector artists are most valuable as GUI designers, also working with programmers to change game functions. All these and more may be suggested by team members in an introduction thread.

Game Designers

Wiki page: Theory Team

Game designers are often not concrete roles, but instead game design is shared amongst all team members (with theorists, the most knowledgeable about a topic, in charge). All game mechanics should be ironed out before being sent to the programmers and artists for creation.

While many overarching mechanics have already been decided upon, the specifics are always up for debate until added to the game (and, in some cases, afterwards when a feature receives updates). Thus, game designers can always jump into a topic on the development forums and make suggestions, providing they're insightful and useful.


Wiki page: Theory Team

Specialist theorists should work with other game designers to decide on mechanics, taking into account both the simulation aspect and the need for effective game design. Theorists can also produce prototypes of game or simulation mechanics, even features intended for much further down the line.

Sound Engineers

Wiki page: Sound Team

Sound engineers are responsible for sound effects and the functionality (but not composition) of music within the game. Often this may limit available tasks, so talk to a senior member for more suggestions based on current progress.


Wiki page: Sound Team

Since the soundtrack for the Microbe Stage is effectively complete, musicians are in less demand at the moment, but there are still possible tasks to complete. Unlike other disciplines, musicians can compose themes for any stage of the game in preparation for later scenarios.


Wiki page:Outreach Team

Promotion works very differently to most other roles, since it isn't tied to game development progress. Promoters should work to keep social media outlets up to date, highlighting interesting discussions from the development forums or elsewhere, as well as working with other team members to organize release scheduling.

Promoters should also interact with fans and the community in all locations.

Web Developers

Wiki page:Outreach Team

Web developers are responsible for maintaining our various websites, both functionally and visually.

Technical Writers

Wiki page:Project Management Team

The main task for all technical writers should be keeping this Wiki up to date, with additions based on discussions on the development forums. Certain pages will need to be updated regularly, while others can simply be created as summaries of forum topics and their conclusions. This will largely be game mechanics.


Wiki page:Project Management Team

All moderators and project managers should make sure the rest of the team are doing what they should be doing. Use the Wiki as a guide for everything.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License