Engine Hopping

As we mentioned before, we were planning to use the Armory3d game engine to build our game. This seemed like a great choice because it checked all our boxes for what we wanted out of a game engine and had a lot of extra going for it such as being able to basically use Blender as its editor. We knew going in we might hit some snags since it is not a production ready engine. We did not foresee it being so difficult just to get a project set up.

The asset pipeline in a typical game engine is not exactly fun but they usually have it worked out pretty well. Often it will be a plugin for your art tool that exports to a format that the engine understands and you work out some details, export, then import in your engine.

armory-blender-screenshot.png

With Armory we thought this was going to be great since our engine was in our art tool. So after playing around with a scene for testing over the last few months we decided it was time to actually start our project. In Blender you can link blend file elements to your current scene. This is how big productions often keep things separate and different artists can work on their own assets without having to worry about the entire project. This is great! No exporting/importing required, just linking. So in our case we created a game blend file then linked our Eddy character. Which showed up in Blender just fine. So we thought it was going to be smooth sailing, until we tried to build our scene in Armory. From this point on we spent a week trying to figure out the proper way to do it and/or a different way. Constantly getting errors.

Blender is currently replacing a lot of the linking system with new improvements and Armory is still using the old systems. Not 100% sure if this is the cause of the problems but either way... it has set us back a lot. Like mentioned earlier we knew there would be problems but didn't expect it to be this early and this big.

So the last few days have been split between trying new ways to stick with Armory and looking at other engines.

We did a good deal of engine scouting before we chose Armory so a lot of it was just revisiting the others we were interested in at the time with the addition of Unreal as our ultimate fallback. The list contained a dozen or so engines but ultimately has been narrowed down to about 5 possibilities, some more likely than others.

Armory is still very much in the mix. If we can somehow get our project set up and organized in a way we can all work on it and things start moving forward, it is still our #1 choice.

In addition to Armory we've decided to look into 2 more engines that come with full tool suites (i.e. an editor.) Godot and Unreal. But we also decided to revisit some other options we were considering when the game was just going to be 2D. Heaps and Raylib. Why? The idea of being able to fully control our project organization is a big plus to us and Heaps brings a lot to the table and has proven success that no other engine on our list has (except Unreal.) Raylib is just a really cool project we like. We even considered starting with inspiration from Raylib and building our own C based engine a few times but that brings up our next point.

It is very difficult to pick a route between 'least resistance' and 'most freedom' and picking a game engine is the ultimate example of this. We could jump straight to Unreal and have all the power of a AAA engine and years of learning materials at our fingertips. If we cannot build the game we envision with Unreal it is our own fault not the engine's. This is the path of least resistance for sure. But it is also not flawless. We primarily develop on Linux right now and research suggests this is not at all stable (even if somewhat possible) using Unreal. So we'd have to set up Windows dev environments. There is also still a learning curve with Unreal. It is a giant toolset after all. So while it is the most likely to succeed it is not without problems and has some other drawbacks. Like not being FOSS. Not being technically free (though we don't expect to make over a million dollars so this is not a huge concern.)

godot-screenshot.png

Godot is a compromise here. We can get a lot of what we want from Godot. The VCS friendly project structure isn't perfect but it is quite nice. The editor isn't super flashy or robust but it has a lot of very helpful utility. Who really wants to learn GDScript? Not us... but it is simple enough that it wouldn't be a big deal. It has also grown big time over the last few years with many helpful resources to speed up development. So this may not be the least resistance possible but it seems like a relatively easy time to get going with. In fact, we have already set up a project and exported/imported our character without much issue. Playing around building a 3rd person controller as well. Has been a couple days now and it isn't bad. Of course Unreal offers this experience too. But Godot does so with a less complicated toolset and still checks the free and open source boxes we like. So not perfect but seems like a good 2nd choice if we cannot get going in Armory.

heaps-dev-screenshot.png

The most freedom route has also been kind of interesting. Heaps our first choice for 2D is actually a 3D engine as well. In fact the creator mostly seems to make 3D games with it. So we set up a quick project based on one of the examples and loaded our model in. This has been both a good and bad experience though. It was nice being able to quickly set up a dev environment without worrying about a giant install or editor or having to learn new tools. We are able to load Eddy as well but that's where we get lost. The documentation is not good and the community heavily focuses on 2D so even trying to understand the material system has been a bit rough. We didn't actually try out Raylib at all. Not sure if we will or not. In the end we really want to make more progress and struggling through "spartan style" programming may not be the best choice for our project. The reason we chose Armory over Heaps in the first place was because this is our first 3D game and having that editor feels invaluable so far.

This has been a long, probably somewhat difficult to read post. So if you made this far, Kudos!

If you have opinions or suggestions feel free to let us know in the comments!

As of now we are still undecided and hopping between Armory and Godot mostly, with a little effort on Heaps and the fallback plan of Unreal.

We are hoping to do a follow up post in the near future with a decision. So follow/subscribe if you are curious where we might end up!

Sort:  

I hope you succeed with your engine hopping. I encourage you to stick with Godot a bit more, not because it's a good development tool now, but because it's FOSS status and the increasingly dedicated development team will ensure that it'll get better and better in the next few years.

While it'll never reach the big players, it may be the best option for Open Source GameDev...

Thanks for the encouragement! We do like Godot a decent amount and a lot of the reason is because of it being FOSS. It definitely has a bright future, 4.0 is sounding better every day.

It is quite capable as well. I think a lot of people assume it is not because it gets a little flack from people that tried an old version, are not capable of understanding it, or are committed to something else already, especially in the 3D department. Not that it is perfect or anything. But as an example we stumbled across this gem of a project in our research. Kmitt 91 - Sandfire and even looking past it being a solo dev over about 6 months, which makes it even more amazing, some of what has been done there is AAA quality (at least in our opinion.)

We're discussing the choices more today. Godot is definitely a finalist. But it also has some drawbacks we are not fond of, sadly.

So many amazing and fun-looking game engines out their days to mess around with.

I’ve been tempted to start a couple of small side projects and trying out a few different one. Just to satisfy my curiosity about what is out there.

There really are some incredible options. And more just keep popping up. Sadly sooo many are in a non-production ready state though. And most that are ready are severely lacking in documentation.

Always fun to play around and try to learn though.

Congratulations @chibititan! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s) :

You received more than 10 HP as payout for your posts and comments.
Your next payout target is 50 HP.
The unit is Hive Power equivalent because your rewards can be split into HP and HBD

You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word STOP

Check out the last post from @hivebuzz:

Hive Tour Update - Governance
Support the HiveBuzz project. Vote for our proposal!