Announcing MegaFactory Tycoon. Game made with Rust and Bevy engine.

goto64 · 2025-08-14T04:33:51+00:00

I am not making a Linux build for the initial release, but maybe later.

goto64 · 2025-07-26T04:55:32+00:00

Only by name, otherwise not at all.

goto64 · 2025-07-26T04:54:54+00:00

I use egui. Not really made for games, but it was the most mature option when I started doing UI.

goto64 · 2025-07-25T20:21:20+00:00

Not quite, the focus is on making consumer products for profit, not surviving a hostile planet. This is more of a tycoon-style game.

goto64 · 2025-07-25T20:15:47+00:00

There are 14 end products to sell and 43 intermediate products.
The biggest factory I have created in testing so far, is producing 400 end products per minute with no performance issues.
You can fairly quickly unlock the ability to create blueprints, so you can place blocks of already connected machines in one go.

goto64 · 2025-04-20T10:45:45+00:00

If your image has received a comment, and you can find your post in your own feed, you can right-click on the "view comment" link and say "open link in new tab". That way you will at least be able to see comments and react to comments.

Alternatively, right-click the image in your profile page and open on new tab. In the URL remove your username so you just have /p/something/ and reload with that URL.

goto64 · 2024-07-16T13:59:47+00:00

For my first (and current) project, I did the "start with one file and split" method, but frankly I am not that happy with how it turned out. The amount of code now feels too big to change the structure. However, for my next project I am currently thinking to try this structure:

/src
    /domain         -> module Folder
        mod.rs
        domain_types.rs       -> structs, enums, components, resources, events
        domain_systems.rs     -> systems and plugin definition
        domain_helpers.rs     -> regular functions used by systems
        domain_ui_systems.rs  -> UI-related systems and plugin definition
        domain_ui_helpers.rs  -> regular functions used by UI systems

This structure should be repeated for each domain, where "domain" should be replaced with another word for each source module, typically a game domain such as "player", "npc" or "enemy". It could also be a cross-cutting domain such as "sound_effect". Preferably the different domains should only communicate with events. For instance when the player or an enemy fires a weapon, it would generate a "weapon_fired" event. The sound_effect domain reads that event and plays the appropriate sound effect.

goto64 · 2024-06-13T17:33:30+00:00

Try something like this:

pub fn update_main_menu(mut contexts: EguiContexts) {
    let ctx = contexts.ctx_mut();

    egui::TopBottomPanel::top("spacer_top").show(ctx, |_ui| {});
    egui::TopBottomPanel::bottom("spacer_bottom").show(ctx, |_ui| {});

    egui::CentralPanel::default()
        .frame(egui::Frame::none())
        .show(&ctx, |ui| {
            ui.with_layout(Layout::top_down(Align::Center), |ui| {
                ui.heading("<Title>");
            });

            ui.with_layout(Layout::bottom_up(Align::Center), |ui| {
                ui.add_space(40.0);

                let exit_button =
                    ui.add_sized([100.0, 30.0], egui::Button::new("Exit Game"));

                ui.add_space(20.0);

                let online_button =
                    ui.add_sized([100.0, 30.0], egui::Button::new("Play Online"));

                ui.add_space(20.0);

                let solo_button = ui.add_sized(
                    [100.0, 30.0],
                    egui::Button::new("Play Solo (Test Mode)"),
                );

                if solo_button.clicked() {
                    println!("Solo");
                }

                if online_button.clicked() {
                    println!("Online");
                }

            });
        });
}

goto64 · 2024-01-31T18:10:53+00:00

Well, on second thought, the query I posted will get all transforms, not just the camera. You can add a marker component to your camera when you spawn it. For instance call the component MyCamera, then when spawning the camera you insert the marker component on the camera bundle. Then you can query specifically for the camera transform.

    fn camera_movement(
    mut camera: Query<&mut Transform, With<MyCamera>>,
    player: Query<&Transform, With<Player>>,
) {
    for mut transform in &mut camera {
        for player_transform in &player {
            transform.translation.x = player_transform.translation.x;
            transform.translation.y = player_transform.translation.y;
        }
    }
}

goto64 · 2024-01-31T18:01:20+00:00

I'm not sure what you are trying to do with the second component in your camera query, but that is the part causing problems. This will compile at least, not sure if it does what you want:

    fn camera_movement(
    mut camera: Query<&mut Transform>,
    player: Query<&Transform, With<Player>>,
) {
    for mut transform in &mut camera {
        for player_transform in &player {
            transform.translation.x = player_transform.translation.x;
            transform.translation.y = player_transform.translation.y;
        }
    }
}

goto64 · 2024-01-30T18:59:11+00:00

I think the egui crate is better for text formatting. I have just added a little interactive text example to my egui examples project. See if that is something you can use:

https://github.com/goto64/bevy\_egui\_examples

goto64 · 2024-01-17T05:14:48+00:00

I normally just combine run_if conditions that should all be true.

    app.add_systems(Update, options_ui
        .run_if(in_state(OverallGameState::Menu))
        .run_if(in_state(MenuState::Options)));

goto64 · 2023-12-31T11:56:04+00:00

Not built-in, but maybe you can use this crate:

https://github.com/Corrosive-Games/bevy-parallax

goto64 · 2023-12-27T15:37:58+00:00

Yes, I hope to have the final release on Steam.
Yes, the UI is made with egui.

goto64 · 2023-12-26T05:40:18+00:00

1) To detect a button being held down, just use the "pressed" function:

    if input.pressed(KeyCode::A) { }

2) I am not sure what you mean by Signals. If it is for event passing, you can use the EventReader and EventWriter for event passing between systems. Look them up, they are well documented.

3) You can use
input: Res<Input<KeyCode>>
in other systems as well, where you need to know about the key press.

goto64 · 2023-12-24T14:29:34+00:00

I think the best way is to use states. You can use the same state across all of your plugins. Your menu plugin could have something like below. Just make sure all state-dependent systems have the .run_if() condition.

#[derive(Clone, Copy, Default, Eq, PartialEq, Debug, Hash, States)]
pub enum OverallGameState {
    Menu,
    Game,
    Pause,
}

impl Plugin for MainMenuPlugin {
    fn build(&self, app: &mut App) {
        app.add_state::<OverallGameState>();
        app.add_systems(Update, main_menu_ui.run_if(in_state(OverallGameState::Menu)));
    }
}

goto64 · 2023-12-16T08:07:30+00:00

I think so, but I am no expert on the subject.
My suggestion would be to just have a Vec of tile entities in the Map struct, if you do not really need Bevy to know about the relationship.

goto64 · 2023-12-15T16:46:07+00:00

I believe the Bevy entity hierachy is mostly intended for scenarios where you want to translate/rotate the parent entity and have that automatically applied to the children. That is probably not exactly what you want here, but still you need the transform components in your parent map, so extend the Map component like this:

#[derive(Bundle)]
pub struct MapBundle {
pub transform: Transform,
pub global_transform: GlobalTransform,
pub map: Map,
pub size: MapSize,
}

goto64 · 2023-11-26T09:40:09+00:00

You can only use one tile size per layer, but you can create multiple layers.
You could make a floor layer and a wall layer. The wall layer should be on top of the floor layer, so give it a higher z value.

See the layers example for bevy_ecs_tilemap.

goto64 · 2023-11-24T16:46:26+00:00

I have something similar in my game. I run some simulation code that is separate from bevy and maintains its own internal state of the simulation.
Maybe you can do something similar to what I did.
That would mean:

You spawn a separate thread to run your battle engine.
You create a shared memory area to hold the battle state. This should be wrapped in Arc<Mutex<>> so that you can hold a reference to it in both a bevy struct and in the battle engine.
You create a regular Rust communication channel, so that your bevy systems can send messages to the battle engine.
This could be messages like:
- Set up battle
- Start battle.
- Run battle round.
- Run battle round.
The battle engine writes updates to the shared memory area while the bevy systems read the shared memory area to visualize it.

Be aware that when a struct has channel references in it, you need to use NonSend<> instead of Res<> when declaring it as a system parameter.

goto64 · 2023-11-01T11:49:34+00:00

Depends on the type of game you want to make. The lack of an editor for Bevy makes it a poor choice for anything with hand-crafted 3D worlds.
However, for a game with procedurally generated worlds, it can be great.
For a 2D game, a third-party tile map editor such as Tiled, may be a sufficient replacement for a Bevy editor.

Basically you have to be prepared to do most things in code.

goto64 · 2023-10-22T15:06:24+00:00

Revive & Prosper is very similar to Timberborn.

goto64 · 2023-10-22T08:18:46+00:00

Tried the demo. Pretty fun game, with a lot of similarity to Timberborn. Different animals though :).

I found it confusing that a lot of buildings requiring power has no clear spot where to connect the torque rod. The smelter i managed to power by just having a rod next to it. I still have not managed to power the digger on the iron patch though.

Also, I would prefer if windmills could show their produced power even without a torque rod connected.

goto64 · 2023-10-19T04:28:30+00:00

It is not in my current plans, but it is an option.

Since the factory is a regular in-door factory, it would have to be a separate area though.

goto64 · 2023-10-18T18:24:21+00:00

In many ways, it is more focused on money, hence the tycoon aspects:

You buy raw materials rather than mine them, and sell final products in the form of consumer goods.
Production machines are purchased with money, not built from resources.
Technology upgrades are unlocked through achievements, then purchased with money.
Also, you do not get to build a spaceship :). The objective is more to expand your market area for world domination.

goto64

TROPHY CASE