• 327 Posts
  • 400 Comments
Joined 4 years ago
cake
Cake day: November 18th, 2021

help-circle





































  • As a matter of fact, I did!

    Godot was even my first choice originally. It’s compact, FOSS, and easy to use. I had a good experience with it and even contributed a few times. But I didn’t end up using it:

    • It’s not ECS-based. They even have an article explaining why. But for a game like this, we need to process a lot of objects to simulate a city (I want cities to be similar to Sims 3), so we benefit from a data-driven approach. Also after actually using ECS, I think I disagree with some points from the article: I found ECS much more natural to work with.
    • It’s not very extensible. Even with GDExtension (a low-level C API), in order to integrate a C or C++ library I have to adapt it. It’s so much more seamless with Rust.
    • GDScript is easy to use and well-integrated, but slow. C# is faster, but the support is worse and I don’t like the language 😅 There also bindings for other languages via GDExtension. Even their C++ API are implemented this way: C++ engine code wrapped into C and then wrapped again into C++. But working with bindings is never the best API experience. Also, after using Bevy for a while, I really appreciated that when something goes wrong, I can directly jump into the engine code and see what’s happening. I’m, of course, planning to provide a scripting API, but using the same language for writing the core stuff is so convenient. I’m basically writing an engine for an engine 🙂
    • I disagree with some of the developers choices. For example, I dislike how they parse the CLI in main.cpp - it’s just messy. A long time ago, I implemented a CLI parser in C++ with a GDScript API for users and suggested reusing it in the engine, but they didn’t end up merging it and said that the current state was fine.

    I also considered Unreal Engine. It’s highly optimized, packed with features, and provides tools for massive simulations. But I also didn’t end up using it:

    • It’s incredibly heavy. Compiling it from source takes hours.
    • Linux support is not great. The editor runs, but poorly. All the Unreal games I know are available only for Windows. Almost all developers also use Windows.
    • The main language is C++, which matches the engine language, but iteration times are awful due to the engine size. It’s game development workflow clearly designed around Blueprints. They’re convenient to use but hard to refactor, and they’re stored in binary format because the engine is designed to use with Perforce VCS. I prefer Git, and even a small change in a Blueprint results in a full file replacement.
    • They don’t allow you to license your game under a copyleft license, which is the kind of license I’d like to use for my project.

    Don’t get me wrong - both mentioned engines are great. I just didn’t mentioned all their advantages and all disadvantages of Bevy. But for this specific project, I found Bevy to be a better fit 🙂



  • Yeah, I’ll definitely try to scale it down as much as possible!

    Right now I considering using a mesh with morphs just to provide a proper API for character customization. I don’t expect this particular part to be that hard. The mentioned MakeHuman is FOSS, so I could use it as a reference.

    I also don’t think it will be incredibly generic. It’ll be focused on life simulation, so it wouldn’t be a good choice for something like an RPG. This lets me scale the project down even further — and a narrower API will be simpler as well.