this post was submitted on 01 Aug 2025
18 points (100.0% liked)

Project Harmonia

97 readers
1 users here now

A work-in-progress life simulation game.

GitHub

founded 2 years ago
MODERATORS
 

Background

For those who don't know, I'm trying to create a FOSS life simulation game — something similar to The Sims.

I haven't posted updates in !projectharmonia@lemmy.ml about the project for a while, only updates to the related crates I maintain. It's just me and my wife didn't have enough motivation to work on it. Mainly because of the overwhelming amount of things we need to make - both assets and code.

Lifesims Are Hard

A life simulation game needs at least one customizable character mesh (which is a huge project on its own), a lot of clothes, animations, textures, and world objects. And coding it isn't easy either — it's basically like making 3 games:

  1. Life simulation.
  2. Building mode.
  3. Character creation. It's probably the smallest part, but still quite complex.

Plus, I'm using Bevy, which is a great engine but still quite immature. This means I have to implement many things myself, even basic features like UI widgets. Some of my work is available as standalone crates: bevy_replicon, bevy_replicon_renet and bevy_enhanced_input. On the bright side, people seem to like them — the input crate is even planned for upstreaming into Bevy. But this also takes time and distracts me from the game.

I guess that's why we don't have many life simulation games — they're quite hard to create even for big companies. For example, Life By You from Paradox got cancelled.

So, is it an impossible task for hobbyists? It would be a shame, because I recently asked which game people would most like to see a FOSS alternative for, and most people voted for The Sims.

A Different Approach

At first, I considered switching to creating a reimplementation that requires the original game assets, like OpenMW or OpenLara. But it's even harder to implement and for me it's not as fun as creating something from scratch. So I continued thinking.

When I created bevy_replicon, it originally used bevy_renet under the hood. But it’s not actively maintained, so after each Bevy release, I had to wait a while for it to be updated. Instead of switching to another messaging library, I decided to abstract the messaging layer completely and move the renet-specific logic into a separate crate called bevy_replicon_renet. I documented the API, and people started creating their own integrations. I decided to embrace this strategy by keeping the crate minimalistic but extensible. Now we have a small ecosystem of crates. I think it's great because more people are getting involved and I have less to maintain.

There also games like Garry's Mod and Luanti (formerly Minetest). They are basically empty by default and players just install mods that add mechanics, objects, story, etc., all made by the community.

All of this got me thinking: why not create a project like this, but in the life simulation genre? From the game menu, players could download character models, clothes, objects, scripts, etc., created by passionate modders. To avoid downloading each mod individually, I could provide mod lists for one‑click installation. This will significantly reduce the scope of the game. Also, I enjoy creating APIs: even when I lost motivation to work on the game itself, I still actively developed the crates. So developing a game like this should be similar.

I even came up with a name — SimGine, short for "simulation engine."

During development, I can test things on free assets wrapping them as mods. For example, I can use character meshes and clothes from the awesome MakeHuman. But this could be anything, even a loader for CCs originally made for The Sims games.

As for the game engine, I still think that Bevy is the right choice:

  • It uses ECS, which is perfect for parallel simulation of many entities.
  • It's incredebly flexible and modular, kinda in the spirit of the game.
  • It's just fun to use for me. When you making a game as a hobby - it's very important, otherwise I'll lose my motivation.

I mentioned that the engine is still immature, but we're getting there. The upcoming 0.17 release will feature hot reloading and finally adds built-in widgets. Plus, the crates I already made are close to feature-completion.

Project Plans

Right now, I'm planning to wait for the release of Bevy 0.17 and, in the meantime, add a few important features to bevy_replicon. After that, I think I'll start working on the game. I'll also start from scratch, since we'll need a different architecture — though I'll borrow some of the old code. And this time, I'll start from the character creator. It's a smaller part, and if I fail with the rest, at least we'll still have a cool app for creating digital avatars 😅

Not looking for any collaborators or mod developers yet — I need to create an MVP first. I expect this will take a quite some time. But I would like to hear your opinions about the idea in general.

top 4 comments
sorted by: hot top controversial new old
[–] vala@lemmy.dbzer0.com 2 points 1 day ago* (last edited 1 day ago) (1 children)

Don't take this the wrong way but have you considered using a different stack? I know rust is cool and everything but it's far from the industry standard for game dev.

Honestly I would really consider using Godot since it's not only going to handle a lot more "game engine" stuff, it will also let you lean on the existing tools made by the community and probably increase your chances of getting direct help as well.

No reason that rust can't be a good Lang for game dev but as you mentioned, the whole ecosystem is a bit immature in terms of game dev.

[–] Shatur@lemmy.ml 1 points 5 hours ago

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 🙂

[–] strahlemann@feddit.org 4 points 1 week ago (1 children)

sounds great, do you plan to use lua for scripts?

[–] Shatur@lemmy.ml 3 points 1 week ago

Yes! I like Lua and even wrote a few plugins for Neovim with it 🙂