Switching engines

Update: see the latest post: Switching engines

It’s time again to discuss about the choice of engines, properly this time, as this topic seems to come up a lot.

I’m willing to try to create a small demo (possibly a cut down version of the current cell stage) in Unreal Engine 4 to see how good it would actually be. That’s why this is for real this time.

These are the pros as I remember / can think of right now:

  • Fully debugged, fully featured commercial grade engine (this should get rid of all the weird audiomanager crashes and fullscreen issues)
  • Very good editor with graphical editors for materials and probably some graphical way to tweak settings like processes and compound spawning
  • (Probably) every graphical effect or thing has been done before so we can look up examples of how to do things
  • Source access so that if we actually need to modify the engine we still can
  • I’ve done procedural mesh generation in ue4 before and it worked great. It required a custom mesh class but no changes to the engine
  • Easier setup process: we can just tell new people to google how to get started with unreal engine 4 and they should be good to go
  • Non-programmers can do more stuff like importing assets, and some might even consider using blueprint (it’s a visual “programming” language, which I’ve heard can “fool” non-programmers to actually do programming)
  • It wouldn’t cost anything as only after earning 3000 dollars would we have to pay royalties. and donations don’t count as revenue so that’s also a plus

So basically faster development (hopefully)

And the cons:

  • If we change the engine code, people on windows won’t be able to use the official unreal engine releases. This may be a big deal breaker so we should probably avoid having to change the engine.
  • Unreal Engine doesn’t use exceptions and the build tools are quite weird with external libraries. So we probably cannot use anything external, but if we stick to json and other things that unreal engine has we should be fine.
  • We need to write a tiny bit of legalese regarding the engine files in releases. Also we cannot ship any raw / uncompiled content or parts of the editor (so anyone who wants to work on thrive has to register for unreal engine and download it themselves)
  • Their user agreement is pretty long and there might be some surprise I didn’t manage to see (but this project doesn’t seem to have any issues being open source: https://github.com/tomlooman/EpicSurvivalGameSeries ) so we should be able to distribute anything that we make (we can’t use any premade assets, or at least put them on github)
  • Everyone working on thrive will need to create an unreal engine account (which is free and fast to setup)
  • and of course we need to scrap a whole lot of work and redesign the game architecture completely (unreal engine doesn’t use the same component pattern) which may be the biggest reason besides everyone being lazy, to not do this

So basically the daunting task of reading the unreal engine license and following it (I think we should be able to keep everything we code ourselves open source, unless it’s an engine modification) and of course the feeling of having wasted previous work.

Before, after discussing the following points nothing has happened so now I’m actually willing to do something about this. The reason I recommend trying unreal engine 4 is that it’s completely free for us as we aren’t going to be making any money and it takes only a little time to register on the unreal engine website before you can download the engine releases or download the source code (yes, thrive would still use an open source engine).

I wanted to let everyone on the team know beforehand so that we can discuss this possibility of switching engines, fully serious this time. And everyone can raise their concerns before anything is done.

So, thoughts?

1 Like

It will (hopefully) also make our interactions with linux less painful for everyone involved xD
Also the engine should be more optimized than ours (hopefully with some degree of parallelism in things like the physics engine)

I don’t really have much to contribute here, I just want to say that if you are really going to build a demo version of the game in Unreal, then I wish you the best of luck and please never leave this project.

Also, since there’ve been discussions on this in dev voice chats in the past, we could aim for another one this weekend if you want conversations with the programmers in real-time. Not a necessity obviously but it’s something to consider.

Can you say a bit more about what this means? I don’t really understand.

How long do you think it would take to get back to where we are now? Are we talking a week or a month or a year?

I think there’s a lot of upside, easier access for new programmers being one of the main ones. However it is a pretty big change of direction. A prototype would be very convincing I think.

Once you register an account you can download the unreal engine source code. So it is possibly to modify the engine and compile it from source, but then everyone has to compile it from source as they cannot use the official releases.[quote=“tjwhale, post:4, topic:340”]
How long do you think it would take to get back to where we are now? Are we talking a week or a month or a year?

I’m estimating that for quite a complete prototype it would take about 2 weeks and full feature parity about a month maybe a bit more if I’m the only one working on this.

I’ve found one more slightly tricky thing: deciding how to split things into github and svn as the unreal engine assets and blueprint files are binary files and git doesn’t work that well with them. So that might be slightly tough to set up a system that makes sense.

1 Like

We should be able to have a pilus when finishing as well, since it seems like it would be easy to implement (the reason i haven’t done that is because our engine’s physics engine and bullet are a complete mistery to me xD)

UE4 uses visual studio for compiling in windows, what compiler is used on linux? Would there be weirdness between the two?

1 Like

Unreal uses clang on linux. Other than some really weird issues with linking external libraries I’ve had to issues. I don’t recommend us trying to use any external libraries because it’s such a pain to set up.

1 Like

I just realized that we will have an issue with licensing as we cannot put our code under GPL license. MIT, BSD and other license would be fine.

The only problem with MIT is that it doesn’t prevent the reuse of our code in commercial applications, meaning someone could take our code and make a competing game out of it. If there was a license that would allow us to combine our code with unreal engine but didn’t let other projects use the code, that would closely match what we have now. That is if we want that or we are fine going with MIT and maybe adding a clause prohibiting thrive code from being used in closed source games (to prevent anyone using our code commercially)

This is what I have so far

(the red arrow points towards the mouse)

I won’t have much time to work more on this until next week so this might be the only progress update until then.

1 Like

Just clarifying, the game will still be open source, right? People will be able to modify the code and possibly turn it into their own game, it’s just that they can’t use the code commercially?

Yes, it will be open source, but people will obviously additionally need to download unreal engine before they can build the game.

I was referring to the non-commercial thing because right now there’s a GPL (license) slapped on the thrive code which means anyone using the code must open source their whole program (even parts that aren’t from thrive). And that’s obviously incompatible with using a proprietary engine (like unreal) so we need to use a different license. If we just use the MIT or BSD licenses the code could be used in a closed source game. I’d be fine with that, but some might not be and that’s why I brought this up.

I just tested creating a release folder and I was quite worried as it was 600 MB, even though it was an empty project. But luckily it hadn’t stripped the debug information so when I stripped that I was able to zip it down to 45 MB, which is pretty good and even smaller than the current releases (but of course I haven’t added the assets yet)

I’m in full support and the time frame doesn’t seem too detrimental and could significantly be cut down if we get multiple people working on it. I’m about to fly out of country for a month so probably will have very little time to actually code. After that though I will be starting my summer 9-5 and will actually have free time again.

Got some movement working and started putting in the backgrounds.


I spent lots of time today trying to get a moving thing with a generated mesh working. I got it finally working when I found out that I need to create some specific type of extra physics geometry that works on moving things. That was really fun to figure out but now the moving cubes should be easy to replace with any procedurally generated thing.

Here’s a video:


This is great, the progress you are making is tremendous :slight_smile:

Great! Though something seems a bit off about the bubbles and the parallax, but I can’t put my finger on it…

Unreal uses a different scale for coordinates so I had to guess by how much to multiply the speed by and I ended up using 10. Also the movement speed is probably different as I haven’t tried to make it the same.

Or were you referring to it looking different in some other way? There’s the automatic exposure that I haven’t tweaked so the brightness is different also the blending of layers might be slightly different. There’s tons to do and that’s why I haven’t worked on these little details, yet.

I’ve now made a windows 64 bit demo program for testing how it runs: https://boostslair.com/files/temp/thrive-ue4/

A screenshot of the membrane:

It works fine, but you can actually squish under the box using the other microbe. I think you can lock the z coordinate in the engine?