From outside the project, it might appear as if things have moved slowly over the summer. But we’re still going. The trouble with this period is a lot of work has gone into under-the-hood changes – that is, the Thrive game engine.

Before we delve into the issues with the engine, we should tell you about a few visible features that have been added. New programmer zyad137 gave us the suicide button, a handy device for offing yourself if you run out of ATP or want a change of scenery. He’s also provided notifications for organelle pickups and improved AI, and is working on a hints system to help players understand what they should do next. Developer crodnu also added improved camera zooming ability.

Engine Change Attempts

The Thrive engine has come under a lot of criticism in the past. Many have suggested switching to another engine, so we gave it a shot and put a lot of work into making that happen (as we said in our previous Devblog).

Attempts So Far

Some criticisms identified the lack of documentation and tutorials for setting up a developer environment, a major factor in our poor retention rate of new programmers. And there are currently many open bugs related to full-screen issues, audio issues and input issues for some Linux users. These are all things we hope a new engine will fix, or at least make fixing the bugs easier and faster.

First we investigated Unreal Engine 4 as a potential candidate. The engine switch thread goes into detail about our reasoning. The most important issues for any new engine are it being free and giving developers source access. We made some progress but soon found our needs weren’t being properly served. There were complaints about it not being truly open-source – which it isn’t, as it lacks a proper open-source licence for editing the engine – and we encountered yet more strange and inconsistent behaviour on different developers’ computers. The combination of weird bugs so early in production and licence worries led us to abandon our attempt to switch to UE4. So that was a lot of time wasted for little public gain.

Another frequently suggested engine is Godot, but even a quick attempt at using it revealed the shader editor was woefully inadequate. Even the basic scrolling background proved impossible to make. The scripting language is also unique to Godot with a very specific way of organising all game objects into scene trees, completely different to the approach our current engine takes, so porting existing work would be needlessly difficult and time-consuming. And it may be argued that the Godot scene format is not a good choice for our use case.

Instead of switching to a different engine and having to redo everything, our latest attempt uses Leviathan Engine, which uses most of the same libraries (middleware) as Thrive and it too uses an entity component system to organise game objects. It’s also written by one of our developers, hhyyrylainen, who is committed to modifying and the improving the engine to allow as much of the existing Thrive code to work as possible with minimal adjustments. There will however be a switch from Lua to AngelScript. This should prove a much easier port than any of the other suggestions (or any other open-source engine). There’s already been some work towards converting Lua code to C++ so the actual impact of using AngelScript should be less than you might expect.

Here’s our opening cutscene within this new engine, and if you’re interested, this is a screenshot of some of the work hhyyrylainen’s been doing for it.

There has been some uncertainty about this switch, especially over the possibility of a new engine becoming unmaintained. This is effectively the situation of our existing engine though – the developers who wrote it are inactive and few of those left understand it enough to maintain it properly.

As the instigator of these attempts at switching, it’s also worth considering hhyyrylainen’s personal reasons behind the latest approach. Working on a single engine which benefits both Thrive and his own projects and spending more time on the main engine instead of inefficiently copy-pasting parts which work better in Leviathon anyway make it a good decision. Pull requests for the engine related to Thrive features will also be accepted relatively liberally.

Improvements of the New Engine

The new engine will have more documentation, and hhyrylainen plans to write further documentation and tutorials for specific common tasks. This is more than can be said for what we have in the existing engine.

It also provides continuous integration and extensive unit tests. Continuous integration in Thrive, constantly building Thrive on servers and reporting the build status each time, would be a great bonus for our developers, and more unit tests will be written after the switch. Consequently, we’ll notice error-generating changes much more quickly.

Meanwhile, the setup procedure will be almost fully automated with a brand new setup script. This may still cause problems as it needs tweaking for Windows systems and developers might have different tools installed causing conflicts with the script’s process. And there’s no one available to maintain the MinGW setup version, so Windows developers will need to install Visual Studio 2015 Community to compile Thrive. However, we feel these are an acceptable price to pay for the benefits a new engine would bring.

Any engine switch also presents an opportunity to document and optimise existing code as each section is adapted to a new environment, which is always a bonus in the eternal coding struggle.

So, what does this all mean for the future of Thrive?

If all goes to plan (and it’s still a big if, since the process is ongoing) we’ll arrive at an engine that’s more reliable, more adaptable, quicker running, easier to maintain and properly documented. It may not be as glamorous as a new GUI or compound clouds or any one of the myriad features put on top of it, but a solid engine is a solid foundation from which we (and you, if you happen to have programming experience and want to help) can construct the someday towering skyscraper of Thrive.

And we’re not using UE4 anymore. Just in case anyone was still under that impression.

Other News

The gears of the Thrivosphere keep on turning outside of programming too.

Project Restructuring

It’s not only the code that’s being taken apart and rearranged into a more efficient form. When NickTheNick returned from a short hiatus recently, he brought with him a new outlook on how to run the team and project. Anyone watching the development forum will have seen a flurry of threads and posts about workflow, outreach and release planning.

Though we’re still working out the specifics, the proposed new workflow is as follows:

1. Someone brings up an idea, feature or improvement on the development forums with a new thread. There follows a discussion on how we might go about implementing it. Ideas could be theory-related, outreach-related or anything else that merits discussion.
2. When the concept is complete, we create an issue on GitHub and assign it to a person and/or release milestone, linking the discussion that spawned the idea. We’ve created a new section of the GitHub repository dedicated to Thrive organisation, where we’ll post about non-programming tasks. Expect to see many links to this across our sites in the coming month.
3. When the issue is resolved and a new feature added, an outreach plan implemented or other item completed, we write a wiki page describing it for documentation purposes.

It’s not set in stone, but we hope this approach can lead to a more efficient workflow, even in the face of the Thrive project’s usual variability in member availability.

Release 0.4.0 and Upcoming Outreach

As you can read in this thread, we’re preparing for the release of Thrive 0.4.0. Yep, if all goes to plan, we think the next release will be major enough to warrant another jump in secondary version number.

What will be included? For starters, all the small features mentioned at the start of this Devblog. And the enormous engine switch this post has been dedicated to. Then we’re switching focus entirely to gameplay, because, as we’ll be the first to admit, Thrive isn’t exactly fun right now. Swimming around for compounds and avoiding predators gets boring fast. The biggest element which could change this is proper combat mechanics – cells will use pili, agents and engulfment to stab, poison and swallow respectively, giving the need to outwit, outmanoeuvre and out-evolve opponents.

Bacteria are also planned. These swarms of tiny organisms will secrete organic compounds into the environment and replace our temporary organelle unlocking mechanism with endocytosis, whereby a eukaryote can engulf a bacterium to gain mitochondria and other organelles. The holy grail of new features this round would be extending the fluid dynamics which already push compound clouds around to affect cells as well. This would give the player and AI more options, such as passive drifting in the currents instead of a rapid-fire predatory lifestyle, and generally provide more interest.

Release 0.4.0 will come with a two-stage outreach plan. Once the engine upgrades are finished (or at least in a presentable state), we’ll target game development forums and spaces looking for new programmers to help with the features for 0.4.0 and beyond. Once all of 0.4.0 is finished, we’ll expand the promotion to the internet in general, hoping to bring in fans and developers together.

Social Media Activity

We’re in the process of adding a few more members to the social media team so we can post more regular and varied updates to all our channels. They’ll scour development activity and post at least a few items per week, keeping activity up. One example is the Thrive Art Competition running on the community forums, which as it happens just completed its monthly cycle. This means we have August’s winners to show. The first image is by Atrox and the second by MirrorMonkey2.

Our YouTube channel will also receive more attention, with extra development updates and even explanations of game concepts like the CPA system. Watch this space. And speaking of YouTube…

Music

Finally, we again have some new music to show you thanks to Oliveriver, our head composer. Enjoy, and we look forward to seeing you in the next Devblog.

Discuss this post on our forums.