I’ve tried everything I could find by googling but it seems none of the methods actually properly lock it. When using the physics based movement then the locking actually works. Teleporting back to the starting z position is probably the right workaround when not doing physics based movement
Everything seems to be working, but movement feels odd and I can’t really explain how. Perhaps once sideways movement is limited by flagella it’ll feel correct.
Yeah, the current movement is different than how it was before, I did implement an additional movement move that feels quite a bit more like it is now, really floaty.
The progress on this has been astounding. Why is it all so quick? Is it in part because you know exactly what you’re building so it’s more straightforward than building it the first time? How much easier would you say it’s been working in Unreal than working with the current engine? Have you found anything particularly difficult or time consuming with unreal?
Should we be questioning this??
Also great job @hhyyrylainen. Making really amazing progress.
1 Like
Pretty much all of the “standard” stuff is really easy and fast to make with a proper editor. Like this is the GUI editor which is much faster to use (and someone who doesn’t want to touch any code could edit the main menu) than editing like 3 separate files:
And the material editor is an absolute pleasure to work with and reduces weird issues with textures so much:
But then things that are uncommon are very difficult to find out. Like using dynamic meshes as a moving character took me an entire day and reading through tons of slightly related threads.
Also I don’t think I’ve benefited that much from the earlier code as I haven’t done these things before, but I did almost completely reuse the membrane generation. I think the quick progress says quite a lot about how easy it is to use an engine that has so much documentation and large premade functions.
3 Likes
I just found out that their intro video player doesn’t support linux. So time to try to port my ffmpeg based video player to unreal.
1 Like
Progress update: I’ve managed to integrate the video player from the old engine and with the help of an external sound library it is now working. Next up I’m going to make everything work on windows and write setup instructions to hopefully help others to get the new version building and hopefully help me with putting in all the features.
1 Like
I’ve now finally gotten everything working on windows again:
I’ve also written a build tutorial for the ue4 engine version: https://github.com/Revolutionary-Games/Thrive/blob/ue4/BUILDING.md
1 Like
Great, i’ll try that tomorrow.
There’s also this thread now: http://thrivegame.freeforums.net/thread/1415/thrive-engine-switch-unreal-tech
Hey guys, I’m sorry I’ve been awol for like half a year, this last semester kicked my ass and I just finished moving to my new place. This thread caught my attention a while back but I haven’t been able to really say or do anything about it. I love the idea of switching engines, and based on this thread its clear that UE4 is a perfect engine for us, its fast, easy to use, powerful, and anyone, from artists to programmers to everyday people can use it. I’ve been using it for about a year now to work on personal projects, and I would love to help out if we make this switch. The blueprint system is user friendly, and again, from this thread its clear how fast progress can be made using this engine. Anything that I can do to assist with this, you just say the word.
1 Like
Got back on track doing new features on the ue4 branch after spending a week messing with setup script stuff.
This is my new compound cloud which supports packing 4 clouds into one texture, which hopefully is actually better than before when (I think) every compound type needed their own cloud for rendering:
That’s a single cloud that has compound 1 on the top and compound 4 on the bottom (they could also be at the same spot when they are mixed, but I think this shows it off better)
2 Likes
So last weekend I had a look at the situation with Ogre (related to another project and not really specifically for thrive). I found out that Ogre 2.0 isn’t going to get updates and it’s basically obsolete and perhaps some of the issues we had with it was caused by this. Thus if we don’t switch to unreal we would have to update to Ogre 2.1 to keep up with new stuff (and that, too drops support for really old graphics cards).
Also that switch wouldn’t be the simplest as Ogre is heading towards not letting users mess with rendering as much: shaders are hidden much deeper and there’s a new shader block system (High Level Material System) that requires rewriting how our shaders work.
And that new version of Ogre has quite easy to use support for PBR (the same type of look that ue4 has by default) and an open source material editor: https://github.com/spookyboo/HLMSEditor. So really the biggest thing we would be missing is the full blown editor (with gui editing, asset importing etc.), which lets non-programmers add assets and other stuff to the game. So I still think this engine switch is required in order to speed up thrive development, but maybe I’m leaning a bit less towards unreal now that I’ve looked at the new Ogre stuff and the list of other libre game engines on github.
1 Like
Update: the effort to switch to ue4 has basically fizzled out due to already getting very weird bugs (different behaviour on my computer than on crodnu’s) and it not being fully free and libre software.
So the current effort is in improving the engine with an engine written by me (https://bitbucket.org/hhyyrylainen/leviathan/src/7366e8d3951f51fb12ad6a16b9d09009fd3712f3/?at=develop). That, too uses Ogre and CEGUI making it very easy to replace the common parts in the thrive custom engine with it without completely breaking the gameplay code.
@crodnu is working on moving lots of the Lua things to C++, this way my porting job will be easier. And even if we decide to switch to some other engine it will be easier. There would still be lots of work in porting the thrive architecture and the parts that use Ogre to a new engine.
I also did try out Godot, but the way it needs you to structure your game is completely different compared to thrive so that, too would be tons of work to port.
The latest code is here: https://github.com/Revolutionary-Games/Thrive/tree/engine_refactor
Here’s a screenshot of the main menu in my engine (you might notice it looks exactly the same):
2 Likes
I finally got around to making the video player work with my engine (I took the version I wrote for ue4 and added it into my engine):
Next up I just need to hook the GUI buttons and I can start working on porting the components and systems.
2 Likes
Instead of working on new stuff I integrated continuous integration into my engine: https://circleci.com/bb/hhyyrylainen/leviathan/tree/master
I might have to switch to a different one if that works too slow, but there doesn’t seem to be any good solutions for c++ projects other than hosting jenkins on a vps
I’ve been distracted by doing really complicated server setup. Now I’ve got one webserver hosting 3 different websites and a jenkins continuous integration server building leviathan documentation. I was going to move the continuous integration that runs tests there too, but it looks like circleci has given my builds more cpu cores all of the sudden.
So now the leviathan documentation is viewable online (and it automatically is updated every time the repo is updated): https://leviathanengine.com/doc/develop/Documentation/html/index.html
I just noticed that there are some out of date build instructions etc. still in there.
1 Like